fix(2347): rfcs' develop cell gets a value that is true again

[LukasWodka]

DRAFT ON PURPOSE — do not mark ready until Step 2 below is applied.
The audit on this branch reports 3 findings today and that is expected:
two of them are the very state a human has to fix first. It goes green on the
arming, not on this merge.

The bind

Lukas protected rfcs/develop on 2026-08-25 — 1 review, dismiss stale reviews,
no force-pushes, no deletions, enforce_admins: false, mirroring rfcs/main.
That was right and it stays. It also left rfcs.protection.develop with no
valid value, because both of the two it can hold are false:

value	live audit
exempt (what is on develop now)	1 finding — "protection.develop is exempt but develop exists and is protected by classic protection. The exemption is stale"
required	2 findings — conversation resolution=False, policy wants True, and does not REQUIRE quality / gitleaks, quality / house-rules, quality / action-pins

Measured, not inferred — scripts/caller-drift.py against the live org from an
unmodified develop checkout, 2026-08-25:

**1 drift finding(s):**
- rfcs: protection.develop is `exempt` but develop exists and is protected by
classic protection. The exemption is stale - promote it to `required`.
EXIT=1

The org audit is already red. It has not run since the protection change; it
will say this the next time it does.

Root cause

rfcs had no quality workflows at all — five kanban callers, and the only
contexts a PR reported were Cursor Bugbot and route / route. Sixteen of
nineteen repos declare code-quality.yml: required; rfcs was one of the nine
backend#1415 measured as missing it, carried since as
code_quality_caller_missing. So the develop policy asserted three contexts
this repo had no producer for.

The three steps, in this file's own prescribed order

1. tracebloc/rfcs#51 — adds .github/workflows/code-quality-caller.yml on
   main (the branch caller-drift.py reads for a non-train repo). Contexts
   confirmed reporting green on that PR before this was opened.
2. A human arms rfcs/develop. Branch protection is a security setting; this
   session did not touch it. The exact command is below.
3. This PR records the result.

Step 2 — the arming command, for Lukas

Not run by this session. One PUT, because required_conversation_resolution
has no sub-resource endpoint and the full object replaces what is there — so
every field currently set is restated, not dropped. Values below are the live
read of rfcs/develop on 2026-08-25 plus exactly the two additions.

gh api -X PUT repos/tracebloc/rfcs/branches/develop/protection --input - <<'JSON'{ "required_status_checks": { "strict": false, "contexts": [ "quality / gitleaks", "quality / house-rules", "quality / action-pins" ] }, "enforce_admins": false, "required_pull_request_reviews": { "dismiss_stale_reviews": true, "require_code_owner_reviews": false, "require_last_push_approval": false, "required_approving_review_count": 1 }, "restrictions": null, "required_conversation_resolution": true, "allow_force_pushes": false, "allow_deletions": false, "block_creations": false, "required_linear_history": false, "lock_branch": false, "allow_fork_syncing": false}JSON

