spec: 010 Phase 5 post-merge — the publish measurement, and a cached 404 on a live page

[iancooper]

Spec documents only. No file under contents/ is touched, no URL moves.

Records what PR #89 actually did on the live site, and one finding worth carrying.

The finding: a live page whose HTML route served a cached 404

outbox-and-inbox/outboxarchiver returned a 190,021-byte 404 shell — the 404 class, body containing "404" and "not found" — while:

• sitemap-pages.xml listed it, and moved 113 → 121, exactly the eight new pages;
• both its children returned real bodies at four segments;
• seven of the eight other new pages returned real bodies in the same probe batch;
• a ?cb= query string did not change the response.

curl <path>.md settled it: 200, 9,145 bytes, leading # Outbox Archiver. GitBook has the page and publishes it — only the HTML route is stale, almost certainly from a probe that landed inside the documented 25–45 second sync window.

The programme already knew a wrong redirect outlives its fix at the edge. The mirror case — a premature probe manufacturing a wrong 404 — was not recorded, and the .md variant is the discriminator because it is served by a route the probe never poisoned.

Rule for the next phase: wait for sitemap-pages.xml to move before probing a new URL, and if an HTML route 404s on a page the sitemap lists, check .md before concluding the page failed to publish.

Both redirects confirmed, and D0's prediction held across two moves

On the second probe, outbox-and-inbox/azureblobarchiveprovider and its configuration child both returned 307 with a location: header. So did the pre-PR-2 key guaranteed-at-least-once/azureblobarchiveprovider.

That is D0's "a redirect entry does not go stale when its page moves again" holding across two moves of the same page — which it predicted, and which had never actually been tested at two.

🤖 Generated with Claude Code

https://claude.ai/code/session_012tcdwxVb8NmKaX2S6fvyFg