fix(2498): rfcs' two stale exemptions, and the reason that rotted with them

[LukasWodka]

Summary

Unblocks .github#318, which has been refused three times in two days — each time by a different conformance finding.

caller-drift reported 2 findings, both on rfcs:

row	said	measured 2026-08-25
callers.code-quality.yml	exempt: *code_quality_caller_missing	code-quality-caller.ymlis on rfcs/main — the branch this guard reads for a release_train: false repo
protection.develop	exempt: *develop_unprotected_non_train ("carries no branch protection")	matches the develop baseline on every key

The branch matters and is why this was easy to get wrong: the caller is not on develop. Checking the wrong ref reads the opposite way.

rfcs/develop, measured:

classic_protection true | min_reviews 1 | bypass_reviews [] | strict false
block_force_pushes true | block_deletions true | require_conversation_resolution true
required_checks: quality/gitleaks, quality/house-rules, quality/action-pins

So it is required with no divergent cell. enforce_admins is false and the baseline does not assert it on develop (backend#1276 D1 leaves it open) — conformant, not divergent.

The second finding is the anchor's own warning coming true.develop_unprotected_non_train says a develop created and left unprotected "is not flagged … no check was going to surface it". None did. The row went stale silently and only the promotion audit caught it.

A third edit no finding asked for

The prod divergent cell drops the three quality / * contexts "BECAUSE the producer is absent". Flipping the caller row makes that sentence false, so it is corrected rather than left sitting behind a fixed field.

The cell stays [] — that is the measured state, rfcs/main requires zero contexts. Only the justification had rotted, which is the failure backend#2449 added the citation guard for, one field over.

Named, not decided: now that the caller exists and reports those contexts on every rfcs PR, maincould require them. That is a protection change, not an inventory correction, so it is written down rather than made quietly.

Verification

caller-drift-selftest.py 197 pass / 0 fail
caller-drift.py (live, org) No drift. Every repo read, every entry matched.

The live audit is the one that matters here — it is the exact check that is red on #318.

Note on the recurrence

This is the third fix of this shape in two days. Each was correct and each was superseded before the mirror could merge, because caller-drift audits the live fleet rather than the diff — so .github can only merge at an instant when every repo in the org is conformant. That structural problem is backend#2498's second half and is not addressed here; this PR only clears the current drift.

---

Note

Low Risk
Changes only the conformance inventory YAML to match live measured state; no runtime or auth logic, though incorrect rows would block .github merges until fixed.

Overview
Unblocks org caller-drift conformance by updating repo-inventory.yml so measured GitHub reality matches the contract (backend#2498 / .github#318).

For rfcs, two rows that still claimed exemptions are flipped to required: callers.code-quality.yml (caller is on main, the audit ref for release_train: false) and protection.develop (now matches the fleet develop baseline; the old “unprotected develop” anchor had gone stale without any check surfacing it). The prod divergent cell keeps required_checks: [] but replaces a false comment that blamed missing quality contexts on an absent code-quality caller; follow-up to arm main is pointed at backend#2501 rather than decided in inventory.

Adds a full design-system-v2 block so a repo that appeared mid-review is no longer “active but absent from inventory,” with cells measured on its only branch (develop).

Refactors the shared code_quality_caller_missing anchor to drop hand-maintained counts/names and document an anchored grep derivation plus remediation history, so prose tallies cannot rot again.

^{Reviewed by Cursor Bugbot for commit ee4e51c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[saadqbal]

Both flips are right, and I checked the fact the whole PR turns on rather than taking the table for it: code-quality-caller.yml is on rfcs/main at 3c30a73, and a fetch of the same path on rfcs/develop 404s. That's exactly the trap you name — checking the wrong ref reads the opposite way. develop: with the comment block above it and a bare required under it parses to develop: required, same as every other row; I loaded the file to confirm rather than eyeballing the indentation. audit and gate are both green on this head.

The two protection tables I could not verify — branch-protection reads 404 for my token, no admin — so those numbers rest on the audit, not on me.

Bugbot is right, though, and I'd fix it before this lands. The anchor still says "Down to THREE citations (claude-skills, release-train, rfcs)". After this PR there are exactly two real aliases: claude-skills (L669) and release-train (L1140). The other four mentions are prose. So the count and the named list are false the moment this merges.

Worth it for the irony alone: that same anchor already records drifting this way once ("The previous revision of this text also said THREE...") and ends by telling the reader to trust grep -n over the sentence. It's a two-word edit, but a PR whose thesis is stale prose rots silently shouldn't ship new stale prose in the file it's fixing.

Also, the "OPEN QUESTION" on main requiring the three quality / * contexts: naming it in a comment is the same mechanism that just failed. Worth a ticket so it's tracked somewhere a grep won't have to find it.

[LukasWodka]

bugbot run

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b8d9bdf. Configure here.}

[saadqbal]

Both my asks are closed, and closed better than I asked. Deleting the count outright rather than decrementing it is the right call — a tally nothing checks was always going to rot, and reason-citations.py verifying an issue is still OPEN was never going to catch a wrong number. backend#2501 for the main-requires-the-three-contexts question is exactly right, and noting that rfcs/develop is currently stricter than rfcs/main is a better framing than the one I gave you.

Two things stop me approving, and the first is almost funny.

The replacement instruction has the same defect the count had. The anchor now says derive the roster with:

grep -n "exempt: \*code_quality_caller_missing" repo-inventory.yml

Run verbatim against b8d9bdf3 that returns four lines — 662, 677, 1128, 1148. Two are real aliases (677 claude-skills, 1148 release-train); 662 and 1128 are prose, comments reading # `exempt: *code_quality_caller_missing` above. So the prescribed derivation over-counts by exactly the two you just removed from the sentence, and a reader following it lands back on "three or four". Bugbot's open thread says the same thing.

Anchoring it fixes it — grep -nE '^\s*exempt: \*code_quality_caller_missing\s*$' returns 2 on that head, which I checked.

For what it's worth this is the fifth instance today of a check or instruction that greps source text and cannot tell code from commentary: client#808's grep -c, e2e-test-agent#233 twice, tracebloc-engine#732's _activation_callers, and now this. It's past the point of being per-PR feedback.

Second: audit is now failing, and it was green before.FINDINGS_TOTAL: 1 at b8d9bdf3, where 3397e024 was clean, and gate fails downstream off it — correctly, a contract change must not merge on a failed audit. Since making the audit clean is the entire point of this PR, that needs an answer rather than a re-run: either the new prose broke something the audit reads, or the org state moved under you. Worth saying which in the thread.

[LukasWodka]

@saadqbal on the audit regression — the org state moved under the PR, and the new prose is not involved.

The audit at b8d9bdf3 reports one finding, and it names a repo this PR never touches:

- design-system-v2: active in tracebloc but absent from repo-inventory.yml.
A new repo arrives with no callers and nothing required of it; add an entry.
The audit exited 1 (0 clean, 1 drift, 2 could not evaluate)

tracebloc/design-system-v2 was created at 11:35:06 today — empty, no branches, no content — which is after this PR was opened and verified clean. That is why 3397e024 was green and b8d9bdf3 is not: same diff, different fleet.

And an inventory entry does not fix it. I tried that first and reverted it, because it just swaps one red for another:

inventory state	audit says
no entry	active in tracebloc but absent from repo-inventory.yml
full entry, every cell exempt	repo has no branches

The second comes from a deliberate fail-closed path in caller-drift.py:

ifnotbranches:
# An empty repo is a legitimate state, but it is not one this guard can# audit, and it must not read as "no callers, all exemptions hold".out.errors.append("repo has no branches")

That reasoning is right — reading an unauditable repo as conformant is the fail-open the guard exists to prevent. The consequence is that an empty repo anywhere in the org blocks every .github promotion until it stops being empty, and no edit to repo-inventory.yml can clear it.

So this is not a re-run and not something this PR can close. It is backend#2498 — caller-drift audits the live fleet rather than the diff, so .github can only merge at an instant when every repo in the org is conformant. Third distinct finding to block the same mirror in two days, and the first one caused by a repo that did not exist when the PR was opened. Full timeline and the two escape routes are on the ticket.

On your fifth-instance observation — agreed, and this PR just supplied the sixth: the derivation I wrote to replace the tally was itself unanchored and returned 4 where 2 was right. Fixed in 429a1fc. A grep over source text that cannot tell code from commentary is now a recurring shape rather than a one-off, and it seems worth its own ticket rather than more per-PR catches.

[saadqbal]

Anchored form is right — I ran both on 429a1fcd: the anchored pattern returns 2, the old one still returns 4. Bugbot's thread is closed too. Nothing left from me on the content.

And I dug into the audit failure, because it isn't yours. The one finding is:

design-system-v2: active in tracebloc but absent from repo-inventory.yml. A new repo arrives with no callers and nothing required of it; add an entry.

A new repo landed in the org between the clean run on 3397e024 and the first red one. That's the second of the two possibilities I raised — org state moved under you, nothing your prose did.

Worth pulling out of that same run: the conformance matrix now reads rfcs | - | OK | OK | OK | OK | OK. The audit itself confirms both your flips, which is the measurement I couldn't make — branch-protection reads 404 for my token.

So the only thing between this and green is a design-system-v2 entry. Your call whether it rides here (it's a one-repo addition and the audit is already the gate) or goes in its own PR with #318 waiting on both.

My change-request stays standing purely because audit and gate are red and I won't approve over a failing required check. It is not an outstanding ask — both of mine are closed.

[saadqbal]

The design-system-v2 entry is measured, and I checked it rather than reading the comment: develop is the default and only branch, and all nine required callers, the add-to-kanban.yml copy, CLAUDE.md and .cursor/BUGBOT.md are actually present on it. So nothing here is aspirational, which was my first worry — a required cell on an empty repo would have turned the audit into nine remediation PRs and kept the fleet red.

I also went looking for the defect that bit this PR twice: whether any anchor the new entry cites carries a prose count that adding a citation falsifies. None of them do — develop_unprotected_non_train has no count or named list, and neither do the other three. Clean.

One question, and it's the PR's own shape one repo over. Three release_train: false repos with no staging branch now give three different answers to the same three cells:

	fr-gate	fr-pass-comment	version-bump-gate
rfcs	exempt	exempt	exempt
claude-skills	required	exempt	exempt
design-system-v2	required	required	required

rfcs' exemption text says the reason is structural: "fr-gate gates the staging → prod hop. This repo has no staging branch, so there is no hop for it to gate." If that's true it's true of design-system-v2 too — it has one branch. And fr_pass_comment likewise: "fr-pass advances a card out of FR on staging."

All three required cells are factually satisfied, because the callers exist — which is exactly why this will never surface on its own. That's the same failure mode as the two rows you're fixing: a cell that's satisfiable while its stated reasoning doesn't hold. claude-skills predates you here, so the inconsistency isn't yours; design-system-v2 makes it a third variant.

If the intent is that this repo joins the train, say so in the entry and required is right. If not, three cells want the rfcs treatment. Either way it's a sentence, not a rewrite.

Four checks pending including the re-run audit, so nothing to approve against yet. My change-request is standing on the gate alone — both original asks are closed and the design-system-v2 blocker was never yours.

[saadqbal]

Green at ee4e51c9 — 12 pass, 1 skipped, nothing pending, no open threads. audit came back clean now that design-system-v2 is entered. Approving, and clearing my change-request, which was standing on the gate rather than on an ask.

For the record, what I verified rather than read: the anchored derivation returns 2 on this head where the unanchored form still returns 4; the design-system-v2 entry is measured, not aspirational — develop is the only branch and all nine required callers, the copy and both quality files are genuinely present; and none of the anchors that entry cites carry a prose count this addition would falsify. The two rfcs flips I could never verify directly, since branch-protection reads 404 for my token — the audit's own matrix reading rfcs | - | OK | OK | OK | OK | OK is what stands behind them, which is better evidence than my inspection would have been.

The fr-gate / fr-pass-comment / version-bump-gate inconsistency across the three release_train: false repos stays a note, not a condition — I said so when I raised it and I'm not going to hold a green PR over it. It's the same shape as what you fixed (a cell satisfiable while its stated reasoning doesn't hold), so it'll keep until someone decides whether design-system-v2 is joining the train. Worth a ticket if the answer isn't obvious.

[LukasWodka]

@saadqbal — both of your asks are closed on the current head, so this is a re-review request rather than a new argument.

1. The grep is anchored. It now reads grep -nE '^\s*exempt: \*code_quality_caller_missing\s*$', and the diff documents why the naive form returns four lines (662 and 1128 are prose comments, 677 and 1148 the real aliases) rather than just quietly fixing it. So the next reader gets the reasoning, not only the corrected command.

2. The audit is green. Latest run at 12:44 — FINDINGS_TOTAL: 0, "No drift. Every repo read, every entry matched." Your FINDINGS_TOTAL: 1 at b8d9bdf3 was real; the answer to your question — new prose, or the org moving underneath — is the org moved: claude-skills#33, claude-skills#35 and release-train#128 all merged at 11:55, between your review and now. Every check on this PR currently passes.

Also: .github#330 has been closed in favour of this PR. It was a duplicate — same two rows, written independently by another session that had also spotted the red audit. It shipped an unanchored grep (grep -n '\*code_quality_caller_missing', worse than the one you rejected here) and its green audit predated the 11:55 merges. This is the surviving fix.

On your wider point — that this is the fifth instance today of an instruction or check that greps source text and cannot tell code from commentary (client#808, e2e-test-agent#233 ×2, tracebloc-engine#732, this) — agreed that it is past per-PR feedback. Filed as a house rule rather than argued again on the sixth: backend#2507.