Preconditions: rfcs#51 must be merged first — arming a context whose producer
is not on the branch leaves every PR pending forever (client#665). Verify after:

gh api repos/tracebloc/rfcs/branches/develop/protection \
--jq '{checks: .required_status_checks.contexts, strict: .required_status_checks.strict, convo: .required_conversation_resolution.enabled, reviews: .required_pull_request_reviews.required_approving_review_count, dismiss: .required_pull_request_reviews.dismiss_stale_reviews, admins: .enforce_admins.enabled, force: .allow_force_pushes.enabled, del: .allow_deletions.enabled}'

Expected: the three contexts, strict:false, convo:true, reviews:1,
dismiss:true, admins:false, force:false, del:false.

What this PR changes

• rfcs.protection.develop: exempt: *develop_unprotected_non_train →
  required, with the bind written down so the next reader does not have to
  re-derive why one edit could not fix it.
• rfcs.callers.code-quality.yml: exempt: *code_quality_caller_missing →
  required # code-quality-caller.yml.

Two things carried because this change makes them false:

• The anchor stays defined — 2 citations remain, claude-skills and
  release-train (grep -n '\*code_quality_caller_missing'). Its text said
  THREE and named rfcs; corrected to TWO. Not deleted: an anchor is only dead
  prose at zero citations, and this is not zero.
  develop_unprotected_non_train also survives with 1 citation
  (claude-skills).
• rfcs' prod cell justified required_checks: [] for the quality / *
  contexts on "the producer is absent". From rfcs#51 that is false. Replaced
  with the narrower true statement — not armed on main, UNDECIDED — so the
  empty list cannot be read as a structural impossibility. prod is otherwise
  untouched; arming main is a separate decision nobody has taken.

Test plan

• python3 -c "import yaml; yaml.safe_load(...)" — parses; anchors resolve
• make check — green, 95 passed / 0 failed
• python3 scripts/reason-citations.py — 0 findings, no exemption went stale
  (26 citations / 124 reasons; the pre-edit baseline was 25 / 126)
• scripts/caller-drift.py against the live org on this branch — 3
  findings, all expected and all named above:
  MISSING required caller for code-quality.yml on main (rfcs#51 unmerged),
  conversation resolution=False, and does not REQUIRE quality / gitleaks, quality / house-rules, quality / action-pins (Step 2 unapplied)
• Re-run the audit after rfcs#51 merges and Step 2 is applied — expect 0

Checklist

• Targets develop (.github's default)
• No branch protection or repo setting changed by this session
• Draft, because repo-inventory.yml is a GUARDED file needing a green
  audit on its own head sha — which is unreachable until a human acts

Refs tracebloc/backend#2347, tracebloc/backend#1415, tracebloc/rfcs#51

---

Note

Medium Risk
Changes the guarded org contract for branch protection and required CI callers; wrong sequencing (inventory before caller merge or develop arming) can leave PRs blocked or audits red until external steps complete.

Overview
Updates repo-inventory.yml so rfcs matches live org state after develop was protected and rfcs#51 adds the code-quality caller—this file only records that outcome; arming develop and merging rfcs#51 must happen first for the audit to go green.

rfcs.protection.develop moves from exempt (develop_unprotected_non_train) to required, with notes explaining why neither value was valid until the caller existed and develop was armed with conversation resolution plus the three quality / * checks.

rfcs.callers.code-quality.yml flips from exempt to required, documenting code-quality-caller.yml on main with soft-fail: false and action-pins-soft-fail: false.

The shared code_quality_caller_missing anchor text is corrected to two remaining citations (claude-skills, release-train) and warns that hand-maintained citation counts drift. rfcsprod commentary is narrowed: empty required_checks on main is UNDECIDED (checks not armed), not “producer absent.”

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

[LukasWodka]

Closing in favour of #332, which does the same job better. Not a preference call — two measured reasons:

1. This PR ships the defect #332 was held for. It tells the reader to derive the roster with:

grep -n '\*code_quality_caller_missing'

That is less anchored than the version @saadqbal rejected on #332, so it matches prose comments as well as real aliases and over-counts. A reader following it lands back on "three or four" — which is exactly the rotting count both PRs set out to remove. #332 now carries the anchored form (grep -nE '^\s*exempt: \*code_quality_caller_missing\s*$') and documents why the naive one is wrong.

2. This PR's green is stale. Its audit last ran at 07:32, before three PRs merged at 11:55 (claude-skills#33, #35, release-train#128). #332's audit ran at 12:44 against current org state and returned FINDINGS_TOTAL: 0 — "No drift. Every repo read, every entry matched." Checks are latest-per-context, so only the later verdict describes reality.

#332 is also the fuller fix: it deletes the count outright rather than decrementing it, and files backend#2501 for the "should rfcs/main require the three contexts" question this PR does not raise.

Nothing is lost. Both PRs flip the same two rows (rfcs.protection.develop, rfcs.callers.code-quality.yml); #332 lands them with better prose around them.

Worth recording why two PRs existed at all: the staleness was created by a branch-protection change — rfcs/develop being protected on 2026-08-25 — which no ticket owned. Two sessions each noticed the red audit independently and each wrote a fix. That is a gap in how a settings change gets an owner, not a coordination failure.