ci: the bugbot-gate caller rollout is complete, so the last row and the anchor go

[LukasWodka]

Relationship to backend#2284

Part of backend#2284, and deliberately NOT closing it.

That ticket is "Bugbot's verdict gates nothing", and it has two halves:

1. wire the callers — what this PR finishes, and
2. make the verdict actually gate — still open. The callers landed as advice, by design (design-system#262: "the Bugbot gate gets a caller here, as advice not a gate"), and Cursor Bugbot is still not a required context. NEUTRAL also still satisfies a required context, which is the second half of the original finding.

So the rollout being complete is a milestone in #2284, not its resolution. The title no longer names the ticket number, because the closing-ref gate is right that a title reference which is not a closing link is inert — and a closing link here would be false.

Summary

design-system-v2 took a bugbot-gate-caller.yml and its inventory row still said exempt — the last of the backend#2284 rollout drift, and the single finding keeping .github#341 red.

Flipping it takes the bugbot_gate_rollout_pending citation count to zero, so the anchor is deleted too. That is what it asks for on its own face:

DELETE THIS DEFINITION when that grep returns zero: an anchor left defined and uncited is dead prose, which this file treats as a defect rather than as harmless.

grep -nE "^\s*exempt: \*bugbot_gate_rollout_pending\s*$" repo-inventory.yml
→ no matches

The rollout is finished: every active repo carries the caller, so there is no repo left for the exemption to describe. Its text had already been corrected twice as the fleet moved (backend#2507, .github#335) and says outright that writing a count there was the mistake — leaving a third stale version behind would repeat it.

Verified

• caller-drift.py reported exactly this one finding on .github#341 head 108a9f4f (audit run 32957248510); the nine from the previous run are gone.
• bugbot-gate-caller.yml is present in tracebloc/design-system-v2/.github/workflows.
• yaml.safe_load parses after the anchor removal — no dangling alias.

Why this kept recurring

Worth recording, because it cost six hops.

.github's audit is a required check that measures the live state of every repo, while .github's own diff is the inventory describing that state. So its mirror can be correct when cut and wrong when the audit runs, for reasons unrelated to its contents.

Today alone: a fleet-wide hop moved 16 repos → nine bugbot-gate rows went stale → #337 fixed them on develop → the mirror predated that fix → a scoped recut carried it → and a tenth repo appeared. Every fix was correct; every one was overtaken.

Nothing in this PR changes that shape — it deserves its own ticket. This is the nine, plus the tenth, plus the dead anchor.

Type

ci

Test plan

python3 scripts/caller-drift.py against the live org is the test, and it is what produced the finding above. Expect No drift on this head unless the fleet moves again first — which is the very problem described.

Checklist

• Targets develop
• One self-contained change
• Assignee set, one reviewer requested
• No secrets, tokens or customer data

---

Note

Low Risk
Contract-only change to the org inventory YAML; it records that bugbot-gate is required everywhere and removes dead shared prose, with no application or security logic touched.

Overview
Closes the backend#2284bugbot-gate rollout in repo-inventory.yml by aligning the last stale row with reality: design-system-v2 moves from exempt: *bugbot_gate_rollout_pending to bugbot-gate.yml: required now that bugbot-gate-caller.yml exists there.

With no repos left citing that exemption, the shared bugbot_gate_rollout_pending anchor is removed entirely—the anchor itself said to delete it when the anchored grep returns zero citations, so the inventory no longer documents a “rollout pending” excuse for bugbot-gate.

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

[saadqbal]

The exit condition is genuinely met, and I checked it rather than trusting the description: at this head the anchored grep returns 0, and bugbot_gate_rollout_pending appears nowhere in the file at all. So deleting the definition is what the anchor's own last line demanded — "DELETE THIS DEFINITION when that grep returns zero: an anchor left defined and uncited is dead prose, which this file treats as a defect rather than as harmless." A stated exit condition, met, and acted on rather than left to rot. That's the whole arc closing cleanly.

set-status / closing-ref is failing, and it's the trap the gate's own docstring describes. Your title is ci(2284): …, so SCOPE_BARE_RE reads 2284 as a bare number, and a bare number resolves against this repo — .github#2284, which returns 404. The ticket you mean is tracebloc/backend#2284. closingIssuesReferences is 0, so there's nothing linked either way.

The gate spells this out at closing-ref-gate.py:85 — "This is the cross-repo trap: a bare Closes #%d resolves against THIS repo, so it links (and on merge closes) the wrong issue" — and it's the reason WRONG_REPO is reported separately from UNLINKED.

Fix is the title: ci(backend#2284): …, which is the spelled form SCOPE_REPO_RE matches. Worth noting this is now the third distinct way I've watched this gate fire this week — an inert prose keyword on e2e-test-agent#248, a named-but-unlinked ticket on the sync batch, and a bare number here. All three read as "the ticket is referenced" to a human and none of them link.

Held on that plus three pending checks. Nothing else from me — the content is right.

[aptracebloc]

Reviewed — correct and clean. Completes the backend#2284 caller rollout: flips the last stale design-system-v2 row to bugbot-gate.yml: required (the caller file now exists there) and removes the now-uncited bugbot_gate_rollout_pending anchor, exactly per the anchor's own "delete this when the grep returns zero" instruction.

Independently verified: zero remaining references to bugbot_gate_rollout_pending at head — the anchor definition and its sole citation are both gone, so there's no dangling *alias; the audit/caller-drift + actionlint checks are green, confirming the file still parses. This clears the caller-drift finding that was keeping .github#341 red.

Approving.

— drafted with Claude Code

[LukasWodka]

@aptracebloc — your approval is on the current head and I am not asking you to redo anything. It cannot satisfy branch protection, and GitHub is not telling either of us why, so I am writing it down rather than leaving the PR looking mysteriously stuck.

aptracebloc has read on tracebloc/.github:

$ gh api repos/tracebloc/.github/collaborators/aptracebloc/permission
read

GitHub only counts an approving review toward required_approving_review_count if the reviewer has write or above. A read-level approval is recorded, rendered in the UI exactly like any other, and contributes nothing. So the state is:

signal	value
aptracebloc review	APPROVED, on 69fb4d7 — the current head, not stale
required_approving_review_count	1
require_code_owner_reviews	false
rulesets on develop	none
every required check	✅ pass
unresolved threads	0
reviewDecision	REVIEW_REQUIRED
mergeStateStatus	BLOCKED

Every visible reason to merge is satisfied and it is blocked anyway. Nothing in the API response names the permission level as the cause — you have to go and ask for it separately, which is the whole problem.

I re-requested @saadqbal (write on this repo) so there is a review that can actually clear it. This is specific to .github — I audited it rather than assuming, and aptracebloc holds write on backend, client, design-system, frontend-app and tracebloc-website, so the reviewer routing is correct everywhere else and only this repo mis-sorts.

Worth noting how this differs from the failure mode already written down in CLAUDE.md: that one is "GitHub keeps showing an outstanding review request after someone else has approved, so a PR reads as waiting on X while being perfectly mergeable" — a PR that looks blocked and is not. This is the inverse: a PR that looks approved and is not. Same root shape, opposite direction, and the second one is worse because the reassuring signal is the false one.

One process note, since it caused a detour here: my own reviewer-assignment pass briefly added and then removed @saadqbal on this PR, on the reasoning that an approval was already standing. That reasoning was wrong for exactly the reason above, and re-adding is the correction — the churn was mine, not a change of mind about the review.

🤖 Generated with Claude Code

[saadqbal]

closing-ref passes now, and it confirms the diagnosis exactly: the head never moved — you edited the title, and a title edit creates no commit — so the whole failure was ci(2284): making 2284 a bare number that resolved against .github, which has no #2284. Dropping the scope parens leaves parse_title nothing to demand a link for.

The content was already right and I'd verified it: the anchored grep returns 0 at this head and bugbot_gate_rollout_pending appears nowhere in the file, which is precisely the exit condition the anchor's own last line set — "DELETE THIS DEFINITION when that grep returns zero: an anchor left defined and uncited is dead prose, which this file treats as a defect rather than as harmless."

Approving. That's the rollout closed end to end — reusable, pilot, nineteen callers, the phase-2 row flips, and now the anchor deleted on the condition it stated for itself.