Audit Category Gate Coverage¶

The codebase audit (/codebase-audit, ~159 agents) finds the FIRST instance of a problem category in the codebase. Every subsequent occurrence should be blocked at CI by a standing gate, not re-discovered by a follow-up audit run. This document classifies audit categories by their resolution path so contributors and reviewers know whether to expect a gate to catch a violation, or whether a category still relies on review-time judgment.

The four resolution paths are:

• Standing gate: a scripts/check_*.py / pre-commit hook / hookify rule that fails CI on the second occurrence of the category.
• Pre-PR mini-pass (/pre-pr-review Phase 3.5): a high-recurrence audit agent rerun on every PR diff. Catches the violation at PR time without a full audit.
• Architecture decision: the category is made unrepresentable by the type system, package layout, or boundary contract. Examples: persistence boundary forbids aiosqlite imports outside src/synthorg/persistence/; cost-recording chokepoint forbids LLM calls outside BaseCompletionProvider.
• Reviewer-enforced: no automated gate; relied on the worktree spawning prompt's "Do-not-introduce" block (.claude/skills/worktree/SKILL.md) and on the audit re-running periodically.

Classification¶

Audit-verdict tiers¶

The Classification table above follows one shape: an audit finds the first instance of a category, and a standing gate catches every recurrence. The complex_service module-size tier inverts that shape, so it is documented here rather than as a table row.

The #2052 cohesion audit reads each oversized file end-to-end and issues a verdict. A file confirmed as one cohesive responsibility that legitimately exceeds the standard service / adapter caps is tagged # module-kind: complex_service (cap 1100), and scripts/check_module_size_budget.py then enforces the 1100 ceiling against it like any other tier. The audit assigns the tier; the gate accepts the verdict. A table row would misrepresent this as a recurrence the gate discovers, when in fact the gate is honouring a judgment the audit already made.

complex_service is reserved for audit verdicts. It is not a free opt-in for new code: new service, adapter, and controller files still hit their strict caps (600 / 700 / 400), and an over-cap new file is fixed by improving its cohesion or shrinking it, not by tagging it complex_service. See ADR-0006 ("Complex-service tier") for the full rule.

Out of scope here¶

• The full walk-all-31-waves audit-the-audit retrofit (Lever 5 of #1740 in its broadest reading) is deliberately deferred: this document captures the gate inventory as it stands. New gate additions land in their own PRs and update this document at the same time, per the Convention Rollout rule in CLAUDE.md.
• Categories that are pure-judgment (e.g. "code is hard to read") are intentionally absent: there is no useful automation for them and the four resolution paths above are exhaustive for everything that has a mechanical signature.

Maintenance¶

When a new gate lands:

1. Move its row from "Reviewer-enforced (gate planned)" to "Standing gate".
2. Update CLAUDE.md "Convention Rollout (MANDATORY)" section's existing inventory list.
3. Close the tracking issue.

When the audit roster grows or shrinks (new agent in .claude/skills/codebase-audit/SKILL.md, retired agent in the "Retired Agents" table there), revisit the corresponding row here.