03-DESIGN/01-to-be/22-the-work-ahead.md

@@ -15,19 +15,22 @@ Everything decided this cycle and not yet built, in the order its dependencies a
 ends at something provable on a running mesh, because a phase that ends at a claim is a phase that
 went missing without anything complaining.
 
-## Phase 0 — the installer completes, once
+## How this is built, and when it is run
 
-**Why first.** Nothing below is testable end to end without an installer that finishes. It has been
-failing on regressions of mine — a stale carried builder, a diagnostic on the parsed stdout — not
-on the mesh.
+**Implemented as code with unit tests, committed per change, and run in the lab ONCE the pieces that
+would change the outcome are in place.** The mistake this corrects: repeatedly running a 20-minute
+lab against a mesh mid-transformation, debugging paths the next phase deletes. The base-build hang,
+for instance, is almost certainly the SDK resolving from a git URL inside a docker build (issue
+053) — which Phase 2 removes. Debugging it on the current shape is debugging deprecated code.
 
-- [ ] 0.1 rebuild the builder image, and **verify the change is in it** (`grep`, not trust `make`)
-- [ ] 0.2 re-carry it, run the one-node installer, watch the phase-two base build with its own logs
-- [ ] 0.3 diagnose and fix whatever the base build actually does — the original hang, now visible
-- [ ] 0.4 all 22 checks green, twice, so it is reproducible rather than lucky
+So the lab run is the acceptance test at the end of the assembled work, not the tool for finding
+each bug. Where a fault can be reasoned out of the code path, it is — reading, not running.
 
-**Done when.** A bare machine becomes a working mesh by running the installer, and the run passes
-again.
+## Phase 0 — folded in
+
+The installer's own regressions (stale carried builder, a diagnostic on the parsed stdout) are
+fixed and committed. Whether it reaches a full green run is answered by the final lab run below,
+after the phases that change its build path are in — not before.
 
 ## Phase 1 — the protocol is one thing, and correct
 
@@ -81,3 +84,9 @@ Each phase leaves the mesh more able to describe and rebuild itself, and each en
 than a paragraph. The order is dependency, not preference: the installer carries everything, the
 protocol is what everything speaks, the registry is what everything is built from, and adoption is
 what makes the last two things ordinary.
+
+## The one lab run
+
+After Phases 1–3 are implemented and unit-tested and committed: rebuild the images, **verify each
+carries its change**, and run the one-node installer once. All 22 checks green, twice, is the
+acceptance test for the whole cycle — not a debugging loop, a proof that the assembled thing works.