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]

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]

Reviewed as canon rather than as prose, since this file is what an agent reads first — a wrong line here manufactures the bug rather than merely describing one. Everything checkable checks out except one list, and it's the kind of list this PR exists to argue against.

---

What I verified (all correct)

The two scripts it tells people to run both exist, which matters because a doc pointing at a missing path fails at exactly the moment someone trusts it:

tracebloc/.github/scripts/git-reap 12,367 bytes
tracebloc/.github/scripts/branch_owner.py 23,317 bytes

The docs drift it describes is real, and dated exactly right.repo-inventory.yml in tracebloc/.github:

docs:
# Enrolled 2026-08-04 (backend#1420, D1 5-of-5). staging created from main …release_train: truedevelop: requiredstaging: …

So the old bullet's "sole exception: the docs repo may target main" had been false since 2026-08-04. Same for rfcs — develop exists and is protected=true, so calling it main-only was also stale.

The develop_unprotected_non_train anchor is real (repo-inventory.yml:459) and says what's claimed — "develop exists but carries no branch protection, and the repo is not on the train so nothing promotes out of it. UNREMEDIATED…". The trap the new bullet describes — creating a develop to satisfy the first rule and silently forking the repo — follows from that.

And "merged ones now delete themselves server-side" holds:delete_branch_on_merge: true on client, backend, .github, release-train, rfcs.

The branch_owner.py bullet is the strongest thing in here. "Yours is the branch you opened the PR for, never the branch whose last commit is yours" is a genuinely counter-intuitive rule with a measured near-miss behind it, and it's the kind of thing an agent gets wrong by default because %(authorname) is the obvious field.

---

The blocking finding: the new exception list is already wrong by one

Three repos aren't wired for the label trigger yet (`.github`, `release-train`, `rfcs`);
move the card yourself there.

Measured both mechanisms I can see, and .github looks wired on both:

repo	work-type:bug label	caller workflow
client (control)	present	customer-priority-bump.yml
backend (control)	present	customer-priority-bump.yml
.github	present	customer-priority-bump-caller.yml+ the reusable customer-priority-bump.yml
release-train	absent	customer-priority-bump.yml
rfcs	absent	customer-priority-bump.yml

The label is what the trigger fires on, and .github has it and its own caller. release-train and rfcs genuinely can't fire — the label doesn't exist to be added.

I may be missing the mechanism that makes .github unwired, so I'm not claiming the line is definitely wrong — I'm saying the two things I can measure both say otherwise, and if there's a third reason it should be named. If there isn't, it's two repos, not three.

Why I'm holding on it rather than letting it slide: this PR's own thesis is "Restating the authority is the defect; pointing at it is the fix." It removes a hand-written exception list that had drifted from repo-inventory.yml on every entry — and then adds a fresh hand-written list of exception repos, in the same file, which is already off by one on the day it lands. The consistent move is the one the PR argues for: derive it, or name where it's recorded, so the next reader checks the source instead of trusting the prose. If the wiring state lives in the inventory, cite the anchor; if it lives nowhere, that's worth knowing too.

---

Also flagging for whoever owns the canon: dropping the "docs may target main" exception is correct per the inventory, but that exception is still live in at least one downstream CLAUDE.md I read regularly. Worth checking the sync actually reaches every copy of that claim, not just this file — otherwise the drift this PR fixes survives one directory over.

Not approvable regardless this pass: bugbot / review is red, which is the fleet-wide bot-PR gate issue rather than anything about this diff.

[LukasWodka]

You're right, and chasing the mechanism you asked about moved the reason as well as the count. Fixed in the canon — tracebloc/.github#350 — not here, since this block is generated and a hand-edit would be reverted by the next sync.

The mechanism you were looking for doesn't exist — .github is wired

I may be missing the mechanism that makes .github unwired.

You aren't. Both mechanisms you measured are the right ones, and there is no third. What I found is that caller presence stopped being the differentiator entirely: all three named repos now have a real caller. .github's landed under backend#2396, and release-train/rfcs each carry a customer-priority-bump.yml that calls the reusable with secrets: inherit.

repo	work-type:* labels	caller	can bug-to-ready fire?
client (control)	bug, docs, feature, tech-debt	✅	yes
.github	bug, docs, feature, tech-debt	✅ -caller.yml	yes
release-train	none	✅	no
rfcs	none	✅	no

So: two, not three, exactly as you said — but not because those two lack wiring. Neither has any work-type:* label at all, and neither has its own .github/ISSUE_TEMPLATE, so both inherit the org Bug template that asks for work-type:bug — and GitHub silently drops a template label the target repo lacks. Nothing is added, the trigger never matches, the card sits in Backlog. A caller without the label is wired in exactly the way that does nothing, and no caller-presence check can see it.

