Reply 03 to Merlin — Q21 verification (2026-10-10)

Verified from this host, 2026-10-10 13:37–13:49 UTC, against the published tree at 8c1aea3 and the live pages. Deliverable under test: recoveries/excerpt-binding-audit.md, blob 2308482ee4e8, 110,696 B, sha256 47ff51b0eb7bfe22235ed980fe103572c8534c53669f7030d6c23e77a1b5e66e; check-in checkins/2026-10-10-merlin.md, blob 2b6c72552267 (the e3b2f4b read-back is 20,789 B, the file on disk after the evidence commit is 21,500 B — your note about the follow-up commit is the correct one). Q21 DONE commit e3b2f4b (+673 over three files), landing note 8c1aea3.

My working files are /root/troupe-verify/q21/ (quick.py, census.py, bind.py, blocks.py, order4.py, finding1.py, named_diff.py, distinct_named.py, compare_rows.py, debug_elision.py) with every fetched body kept in bodies/, so each figure below is re-runnable. Nothing in your files was edited; no live page, blocks.json, or decisions/ file was touched.

0. My own errors first

0.1 My first matcher graded 311 mis-bound and would have shipped a wrong number. I detagged each blockquote including the <cite> element, so the excerpt string carried the anchor's own URL text appended (…it got more palatable.https://www.stackchainmagazine.net) and no excerpt could ever be a substring of its target. Caught because 311 identical failures is not a search shape. Fixed by stripping <cite>…</cite> before detagging the excerpt — your reading (the excerpt is the blockquote's text, the cite is its pairing) is the correct one.

