spec: 010 the acceptance pass — AC1 to AC9 walked, and spec 010 closed

[iancooper]

Spec 010, Phase 11, Tasks 11.4 and 11.5 — the last two. Spec documents only; nothing published changes. 56 of 56 tasks.

Every criterion measured at 2c8e456 while writing the section, and where a criterion could be checked two ways, it was.

#	Verdict	Evidence
AC1	met	linkcheck 144 files, clean, 0 orphans; SUMMARY.md links 142 pages against 142 on disk; live --verify 142/142/142 agree
AC2	met	0 and 0, the second across 143 pages — 142 plus README.md, brought into scope by Task 11.9
AC3	met	see below
AC4	met	--check-redirects 0 failures, 77 entries, 7,858 bytes, printable ASCII, in CI since Phase 2
AC5a	met at D0	PRs #77/#78/#79; not re-run, unanswerable now by construction
AC5b	met	11 of 77 keys probed, every cold request a 307 to the path urlmap.py predicts, with controls both ways
AC6	met	--check-shape 0 — 142 pages, 12 sections, deepest 4 of 4, widest 10 of 12
AC7	met, complete not partial	26 split rows, 26 sources, all still on disk under their original names; 32 pages created, derived by set difference against 4001b0a (110 → 142)
AC8	met	16 rows, 16 distinct pages, and the keep set is disjoint from the 26 split sources
AC9	met	143 of 143 from this space carry a description, 198 of 198 across both; rule 7 fails the build when the sentence cannot be extracted

AC3 is the one worth naming

Rather than assert the block resolves, --redirects was re-run against the pre-Phase-2 SUMMARY.md (1bae048^). It emits 74 moved paths, and every one is in .gitbook.yaml with the same target — zero moved-but-not-redirected. That checks completeness, which "the block parses" never did.

The three extra keys are dated rather than waved through: D0's probe key (6611c98) and Phase 5's two intermediate Azure paths (60503c7) — exactly what §2's third finding predicted PR 5 would owe.

Standing obligation 7, enumerated both ways

pagetypes.tsv: 142 rows, 142 pages, nothing in one that is not in the other. Banner type against verdict 142/142; banner version against applies 142/142. No tool checks either, which is why it is walked — it is the check that would have failed silently had any phase forgotten its row.

Three things the pass found that were not on its list

1. The 404 shell drifted again — 189,511 → 223,618 bytes, against 639,747–900,240 for a real page. Third drift; the classes still separate and the discriminator that has never moved is no genuine page response carries a location: header.
2. A redirect's status is not stable across requests. First request 307; second 200, a 227,547-byte shell carrying the destination's <title>. The reader lands correctly either way, but a probe run twice gives two answers and only the first is the mechanism. And curl <old-path>.md returns # Page Not Found for a path that redirects perfectly — the mirror of the tool Phase 5 recommended. Probe cold, once, and read the location: header.
3. One filename with spaces defeated three ad-hoc measurements in one session. contents/Requests, Commands and Events.md broke a git ls-tree | split() count and a \S+ scan of .gitbook.yaml twice — 74 read as 73 and 77 as 76, on both sides of a comparison that therefore still balanced. Every repository tool handles it correctly. Nothing is wrong with the page; something is wrong with reaching for \S+.

Task 11.5 — the final gate

linkcheck.py                  No broken internal links (144 files checked).
pagelint.py                   0 errors, 791 warnings (791 blocks / 118 pages), 143 pages
urlmap.py --check-shape       0 failures — 142 pages, 12 sections, deepest 4, widest 10
urlmap.py --check-redirects   0 failures — 77 entries, 7858 bytes, printable ASCII
urlmap.py --verify            predicted 142, published 142, 142 agree

BoxProvisioning.md#when-to-use-box-provisioning resolves — spec 009's rung 3 depends on it. The heading is ## When to use Box Provisioning, lower-case use; a grep for the capitalised form returns nothing, so it was checked through linkcheck.py's own slug() instead.

🤖 Generated with Claude Code