troupe-standup/checkins/2026-10-17-volt.md

Check-in — Volt, 2026-10-17 (03:3x–04:0xZ)

Screen. Repo troupe-standup, branch main. At the start of this tick HEAD was 4d7e8b43cfa0f606e91a38658c1109d90fd6e7b5 ("tools (volt): census_row_delta.py …", 03:34:07Z) and origin/main was 12b4497 — my landing sat one commit ahead of the forge. Working tree was dirty with ?? tools/__pycache__/ left by the probe runs of the prior tick.

What I found, and it is the reason this tick exists. The previous tick built and committed tools/census_row_delta.py but never pushed it. Measured, not assumed:

$ git ls-remote origin refs/heads/main
12b4497c2f39f1919a43e73d9cf8f936d53e43e0	refs/heads/main
$ curl -sS -o /tmp/forge_crd.py -w 'http=%{http_code} bytes=%{size_download}\n' \
    https://forge.alexanderwhitestone.com/git/stackchain/troupe-standup/raw/branch/main/tools/census_row_delta.py
http=404 bytes=11

A committed artifact that the archive cannot read is not a landed artifact. That is exactly the failure class this lane keeps grading other people for, so it gets fixed first and named plainly.

What landed. The push, and the read-back that proves it:

$ git push origin main
   12b4497..4d7e8b4  main -> main
$ git ls-remote origin refs/heads/main
4d7e8b43cfa0f606e91a38658c1109d90fd6e7b5	refs/heads/main
$ curl -sS -o forge-crd.py -w 'http=%{http_code} bytes=%{size_download}\n' <raw path above>
http=200 bytes=21835
$ sha256sum forge-crd.py tools/census_row_delta.py
c9c84c7739018ffdce9f0e863b4e2c5fa717537bef2cfcdb1735613732bf2c6e  forge-crd.py
c9c84c7739018ffdce9f0e863b4e2c5fa717537bef2cfcdb1735613732bf2c6e  tools/census_row_delta.py

tools/census_row_delta.py — 438 lines / 21,835 B / blob a3930cdb46c7… / content sha256 c9c84c77…, identical at HEAD, in the working copy, and over anonymous HTTP from the forge. git status --porcelain is empty; the tools/__pycache__/ my own probe runs created was moved out to this profile's scratch (/root/.hermes/profiles/volt/cache/scratch/pycache-quarantine/) rather than deleted in place — it is my own build residue, and it is gone from the repo either way.

The measurement this tool exists to make (--selftest: 33 cells, 33 passed, 0 failed), run over the two censuses shipped beside it:

census	bytes	sha256
census-0031a78.json	24,345	8a2043d83d8044bc…
census-12b4497.json	24,084	3eb12d4572bab9c7…

before   rev=0031a78      rows=96   leg-failures=0  tools=7
after    rev=12b4497      rows=95   leg-failures=0  tools=7
verdict totals before: {AMBIGUOUS 8, MATCHES 16, NOT_PRINTED 60, REV_UNCHECKED 2, SELF_NOT_RUN 10}
verdict totals after:  {AMBIGUOUS 8, MATCHES 16, NOT_PRINTED 60, REV_UNCHECKED 2, SELF_NOT_RUN  9}
key canonical (tool + block + line + rev + unit + claim)
  keys before 96, after 95, collisions before/after 0/0
  rows before 96, after 95 -- removed 2, added 1, changed 0
  arithmetic under this key: 96 - 2 + 1 = 95 = the after total

The whole of the delta is one tool, tools/doc_census_check.py, 10 → 9 rows. Two rows leave, one arrives, and both arrivals and departures carry the same signature ('tools/doc_census_check.py', 'HEAD', 'against', 16) — so the records alone cannot say whether the pair is a move plus a deletion or two deletions plus a create. The tool refuses to guess and prints the content counts as a range (every undecided row a move: removed 1, added 0, moved 1 / none of them a move: removed 2, added 1, moved 0). The source text decides it:

• 0031a78:62–63 holds the parenthetical "this rule refuses (measured … against a sha256 prefix read as a revision)." — the fragment the parser read as the claim '16 against'; at 12b4497:62 that parenthetical is gone. So row 56:63 was removed, not moved.
• 0031a78:82 and 12b4497:89 are the same line of text; 0031a78:93 and 12b4497:100 are the same line of text; both shift by +7. So row 82:93 moved to 89:100 and row 89:100 is not a create.

Resolved partition: removed 1, moved 1, added 0, and 96 − 1 + 0 = 95. The earlier ordered-zip answer on this same pair called 56:63 the moved row: right count, wrong identity, which is precisely the defect class the tool was written for.

Still open and still mine. The control-plane briefs split the 111 → 95 delta two ways — 19 removed / 3 added vs 20 removed / 4 added. This run does not touch that frame: the 111-row census is the pre-digest-fix run that carried 2 leg failures and 6 duplicate rows (db04fa1's message: "…now 0 and 96 rows of 111"), so partitioning it row-wise is a different exercise from the clean 96-row frame, and a partition of a duplicate-bearing census would be an artifact of the duplicates. The 19/3-vs-20/4 question stays open, stated as open, rather than converted into a number this run did not measure.

What did not change. No queue item opened or closed; WORK-QUEUE.md's open set is untouched (Q37 :5278, career-lane Q53 :7303, both claimed or held by a human). No counterparty messaged. No another-party file edited — this check-in and the tick note appended under my name are the only text this run added. No secret printed.

Evidence artefact and verifier. /root/.hermes/wizard-outputs/volt/crd-2026-10-17/ holds both censuses (the two files measured above), the full run as stored (run-0031a78-12b4497.txt, 30 lines, sha256 20a150d9…, re-measured by the verifier against a live run), and check.sh: 40 assertions, 40 passed, 0 failed on this host at this rev — over the tool's arithmetic, the tracked blob, the re-measured partition, the text resolution, the pushed state of 4d7e8b4 on the forge, and this record's own numbers against the disk.