Uh oh!
There was an error while loading. Please reload this page.
docs(kanban): the bug-to-ready exception is two repos, and for a different reason - #350
Conversation
…ent reason @saqlainsyed007's blocking finding on the sync PRs (client#848). He is right, and chasing the mechanism moved the reason as well as the count. MEASURED. All three named repos now have a caller -- `.github`'s landed under backend#2396, and `release-train`/`rfcs` both carry a real `customer-priority-bump.yml` calling the reusable. So caller presence is no longer the differentiator, and `.github` is fully wired: it has the caller AND all four `work-type:*` labels. The list was wrong by one, exactly as the review said. What remains is narrower and invisible: `release-train` and `rfcs` have no `work-type:*` labels AT ALL. Neither has its own `.github/ISSUE_TEMPLATE`, so both inherit the org Bug template, which asks for `work-type:bug` -- and GitHub SILENTLY DROPS a template label the target repo lacks. Nothing is added, `bug-to-ready` never sees its trigger, and the card sits in `Backlog`. A caller without the label is wired in exactly the way that does nothing. THE ANCHOR THE OLD TEXT CITED IS GONE. `customer_priority_bump_caller_missing` no longer appears anywhere in `repo-inventory.yml` -- it was removed when the exemptions were retired -- so the reusable's header sent a reader to a key that returns nothing. That is worse than a stale count: it is a doc teaching a lookup that cannot answer. Corrected in place, with the new reason stated and backend#2598 named as where it gets closed. THREE COPIES, because the sync only reaches one of them. `org-standards.md` and its 19 synced `CLAUDE.md` blocks travel together, but a workflow COMMENT does not -- so the reusable's header and the caller's header were both hand-corrected here. The review's second point ("check the sync actually reaches every copy") is the reason I went looking; it does not, and two of the three copies were only reachable by hand. ON NOT REPLACING A DRIFTED LIST WITH A FRESH ONE, which is the review's real argument: the sentence now states the CONDITION rather than a roster -- the label has to exist for the trigger to match -- so a reader can check it in one API call instead of trusting prose. It still names two repos, and that is deliberate rather than settled: backend#2598 creates the labels, at which point the exception has no members and the sentence is DELETED rather than kept accurate by hand. Emptying the list is the fix; re-writing it is not. Verified: `classify` reports IN_SYNC (canon and CLAUDE.md agree), standards-sync selftest 31 checks / 0 failed, both workflows parse, actionlint clean, reason-citations 0 findings. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
aptracebloc
left a comment
There was a problem hiding this comment.
Docs/comments only, CI green, zero logic change — but requesting changes because the PR's central claim is factually wrong in a way that will silently drop bug cards.
The bug-to-ready exception is three repos, not two.design-system-v2 is in the identical broken state to release-train and rfcs: it has nowork-type:* labels (verified: 0, vs backend's 7) and it carries customer-priority-bump.yml: required (repo-inventory.yml:689, added 2026-08-25 via .github#332). So the Bug template's work-type:bug label is silently dropped there and the card stays in Backlog — exactly the miss this text documents. Because org-standards.md syncs into every repo's CLAUDE.md, this canonizes the omission fleet-wide.
Please fix, in all four places the omission appears:
org-standards.mdandCLAUDE.md— the "release-trainandrfcs… those two" line should includedesign-system-v2(three repos).customer-priority-bump.ymlandcustomer-priority-bump-caller.ymlheader comments — same addition.- The arithmetic: "those two … the other 17 … are covered" assumes a 19-repo fleet, but 20 repos carry
customer-priority-bump.yml: required(0 exempt). With three unlabeled repos it's 3 + 17 = 20 — the "17 covered" is only coincidentally right because a third broken repo exists. - The remediation anchor: backend#2598 is scoped to
release-train/rfcsonly, sodesign-system-v2stays broken after it lands. Either widen #2598's stated scope or note thatdesign-system-v2remains manual.
Minor (non-blocking): the "grepping for it returns nothing" line for customer_priority_bump_caller_missing — the key is indeed gone from repo-inventory.yml (true), but a repo-wide search still hits scripts/reason-citations.py and the comment itself; scope the claim to repo-inventory.yml.
Nothing else here — the workflow logic, triggers, permissions, and check contexts are untouched; it's purely the accuracy of the text.
— drafted with Claude Code
…m the prose @aptracebloc's review on #350. He is right on every point, and the one that matters is the one I would have kept getting wrong. THE COUNT IS THREE. `design-system-v2` is in the identical broken state to `release-train` and `rfcs`: no `work-type:*` labels at all, no own `.github/ISSUE_TEMPLATE`, and `customer-priority-bump.yml: required` in repo-inventory.yml (added 2026-08-25 via .github#332, after the prose this PR was written against). WHY I MISSED IT, WHICH IS THE ACTUAL DEFECT. I checked the three repos the OLD SENTENCE NAMED and found one of them wired, so I wrote "two". I never asked the inventory which repos declare the caller. That is CLAUDE.md rule 6 exactly -- derive the input domain from the producer's declared surface and test all of it, because a vocabulary gap is invisible to any amount of checking inside the wrong domain. In a PR whose whole argument is "restating the authority is the defect", I restated the authority. Derived properly this time: `repo-inventory.yml` declares `customer-priority-bump.yml: required` for TWENTY repos and exempts none; all 20 were measured, and exactly three have an empty label set. The arithmetic follows -- 20 declared minus 3 unlabelled is 17 covered. The previous "17" was right only by coincidence, being 19 minus two. Fixed in all four places the omission appeared, as asked: `org-standards.md`, `CLAUDE.md`, and both workflow headers. The reusable's header also now records that the list is derived and why an earlier version named two, so the next reader sees the trap rather than just the corrected number. MINOR, ALSO HIS: "grepping for it returns nothing" was too broad. The `customer_priority_bump_caller_missing` key is gone from `repo-inventory.yml` (true, and the point), but the STRING still appears in `scripts/reason-citations.py` and in the comment itself -- I had grepped it up earlier in this same session and still wrote the wider claim. Scoped to the inventory. backend#2598 widened to three repos in the same pass, since it was scoped to two and would have left `design-system-v2` broken after landing. Verified: `classify` reports IN_SYNC, standards-sync selftest 31 checks / 0 failed, both workflows parse, actionlint clean, reason-citations 0 findings. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
LukasWodka
commented
Aug 26, 2026
You're right on all four, and the one that matters is the one I'd have kept getting wrong. Fixed in
|
LukasWodka
commented
Aug 26, 2026
@aptracebloc re-requesting review — your All five points are in that commit, including the minor one: 🤖 Generated with Claude Code |
aptracebloc
left a comment
There was a problem hiding this comment.
CI is green now (the earlier Selftest the checker red was a flake — it re-ran clean), no open threads, head unchanged since my re-review. The fix fully addresses my change-request: design-system-v2 is now named alongside release-train/rfcs across all four files ("THREE of the twenty repos"), the count is corrected (20 declared − 3 unlabelled = 17), and the manual-handling-until-backend#2598 note covers all three. Approving.
— drafted with Claude Code
saadqbal
left a comment
There was a problem hiding this comment.
Verified the new claim rather than the one it replaces, since a docs fix that swaps a stale anchor for a fresh one can just be wrong in a newer way. Both hold: customer_priority_bump_caller_missing is at zero occurrences in repo-inventory.yml, and design-system-v2, release-train and rfcs each carry 0work-type:* labels — with backend's 7 as the control, so the zeros are the repos and not a broken query.
"Caller presence is not the whole story" is the sentence that earns this PR. Distinguishing the string still existing in reason-citations.py from the inventory no longer recording it is also the right level of care — that's precisely the distinction that sends a reader to a lookup which can't answer. 👍
…354) Four PRs in one day failed `closing-ref` for the same reason -- .github#349, #350, #352, #353 -- and all four were fixed by retitling. That is a rule the canon is missing, not four mistakes: a finding that recurs across PRs becomes a rule rather than a fifth hand-fix. THE COLLISION. The canon says commit subjects are `type(scope): summary`, `referencing the ticket (backend#1234)`. Read quickly, `(scope)` looks like the ticket slot, so sessions write `sec(2157): ...`. `closing-ref` then reads a bare number in the title as a PROMISE to close that ticket and fails unless the body carries a closing keyword -- which for partial work would be WRONG to add. Every one of the four was partial work correctly saying `Part of tracebloc/backend#N`, and every one went red for saying so. The canon's own example is already the qualified form (`backend#1234`), not a bare number; the gap is that it never says the number does not belong in the subject, and that a bare one has a specific machine meaning. Both are now stated. WHY NOT LOOSEN THE GATE INSTEAD. The gate is right and its failure message is excellent -- a title reference is inert, and it cannot tell which repo owns a bare number, so it would accept a link to any repo at that number. The defect is the convention pointing one way while the check reads the other. Verified: `classify` reports IN_SYNC (canon and CLAUDE.md agree), standards-sync selftest 31 checks / 0 failed. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Uh oh!
There was an error while loading. Please reload this page.
…356) * fix(2284): the gate tolerates a review that never came, and says so Two absences were one verdict, and they mean opposite things. `PENDING` covered both "Bugbot is still running" and "Bugbot never showed up", and the timeout failed both identically. A check that STARTED and never finished is a review that BROKE -- worth blocking on. A check that never appeared is Bugbot dropping the PR, which this repo cannot fix, retry, or wait out. Measured 2026-08-26 on human-authored PRs, well past p50 164s / max 635s: six of nine never got a check at all -- .github#349 (57 min), #350 (55), #352 (40), #353 (37), #354 (32), e2e-test-agent#273 (2h+) -- while #351, opened BETWEEN two of them, was reviewed in three minutes. Not latency, not the seat limit, not the author. backend#2114 closed COMPLETED saying "no discriminator survives the data"; the drop is still live. `bugbot run` cannot recover it: Cursor refuses on a seat limit and the App will not be given one (decision, 2026-08-26). So requiring this context while failing UNCLAIMED would block roughly two thirds of PRs for the full wait and then fail them with no remedy -- the gate would look broken while behaving exactly as written. WHAT THIS IS NOT: it is not a pass. UNCLAIMED exits 0 so the context can be required, and every other word says the head is UNREVIEWED -- its own banner, its own summary line, and an explicit "read the diff yourself". The honest report is "nothing looked at this", not "this is clean". PENDING still blocks, and that asymmetry is the whole change. Also corrected: the vocabulary comment said "Only PENDING is waitable", which this makes false. `main` now READS `WAITABLE` rather than restating it. 79 selftest assertions (4 new through `main`, since the exit code is the behaviour and `evaluate` alone cannot show it). Registry: 1 stale marker fixed, 5 mutations added -- the collapse in both directions, the tolerance leaking onto PENDING, the tolerance removed, and the banner reading as a pass. Part of tracebloc/backend#2284 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(2284): pin the UNREVIEWED banner, which no assertion covered The mutation `the UNREVIEWED banner reads as a pass` came back UNCAUGHT. Every other assertion in this suite checks a verdict or an exit code, and the banner is neither -- it is the one line a human skimming the summary actually reads, and the only thing standing between "exits 0" and "looks clean". Three cases: the UNCLAIMED headline says UNREVIEWED, does not contain the word pass, and a genuine pass still does. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * style: hoist the selftest imports ruff flagged E402/E401 from the banner test added in the previous commit. `make lint` is where I should have run it before pushing, not after. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(2284): the threshold is applied before the head is classified Bugbot on #356, High: `evaluate` returned UNCLAIMED as soon as the head had no Bugbot check, without applying the open-finding threshold to the threads it had ALREADY loaded one block earlier. So the tolerance this PR adds for a dropped review would launder a finding that had already come -- review head A, get a High, push head B, Bugbot never claims B, and the gate reports UNREVIEWED-but-not-blocked over an open High at exit 0. The same hole was in PENDING, and fixing only the branch Bugbot named would have left its twin. So `blocking` is now computed before `bugbot_check` is consulted at all, and an absence of either kind with a blocking finding is a FAIL that names the finding and does NOT wait -- the answer would not change. Both absence verdicts now also state that the threshold was checked, so the report says which question was answered. The tolerance itself is intact and asserted: a Low on an unreviewed head is still UNCLAIMED, exit 0, and so is a resolved High -- otherwise the remedy the FAIL message names would not clear it. Not a shipped bug: `required_conversation_resolution` is true on every train branch, so the merge was blocked anyway. It was a gate naming the wrong reason, which is the failure mode this file exists to prevent. One renderer (`_finding_lines`) feeds both paths, because two would drift and one of them would quietly stop saying OPEN (rule 9). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
…e truthful (backend#2556) (#360) * fix(closing-ref): re-run when the title changes, and let a child PR be truthful (backend#2556, backend#2616) Two defects in one gate, fixed together because either alone leaves the other's remedy unusable. BACKEND#2556 -- THE GATE READS THE TITLE AND NEVER RE-RUNS WHEN IT CHANGES. `closing-ref` decides its verdict from the PR title and body; the callers triggered on `[opened, reopened, ready_for_review, converted_to_draft]`, and `edited` is the only event GitHub fires when either field changes. So the two inputs the gate reads were the two inputs that could change without re-running it. That is a bypass, not a gap: open a PR titled `chore: tidy up`, the gate records NOTHING_NAMED and goes green, then retitle it to `fix(1234): ...` with nothing linked -- no event fires, the green stands. It also made the remediation unusable in the other direction: 20 sync PRs had to be cleared with 20 manual `gh run rerun` calls (backend#2555). Same one-word fix, same reason, as `fr-gate-caller.yml` (backend#1945). A CONSEQUENCE THAT HAD TO BE GUARDED, not discovered later. Every trigger this workflow had was reachable only on an OPEN PR, so `set-status` writing Status unconditionally was always correct. `edited` is not: GitHub fires it when a MERGED PR's title or body is edited, and this is the one board writer in the fleet that does not compare pipeline rank. Without the new guard, fixing a typo in a shipped PR's description would drag its card from `Prod` back to `Code review`. Both jobs are now `if: ...state == 'open'`. BACKEND#2616 -- ONE SATISFYING FORM, AND A CHILD PR CANNOT TRUTHFULLY USE IT. The checker read `closingIssuesReferences` and nothing else, and that field is populated only by a closing keyword. So a PR whose title named a ticket had exactly one satisfying form: promise to close it. For this org's most common shape -- a parent ticket with several child PRs titled `type(NNNN): ...`, none of which finishes it -- the only remedies were a FALSE `Closes`, or deleting the number from the title, which passes the check by removing the traceability the check exists to enforce. Four PRs in one day took the second (.github#349, #350, #352, #353) and #354 wrote that workaround into the canon. A declared NON-CLOSING body reference now satisfies the title, reported as its own state (`MENTIONED`) so a green run still says which promise was made. The closing link stays the stronger form, and `WRONG_REPO` is decided BEFORE any body reference is consulted -- a truthful `Part of tracebloc/backend#304` must not mask a `Closes#304` that closes `.github#304` on merge. DERIVED, NOT RESTATED (rule 1). The non-closing vocabulary is PARSED out of `org-standards.md`, which already declares the org's partial-work form. Add `Refs <owner>/<repo>#N` to the canon and the gate accepts it with no code change. The derivation fails closed in both directions: an unreadable canon and a canon declaring no non-closing form are separate cannot-tells (exit 2), never a silent reversion to closing-only -- reverting is the defect itself. GitHub's closing keywords are the one list here that cannot be derived from this org, so they are named, cited, and used only to subtract. The canon and CLAUDE.md carried two statements this change makes false -- that the check fails unless the body carries `Closes`, and to keep the number out of the subject. Both are rewritten; classify() reports IN_SYNC. EVIDENCE closing-ref-gate-selftest 156 assertions, all passed (was 109) closing-ref-gate-mutations 53 mutations, 0 stale, 0 uncaught (was 36) ruff / actionlint / shellcheck / house-rules clean standards-sync selftest 60 checks, 0 failed The mutation harness now rewrites the two WORKFLOW files as well as the checker: `edited` and the open-state guards are guarantees declared in YAML, and rule 5 does not exempt a guard for living in a different language. Part of tracebloc/backend#2556 Part of tracebloc/backend#2616 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(closing-ref): an escaped Unreadable reddens a case instead of killing the suite The multi-word-keyword mutation was scored UNCAUGHT for the right reason: it made `evaluate` raise, which killed the suite mid-run, and the harness refuses to count a broken harness as coverage. `evaluate` grew a path that can raise for a NEW reason (the derivation from org-standards.md coming back empty), so the positive cases now go through a wrapper, exactly as `value` already does for every other call. Part of tracebloc/backend#2616 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(closing-ref): the derived-vocabulary cases report a refusal instead of crashing `value` returns the exception TEXT on a refusal, and a string is iterable -- so a case that walked the derived list iterated characters and raised IndexError on the space in "RAISED Unreadable: ...". Normalised once. Found by the multi-word-keyword mutation, which is the job: it was scored UNCAUGHT for breaking the harness rather than being caught by a case. Part of tracebloc/backend#2616 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Addresses @saqlainsyed007's blocking finding on the
docs(claude): sync the org-standards blockbatch (raised on client#848). He is right that the list is wrong by one — andchasing the mechanism moved the reason as well as the count.
What I measured
work-type:*labelsbug-to-readyfire?client(control).github-caller.ymlrelease-trainrfcsAll three named repos now have a real caller —
.github's landed under backend#2396, andrelease-train/rfcsboth carry acustomer-priority-bump.ymlthat calls the reusable.Caller presence is no longer the differentiator, and
.githubis fully wired on bothmechanisms. Two repos, not three.
What remains is narrower and invisible: neither
release-trainnorrfcshas its own.github/ISSUE_TEMPLATE, so both inherit the org Bug template, which asks forwork-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 withoutthe label is wired in exactly the way that does nothing.
The anchor the old text cited is gone
The reusable's header sent readers to
customer_priority_bump_caller_missinginrepo-inventory.yml. That key no longer appears there — removed when the exemptionswere retired. That is worse than a stale count: a doc teaching a lookup that cannot
answer. Corrected in place.
Three copies; the sync reaches one
The review's second point — "check the sync actually reaches every copy of that claim" —
is why I went looking. It does not.
org-standards.mdand the 19 syncedCLAUDE.mdblocks travel together, but a workflow comment does not, so both workflow headers were
hand-corrected here.
On not replacing a drifted list with a fresh one
That is the review's real argument, and I took it. The sentence now states the
condition — the label has to exist for the trigger to match — so a reader can check it
in one API call instead of trusting prose. It still names two repos, and that is
deliberate rather than settled: backend#2598 creates the labels, at which point the
exception has no members and the sentence gets deleted rather than kept accurate by
hand. Emptying the list is the fix; re-writing it is not.
backend#2598 also asks whether
caller-drift.pyshould assert the label vocabularyalongside caller presence — today nothing can tell a wired repo from a wired-but-inert one.
Propagating to the open sync PRs
Merging this does not refresh them:
CREATE_PRSis true only onworkflow_dispatchwith
create-prs: true(standards-sync.yml:165); the push-triggered run is report-only.So after this lands,
standards-syncneeds a dispatch withcreate-prs: trueto updateclient#848 and its siblings.
Verification
classifyreportsIN_SYNC— canon andCLAUDE.mdagreereason-citations.py: 31 citations, 0 findingsPart of backend#2598.
Note
Low Risk
Comment and standards-doc edits only; no workflow logic, inventory, or automation behavior changes.
Overview
Updates documentation only so the engineer-kanban “bugs skip refinement” rule matches how
customer-priority-bumpactually behaves after callers landed everywhere.The prose no longer says three repos lack wiring (
.github,release-train,rfcs) or points atcustomer_priority_bump_caller_missinginrepo-inventory.yml— that inventory key is gone. It now explains that caller presence is not enough:design-system-v2,release-train, andrfcshave callers but nowork-type:*labels, so GitHub dropswork-type:bugfrom the org Bug template andbug-to-readynever fires; cards stay inBackloguntil someone moves them or backend#2598 adds labels (and may extendcaller-drift.py).org-standards.md, the syncedCLAUDE.mdblock, and comments incustomer-priority-bump.yml/customer-priority-bump-caller.ymlare aligned on that mechanism and the 20 declared − 3 unlabelled = 17 fully covered repos.Reviewed by Cursor Bugbot for commit 804914c. Bugbot is set up for automated code reviews on this repo. Configure here.