# 📦 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](https://borda.github.io/lucid-YOLO/engineering/phase-13-contributor-admission/)
>
> 🔗 Depends on [WP-152](https://borda.github.io/lucid-YOLO/work_packages/wp-152/) · Needed by none
>
> ⬅️ [WP-152](https://borda.github.io/lucid-YOLO/work_packages/wp-152/) · [Roadmap](https://borda.github.io/lucid-YOLO/ROADMAP/) · [WP-153](https://borda.github.io/lucid-YOLO/work_packages/wp-153/) ➡️


## WP-152b — thirteen rows become six, and the ratchet earns its keep

<a id="wp-152b"></a>

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](https://borda.github.io/lucid-YOLO/work_packages/wp-154/) still cannot start before FA-1, FA-2 and FA-3 have all shipped, where the old [WP-154](https://borda.github.io/lucid-YOLO/work_packages/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](https://borda.github.io/lucid-YOLO/work_packages/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](https://borda.github.io/lucid-YOLO/work_packages/wp-147/)'s five parameter dataclasses took it to 55.