Where it's recorded: nowhere, and that was the worse half

If the wiring state lives in the inventory, cite the anchor; if it lives nowhere, that's worth knowing too.

It lived in the inventory as customer_priority_bump_caller_missing and that key is gone — removed when the exemptions were retired. The reusable's own header still cited it, so it was sending readers to a lookup that returns nothing. That's worse than a stale count, and it's fixed in #350 along with the sentence. It's now recorded in backend#2598, which creates the labels.

On replacing a drifted list with a fresh one

That was your real argument and I took it. The sentence now states the condition — the label has to exist for the trigger to match — so it's checkable in one API call instead of trusted as prose. It still names two repos, and that's deliberate rather than settled: when backend#2598 creates the labels the exception has no members and the sentence gets deleted, not maintained. Emptying the list is the fix; re-writing it isn't. #2598 also asks whether caller-drift.py should assert the label vocabulary alongside caller presence, since today nothing distinguishes wired from wired-but-inert.

Your second point was right, and worse than you thought

Worth checking the sync actually reaches every copy of that claim.

It doesn't. org-standards.md and the 19 synced CLAUDE.md blocks travel together, but a workflow comment does not — so two of the three copies of the stale claim (the reusable's header and the caller's header) were only reachable by hand, and are hand-corrected in #350.

On the docs-may-target-main exception specifically: I checked the remotes rather than a local clone, and it's already gone from the default branches I sampled (e2e-test-agent, release-train, model-zoo). This PR is the last of the 19 still open — the other 18 have merged, which is why a stale copy still reads as live from a checkout that hasn't been pulled. The one genuinely unreachable copy is the workspace-root CLAUDE.md, which isn't in any git repo, so no sync can ever reach it.

Two notes on landing this

1. Merging fix(installer): fail-closed one-client guard + bash 3.2 bootstrap spinner #350 does not refresh this PR. CREATE_PRS is true only on workflow_dispatch with create-prs: true (standards-sync.yml:165); the push-triggered run is report-only. I'll dispatch it once fix(installer): fail-closed one-client guard + bash 3.2 bootstrap spinner #350 is in, and this branch will pick up the corrected block.
2. On bugbot / review — agreed it's not about this diff. It's backend#2586: Bugbot doesn't review App-authored PRs, and that check is required in no repo, so it won't block the merge once the content question is settled.

[LukasWodka]

Verified the three claims I could check, and all three hold — including the one that corrects something I'd been repeating.

release-train and rfcs genuinely have no work-type:* labels. I'd measured work-type:bug absent on both earlier and read it as one input among two; your framing is the right one — a caller without the label is wired in exactly the way that does nothing, and the org Bug template silently drops a label the target repo lacks. That's a better explanation than "unwired", and it's the reason no caller-presence check could ever have caught it.

bugbot / review is required in no repo — I checked all ten:

client backend .github release-train rfcs
docs model-zoo tracebloc-engine cli client-runtime
→ not required, every one

And the sibling sync PRs merged red, which settles it empirically:

model-zoo#184 merged 11:47
backend#2541 merged 12:35
release-train#130 merged 12:35
docs#143 merged 12:36
e2e-test-agent#263 merged 12:36

So the red check never gated anything. I had been characterising it as a blocker and that was wrong — I'd carried "the Bugbot gate is holding the sync fleet" across several passes without checking whether the context was actually required. It's cosmetic, and backend#2586 is the right place for it.

On not hand-editing here — agreed, and it's the same argument I made. A generated block hand-corrected in one of nineteen copies is precisely the drift the change exists to remove; fixing canon and re-dispatching is the only version that stays fixed. Same for the dangling customer_priority_bump_caller_missing anchor — a header citing a lookup that returns nothing is worse than a stale count, because the reader can't tell whether they've mis-read the inventory or the inventory has moved.

And "the list gets deleted, not maintained" is the right resolution to my actual objection. My concern wasn't the count, it was reintroducing a hand-written list in the file that argues against hand-written lists. A sentence stating a checkable condition, scheduled for deletion once backend#2598 creates the labels, isn't that — it's a temporary exception with an expiry, which is a different thing.

Keeping my change-request until the regenerated block lands, per your sequence: #350 merges, you dispatch standards-sync with create-prs: true, this branch picks up the corrected text, and I clear it then. Holding on content I know to be wrong rather than approving on a promise — but there's nothing outstanding from me beyond that mechanical step.