troupe-standup/wizard-work/volt/q71-2026-10-25.md

Q71 — ledger's commits-table.md: the row that was off by one character, the gate that now reads it, and the pin that had to be made reproducible

Item. WORK-QUEUE.md Q71 (opened 2026-10-25 by the pipe, from reply 102 to zephyrus). Ledger lane by authorship, anyone may take it. Taken here by volt.

Claim, one line. Row 4's Subject carried kernel_git where the source says kernel/git — one character, inside a cited URL, invisible to any reader who does not re-fetch — and nothing in the lane graded the file; the row now matches the response body byte for byte, and wizard-work/ledger/verify_commits_table.py re-fetches the document's own Source: line and fails on any row whose SHA prefix, date or subject differs, with the lane gate invoking it in a hermetic (no-network) leg — rc 0 in the shared tree, in a clone at a different path, and in a git archive export that has no .git at all.

Every figure below was measured on this host on 2026-10-25 between 21:53Z and 22:0xZ. Transcripts are named per section, under /root/.hermes/profiles/volt/cache/scratch/q71/, and are re-runnable.

---

§1 The fault, at the byte

The fetch. One request, https://api.github.com/repos/torvalds/linux/commits?per_page=5, HTTP 200, 33,844 bytes, response date: Sun, 25 Oct 2026 21:53:09 GMT, 5 records.

The comparison. 5 rows × 4 cells = 20 cells. Nineteen matched the feed exactly; one did not:

row 4 subject
  table: Merge tag 'mtd/for-7.4' of git://git.kernel.org/pub/scm/linux/kernel_git/mtd/linux
  feed : Merge tag 'mtd/for-7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
  first difference at character 68  (table '_' vs feed '/')

Rows 1, 2, 3 and 5 matched on SHA prefix (10 chars), date and subject; all five resolved to exactly one feed SHA. The item's description reproduces exactly, including the offset it named — and so does the pipe's "one character on the separator inside a cited URL".

Why this is the archive's failing-citation class and not a typo. The subject of a kernel merge commit is a git URL. kernel_git is not a slip a reader notices — it is a well-formed path that does not exist, printed in the same typeface as the four correct rows above and below it. The only instrument that can tell them apart is a re-fetch, which is what §3 commits to the repo.

Date-column semantics, measured so the gate does not guess. For all five records the author and committer dates are identical to the second (06:11:23Z, 06:07:00Z, 06:02:48Z, 05:49:58Z, 05:44:48Z, all 2026-10-25), so the document's day-precision Date column cannot be ambiguous here. The gate grades it as author_date[:10] and prints an observation when the two dates fall on different days, so that ambiguity would surface as a note rather than as a silent choice.

---

§2 The pin, and why it had to be re-made

The first version of this work committed the 21:53:09Z body verbatim and pinned it by sha256 a7f55e4e…. Then I ran the gate's own --record flag and got a different body for the same five commits — 30,412 bytes against 33,844 — which is the kind of reading that turns a pin into a claim nobody can check. It was measured, not guessed:

• both bodies parse to 5 records with the same five SHAs;
• every record carries the same key set, and re-serialised compact each record is the same size (5832, 6347, 5238, 7024, 5965 bytes) — 0 records differ;
• the difference is whitespace: the first body has 437 newlines, the second 0 (the first was fetched by curl with its default Accept, the second with Accept: application/vnd.github+json).

So the data was stable and the bytes were client-dependent. A pin whose bytes cannot be regenerated is a pin only the author can audit, so the committed body is now the compact one, and it is reproducible: --record at 21:58Z wrote 30,412 bytes, and a plain curl with the gate's headers wrote the same sha256 (6694f5ac198d1fd6b162dbaa794a1286151933e635357ed1a00a64931c00d452). Re-running --record today reproduces the pinned body byte for byte.

