fix(2214): audit the branch a repo ships from, not any branch named develop

[LukasWodka]

Closes backend#2214. Found by the backend#2157 sweep — the first change ever made to a copied workflow file.

The bug

caller-drift preferred develop wherever that branch existed. rfcs is the only repo in the org whose default is main, so the sweep landed there — where rfcs actually ships — and the audit read a develop that lags:

ref	blob
rfcs/main (default, where it ships)	2a3a432b3d01 ✅
rfcs/develop (what the audit read)	07283e30b80b ❌

It then reported drift against a change that was correctly in place.

It agreed by coincidence for months

That's the part worth recording. Both refs held the same blob because nothing had ever changed that file, so a wrong ref and a right ref were indistinguishable. A resolver pointing at the wrong branch produces a correct-looking result for exactly as long as the two branches happen to match, and emits a false finding the first time real work lands.

The rule is now derived, not listed

Develop-first exists because train repos default to main/master while work lands on develop, so a default-branch audit under-reports work in flight. A non-train repo has no promotion pipeline: its default branch is where it ships, and preferring a stray develop audits a branch nobody merges to.

on_train=bool(meta.get("release_train"))
ifon_trainand"develop"inbranches: ... # train: develop-firstelifmeta.get("default_branch") inbranches: ... # else: the shipping branch

The discriminator is release_train, which the inventory already carries and which load_release_trainalready verifies against release-train/repos.yml — so the audited ref is derived from a fact this guard independently checks, rather than from a hand-maintained audit_ref field or an exception row for rfcs. An override would just be a second place to be wrong.

Measured across all 19 repos before writing it: the new rule changes exactly one answer — rfcs, develop → main. Nothing else moves.

audit_branch is renamed develop-first → develop-first-on-train in both the inventory and SUPPORTED_AUDIT_BRANCH, because the schema check compares them and the semantics changed. The description above that key said "develop where that branch exists, else the default" — precisely the behaviour being removed.

Verification

Both directions are pinned, because neither case can fail alone: assert only the train side and the non-train path is untested; assert only the non-train side and a resolver that always uses the default branch passes.

mutation	result	caught by
reverts to plain develop-first	193/1	the non-train case
always the default branch	192/2	the train case
train flag read inverted	191/3	the train case + two more
audit_branch no longer enforced	193/1	the inventory positive control

And one fix to the suite itself

The _good positive control raised AssertionError when the tree was fetched off develop — which aborts the whole run. Two of those mutations first reported CRASH and hid every other case they also broke. It now returns an empty tree and fails cleanly. A suite that dies on the first surprise can't tell you the shape of a regression.

The fixture META also gained release_train: True, now load-bearing: without it every existing case would have silently exercised the non-train path while being written about develop-first.

make check green — 194 caller-drift cases, all selftests, coverage gate, actionlint.

Not fixed here, because it isn't in this repo

The workspace CLAUDE.md says "Verified 2026-08-06: every active repo's default branch is now develop (all 20)". That's false for rfcs, and it's the line a reader would use to conclude this guard reads the right branch. It lives outside any git repo so it can't ride a PR — flagged on backend#2214 instead.

---

Note

^{Cursor Bugbot is generating a summary for commit f7c7bcc. Configure here.}

[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 f7c7bcc. Configure here.}

[LukasWodka]

bugbot run

[saadqbal]

Verified the interesting part first: list_active_repos does build each entry with exactly visibility and default_branch (caller-drift.py:1055-1056), so the earlier meta.get("release_train") really was always None — every repo audited on its default branch, develop-first silently deleted for the train repos it exists for. Good catch, and the diagnosis of why the selftest missed it is the more valuable half: a fixture that constructs the meta it wishes for cannot fail on the producer's real shape.

The recurrence guard is the right shape. Rather than another fixture, the suite now parses list_active_repos' own source and asserts the keys it writes, plus that main() derives on_train from the inventory entry — so if the producer changes, the test moves with it. Confirmed by mutation, 197/0 baseline:

• Read train membership from meta again (the original High) → 2 failures, led by a TRAIN repo is audited on develop even when it defaults to main. That it's now caught behaviourally and not only by the source checks is what makes this closed rather than papered over.
• Drop the discriminator (plain develop-first) → 1 failure: a NON-TRAIN repo is audited on its default branch, not a stray develop.

Making on_train required and positional is the right call over a defaulted keyword — = False would have reproduced the identical bug with better manners.

On the rule itself: deriving from release_train, which load_release_train already cross-checks against release-train/repos.yml, beats a per-repo audit_ref or an rfcs exception row. A hand-maintained override is a second place to be wrong, and it would have needed a human to notice rfcs was the odd one out — which nobody did for months. Measuring that the new rule changes exactly one answer across all 19 before writing it is the part that makes this safe to land.

The "it agreed by coincidence" note is worth having written down. A resolver pointing at the wrong branch produces correct-looking output for exactly as long as the two refs happen to match, then emits a false finding the first time real work lands — and a false finding on this guard blocks merges. That's a failure mode with no signal until it bites.

[LukasWodka]

/fr-pass