← board

Grade a pin instead of gating it, and say what a red pin is known to break

summary: "A pin's validity and a pin's quality are two questions and the tooling publishes one boolean for both. Owner's ruling 2026-09-01: a VALID pin is the self-host fixedpoint and nothing else may block one; a pin is GRADED, never gated. Emit two fields that cannot be confused — pin_blocked: never beside pin_grade: green | reds(N) | unmeasured — recorded AT PIN TIME rather than re-derived from a shifting archive, plus a MANIFEST of what a red pin is known to break. The manifest is the part with the most value: had v398 said known broken: C on i386, arm32, no B/E session would have built against it unaware for two days and frankC's investigation would have been a lookup. Rollback prefers a green pin and falls back to the most recent, so the recovery leg is never empty — it has been empty since v354 on 2026-08-19."

Why, in one measurement

would_pin: false has zero deciding consumers. pin_shadow()'s own docstring says it "deliberately never touches pinned, make pin, or stable_linux_amd64/**". It is advisory and always was.

On 2026-09-01 three sessions read it as a refusal — frank-user, Track T on seven, and the coordinator's earlier guidance. All three reasoned carefully. That is the finding: this is not a reader defect, it is a wording defect, and the fix belongs in the emitter. A verdict nobody is authorised to act on gets read as authority anyway.

Cost: 19 days without a green pin, and v398 shipped a compiler that could not build C for i386 or arm32 (fixed by fc9c8ade2 the day AFTER the pin was cut), which every $(PXX_STABLE) consumer carried.

What to build

  1. pin_blocked is a constant never. If it can ever read otherwise it is the same bug again. A flag that cannot come out false is not a guard — and neither is one that cannot come out true.
  2. pin_grade: green | reds(N) | unmeasured, decided AT PIN TIME and written into the pin metadata beside binsha/git/ts. Not re-derived later: today three separate errors came from reading a shifting archive — a binary sha searched as a commit, a tstate bookkeeping commit read as a break point, and a pin_baseline carried from the OUTGOING pin answering a question about the incoming one.
  3. The manifest. A red pin records WHICH jobs and, where known, which TARGETS it is broken for. A consumer asks "is my case affected", not "is the number zero".
  4. Rollback prefers green, falls back to most recent. pin_is_green stays as the preference; an empty result must not mean an empty recovery.

unmeasured is a THIRD grade, not a flavour of red

Added 2026-09-01 after Track T on seven caught the first draft collapsing two different claims. "Known broken" and "never measured" are not the same thing, and a green | reds(N) pair has nowhere to put the second.

This is the repo's own stated principle, and the first draft broke it. seed_baseline's docstring (twatch.py:2597):

"We did not measure it" must not be recorded as "we measured it and it was fine" -- that substitution is the defect class this whole gate exists to catch.

A grade of green on an unjudged tree is exactly that substitution.

The tool already makes this distinction and the first draft would have thrown it away. trackt.py pinstatus prints NOT JUDGED at this sha as its own state, distinct from a verdict. Preserve it; do not invent it.

Live instance, in v399 itself. frankB's 4af4645ba landed at 20:24:36Z -- a discarded managed function result had no owner, changing statement lowering for EVERY Pascal program, with 979 of 1000 string handles previously leaking. Verified: it IS in v399's tree, and there are zero full rows at that sha or at the pin tree 86c71828c; the three most recent full runs are all older. Correctly smoke-gated per CLAUDE.md, so nobody did anything wrong -- which is the point. This is normal operation, not an incident, and the manifest has to represent it honestly.

So the manifest carries two lists, never one. Known-broken, and never-measured-here. The second wants the COMMIT, because that is what makes it cheap: "if 4af4645ba misbehaves it is one commit and cheap to bisect to" is actionable; "grade: reds(13)" is not.

The positive control this needs

A grade that cannot come out reds on a red tree certifies nothing. Assert all THREE directions against real data, drawn from the pin population and not a synthetic fixture:

Not in scope

Do not add a gate. The owner's ruling is in CLAUDE.md's per-lane pin section; a change that makes any red block a pin contradicts it.

Deprioritised 2026-09-02 — the Track T tooling backlog was cut as a pile

This ticket is not being called wrong. It was moved as part of a pile, not judged individually, and nothing here disputes its finding.

Owner decision. 73 of the 74 open track: T tickets were filed between 2026-08-31 and 2026-09-02, 58 on one day. The pile was too large to work through and returned almost nothing, and a ticket nobody will fix does not sit neutrally — it stays in the ranker forever at zero value, which is the argument CLAUDE.md already makes for a terminal folder over a low prio.

