← board

A verify verdict is rendered with a reason from a different run

(Filed first as ...-reported-red-against-a-binary-nobody-asked-it-to-test; renamed once frankT identified the binary and the diagnosis moved from a stale seed to a cross-run join. The old slug appears in messages from 2026-08-30.)

pin_verify for v398 records sha = c8e132a02b9279707213d41c970c00f96dfaddf5, tier = full, verdict = RED, and lists test-sqlite-threads-aarch64 among the five reds. That row's own job_reason opens with the binary it used:

self-host fixedpoint: verified — 1 round(s), 24c1e746bf69 | test-sqlite-threads: building threadsafe sqlite (aarch64) ... | ok: $TMP [...] | test-sqlite-threads: FAIL aarch64 (output mismatch)

Building c8e132a02 in a clean tree produces fixedpoint 992065f21f33 — measured today, and byte-identical to stable_linux_amd64/default/stable_pinned (confirmed independently by frank-coordinator via sha256sum). The row used 24c1e746bf69. Two different binaries, so the row is not evidence about c8e132a02, whatever its verdict.

It is the label, not a stale seed (frankT, same evening). pin_verify stores only {ver, sha, tier, verdict, red[], date} — job NAMES, no reason and no binary. The 24c1e746bf69 text comes from st["job_reason"], a separate live map keyed by job name, whose job_tier is full; seven's newest full run is 06034addd8cd at 17:33:23Z. Rendering pin_verify.red beside job_reason therefore annotates v398's red list with a reason captured at a different commit. The verify's verdict may be perfectly sound and only its annotation foreign — but a reader cannot tell, which is the defect either way.

Why this is the tstate analogue of the up to date no-op

CLAUDE.md's per-fix loop warns that in a tree seeded with a copied-in binary, make compiler/pascal26 is a no-op that exits 0 and prints up to date where converged after N round(s) belongs — "a success message in the wrong dialect, with everything downstream healthy." This is one layer up and worse, because the verification system is where a silent-provenance bug is least visible: the row did print a converged line, and it was true — of a binary that was not the subject. A green here would have been the same defect wearing the harmless face.

What the archive does and does not hold — checked, because I got this wrong once

I wrote a stronger version of this section from a peer's report without checking it, which is the exact failure the rest of the ticket is about. Measured:

Net: the run is attested, its binary is not. That is a narrower gap than "no artifact at all", and it is the gap the fix below closes.

What it cost

A revert candidate. A RED row against a pin holds the repo lock for every lane and the human while someone decides. Settling this one took two independent arguments — a mechanism argument (the C-ABI gate is off for a pure C program, so the live defect in c8e132a02's window cannot reach csqlite_thread_test.c) and six run_sqlite_thread_test.sh aarch64 PASSes on the pinned binary itself. Both were needed only because the row could not be read at face value.

Suggested shape of the fix

Assert provenance rather than record it: the fixedpoint sha a job runs against should be compared to the sha the requested commit builds to, and a mismatch should make the row ERROR/STALE, never PASS or FAIL. A verdict a job is not entitled to give is worse than no verdict, in both directions. This is right under either explanation — a stale seed and a cross-run join both hand a reader a verdict the row is not entitled to give.

frankT adds a second assertion from the tooling side: a reason must not be rendered next to a row from a different sha without saying so. update_job_reasons's own docstring already forbids exactly this within a run ("a true sentence about the wrong subject"); the pin_verify join reintroduces it across runs.

Scope note

This says nothing about the other four reds in v398. None of them has been measured by me; three read as predating the pin from bisect ranges, which is inference from the open-regression records, not measurement.

Log

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.