fix(fr-gate): an ancestry-only promotion has nothing to gate

[LukasWodka]

Fixes the deadlock that kept data-ingestors out of today's prod hop.

The deadlock

The no-items fallback did this:

# If commit subjects yielded no PR refs, gate the promotion PR itself.
NUMBERS="$PROMOTION_PR"

which is unsatisfiable by construction: set-pr-status parks a promotion PR in Code review, and the only way out of that column is merging — which this gate is what blocks. So the train could never merge that repo, and the failure read as a legitimate governance block (❌ #423 — Status='Code review', required 'Ready for prod') rather than as a bug.

Why the item set was legitimately empty

data-ingestors' master...staging range contained exactly one commit — the mirror merge from the staging hop — and 0 changed files, because a manual promotion (data-ingestors#421) had already carried that content to master. Both PRs associated with that commit were correctly filtered as train plumbing (#415 by its release-train/* head, #423 by still being open). So there was no cargo, because the promotion genuinely ships nothing.

The fix

Distinguish the two causes of an empty item set by whether the range touches any file:

Range	Meaning	Verdict
0 files changed	ancestry-only — nothing shipped	pass, with a notice
>0 files changed	real content we couldn't attribute	gate the promotion PR → fail closed

An unset file count falls into the fail-closed branch, so failing to compute it can never become a pass. The existing unattributable-commit check is untouched, so a direct push into the range still fails closed on its own terms.

Verification

actionlint + shellcheck clean at CI-pinned versions. All four decision paths exercised locally:

PRS='' files=0 -> PASS (ancestry-only) # the DI case
PRS='' files=7 -> gate promotion PR (fails closed) # attribution broke
PRS='1364 …' files=12 -> verify items # normal promotion
PRS='' files='' -> gate promotion PR (fails closed) # unset defaults safe

Confirmed against the live repo that data-ingestors' range really is ahead=1, files_changed=0 — I checked that the "nothing to gate" premise holds empirically before relying on it, rather than assuming an ancestry-only range implies no content.

---

Note

Medium Risk
Changes promotion merge gating logic; the early-pass path is narrow (0 files + empty UNATTRIB) but a wrong file count could theoretically allow or block merges incorrectly.

Overview
Fixes a release-train deadlock when the FR gate found no attributable PRs and always fell back to gating the promotion PR itself—an unsatisfiable loop because that PR sits in Code review until merge.

The Discover items step now counts how many files the promotion range actually contributes using the GitHub compare API with three-dot semantics (BASE...HEAD), with retries and fail-closed behavior if the count cannot be obtained. That count is exposed as changed_files.

The Verify step uses that signal when the attributed PR list is empty: if changed_files is 0 and there are no unattributable commits, the workflow passes with a notice (ancestry-only mirror merge, no new content to review). If files changed or attribution is incomplete, it still gates the promotion PR and fails closed as before.

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

[LukasWodka]

bugbot run

[LukasWodka]

👋 Heads-up — Code review queue is at 35 / 30

Above the WIP limit. The team convention is to review existing PRs before opening new work.

Open PRs currently in Code review (oldest first):

• backend#1201 — docs(rfc): Data spaces & federated dataset composition (draft) · author: @LukasWodka · reviewer: @saadqbal
• backend#1217 — docs(rfc): Dataset integrity & score reproducibility (draft) · author: @LukasWodka · reviewer: @saadqbal
• backend#1261 — RFC-BACKEND-0008: board & process reset (decision RFC — for markup) · author: @LukasWodka · reviewer: @saadqbal
• backend#1284 — docs(deploy): backend deploy runbook skeleton (#1263) · author: @LukasWodka · no reviewer assigned
• backend#1332 — feat(check-model): allow KNN/GaussianProcess on a single-edge owned dataset (#923 follow-up) · author: @divyasinghds · no reviewer assigned
• backend#1353 — chore(ci): baseline historical gitleaks findings + wire caller · author: @LukasWodka · no reviewer assigned
• backend#1361 — feat(tasks): bound ExperimentQueue growth for PAUSED experiments (backend#1351) · author: @saqlainsyed007 · reviewer: @saadqbal
• claude-skills#14 — feat(skill): add tracebloc-frontend-app skill · author: @waqaskhanroghani · no reviewer assigned
• claude-skills#15 — feat(skill): add tracebloc-design-system skill · author: @waqaskhanroghani · no reviewer assigned
• claude-skills#16 — feat(skill): add tracebloc-website-frontend skill · author: @waqaskhanroghani · no reviewer assigned

Pull from review before opening new work. (This is a nudge from the kanban WIP check, not a block.)

[LukasWodka]

Valid, and a real fail-open in my own fix — fixed.

The early exit sat ~150 lines above the UNATTRIB fail-closed check (my exit 0 at ~273, that check at ~431), so it jumped straight over it. A tree-identical range containing a commit we could not verify — commits/{sha}/pulls erroring three times, say — would have passed the gate. And my PR body asserted "the existing unattributable-commit check is untouched", which was simply wrong: an early return in the same step is exactly how you touch it.

The premise needed tightening too: 0 files changed means "nothing shipped" only if every commit was successfully accounted for. An unverifiable commit means we don't actually know what the range contains, so the file count proves nothing. The ancestry pass now requires UNATTRIB to be empty as well.

Re-tested every path:

PRS='' files=0 unattrib='' -> PASS (ancestry-only) # the DI case
PRS='' files=0 unattrib='abc1234' -> FAIL CLOSED # this finding
PRS='' files=7 unattrib='' -> FAIL CLOSED # attribution broke
PRS='1364' files=12 unattrib='' -> verify items # normal
PRS='' files='' unattrib='' -> FAIL CLOSED # unset defaults safe

actionlint + shellcheck clean. This is the third time today Bugbot has caught a fail-open in a guard I wrote — worth noting the pattern: my guards keep failing open on the error path while reading correctly on the happy path.

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

[LukasWodka]

Valid, and worse than the description suggests — my fix would not have fixed its own motivating case. Fixed.

I used two-dot git diff BASE..HEAD, which compares the two tips and therefore counts files the base moved on alone. Measured on the actual data-ingestors case:

two-dot master..staging = 6 files <- what I shipped
three-dot master...staging = 0 files <- the correct answer

Those 6 are all base-only: .cursor/BUGBOT.md, auto-release-on-master.yml, code-quality-caller.yml, release-image.yml, RELEASING.md, tracebloc_ingestor/__init__.py — master's own #421 content that staging lacks. So the check would have returned 6, taken the fail-closed branch, and the DI deadlock would have persisted despite this PR.

The underlying mistake is worth naming: I verified the premise with the compare API (three-dot) and then implemented local two-dot git. Validating with one operation and shipping another is how a fix passes review while not working. It now calls the compare API directly, so the check and the thing I verified are literally the same operation.

That also sidesteps a second trap: local git diff A...Bsilently picks one merge base, and this history has multiple after the mirror reconciliations (git even warns: multiple merge bases, using 07ff47f1). The API has no such ambiguity.

Any failure to count now yields -1, which takes the fail-closed branch — an uncounted range is never treated as empty.

Re-verified against the live repos:

data-ingestors compare(master...staging).files = 0 -> ancestry pass ✓
client compare(main...staging).files = 36 -> will not pass ✓
files=-1 (API failed) -> FAIL CLOSED
files=0 + unattrib commit -> FAIL CLOSED
files=8 -> FAIL CLOSED

actionlint + shellcheck clean.

bugbot run