Rules overview

AppArch’s rule catalog defines what counts as “good architecture” in your codebase. This section documents every rule by programming language and category - with bad/good code examples.

How the rule list is delivered

Rules are pulled by the running collector (runner) at startup from the /api/v1/runner/rules endpoint. The list is:

Filtered by language - a Python collector only receives python.* rules, never the .NET ones. The one exception is the configuration rules (config.*, below), which every collector receives.
Override-aware - rules you disable per project or workspace in the panel are never sent to the collector, so disabled rules produce no findings.

Every rule carries a code (ARCH302), a key (dotnet.security.sql-injection), a category, a severity and (for security rules) a CWE id.

How findings and comments are produced

The runner scans the changed code in your own CI against the rule set.
Each matching rule produces a finding (file + line + rationale).
ArchPilot posts it as an inline comment on the PR/MR. Comments are marker-keyed: the same finding isn’t re-posted on each push, and fixed violations auto-resolve.
Manage false positives with except/ignore, or “Accept” with one click from the comment.

See Enabling ArchPilot and Writing rules.

Microsoft rules and your own build settings (.NET)

The CA, IDE, CS and ASP rules are Microsoft’s own analyzers, run by the collector at the catalog’s severity - the .NET SDK’s default analysis level, which switches most of them off, does not apply. What your team decided in the repository does:

#pragma warning disable CA1806 and [SuppressMessage] in the source.
A rule’s own entry at none in a .editorconfig or .globalconfig inside the repository, for the files its section covers: dotnet_diagnostic.CA1806.severity = none. Other severities (suggestion, silent) and category or blanket switches (dotnet_analyzer_diagnostic.category-Performance.severity) do not turn a rule off.
<NoWarn> in the project file or Directory.Build.props that builds the file.

The collector’s log names every rule switched off this way and how many findings it held back. To turn a rule off for a whole project or workspace without touching the repository, use the rule settings in the panel.

Configuration files

Dockerfiles, docker compose files, Kubernetes manifests, GitHub Actions workflows and GitLab CI definitions are checked by one checker that every collector image carries, so a repository in any language gets the same answers. Its rules (ARCH10001-ARCH10033, keys config.*) are listed under Configuration files. Their findings are ordinary findings: they count in the ArchScan score, the security ones (with a CWE) reach ArchSecurity, and ArchPilot comments on them in merge requests. Switch them on and off in the rule settings like any other rule; the scan scope’s excluded paths apply to them too.

The checker only reads files. It never runs anything from your repository - no image build, no helm template - so Helm templates are skipped rather than guessed at.

Severities

Level	Meaning
error	Serious violation; may block the merge.
warning	Issue you should fix.
info	Informational / style suggestion.