docs(repo-inventory): every train repo's prod branch is main since 2026-09-08

[LukasWodka]

Comment-only update in repo-inventory.yml.

The prod-role comment records a 2026-08-10 measurement in which three repos still had a master branch. client-runtime, tracebloc-engine and tracebloc-py-package were renamed to main on 2026-09-08 (protection carried, promotion ruleset re-pointed), so no train repo has a master branch any more and the branches/master rename-redirect probe now returns a false 200 on all 16 — which is exactly why the role resolves from the branch list. The comment now says so.

No key, value or script changes; yaml.safe_load clean.

---

Note

Low Risk
Comment-only inventory update with no schema, policy, or script changes.

Overview
Documentation-only change to the branch-protection header in repo-inventory.yml; no keys, values, or audit behavior change.

The comment that explains why prod is resolved from the branch list (not from a branches/master API probe) is brought up to date: after 2026-09-08 renames on client-runtime, tracebloc-engine, and tracebloc-py-package, no release-train repo still has a real master branch—every train repo’s prod role is main. The note now states that GitHub’s rename redirect makes the master probe return a false 200 on all 16 repos, which is why list-based resolution remains the rule.

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

[saadqbal]

Verified and correct. The parenthetical is the good part, and I confirmed it rather than trusting it: GET /repos/{r}/branches/master now returns .name = "main" for client-runtime, tracebloc-engine and tracebloc-py-package, so the probe really does lie on all 16 — where it previously lied on 13. Listing branches instead shows ["develop","main","staging"] for each, no master.

Keeping the measured-2026-08-10 clause and appending rather than rewriting it is right: the old measurement stays true as a measurement, and the new sentence says what changed. A reader who greps for why the probe is forbidden still finds the original reason.

One note that belongs on your paired release-train#180 rather than here: PUBLISH-PATHS.md still says 16 enrolled prod branches while release-train/repos.yml lists 17 (all main). I've left the detail there. Worth landing the two together — this file is the authority per CLAUDE.md, so if this merges and #180 stalls, the prose is the thing that drifts, which is the exact failure that bullet exists to warn about.

Nothing blocking here; CI is still running.

[saadqbal]

This is red for something outside your diff — don't go looking in it. The chain:

gate fails only because audit did: "caller-drift.yml concluded 'failure' for 616260d. A contract change must not merge on a failed or skipped audit." And audit fails on 8 repo-conformance drift finding(s), exiting 1 — its own legend says 0 clean, 1 drift, 2 could not evaluate, so it did evaluate and the findings are real.

They are not yours. caller-drift.yml's scheduled run against develop on 2026-09-07T07:00:03Z also concluded failure — no connection to this branch. The 2026-08-31 scheduled run was green, so the drift appeared between those dates. Your change is a prose comment; it moves no inventory value and cannot produce conformance findings.

The structural consequence is worth naming. Touching repo-inventory.yml at all makes this a "contract change", which makes gate require a passing audit. So while those 8 findings stand, no edit to this file can merge — including a comment-only one. That is the gate behaving as designed, but it means the fleet's drift is now blocking documentation of the fleet's state.

That also sharpens the ordering point I raised earlier. Your paired release-train#180 has no such gate, so it can land while this one cannot. If it does, PUBLISH-PATHS.md will carry the new fact and repo-inventory.yml — the authority per CLAUDE.md — will not, which is the drift direction that bullet exists to prevent. Either the 8 findings get cleared first, or #180 waits.

Nothing to change here on my side; the content is verified correct (I reproduced the redirect on all three renamed repos). Worth a backend ticket for the drift if there isn't one, since it now gates more than itself.