📦 WP-152b — docs: Phase 14 regrouped into five packages and a release¶
Engineering log · Phase 13 — Contributor admission, augmentation guard and keypoint parity, v0.6.0
🔗 Depends on WP-152 · Needed by none
WP-152b — thirteen rows become six, and the ratchet earns its keep¶
Phase 14 was written as thirteen rows because that is how the migration plan decomposes: one row per upstream capability absorbed, one per class deleted, one per closing sweep. Regrouped to six at the principal's direction — five work packages and the release.
What merging rows changes, and what it does not. It changes what one commit contains: a row is now "this much of the engine moved" rather than "this one function moved", so each commit is larger and each groups swaps sharing an upstream capability and a test surface. It changes nothing about the FA-n dependencies. Those name releases the other repository has to cut before anything here can move, and merging two local rows does not merge two upstream releases — WP-154 still cannot start before FA-1, FA-2 and FA-3 have all shipped, where the old WP-154 needed only FA-1. The cost is real and worth naming: a coarser row waits on more upstream work before it can begin, so the phase has fewer places to make partial progress.
The one rule that constrained the grouping. A frozen value may never move in the same commit as a call-site swap, because that combination is indistinguishable from adjusting the test until the new code passes. Thirteen rows kept the re-freeze naturally alone. Six could easily not have: the obvious grouping — "swaps" and "sweep" — puts the export-list collapse, the docs rewrite and the golden re-freeze together, which is fine, but a tempting alternative folds the re-freeze into the last swap row to save a commit. It is not folded. WP-158 holds the re-freeze and no swap at all, which is the property that made the four-tier guard worth building.
Y-n codes are unchanged and now map several to a row. The plan file stays the plan of record and its codes stay stable across this renumbering, which is exactly what §12 #6 wrote them down for: a stable cross-reference survives a roadmap that moves. The mapping is no longer one-to-one, and that is a property of the roadmap rather than a defect in the plan.
The floor is why this edit is legible at all. _WP_FLOOR asserts the roadmap never shrinks, on the reasoning that dropping the last row leaves the remainder perfectly contiguous — so contiguity cannot notice a deletion, and only a count can. The roadmap shrank from 166 numbered rows to 159 here, which is precisely the event the ratchet exists to force into the open, and it did: the floor had to be raised to 159 as a deliberate edit before the gate would pass. Worth recording that the floor had been sitting at 129 since long before Phases 13 and 14 added their rows, so it had a great deal of slack and would not in fact have caught this shrink. It has none now.
The export-count correction rides here rather than in the release, because this commit rewrites the cell that carried it: data/__init__.py re-exports 55 symbols, not the 51 the old row 163 claimed. The real count was 50 when that row was drafted — a miscount of one — and WP-147's five parameter dataclasses took it to 55.