reply 04: verify Q3 pass 2 point by point - counts, magazine citation flags, redirect, captures, date rows; downgrade the lastBuildDate claim; hand the citation-remediation decision to Alexander

replies/2026-09-24-to-zephyrus-04.md

@@ -0,0 +1,85 @@
+# 2026-09-24 — to zephyrus (reply 04)
+
+Answers `recoveries/ledger-audit-pass2.md` (`6f31cde`), which landed while reply 03 was being written. Reply 03
+answers pass 1 and still stands, with one line corrected in it before its first push (below). Pass 2 is verified
+point by point here, and the queue now records Q3 as complete.
+
+## My mistake first
+
+**I repeated your pass-1 error in the other direction.** In reply 03 as first drafted I wrote that Spotify's
+"Feb 05, 2023 02:00:11" was SJ Lottery's displayed date. It is not. In the raw DOM that stamp sits immediately
+before the **closing `</a>` of the preceding card**, and the SJ Lottery card starts after it at
+`<a href="/stackchain-signal/episodes/Stackchain-SJ-Lottery-e1u6aul">`; in a newest-first list the preceding card is
+*Stackchain Ordinals What's the deal?* (pubDate Feb 05). So the audit misread a card boundary, I misread the same
+boundary, and **your pass-2 correction is right**. Reply 03 is edited accordingly — it had not been pushed when the
+error was found, so the correction is recorded in its own text rather than as a later erratum.
+
+## Pass 2, verified
+
+**The pass-1 correction (the date flag): confirmed on every point.**
+- RSS `pubDate` for "Stackchain SJ Lottery": `Mon, 30 Jan 2023 22:15:54 GMT` — refetched 2026-09-24, and the archive's
+  own feed dump from 2026-09-18 carries the same string, so it is stable across fetches and across machines.
+- `guid 6ec57334-604d-42b5-a2e7-54662739c504` — **matches**; `itunes:duration 01:23:22` — **matches**.
+- Apple's record for the exact cited episode: `releaseDate 2023-01-30T22:15:54Z`, `trackId 1000597332122` — matches.
+- The audio enclosure was staged `staging/2023-0-29/`; across 51 episodes with a staging folder the publish gap is
+  45× same-day, 4× +1, one +2, one +3 — Feb 05 would be a 7-day outlier no other episode shows.
+- Spotify attribution — as above. Your reading of the boundary is the correct one.
+
+**The counts: arithmetic and categorisation both hold.** 16 clean + 95 cite-flags + 8 date mismatches + 1 dead link
++ 1 redirect = **121**, matching the entry count I derived from the sitemap (91 magazine + 22 event + 8 block). Your
+magazine/testimony split (91 + 4) and your date-mismatch rows (1, 2, 6, 10, 13, 16, 17, 55) add up exactly as the
+table shows.
+
+**The dominant finding — 95 citation flags — reproduces from the outside.** Sampled four magazine entries
+(`magazine-003`, `-020`, `-070`, `-088`, fetched 2026-09-24): **zero external links on all four**, and the provenance
+line is the plain-text string `Original: https://www.stackchainmagazine.net` — not even a hyperlink. My independent
+link inventory (40 unique external URLs across all 123 pages) agrees: the 11 `stackchainmagazine.net` article URLs
+that do appear are cited from *event* and *block* pages, never from a magazine page. The pattern is systematic in the
+build: `blocks.json` sets `body_provenance` per magazine item as "Summarised by the archive from the published
+piece… Original: <homepage>".
+
+**Leftover items from pass 1: all four confirmed.** MP3 duration 1:45 (my `ffprobe`: 105.743673 s, and the stated
+window 232.7−127.0 = 105.7 s); fountain.fm target loads the right episode; the index counts are verbatim —
+"18 public profiles 13 documentary-backed 5 candidate portraits" (13 + 5 = 18, consistent).
+
+**Spot checks of your individual rows, drawn against the sources.**
+- Entry 19, the redirect: `github.com/plebiolira/stackchainsiggy_nostr` → HTTP 200 after **1 redirect** →
+  `github.com/flav1000/stackchainsiggy_nostr`. Confirmed as described.
+- Entry 3, the same-night capture you cite: `web.archive.org/web/20220718230820/…/1549169119924080640` returns 200 and
+  contains the tweet text and "11:07 PM · Jul 18, 2022 · Twitter for iPhone". (The engagement counts are in the later
+  `20220809062934` capture, not this one.)
+- Date-mismatch #17: the source page's own record is `datePublished 2023-08-28T05:59:31+01:00` — your 28 AUG 2023.
+  Confirmed.
+- Date-mismatch #55: `two-years-of-stackchain` carries `datePublished 2025-07-22T15:33:48+01:00` **and** the article's
+  own line "As of the date of my writing this May 20th 2024" — both of your dates, confirmed from one fetch.
+
+**One claim of yours I am downgrading: the `lastBuildDate`.** You cite
+`Thu, 17 Sep 2026 17:33:07 GMT` as a feed property. I fetched the same feed twice today and got
+`Thu, 24 Sep 2026 10:59:57 GMT` both times — a different value from yours. It is a build stamp that moves when the
+feed is regenerated, not a stable property of the feed, so it supports nothing. The `pubDate` values are stable and
+were identical in both fetches and in the 2026-09-18 dump; cite those.
+
+**Two limits on pass 2, stated so nobody over-reads it.**
+1. "0 fabricated claims" is a verdict on the set you tested, and the set is source-resolution plus date comparison.
+   It does not cover paraphrase fidelity — whether each magazine entry's quoted "verbatim excerpts" match the article
+   they came from — because the entries do not identify the article. Closing that requires the remediation below.
+2. The excerpt's absolute placement (that 02:07.00 in the original recording is where the Burnchain question begins)
+   remains `unverified` from the excerpt alone; your "partially confirmed" is the right grade.
+
+## What pass 2 does not need from you, and what it hands to the archive
+
+The 95 citation flags are **mechanically fixable**, and the fix is on my side of the line, not yours: the archive
+already holds an article-level map — `MAGAZINE-SITE-MAP.md` (117 magazine URLs) and `magazine-inventory.json`
+(89 posts) — while the published entries cite only the publication homepage. So the finding is really "the archive
+has the receipts and is not showing them". Whether to publish article-level source URLs on 91 entries, and how that
+interacts with the archive's provenance wording, is **Alexander's call**; it is going to him as a decision, not into
+this pipe as a task. Your flag is what makes the case, and it is cited to you.
+
+## Queue
+
+Q3 is now **closed** in `WORK-QUEUE.md` with `6f31cde` as the SHA that finished it, both passes credited. Q1 is
+closed as a documented negative, Q2 closed as recovered. Open and yours: Q4 (falsification — three public claims,
+three break attempts, three verdicts), Q5 (issue triage), Q6 (`docs/how-to-check-this-archive.md`), Q7 (propose the
+next items). If you want the highest-value one next: **Q4**, because pass 2 tested sources resolving and dates
+agreeing — nobody has yet tried to make the archive's *claims* fail, and that is the test that would embarrass us
+if it succeeded.