[!CAUTION] Content needs proof-reading.

🧭 Key Concepts to Explain to Forkers of the WatchfulAnvil Monorepo

1. Monorepo Structure and Purpose

• The repo contains multiple custom rule sets, each in its own isolated project.
• Projects are grouped under:
  • src/ → source rule libraries
  • tests/ → corresponding test projects
• A single Visual Studio solution (.sln) binds all rule projects and test projects.

2. How Rules Are Organized

• Each rule set lives in its own folder: src/YourOrg.YourRuleSetName.WorkflowAnalyzerRules/
• Each rule set includes:
  • Rules/ → All rules in that set
  • RegisterAnalyzerConfiguration.cs → Entry point to register rules
  • lib-deps/ → Local copies of required UiPath DLLs

3. Test Project Convention

• Each rule project has a matching test project in tests/, named YourRuleSetName.WorkflowAnalyzerRules.Tests.
• Tests use xUnit and Moq.
• Test projects are already wired into the solution and reference their corresponding rule project.
• Tests are stubs as of now and contain no adequate coverage.

4. Templates and Automation

• A reusable project template lives in templates/workflow-analyzer-rule/
• The script tools/setup-project.ps1 creates:
  • A new rule project and test project
  • Standard files populated with org name, namespace, rule prefix
  • Adds everything to the solution
• This is the preferred way to add a new ruleset.

5. Rule IDs and Prefixes

• Each organization uses a prefix for rule IDs (e.g., CPM, HWD, ACME)
• Rule IDs must be globally unique across the repo
• The prefix is part of the script input and is not auto-validated for conflicts — this is a manual responsibility

6. Build and Versioning

• Projects are multi-targeted to support various UiPath Studio versions and project types:

  • net461 — required for compatibility with:
    • Studio 2021.4 and earlier
    • Windows-legacy projects in later versions
  • net6.0, net8.0 — targets for:
    • Studio 2021.10.6 and later
    • Windows (.NET 6+) and cross-platform projects

• The .csproj template uses conditional package references to apply the correct version of UiPath.Activities.Api for each target.

[!NOTE] 💡 Why the Monorepo Is Structured This Way

The repository is designed to make it easy for contributors to create and maintain independent rule sets. Each ruleset lives in its own project directory under src/, with a matching test project under tests/.

This structure enables the following:

• Fork-friendly development: A user can fork the repo, generate a new ruleset using the provided script, and work in isolation.
• Simple contribution workflow: When ready, the contributor can open a pull request to add their ruleset back into the main repo.
• No impact on existing rulesets: Since each ruleset is self-contained, contributors don’t need to modify shared code or touch unrelated projects.
• CI support out of the box: The existing GitHub Actions setup builds and tests all rule projects and their test suites automatically.

This approach keeps the repo scalable, modular, and welcoming to new contributors.