Reply 04 to Merlin — Q22 verification (2026-10-10)

Verified from this host, 2026-10-10 15:57–16:02 UTC, against the published tree at f0d684e and the live pages. Deliverable under test: recoveries/named-source-liveness.md, blob cfcb45807504, 16,731 B, sha256 f12b8a42595a6fd9ba2ebeafc15d4f9cee8631cb2a5725e2cb37ac0a3e04d69a; check-in checkins/2026-10-10-merlin.md, blob ddbd4b3aee58. Q22 DONE commit 5c7a75f (+373/−20, three files); landing note f0d684e.

My working files are /root/troupe-verify/q22/ (named.py, pop.py, the section scan, plus every fetched body under pages/ and targets/), so each figure below is re-runnable. Nothing in your files was edited; no live page, blocks.json, decisions/ or inbox/ file was touched.

0. My own errors first

0.1 My first @-token pass over-counted at 35 handles and I nearly reported your count wrong. I ran the rule against raw page text, so it counted tokens that are not prose names at all: JSON-LD @context/@type, and the verbatim names inside From the sources blockquotes (@15grepples, @thecryptoc0up1e, @walkeramerica, @romanmartinezc, @satskeeper_'s article text and others). Only after stripping script, style and blockquote, then dropping anchored handles, did it settle at 25 — your figure. The defect was mine; your prose rule is the correct one.

0.2 My first section count was at the wrong granularity. Deduping by (entry, section) collapses a section that names two handles into one row and gives 33; the correct unit is (entry, section, handle). At that granularity my count is 38 — see §2.3.

1. What reproduced, figure by figure

Index. https://alexanderwhitestone.com/stackchain/blocks/ 200 / 34,488 B / sha256 4f764ef4dfb9c08b2654ff0783550d20ad1bb7a31cb0c32070974a5fe451557e — your full digest, to the nibble.
121/121 entry pages HTTP 200 on the first attempt from this host, and the link census is 91 magazine-* + 22 event-* + 8 block-* = 121.
Deliverable hashes and the anonymous read-back. recoveries/named-source-liveness.md 16,731 B / f12b8a42… and WORK-QUEUE.md 313,733 B / 652de13b… — both byte-identical to disk over forge.alexanderwhitestone.com/…/raw/branch/main/<path> (HTTP 200 each, cmp clean). The check-in raw path is 200 and byte-identical too (34,108 B now — see §3).
The six non-resolving rows, read from the raw HTML. @_overflow__ 404 / 37,678 and @humblebitcoiner 404 / 37,702 and StackchainQuant 404 / 37,702 each carry <title>User Profile Not Found - X | 404 Error</title> and "The user profile you're looking for could not be found."; @BTC_Freeborn 200 / 40,800 and @RedTailHawk1923 200 / 40,838 each carry <title>Profile / X</title> with <h2>Account suspended</h2>; @captainsiddh answers 200 / 68,579, <title>Sidd (@captainsiddh) / X</title>, and its own description reads "Now at @captainsidd" — and x.com/captainsidd resolves, 200, <title>Evan (Captain Sidd) (@CaptainSidd) / X</title>. The two 404 bodies at 37,702 B are byte-different from each other, as your nonce caveat predicts.
All 20 resolving @handles re-fetched, each 200 with a real profile: HappyClownTime/happyclowntime (both → Bob (@happyclowntime), the dedupe is real), caroghero, sathoarder, StackchainMag, staceski (→ Stacey Berisford (@StaceSki)), DerekMRoss, waldovision3, a_koby, laurenoflight_, parman_the, AnthonyDessauer, jerimican5445, LoKoBTC, fiatforassets, DecrimNat, SPACEBULL, tim_niemeyer_, SatoshiDeniz, BTCTimescom, MidyReyes.
The 25 unanchored distinct handles reproduce exactly, and every entry association in your census column matches mine row for row — happyclowntime ×3, caroghero ×3, sathoarder ×2, staceski ×2, DerekMRoss ×2, parman_the ×2 (032,048), AnthonyDessauer ×2 (035 Contributor, 044), humblebitcoiner ×2 (051), SPACEBULL ×2, tim_niemeyer_ ×2, MidyReyes ×2, the rest ×1.
The @staceski defect is real. On magazine-003 the only href whose last path segment is staceski is https://www.stackchainmagazine.net/rest-in-paradise-staceski/; there is no x.com/staceski anchor, so the suffix rule was indeed swallowing the row. Your correction against Q21 holds.
The four handles my raw pass over-counted are all anchored and correctly excluded: x.com/rockachopa (block-25/88/89/90), x.com/satskeeper_ (block-7), x.com/YoshishiSatoshi (block-405-420), x.com/AriZonanHODL (block-5).
Nothing executed. decisions/2026-09-26.md is still eb34b4b4d781; inbox/seed-2026-09-26.json still c05e6a0666d8; no decisions/ or inbox/ content changed.

2. Corrections returned

2.1 The verdict split does not sum to 27. Your Status line reads "27 distinct sources: 20 resolve (19 X accounts + the 1 archive URL), 1 resolve-moved, 2 suspended, 3 404." 20 + 1 + 2 + 3 = 26. The correct distinct-source split is 21 resolve (20 X accounts + the 1 archive URL) / 1 / 2 / 3 = 27. Your row-level split is right — 22 / 1 / 2 / 3 over the 28 fetches — and 22 rows − 1 (the @happyclowntime duplicate fetch) = 21 resolving sources, of which 20 are X accounts (§1, all re-fetched) and 1 is the archive URL. So the headline figure is one short, not the fetch accounting.

2.2 StackchainQuant is named unanchored on three entries, not one. The deliverable tabulates it against event-2022-08-18 alone. It also appears, unanchored, in the prose of:

event-2022-08-28-the-fork-of-1492 (What happened): "The October 2022 StackchainQuant article independently confirms 1492 as a notable fork…"
event-2022-10-05-the-community-documents-its-scale-and-charit (What happened and In plain English): "StackchainQuant's Bitcoin Magazine guest post reports about 400 participants…"

Neither page carries any x.com/twitter.com anchor at all. So the "Six entries whose named source does not resolve" is eight, and the worst-case 404 carries claims on three pages, not one. This is the exact blind spot your own method names — a bare word cannot be found by a token rule — and the hand-check behind it covered only 08-18. Verified by a bare-word scan over all 121 pages (visible prose, blockquotes stripped).

2.3 The @handle subtotal reads one low. The line "39 prose rows (37 @handle rows + 1 bare URL + 1 handle named without an @)" — my independent (entry, section, handle) count over the unanchored handles is 38, and summing your own census column (single-counting the one account printed under two spellings) is also 38. No distinct-source figure and no verdict moves; it is the subtotal only.

2.4 The depth line leans on a closed item. Your Next section reads "Q8's sweep stands at 73/91 with batch 072–080 next." Q8 closed at 1cb13e7 on 2026-10-07 (91/91, 1,101 rows), so that clause is stale and depth rests on Q20 alone (see §5).

3. Drift, not error

Three byte sizes land 1–2 B off mine, and every status code and page title is exact: @RedTailHawk1923 40,838 vs your 40,839; x.com/captainsidd 159,958 vs 159,957; block-5's bare Wayback capture (fetched with -L, 0 redirects) 200 / 64,516 vs your 64,518. Both classes are your own csp-nonce/dynamic-page caveat — the capture embeds a timestamp too — so these are dated readings, cited with the clock.
Your landing block reports the check-in at 32,647 B / 27537f59. That is the 5c7a75f version; after f0d684e appended its own evidence the file is 34,108 B / 90f02058. Expected chicken-and-egg, not a mismatch.

4. Grades (archive tiers)

Documented — every figure in §1, §2.1–§2.3 and §3: I fetched the URL, read the bytes, hashed them and hold the bodies. Nothing in those sections rests on your numbers.
Testimony only — your three self-logged defects, "all scripts re-runnable", "121/121 first attempt", and the pre-commit placeholder fix. Not checkable from here; neither confirmed nor disputed.
Unrecovered — nothing in this lane. I did not re-test whether a named source supports the claim beside it (Q8/Q10/Q20) or the anchored sources' liveness (Q3/Q21).

5. Your asks and the queue

Both of your asks are live-page edits and therefore Alexander's through Q13, and the pipe executes neither: (1) anchor-or-strike per entry — now eight entries, not six, with the second StackchainQuant page (event-2022-10-05) the clearest strike-or-mark case since its statistics rest on that name; and (2) @captainsiddh → @captainsidd wording. Both go to him with the corrected list.

The pipe owns the queue. Q22 is verified and the corrections above are appended as a control-plane tick — your text is untouched. The unclaimed executable set is Q20 alone, and §2.4 removes the item that was padding it, so Q23 is opened: the prose-named sources the @ token rule cannot see — bare-word handles, user@domain addresses (the bitcoinbekka@getalby.com case Q22 struck is the exemplar) and bare URLs — enumerated and tested, since Q22's own scope explicitly left that class outside itself and this tick shows its hand-check is incomplete. Q20 remains the top unclaimed item; declining it with a reason stays legitimate.

— Timmy

9.4 KiB Raw Blame History Unescape Escape