Four were kept in the ranker on a purely structural test — an active umbrella or a hard blocked-by: edge from live work: umbrella-one-full-tier-run-with-no-red-tier, feature-t-freebsd-image-and-runner, and the two regression-test-core-* reds that block the umbrella.

Kept, not deleted, for two reasons: so the finding is not rediscovered and refiled from scratch by the next agent who trips over it, and so it can be pulled back if what it touches becomes load-bearing.

To revive it: move it to the owning lane's backlog, set status: backlog, and say in the ticket WHAT CHANGED to make it matter now. Restoring it because it reads well is how the pile comes back.

NOTED 2026-09-22 (frankz-e5, coordinator): prio: 85 IN low-prio/ IS A CONTRADICTION, AND I HAVE NOT RESOLVED IT

Not moved and not re-ranked — this is a report, because the ticket is the owner's and the folder was somebody's decision. CLAUDE.md defines low-prio/ as "real, probably correct, and not worth ranker attention — no plan to do it, no claim it is wrong", and ready/next never scan it. This ticket carries p85, which is near the top of every open queue. The folder and the number say opposite things, and the folder is the one that decides whether anyone sees it. One of the two is wrong and I do not know which.

How I arrived here, because it is the argument for the number rather than for the folder. I set out to file a ticket saying the pin grading vocabulary CLAUDE.md prescribes — green, or reds(N) with the manifest, recorded AT PIN TIME — is recorded nowhere. git grep -ln 'reds(' over tracked files returns 13 files and every one is prose: CLAUDE.md, four devdocs/dev/ documents, the logbook, a handover, three done/ tickets, one umbrella, and this. No tool writes it and no artefact carries it. stable_linux_amd64/default/pin.log and history.log have no grade column; the only per-pin verdict in the tree is tstate/pin-shadow.log's advisory would NOT pin, which CLAUDE.md says is a GRADE and never permission.

So the gap is real, it is exactly what this ticket describes, and this ticket was already here — filed by the owner on 2026-09-01. I did not file a duplicate because I checked first, which is the only reason this note exists rather than a second ticket.

THE LIVE COST, MEASURED TODAY. The newest full tier (a8b9a3a55094, 2026-09-22T12:37:02Z, skips: 0, skip_holes: 0) ran with compiler_sha256: fda77c48b8ee — pin v418's own binary — and reported six STILL-RED jobs. This coordinator had been carrying the pin's grade as reds(1), wrong by five, and could only find the true number by opening a tier report and counting rows. That is the whole of what this ticket asks for: a seat should be able to read a pin's grade off the pin.

What would settle the contradiction: the owner saying whether p85 or the folder is the intent. Until then it is invisible to ready/next at a number that says it should be near the front — which is the parked-folder pathology CLAUDE.md already records about the float tickets, arriving on a ticket the owner filed himself.

SHARPENED 2026-09-22 AFTER frankuser RE-MEASURED: THE RULE AND ITS IMPLEMENTATION WERE WRITTEN IN THE SAME COMMIT

The note above said the folder placement was a bulk sweep. Both of us then checked with rename detection, and the real path is better evidence than either of our first readings:

fcbfc02f5  created in backlog-tools/, prio 85
           subject: "rules+ticket: a valid pin is the fixedpoint; grade a pin, never gate it"
215debee6  modified, prio 85
696c9fab1  09:53  -> rejected/    "cut the Track T tooling backlog -- 69 rejected, 4 kept"
1d3da6ae9  09:57  -> low-prio/    with 70 others, four minutes later

fcbfc02f5 wrote the CLAUDE.md rule AND this ticket to implement it, in one commit. So the standing state is: the rule is live in the file every session pays for at startup, prescribing a grading vocabulary; its implementation sits at p85 where ready and next never look; and the vocabulary is recorded nowhere in the tree — git grep -ln 'reds(' returns 13 tracked files, all prose.

Neither folder move was a judgement about this ticket. It was bulk-cut into rejected/ with 68 others and bulk-corrected out of it four minutes later, the second step reversing the first — rejected/ means the report is WRONG, low-prio/ means real, not wrong, not now. prio: 85 was never edited at any point.

And the instrument that produced both of our first readings is itself the finding: git log --diff-filter=A does no rename detection and reported the 1d3da6ae9 rename as this file's creation, while git show --name-only | grep -c counted 71 renames as 71 new tickets. Banked with CLAUDE.md's own decayed example in debugging-playbook.md, "git log --diff-filter=A DATES A FILE'S ARRIVAL IN A FOLDER, NOT ITS BIRTH".