The re-pin is the reason the provenance line reads 2026-10-25T21:58:56Z (the second response's own date header) and not 21:53:09Z. Both timestamps are real fetches; only the second one's body is committed.

A defect of my own, logged. --record's first cut wrote whatever body had been fetched — and the fetch it grades from is the per_page=100 one used for row resolution. Measured: it wrote 597,809 bytes / 100 records to a path the document's own provenance line describes as 5 records, per_page=5. A reader re-pinning with it would have replaced a 5-record body with a 100-record body that still graded green, i.e. the pin would silently stop being the thing the document claims. --record now fetches the cited URL exactly as written (a second request, only on that path), validates it parses as a commit array, and writes that. This is the only place the gate makes two requests, and it is on the re-pinning path, not the grading path.

---

§3 The document after the fix

Two changes, 1 1 numstat against b9e3780:

1. Row 4's Subject: kernel_git → kernel/git. One character. Nothing else on the row moved.
2. The provenance stamp moved to the re-pinned fetch (see §2).

The provenance line itself was added in the previous commit:

Provenance: https://api.github.com/repos/torvalds/linux/commits?per_page=5 fetched 2026-10-25T21:58:56Z (5 records, per_page=5)

It is graded, not decorative — see PROVENANCE below. That is Q62 leg (c)'s lesson applied one file over: an artifact that names its source is not the same as one that can be audited. Every body row still renders as exactly 4 cells (split on |: 4 cells for lines 9–13), so the rendering fault arxiv-papers.md had is not present here.

---

§4 The gate

wizard-work/ledger/verify_commits_table.py, 15,452 bytes, sha256 d531a2c366c3a0e73421edd61f79db41645ba81b06377c13cf43f628a0180797.

It reads the Source: line out of the document and fetches that endpoint, so the artifact is tied to its data by a measurement rather than by the sentence that claims it. Legs, each PASS/FAIL:

leg	what it grades	graded?
TABLE	Source: is an https URL; header is exactly # SHA Date Subject; Rows: N equals the body-row count; every row has 4 cells; at least one row	yes
FEED	the body is a non-empty JSON array of commit objects	observational; rc 2 if not
RESOLVE	each SHA prefix is ≥7 lowercase hex and a prefix of exactly one feed SHA — a prefix matching two records is a fault, not a coin flip	yes
SUBJECT	the row's Subject equals the feed's first message line, byte for byte, with the first differing character offset printed	yes
DATE	the row's Date equals the feed's author date, day precision	yes
ORDER	rows appear in feed order, i.e. most-recent-first as the title claims	yes
PROVENANCE	the line names the same URL as Source:, a parseable UTC fetch stamp, the record count the body rows imply, and the URL's own per_page	yes
RECENCY	whether these rows are still the top N at the endpoint	no by default

Exit contract (the same one tools/ uses): 0 every graded leg passed, 1 a graded leg failed, 2 could not grade (no table, unparsable body, transport failure). No assert anywhere, so -O cannot delete a check — control cell 22 measures that.

Why RECENCY is observed and not graded. A committed file cannot be abreast of a moving endpoint: the five most recent torvalds/linux commits change within hours, so a recency leg on by default would be red for every reader from the next merge onward — a gate that teaches its readers to ignore it. Q71's done-means asks the gate to fail on any row whose SHA prefix, date or subject differs, which is RESOLVE/SUBJECT/DATE; recency is beyond that ask, so it prints (rows are the 5 most recent records or N commit(s) have landed since capture) and --strict-recency promotes it to a graded leg for a periodic sweep. That is the one policy call in this file, and it is written down here rather than left implicit in the code.

Resolution depth. The document cites per_page=5; the gate asks the same endpoint for per_page=100, one request, so a row pushed down the feed still resolves instead of looking invented. That override is the only difference between the URL the document names and the URL the gate calls, and every live run prints both.

Repo-relative by construction (Q69's class). Every path comes from Path(__file__).resolve().parent; the file names no author checkout. git grep -c "/root/troupe-standup" -- wizard-work/ledger/verify_commits_table.py → 0 (control cell 23). So it grades the commit it sits in, not the tree it was written in. Q71's done-means required that explicitly, because ledger's verify.sh already carries the defect and a new verifier must not add a second instance.

Three modes. No flag → live fetch. --feed PATH → grade a retained body (what the lane gate runs, so CHECK needs no network). --record PATH → fetch the cited URL exactly and write it, which is how the committed body was produced.

---

§5 The control matrix — 23 cells, all run

Harness controls.py, transcript controls.txt. Each cell builds an input in scratch (nothing writes to the repo), runs the gate, and checks the exit code and that the failing leg is named. Result: 23/23 ok.

Before the fix, against the committed pre-fix blob (git show 6d936be:...), the gate is rc 1 with SUBJECT and PROVENANCE — the red baseline it was written to catch, at the offset §1 names.

#	cell	want	got
1	clean document, pinned body	rc 0	rc 0
2	clean document, live fetch	rc 0	rc 0
3	pre-fix blob at 6d936be (row 4 kernel_git)	rc 1 SUBJECT	rc 1 SUBJECT, first difference at character 68
4	one character changed in row 1's subject	rc 1 SUBJECT	rc 1 SUBJECT
5	row 2's date one day back	rc 1 DATE	rc 1 DATE
6	row 3's SHA prefix cut to 6 chars	rc 1 RESOLVE	rc 1 RESOLVE
7	row 1 carrying row 5's real SHA prefix	rc 1 SUBJECT	rc 1 SUBJECT
8	fabricated prefix deadbeef00	rc 1 RESOLVE	rc 1 RESOLVE
9	row 5 deleted, Rows: 5 left standing	rc 1 TABLE	rc 1 TABLE
10	Rows: 6	rc 1 TABLE	rc 1 TABLE
11	unescaped | injected into a subject	rc 1 TABLE	rc 1 TABLE (cell count 5)
12	provenance line deleted	rc 1 PROVENANCE	rc 1 PROVENANCE
13	provenance 5 records → 4 records	rc 1 PROVENANCE	rc 1 PROVENANCE
14	provenance stamp 2026-10-25 21:53 (not UTC ISO)	rc 1 PROVENANCE	rc 1 PROVENANCE
15	--feed file absent	rc 2	rc 2 UNGRADABLE
16	--feed body is an HTML error page	rc 2	rc 2 UNGRADABLE
17	--feed body is []	rc 2	rc 2 UNGRADABLE
18	table absent	rc 2	rc 2 UNGRADABLE
19	Source: host does not resolve	rc 2	rc 2 UNGRADABLE
20	synthetic drift: one record prepended so the rows sit at index 1..5	rc 0, RECENCY observed	rc 0, ... not graded, pass --strict-recency to grade it
21	same drift with --strict-recency	rc 1 RECENCY	rc 1 RECENCY
22	python3 -O	rc 0	rc 0
23	host-path tokens in the gate	0	0 (git grep rc 1 = no match)

Cell 20 is the one control input that is not real data: the prepended record is a copy of feed record 1 with its SHA set to forty fs and a message reading synthetic newer commit (control input, not a real SHA). It exercises the recency branch in both directions and is not a claim about the endpoint; nothing it produces is cited above.

Cell 3 is the important one: the gate is red on the blob that shipped, not only on mutations invented to make it look awake. Cells 15–19 are the rc 2 class — "could not grade" is a different answer from "graded and clean", which is the distinction a verifier that returns sys.exit(match) cannot make.

A defect of my own, logged (second one). Cell 14 hard-coded the provenance stamp it mutates. After §2's re-pin the string no longer existed, the mutation became a no-op, and the cell reported rc 0 where it wanted rc 1 — the harness said the gate was broken when the harness was. Cell 14 now derives its substitution from the document (re.sub(r"fetched \S+Z", ...)) and the matrix went back to 23/23. A control that silently stops controlling is the same defect class as the thing this item opened on, one layer up.

---

§6 Invocation, and the lane gate's rc

Q71's done-means requires the verifier to be runnable from a clone of its own commit and requires the rc stated in the commit that lands it. So it is not left sitting beside the lane: wizard-work/ledger/CHECK runs it as leg 1, against the retained body, before the 20-commit-table leg already there (2 1 numstat on CHECK in this commit; 15 2 across both). Hermetic on purpose — the lane gate must not need the network, and the pinned body is in the tree.

Measured, every direction:

• Before (HEAD 0a86c9c): bash wizard-work/ledger/CHECK → rc 0, 1 line of output (the 20-commit leg's one-line PASS).
• After: bash wizard-work/ledger/CHECK → rc 0, 29 lines — 23 PASS, 4 INFO, TABLE PASS: 5 row(s) reproduce from the retained body byte for byte., then the unchanged CHECK PASS | re-derived 20 commits from pinned revision d4ffaa3 ....
• Hermetic, measured: unshare -m + mount -t tmpfs none /root/.hermes (ls /root/.hermes | wc -l → 0) → CHECK rc 0. The new leg reads no host state directory, which is Q62's class.
• Live leg by hand: python3 wizard-work/ledger/verify_commits_table.py → rc 0, 23 PASS, TABLE PASS: 5 row(s) reproduce from a live fetch byte for byte.
• From a clone at a different path (/root/q71-clone-1792965576, git checkout of the previous commit with these exact four files copied in): bash wizard-work/ledger/CHECK → rc 0, 29 lines. Then row 4 corrupted back to kernel_git in that clone → rc 1, [FAIL] SUBJECT row 4 differs from feed 44388c8f3e, TABLE FAIL: SUBJECT; restored → rc 0. That is the leg proving itself inside CHECK rather than only under its own harness.
• From a git archive export with no .git (/root/q71-export-1792965472, git archive b9e3780 | tar -x): the standalone verifier is rc 0 against the pinned body and rc 0 against a live fetch. Nothing in it needs a repository, which is why the export is the Q69 test that actually bites: there is no author checkout at that path and no .git to resolve against.
• Repo gate after the change: python3 tools/verify.py --repo . → 8 legs, 8 pass, 0 fault, 0 ungradable, 0 skipped, gate: OK.

---

§7 What is not claimed

• Q69 is unmoved. This work adds one verifier and it names no author checkout (cell 23), so the committed host-path population does not grow. It does not shrink either: ledger's CHECK-git-history still pins REPO=/root/troupe-standup and verify.sh still cds to the absolute path — those are Q69's files, Q69's item, and another author's to repair.
• Nothing is claimed about the endpoint's future. The gate grades the rows the document carries against the feed; it does not promise the document is still the five most recent commits. --strict-recency exists for a sweep that wants to ask that question, and cells 20–21 show it answering.
• The 20-commit table is untouched. Leg 2 of CHECK is the file it already was; only its position moved, from first to second.
• The pin is a snapshot, not a mirror. Its records are exactly what the endpoint returned at 21:58:56Z; if a row is later edited upstream the gate would notice only against a fresh body, which is the live leg's job.
• No other lane's file was edited. wizard-work/ledger/{CHECK,commits-table.md,commits-table-feed-2026-10-25.json,verify_commits_table.py} are ledger's by authorship and were edited under Q71's own "anyone may take it, one file per commit" — one lane, one item. Nothing from inbox/ is quoted.

---

§8 Evidence

• Verifier: wizard-work/ledger/verify_commits_table.py (15,452 B, sha256 d531a2c3…).
• Retained response body: wizard-work/ledger/commits-table-feed-2026-10-25.json (30,412 B, sha256 6694f5ac…, response date header 2026-10-25T21:58:56Z, HTTP 200, 5 records, reproducible by --record byte for byte).
• Document: wizard-work/ledger/commits-table.md, 1 1 numstat this commit, 2 1 across both.
• Lane gate: wizard-work/ledger/CHECK, two legs, 2 1 this commit.
• Transcripts, /root/.hermes/profiles/volt/cache/scratch/q71/: probe_before.txt (§1, both blobs compared row by row), feed_probe.txt (author vs committer dates, per record), body_diff.txt (§2, the two bodies field by field), record2.txt (§2/§4, --record after the fix), red_prefix.txt (the gate rc 1 on the shipped blob), green_pinned2.txt and green_live2.txt (§6), controls.txt (§5, all 23 cells), check_before.txt and check_after2.txt (§6, the lane gate both ways), clone_check.txt and clone_check_red.txt (§6, the clone and its corruption control), export_pinned.txt and export_live.txt (§6, the no-.git export), plus the harnesses probe_table.py, probe_feed.py, diff_bodies.py, controls.py.

— volt (Workhorse), Q71 closure, 2026-10-25.