docs(claude): sync the org-standards block

[tracebloc-release-train]

Managed sync of the org-standards block into this repo's CLAUDE.md — canonical
source: tracebloc/.github/org-standards.md. Do not hand-edit the block; to change
a rule, open a PR against tracebloc/.github and the sync propagates it.

Part of tracebloc/backend#1602 (org-wide engineering standards).

🤖 Generated with Claude Code

[LukasWodka]

The content is fine — this is a managed sync of the org-standards block, byte-identical across the fleet. The problem is that this PR, and the other nineteen in the batch, are all red on the same required check, and the gate's own remediation would make things worse if followed.

What's failing.set-status / closing-ref, at the step "The title names a ticket, so the PR must link it". The gate parses backend#1602 out of the title's trailing (backend#1602) and then requires that ticket to be in the PR's link graph. The body says:

Part of tracebloc/backend#1602 (org-wide engineering standards).

That's a plain mention. GitHub creates a link only from a closing keyword, so the link graph is empty and the gate refuses — correctly, by its own rules.

Why the advice it prints is the wrong move here. The gate says:

Add Closes tracebloc/backend#1602 to the body

Do that and, since cross-repo closing keywords do fire in the owner/repo#n form, the first of these twenty PRs to merge closes backend#1602 while nineteen siblings are still open. The epic gets closed roughly 5% of the way through its own rollout, and the remaining nineteen merge against a closed ticket.

Worth saying plainly because the gate is otherwise thoughtful about exactly this failure mode — the WRONG_REPO branch carries a long comment about an earlier remedy that "manufactures the defect the gate exists to prevent". This is the same shape one level out: the gate has no vocabulary for "the title names a ticket this PR contributes to but must not close", so its only advice is the one that's wrong for umbrella work.

The cheap correct fix is in the bot, not in the gate.NOTHING_NAMED is an accepted verdict — a title that names no ticket has nothing to assert. So the sync workflow should emit:

docs(claude): sync org-standards block

and keep Part of tracebloc/backend#1602 in the body, where it still produces the human-readable cross-reference on the epic without a closing link. One change to the generator, twenty PRs go green, nothing about the gate moves.

The alternative — teaching the gate a Part of / Refs verdict for contributes-but-doesn't-close — is the more general fix and probably worth filing, but it shouldn't block this batch.

Two per-repo extras, unrelated to the above:docs#143 also fails its check job, and release-train#130 also fails set-status / set-status. Both look repo-local rather than part of this pattern; worth a glance separately.

I'm holding my review rather than approving — the content is right, but I'm not going to bless twenty PRs into a required-check failure, and the fix isn't in this diff. Ping me when the titles are regenerated.

[LukasWodka]

The title fix worked — set-status / closing-ref is green here and across the batch. Dropping (backend#1602) while keeping Part of tracebloc/backend#1602 in the body was the right side to fix, and nobody had to add a Closes that would have shut the epic on the first of twenty merges. I approved the identical content on rfcs#54.

But there's a second, structural blocker, and it's worth naming because it can't clear itself.

bugbot / review is red, and not because Bugbot found anything:

Bugbot review gate: FAIL
No Bugbot check run on head 4bc5e085de02.
Bugbot has not reviewed the current head, so nothing has looked at the last push.
An absence never approves.
Waited 900s over 46 attempt(s) and Bugbot never reported a terminal verdict on this
head. Measured Bugbot latency is p50 164s / max 635s over 40 runs, so this is not
slowness.

The gate is behaving correctly — "an absence never approves" is the fail-closed rule, and citing measured p50/max latency to separate "slow" from "never ran" is exactly how a gate should distinguish those. No complaint about the gate.

The problem is the pairing. This PR's author is app/tracebloc-release-train, and Bugbot doesn't review bot-authored PRs — so the verdict the gate waits for will never arrive. Every managed sync PR into a Bugbot-gated repo burns 900 seconds and then reports red, permanently. Three of the five I'm reviewer on are in this state (.github, release-train, docs); rfcs has no Bugbot caller, which is why it went green and merged past this.

I'm holding my approval, and I want to be clear that's a rule call rather than a judgement about this diff. All eight required contexts pass — actionlint, gate, selftests, and the five quality/* — and bugbot / review isn't among them, so it's advisory and doesn't block the merge itself. The content is the same block I've already read and approved. But I don't approve over a red check, and approving here would quietly remove the pressure to fix something that will recur on every sync from now on.

Two ways out, and this is a call for whoever owns the gate:

1. Exempt bot-authored PRs in the caller — if Bugbot won't review them, waiting 900s for a verdict that cannot come is a guaranteed red plus fifteen wasted minutes per PR per repo. A skip with a stated reason is honest; a timeout is not.
2. Accept it as advisory and say so explicitly, so reviewers know a red bugbot / review on a bot PR carries no information.

The first is better. The gate's own reasoning is that an absence never approves — which is right when a review could have happened. When it structurally cannot, the absence isn't evidence of anything, and treating it as failure trains people to ignore the gate on exactly the PRs where it might one day matter.

Same applies to release-train#130 and docs#143. docs#143 also has a separate check failure that looks repo-local and needs its own look.

[LukasWodka]

bugbot run

[cursor]

Bugbot couldn't run

Bugbot is not enabled for your user on this team.

Ask your team administrator to increase your team's hard limit for Bugbot seats or add you to the allowlist in the Cursor dashboard.

[LukasWodka]

bugbot run

[cursor]

Bugbot couldn't run

Bugbot is not enabled for your user on this team.

Ask your team administrator to increase your team's hard limit for Bugbot seats or add you to the allowlist in the Cursor dashboard.