fix(playbook): a repo gotcha an auditor cannot see does not exist

[stranske]

Found live during a repo-audit run of stranske/Trend_Model_Project. Three defects in repo_knowledge, all of which made the playbook worse than silent — a review consult got 308 characters, and the summary in them was false.

1. The summary was factually wrong

It read "Trend opener work cuts from phase-3, not the default branch" while phase-3 is that repo's default branch, so a reader went looking for a main that does not exist.

Checked every other seeded summary against live state: the rest are main and make no branch claim; Counter_Risk's Black gate and the LMS Postgres claim both hold. But the Trend lint gotcha was wrong in the same direction — pr-00-gate.yml gates black --check --line-length 100 alongside ruff check, so "CI convention is ruff check" omitted the actual format gate. Both corrected.

The same wrong belief lived in provision.py's comment, beside the literal "phase-3" the registry was duplicating. The SEED now reads provision.BASE_BRANCH_OVERRIDES rather than repeating the branch name — a matching pair of literals can drift, one name cannot — with a selftest that fails if they ever disagree.

2. Every seeded invariant was task_type-scoped

consult	before	after
review / audit / ux / None	308	2411
testgen	404	2411
implement	627	2411

The lint convention, the base branch and the owner direction were all filed under someone else's task_type. Adding review/audit to each list would just drift on the next task type, so the rule is now: task_types/lanes mean "only matters while doing that kind of work"; a repo invariant carries none. The base branch is no longer gated on lane == "opener" either — in the prompt, the AGENTS.md export, or memory search.

scope_audit() reports both numbers in one place: 3 scoped, 0 invariant reads differently from 3 scoped, 3 invariant. --audit-scopes exits non-zero on the second, and the selftest fails if a seeded invariant is re-scoped.

3. The highest-value gotcha was absent, and the advisor contradicted it

frontend-verifier is bound for this repo at two surfaces while the repo's own audit record says frontend_verify.py snapshots its Streamlit SPA before the websocket render completes. repo-playbook — the capability whose whole job is per-repo gotchas — was offered in the same response and did not carry it.

New typed contraindications section ({capability, reason, instead, evidence}), rendered in the playbook and read by capability_advisor.advise(repository=…) on both answer paths, including the classification-miss path a free-text audit consult actually lands on. Reproducing the original consult:

confidence: binding_only
contraindicated: ['frontend-verifier']
  offload, partitioned-review, role-decomposer, repo-playbook   (bound)
  frontend-verifier | contra True
      reason: snapshots this Streamlit SPA before the websocket render completes
      instead: Drive a real browser, or execute the real functions.

It annotates and de-ranks; it never conceals — a concealed candidate can never earn the evidence that would clear it, the same reason binding does not conceal. Repo-scoped rather than surface-scoped on purpose: a surface demotion would unbind the capability for every other repo.

Dedup finding (recorded in the repo-playbook ledger notes, not only here)

• contraindicat|not_recommended|discourag|denylist|blocklist → zero hits, so the contraindication is genuinely new.
• suggest_from_docs already reads an arbitrary root plus an explicit --repo, so it can mine an out-of-tree audit README — verified by running it before writing anything. Extended, not rebuilt: it split wrapped bullets at the physical newline (candidates starting mid-sentence) and had no section scoping, so round-history prose arrived as durable repo knowledge. _doc_blocks + sections= fix both.
• A named section now implies the signal filter, because the single most valuable note in the real README carries no must/should/never token and would otherwise have been dropped on the floor.

Ran the ingestion across all 12 Code/Audits/<repo>/README.md: only Trend has a "Standing notes for the next round" section (21 candidates). Four were verified against phase-3 and seeded. The section also asserts "CI gates ruff check only", which is false — so these notes stay a review queue, not a source of truth.

Why a schema migration

The SEED is only written when the registry file is absent, so a code-only fix would leave every running instance still reading the wrong line. Hence schema v2 plus a load() migration: exact-match text correction, seeded items and their scope reasserted, instance-added entries never touched, idempotent, and best-effort on write so a read-only volume cannot stop prompts being built. save() is now write-then-rename, because load() now writes on read and append_context reaches it on every dispatch.

Verified against a copy of the real registry: Trend corrected to 7 unscoped gotchas + 1 contraindication, and Workflows' two instance-added scoped items kept their scope untouched.

Verification

Selftests green across repo_knowledge / capability_advisor / capabilities, each new behaviour carrying a deliberate-break→revert case.

verify.py: 365 passed, 368 collected (unchanged from baseline), 82/82 selftest modules, 0 skips.

The 3 pytest failures and 2 red gates are pre-existing and reproduce with this change stashed. All three are the single ledger row evidence-acquisition, registered 2026-08-22 against evidence_acquisition.py:run — a module that does not exist in this tree. Untouched here; being handled separately.

Downstream consequence

stranske/Workflows is the only fleet repo with a committed managed orch-playbook block in its AGENTS.md. Unscoping the two seeded definition-of-done items changed the export, so validate_agents_md_export now reports status: mismatched (a warning, ok: true). It needs a two-line re-export in that repo.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

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

Your current included review allowance is based on your included PR review attempts over the past 7 days.

Next review available in: 16 minutes

Limit details: You’ve used the included review currently available. Your 70 included PR review attempts over the past 7 days set your current allowance at 1 review per hour.

Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab.

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: e53e27e9-472c-4aa5-9b1a-b32cd9d0a65e

📥 Commits

Reviewing files that changed from the base of the PR and between 48121ed and fee9089.

📒 Files selected for processing (4)

• ARCHITECTURE.md
• capability_advisor.py
• provision.py
• repo_knowledge.py

---

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