spec 010 D0 step 2: the redirects block, with the only key that can prove it works

[iancooper]

Step 2 of two. Step 1 (#77) changed what this step had to be.

What step 1 found

Merged with no redirects: block anywhere in the repo. Within 25 seconds, the old path returned HTTP 307 to the new one. A Git-synced SUMMARY.md rename does count as a "move" for GitBook automatic-redirect machinery.

Observation	Evidence
Uncached request to old path	307 → Location: new path, seen twice on cache-miss
location: header is unique to the old path	3 known-good pages: 0 · 404 control: 0 · old path: 1
Old path serves no content	192KB vs the 404 control at 189KB. New path: 584KB with the real <h1>
Sync latency	new URL 404 → 200 between 25s and 45s after merge

Recurring 200s on the old path are a CDN artifact — every one carries x-opennext-cache: HIT and the location: header, which no genuine page response has. It is the cached 307 replayed.

Why that killed the planned step 2

GitBook resolves automatic redirects first, and consults .gitbook.yaml only if the URL did not resolve. The path #77 moved now resolves. So a redirect for it would never be read — and would report success either way. That is exactly the vacuous green D0 exists to prevent.

What this block actually does

Two keys, two jobs:

• The real redirect for spec 010 D0 step 1: rename a section, deliberately without a redirect #77's rename — belt-and-braces, and what spec 010 would ship anyway.
• A probe key for a path that has never existed and returns 404 today (verified). No automatic redirect can mask it. This is the only discriminating half of the change.

Probe result after publish	Meaning
resolves	.gitbook.yaml redirects are read on this site, and the plan permits them
still 404	They are not. Spec 010's D2 is dead and automatic redirects are the only mechanism

The probe key is marked for removal and comes out in a follow-up PR once measured.

Verification, the way P0-3 demands rather than by eye

• Zero bytes outside printable ASCII; no trailing whitespace. GitBook's own published .gitbook.yaml example carries two U+200B zero-width spaces, and this file carried them until 2026-08-05 — which is why GitBook never read the structure: block at all and nothing looked broken. The example is a live contamination source, so this block was typed, not pasted.
• Parses as YAML; structure: intact; both targets exist on disk; no leading slashes either side.

linkcheck.py clean (112 files); pagelint.py 0 errors.

🤖 Generated with Claude Code

https://claude.ai/code/session_012tcdwxVb8NmKaX2S6fvyFg