fix(inventory): tracebloc-website is on the release train (backend#1415)

[LukasWodka]

The caller-drift guard from #131 went red on its first real run — and it did so on #127, the develop → main promotion, which is the worst place to discover a red guard.

tracebloc-website: release-train/repos.yml says on-train=True, the inventory says False.

The guard is right

release-train#14 ("enroll tracebloc-website in the release train") is merged, so repos.yml on main lists the repo. repo-inventory.yml was written from the pre-merge state. release-train has no develop branch, so the guard reads main there and sees the enrollment immediately — the inventory is simply one merge behind.

Its kanban card still sitting in Code review is what made this easy to miss: the card says the enrollment is unlanded, the repo says otherwise.

Nothing is actually ungated

The finding's wording warns about "a repo joining the train without an fr-gate caller ... an ungated staging -> prod hop". That part does not apply here — the check is a plain equality on the boolean, and for this repo fr-gate.yml is already required with fr-gate-caller.yml present on develop. Only the recorded fact was stale.

Verified against the live org, not just reasoned

Ran scripts/caller-drift.py locally before and after the change:

	result
before	1 drift finding(s) — reproduces the CI failure exactly
after	No drift. Every repo read, every entry matched.
both	Audited 20 of 20 on the develop-first branch
selftest	exit 0

Not included

The same inventory carries a second stale fact — the wip_limit_check_has_no_callers reason asserts "ZERO callers anywhere in the org (all 20 active repos)", but eight repos still call the reusable on their default branches (averaging-service, client, data-ingestors, docs, model-zoo, start-training, cli, claude-skills), each uses: .../wip-limit-check.yml@main. The guard reads develop-first by design, so it does not go red — but the reason is the stated premise for the delete-or-wire follow-up, and deleting the reusable would break those eight. Left out of this PR deliberately; it needs a decision, not a correction.

🤖 Generated with Claude Code

---

Note

Low Risk
Single boolean and comment in inventory YAML; no workflow or runtime behavior changes.

Overview
Fixes a caller-drift guard failure where release-train/repos.yml already lists tracebloc-website as on the release train (after release-train#14) but repo-inventory.yml still had release_train: false.

Updates tracebloc-website in repo-inventory.yml to release_train: true and adds a short comment that enrollment is merged and only the inventory fact was stale—fr-gate.yml was already required with the caller on develop, so this is metadata alignment, not a new gating change.

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

[LukasWodka]

Confirming this independently — I hit the same red audit and arrived at the identical one-line fix, so closing my duplicate (#133) in favour of this one; the inline comment here is the better version of it.

Evidence from my pass, so the reviewer doesn't have to take the fix on faith:

The audit's finding is the only one. I cross-checked every release_train boolean in the inventory against the 11 repos in release-train/repos.yml. Exactly one mismatch — this one. Nothing else drifted.

Both directions proven, not just the green one. CI is red on develop with false; running caller-drift.py against all 20 repos with true exits 0:

Inventory: 20 repos x 9 reusables + 2 copies. Audited 20 of 20 on the develop-first branch.
No drift. Every repo read, every entry matched.

caller-drift-selftest.py: 42 pass, 0 fail.

The hop really is gated, as this PR's comment says — worth restating because the audit's message reads alarmingly. That "ungated staging -> prod hop" sentence is the rule's rationale, not a measurement of this repo. tracebloc-website's caller set is byte-identical to design-system's, an established on-train repo.

One extra thing I checked while here:repos.yml gives the website prod_branch: main, and that is correct — main carries the release commits (main release (#384)). Note for anyone verifying this themselves: GET /repos/{o}/{r}/branches/master returns a SHA on this repo even though master does not exist. git ls-remote and GET /git/ref/heads/master both agree it is absent (only develop, main, staging). That endpoint is not a reliable existence oracle — the train's own scripts correctly use git/ref/heads/..., so they are unaffected.

Worth noting the class of defect: release-train/repos.yml and this inventory are two files in two repos that must agree, and nothing forced #14 to update the second. The guard caught the contradiction within minutes, which is the win — but enrolling a repo in the train is a two-file change, and that belongs in the enrolment docs rather than in reviewers' heads.

[LukasWodka]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

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