fix(audit): a generator-owned instruction pair is not mirror drift

[jaruesink]

Mirror Sync Health fails on drifted > 0, and one of saffron's three drifted families was budgets — whose AGENTS.md and CLAUDE.md are both generated by rulesync from one .rulesync/ source.

AGENTS.md carries a TOON index of the path-scoped rules that CLAUDE.md doesn't need, because Claude reads those through .claude/rules instead. One source, two tool-appropriate outputs — not two copies that fell out of sync.

The fix

MirrorConfig now records whether a generator declares it owns both surfaces, detected from rulesync.jsonc/.json in either the array or object targets shape. A drifted instruction family whose directory has such a config counts as healthy.

Resolved per family directory, not at the scan root. My first attempt checked only the root and changed nothing — in a repo-of-clones every generator config lives inside a nested repo (budgets' config is at projects/budgets/, not at the scanned saffron root). That distinction is the whole fix.

Result

drifted 3 → 2, healthy 19 → 20.

The remaining two are real and Stage A should keep failing on them: forge/docs-site and openclaw-forge/docs-site give Claude 479 lines of rules through ai-rules imports while giving Codex 64 lines of Atlas docs. Different guidance per tool, both sides genuine. That's a repo fix, not a scoring one.

Tests

Four in audit-scoping.test.ts: both config shapes detected, comments tolerated, false when only one surface is targeted (360training targets claudecode+cursor, so its pair differing is real drift), and false on a missing or unparseable config. Suite 379 pass, plus the 2 known npm-on-PATH failures.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 31 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 21016bd7-68fe-4c76-ab33-58ef5023eeb3

📥 Commits

Reviewing files that changed from the base of the PR and between 765f8e7 and 3a6fca5.

📒 Files selected for processing (2)

• scripts/audit-scoping.test.ts
• scripts/audit.ts

---

_{Comment @coderabbitai help to get the list of available commands.}