feat(augmentcode): add a checks adapter for code_review_guidelines.yaml

[dyoshikawa]

Closes #2420.

Gaps 1, 2 and 4 of that issue (the PromptSubmit hook event, handler args / matcher-group metadata, and the .agents/commands/ import root) landed in #2444. Gap 3 — the .augment/code_review_guidelines.yaml checks adapter — was the sole open item, and this is it.

What Augment reads

Augment Code Review reads one YAML file at the repository root's .augment/, grouping rules into named areas:

areas:
  databases:
    description: "Data and Database related rules"
    globs: ["**"]
    rules:
      - id: "no_pii_in_bigquery"
        description: "Never store PII data in BigQuery tables."
        severity: "high"

Every field shown is required — area description/globs/rules, and per-rule id/description/severity. A top-level file_paths_to_ignore takes doublestar globs.

Mapping

One .rulesync/checks/*.md becomes one rule. The body is the rule's description (the check's description when the body is empty, the file stem when neither is set); the rule lands in an area keyed by the check's file stem. An augmentcode frontmatter block moves it: area groups several checks under one key, with areaDescription and globs coming from the first check to name that area (globs defaults to ["**"], matching Augment's example), and id overrides the rule id.

Like Cursor Bugbot, Rovo Dev and Takt, the whole set collapses into one file via fromRulesyncChecks rather than a file per check. Registered project-scope only with committedOutput: true — the reviewer reads the file from the committed tree, and Augment documents no user-level equivalent.

Severity mapping (an Augment-only call)

Canonical critical maps to high. Augment's scale is high / medium / low with no band above high, so the alternatives were dropping the rule or demoting it to medium — either losing the check or understating the one severity a reviewer most wants raised. The fold is one-way: a critical check generates high and imports back as high, so the canonical value is not recoverable from Augment's file alone. A test asserts that asymmetry explicitly rather than leaving it implied.

A check with no severity emits medium, since the field cannot be omitted: high would push every unannotated check past the ones deliberately marked medium, and low would bury them.

Documented in the adapter docstring and in docs/reference/file-formats.md. Note this is the same severity-scale question shared with #2399/#2404; nothing here presumes an answer for those.

Preservation, and what it costs

Augment's docs tell users to hand-write this file, so generation merges instead of replacing: only areas the current check set claims are rewritten, and every other area, file_paths_to_ignore, and any key Augment adds later survive untouched. file_paths_to_ignore is recognized and preserved but never authored or imported — the canonical check model has no ignore surface, and adding one is a separate design question the issue does not propose.

The honest cost, stated in the docstring and docs rather than hidden: rulesync cannot tell its own leftovers from a hand-written area. Renaming a check strands the area under the old key, and when checks remain but none target AugmentCode the areas are left in place with a warning rather than guessed at. canDeleteAuxiliaryFiles therefore returns false whenever the file exists — unlike the Markdown surfaces, YAML has no marker to distinguish generated content, since a rewrite drops comments and an unknown top-level key would risk Augment's own parser.

Import

Each rule becomes its own check (an area of three rules is three checks, not one), carrying the area key, description and globs back in its augmentcode block so the next generate regroups them exactly where they were. A test round-trips a hand-written two-rule area to a byte-equivalent document. A rule missing id or description is left in the YAML rather than imported, and a rule id repeated across two areas is suffixed so the second check cannot overwrite the first.

Tests

augmentcode-check.test.ts (19 cases) covers generation, area grouping, both severity behaviors, preservation vs. claimed-key rewrite, the no-targets warning, the deletion guard, and the import/round-trip paths. src/e2e/e2e-checks.spec.ts gains the matrix case, and checks-processor.test.ts picks up the new target. Tables regenerated via pnpm run generate:tables.

pnpm cicheck green; npx vitest run --config vitest.e2e.config.ts src/e2e/e2e-checks.spec.ts green.

🤖 Generated with Claude Code