novox/hq
3
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Reorder the work: implement and unit-test first, run the lab once at the end

Browse Source 
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
This commit is contained in:
jschoubben
2026-09-16 00:02:51 +02:00
parent 2e1ae061b5
commit 6e1099a905
1 changed files with 19 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
03-DESIGN/01-to-be/22-the-work-ahead.md
+19 -10
View File
@@ -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.