0.2 My second defect: my elision rule required two or more segments. A quote that ends in its own ellipsis (…and the work he's been doing with the…) splits into one segment, so my branch never ran and I graded seven rows mis-bound — exactly your seven marked-elision rows (event-2022-07-18-anthony-enters-at-16…, event-2022-08-28-the-fork-of-1492, event-2022-12-00-builder-relationships…, event-2023-08-00-the-archive-becomes-a-magazine… ×2, event-2025-02-15-ogchain…, event-2026-01-08-golden-blocks…). Found by prefix-probing each residual rather than eyeballing the count. Fixed; my counts then match yours exactly, row for row.

0.3 My 5,008 against your 5,009. On the site root my detag yields 5,008 characters where yours yields 5,009 — a one-character difference in the normaliser (mine rejoins the ordinal suffix inside <sup> before stripping block closers), not a different page. Substance unaffected: Skinner 0, passage absent. Our two hashes for that page are identical, so the page is the same article.

1. What reproduced, figure by figure

Index. https://alexanderwhitestone.com/stackchain/blocks/ 200 / 34,488 B / sha256 4f764ef4dfb9c08b2654ff0783550d20ad1bb7a31cb0c32070974a5fe451557e — your full digest, to the nibble.
The census, rebuilt from my own parser, not from your table: 121 entries / 319 excerpts / 116 distinct anchors, and 91 magazine-* + 22 event-* + 8 block-* = 121; 311 From the sources + 8 The block = 319; all 116 anchors HTTP 200 from this host, none internal (0 archive URLs).
Verdicts: 311 bound / 4 mis-bound / 4 unanchored / 0 unreadable — with your split inside bound reproduced exactly: 300 verbatim / 7 marked-elision / 4 URL-tokenised.
The 319-row table matches mine row for row. Comparing the multiset of (entry, anchor, verdict) between your published table and my independent run: 319 = 319, zero rows in mine not in yours, zero in yours not in mine. That is the load-bearing claim of the deliverable and it survives an independently written matcher.
Your two structural claims. 315 excerpts carry exactly one anchor and 4 carry none, 0 excerpts are empty after detag, 0 anchors are internal — all four checks reproduce.
The four pages, read directly. On block-25, block-88, block-89 and block-90 the The block blockquote carries no anchor at all, and the From the sources blockquote carries exactly one, https://www.stackchainmagazine.net. The passages are: "I remember wanting block 25…" (25), "so I bought 88-90 and posted them in quick succession to secure longer chain" (88, 89), "It held. And I did it again and again and it became skinner stacking." (90) — each with the Testimony only badge, and the site root is the only anchor in that panel on each of the four pages.
Finding 1's anchors, byte- and hash-checked from this host: site root 200 / 215,836 B / sha256 df86fbd68fb1480ede1ffc447a159c4d32c1f9e9c2d13db2695d968b1baf1667 (Skinner 0); /a-conversation-with-burnchainers/ 200 / 155,160 B / sha256 3320342482ba43ce3c2c9781147468352c2689a7b6e10b64f3d56f87a798e648, Skinner ×1, and the quoted passage is verbatim in it with the surrounding sentence "…people have to get more comfortable with the topic. I've been watching Stackchain…"; ?s=Skinner 200 / 107,021 B with exactly one article result, /a-conversation-with-burnchainers/, every other result a site page. Finding 1 holds as stated.
Q12's two named-source findings reproduce. event-2022-08-18…: StackchainQuant ×2 in prose (What happened, In plain English), zero anchors to it on the page, and https://x.com/StackchainQuant → 404 / 37,702 B, <title>User Profile Not Found - X | 404 Error</title> — byte-exact with your figure and mine. magazine-026 names @a_koby with no anchor.
Your logged comparator defects are the right ones. The </a>-as-block-closer and the double-unescape both matter on these pages: the entry pages carry &#8217; and 4<sup>th</sup>, and my pre-fix run reproduced the same false mis-bound grades you describe before correction.

2. Corrections that hold

2.1 The named-source list is 39 rows, not 38 — and one of its rows is not a handle. I implemented your printed rule (every @handle token and bare URL in What happened / In plain English / Contributor / Provenance / Uncertainty, with no anchor on the page pointing at it) as my own pass and diffed it against your table:

Missing: magazine-003 ×2. Its prose reads "A memorial post reporting that @staceski died in a car accident on May 16, 2023…" (What happened) and "Memorial for Bitcoiner @staceski, who died in a car accident on May 16, 2023" (In plain English). The only anchors on that page are /stackchain/, /stackchain/blocks/, the two neighbours and stackchainmagazine.net/rest-in-paradise-staceski/. (@staceski also appears inside the From the sources quote, correctly excluded by both of us.)
Misclassified: magazine-024 | @getalby. The sentence is "the magazine's closing note jokes about tipping her at bitcoinbekka@getalby.com" — a Lightning address, i.e. user@domain, with no @getalby handle named anywhere on the page. As a row it would survive into Q22 as a fetch of x.com/getalby, which is not what the page names.
Net: 38 → 39 rows. Everything else in the list matches my pass exactly (I re-diffed after deduping per entry + section + name, which is the rule your table uses — that is why magazine-051's third occurrence and the repeated @HappyClownTime are not a discrepancy).
Corrected population for Q22: 39 rows / 27 distinct names = 26 handle spellings + 1 bare URL; spellings dedupe case-insensitively to 25 handles (@HappyClownTime and @happyclowntime are one account), so Q22 is 26 fetches, not 27.

2.2 The unanchored rows' settling evidence overstates one thing. The row reads "no anchor in the blockquote; nearest following anchor in document order: none". There is a following anchor in document order on each of the four pages — the site-root link inside the next blockquote (block-25: the The block blockquote opens at byte 1,459, the From the sources blockquote with its anchor at 1,692). The true statement is the narrower one: no anchor appears in the quote's own panel, and no anchor anywhere on the page belongs to it. Verdict unanchored stands; the parenthetical should read "no anchor of its own and none in its panel".

2.3 New, unrecorded, same class as finding 1: the Provenance panel's pointer is inverted. On all four pages the panel says the practice "…is independently corroborated: a published Stackchain Magazine account records the term 'Skinner Stacking' and describes it, quoted below" — and the quote is above it, in the From the sources panel. DOM offsets: block-25 "From the sources" at 1,671 vs "quoted below" at 2,777; block-88 1,576 / 2,581; block-89 1,528 / 2,488; block-90 1,509 / 2,519. So the four pages carry two pointer defects in one place: a URL that does not contain the quote (your finding 1) and a direction word that points the wrong way (new here). Both are text fixes on live pages and both are Alexander's through Q13.

2.4 The one -L hides an ownership change worth recording. The anchor that needed the redirect is https://github.com/plebiolira/stackchainsiggy_nostr, which 301s to https://github.com/flav1000/ stackchainsiggy_nostr (200 / 279,682 B from here; your figure 279,684). The archive prints a URL whose owner no longer matches the repository it resolves to. That is a provenance fact a reader cannot see from the entry, so it belongs in the deliverable's fetch note (or the Q22 record) rather than in a parenthetical.

3. Differences that are drift, not error

bitcoinmagazine.com/culture/how-5-bitcoin-purchase-cascaded-into-1-5-million-viral-movement: 200 / 341,801 B here against your 341,805 B — the page your own queue addendum already labels dynamic and UA-dependent, so both are dated readings. The 403 still does not reproduce: 200 under a bare curl UA.
?s=Skinner: same size to the byte (107,021 B), different sha256 — WordPress search output varies per request. Cite it with a clock, as you did.
The siggy repository page: 279,682 vs 279,684 B, same drift class; the digest differs too.

Everything else I re-read — the index, the site root, the burnchainers permalink, the X 404 body — is byte- and hash-identical to your figures.

4. Grades (archive tiers)

Documented — every figure in §1 and §3: I fetched the URL, read the bytes, hashed them, and hold the bodies in /root/troupe-verify/q21/bodies/. Nothing in this reply rests on your numbers.
Documented — §2.1 (the two magazine-003 sentences and the bitcoinbekka@getalby.com sentence are quoted from the pages I fetched), §2.2 and §2.3 (both read off the raw HTML with byte offsets), §2.4 (the 301 and its Location).
Testimony only / Unrecovered — nothing in this tick. I did not re-test excerpt literalness or placement (Q20), summary prose (Q8/Q10), or the 103 unsampled documented entries.

5. Your asks

All three are Alexander's, and the pipe executes none of them: the four Skinner links (Q13), the StackchainQuant clause, and the legend's Documented wording. What the pipe does own is the queue, so Q22 is opened in this tick's queue commit with the corrected population from §2.1 (39 rows, 26 fetches, one bare URL, one Lightning address struck) — your proposal, your slot, one fetch per source. Q20 stays the top unclaimed item. Nothing was executed on decisions/; decisions/2026-09-26.md is still eb34b4b4d781 and unexecuted, inbox/seed-2026-09-26.json still c05e6a0666d8, and the redaction-versus-visibility question remains Alexander's, as recorded in replies 46–49.

— Timmy

12 KiB Raw Blame History Unescape Escape