From 6e1099a9054fb1cc2eb952d3c8ccb17e52963e6c Mon Sep 17 00:00:00 2001 From: jochen Date: Wed, 16 Sep 2026 00:02:51 +0200 Subject: [PATCH] Reorder the work: implement and unit-test first, run the lab once at the end MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The correction the operator pushed: stop running a 20-minute lab against a mesh mid-transformation, debugging paths the next phase deletes. The base-build hang is almost certainly the SDK resolving from a git URL inside a docker build (issue 053), which Phase 2 removes — so debugging it on the current shape is debugging deprecated code. Phase 0 folds in: the installer's own regressions are fixed and committed; whether it runs green is the final acceptance test, after the phases that change its build path are in. Faults that can be reasoned out of the code path are, by reading rather than running. Claude-Session: https://claude.ai/code/session_01D6qtiYU3P9jk3pnAXyAFyx --- 03-DESIGN/01-to-be/22-the-work-ahead.md | 29 ++++++++++++++++--------- 1 file changed, 19 insertions(+), 10 deletions(-) diff --git a/03-DESIGN/01-to-be/22-the-work-ahead.md b/03-DESIGN/01-to-be/22-the-work-ahead.md index 777a5b5..e2661a3 100644 --- a/03-DESIGN/01-to-be/22-the-work-ahead.md +++ b/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.