@henols/vice-mcp 0.2.3 → 0.2.4

package/resources/broker-launch.mjs

@@ -6,29 +6,28 @@
 // rebuild.
 // broker-launch.mts
 //
-// C (complete, plan 02 of Phase 01.6.2): the single `in_flight` launch-guard
-// owner (plan 01, unchanged -- every launch call site in the whole broker
-// goes through tryLaunchOne(), which is what makes the single-owner
-// guarantee mechanical rather than a convention plan 02's own concurrency
-// race test can silently violate), PLUS the readiness probe's single
-// in-process mechanism (collapsed from a three-way branch by Phase
-// 01.6.2.1's own plan 02 -- D-05 as amended by P-05/P-06/P-07; see
-// probeReady()'s own header comment below for the amendment's record),
+// This module owns three concerns that started life separately and were
+// folded together here: the single `in_flight` launch-guard owner -- every
+// launch call site in the whole broker goes through tryLaunchOne(), which
+// is what makes the single-owner guarantee mechanical rather than a
+// convention a concurrency race test could silently violate -- PLUS the
+// readiness probe's single in-process mechanism (collapsed from a
+// three-way branch down to one; see probeReady()'s own header comment
+// below for the full record of that collapse and its later amendment),
 // the launching -> ready promotion sweep (promoteLaunchingInstances() --
-// plan 41-05, folded todo: this used to be step 1 inside a warm-floor
-// maintenance function that speculatively pre-launched spare instances;
-// that floor is RETIRED and VICE now launches strictly on demand, but the
-// promotion sweep outlived it), and the fixed-order evaluation pass both
-// surviving concerns run through.
+// this used to be step one inside a warm-floor maintenance function that
+// speculatively pre-launched spare instances; that floor is RETIRED and
+// VICE now launches strictly on demand, but the promotion sweep outlived
+// it), and the fixed-order evaluation pass both surviving concerns run
+// through.
 //
-// Plan 03, Task 2 grows this module into a real per-child supervisor
-// (C2/D-23), absorbing resources/vice-supervisor.sh wholesale: superviseChild()
+// This file also grew a real per-child supervisor: superviseChild()
 // launches an instance through tryLaunchOne() (the SAME single guarded
 // primitive above) and installs an exit handler on the spawned child that
 // respawns on crash (doubling backoff, clamped at a ceiling), gives up
 // cleanly after too many crashes inside a window, never respawns a
 // deliberately-killed instance, and writes the per-instance boot/crash log
-// D-23 preserves at the exact path shape the retiring bash supervisor used.
+// at the exact path shape the retiring bash supervisor used.
 import { spawn as nodeSpawn } from "node:child_process";
 import { mkdirSync, mkdtempSync, openSync, closeSync, existsSync } from "node:fs";
 import { join, basename } from "node:path";
@@ -37,13 +36,13 @@ import { tmpdir } from "node:os";
 // synchronous check, synchronous set, released in a finally, with no
 // `await` between the check and the set.
 //
-// D-07 (01.6.2.1-03-PLAN.md): launch PRIORITY is layered on this owner, and
-// never replaces or weakens it. An in-flight boot always completes and is
-// NEVER killed or abandoned to serve a later arrival -- preemption was
-// considered and rejected (01.6.2-CONTEXT.md D-07) because a kill/relaunch
-// overlap re-creates the exact concurrent-spawn window the 2026-08-01
-// outage came from (one SEGV, one exit 1, one exit 0 at the identical spawn
-// second). Once a boot reaches `ready`, a waiting request takes it
+// Launch PRIORITY is layered on this owner, and never replaces or weakens
+// it. An in-flight boot always completes and is NEVER killed or abandoned
+// to serve a later arrival -- preemption was considered and rejected
+// because a kill/relaunch overlap re-creates the exact concurrent-spawn
+// window the 2026-08-01 outage came from (one SEGV, one exit 1, one exit 0
+// at the identical spawn second). Once a boot reaches `ready`, a waiting
+// request takes it
 // regardless of which reason booted it (vice-broker.mts's
 // selectWarmInstance() performs no `reason` check at all -- proven by
 // vice-broker-acquire.test.ts). Priority governs only which REASON wins
@@ -54,10 +53,9 @@ let inFlight = false;
 // only, never a second guard: nothing branches on this value's presence to
 // decide whether a launch may proceed (that is `inFlight` alone, checked
 // and set synchronously exactly as before). Its only consumer is the
-// launch-slot decision log line (D-07's standing constraint that a
-// lifecycle decision must be reconstructable from the log after an
-// incident -- both 2026-08-01 and 2026-08-02 were diagnosed from broker log
-// lines).
+// launch-slot decision log line: a lifecycle decision must be
+// reconstructable from the log after an incident -- both the 2026-08-01
+// and 2026-08-02 outages were diagnosed from broker log lines.
 let inFlightReason = null;
 /** True while a launch is in progress -- exported for the race test plan 02
  * writes against two concurrent tryLaunchOne() calls. */
@@ -69,31 +67,31 @@ export function isLaunchInFlight() {
 // most once per process -- the repo-root.ts `warnedEnvOutsideFrom` gate
 // pattern, reused here.
 let warnedBinmonBindWidened = false;
-// Plan 03-04 (DIRECT-06, D-13): the SAME one-time-note idiom as
-// warnedBinmonBindWidened above, for the SECOND (`-remotemonitor`) port's
-// bind -- a separate boolean because the two flags widen independently (a
-// caller could widen one host override and not the other, though in
-// practice both resolve from the same `binmonHost` value below).
+// The SAME one-time-note idiom as warnedBinmonBindWidened above, for the
+// SECOND (`-remotemonitor`) port's bind -- a separate boolean because the
+// two flags widen independently (a caller could widen one host override
+// and not the other, though in practice both resolve from the same
+// `binmonHost` value below).
 let warnedRemoteMonitorBindWidened = false;
-/** Phase 33, plan 33-05 (`REPRO-01`): the random seed the stock determinism
- * block pins, and the exact value the reproduction was measured with on this
- * host -- exported so a capture record's reproducibility key can cite ONE
- * definition rather than re-deriving a literal that could silently drift away
- * from the launches it claims to describe. MEASURED 2026-09-02 against genuine
- * stock 3.9 over `-binarymonitor` (33-RESEARCH.md M3): two cold boots WITHOUT
- * the block differ at 59 of the 4080 addresses in the untouched `$C000-$CFEF`
- * window; WITH it, at 0 of 4080. */
+/** The random seed the stock determinism block pins, and the exact value
+ * the reproduction was measured with on this host -- exported so a capture
+ * record's reproducibility key can cite ONE definition rather than
+ * re-deriving a literal that could silently drift away from the launches it
+ * claims to describe. MEASURED 2026-09-02 against genuine stock 3.9 over
+ * `-binarymonitor`: two cold boots WITHOUT the block differ at 59 of the
+ * 4080 addresses in the untouched `$C000-$CFEF` window; WITH it, at 0 of
+ * 4080. */
 export const STOCK_DETERMINISM_SEED = 4242;
-/** Phase 33, plan 33-05 (`REPRO-01`): the determinism block, in ONE fixed
- * order, emitted UNCONDITIONALLY by the stock branch below (never gated on
- * `profile` -- see buildViceArgs()'s own comment above `args`). Exported and
- * frozen so tests and evidence scripts assert against this single definition
- * instead of a second hand-copied array, and so no caller can mutate the
- * shared value into a launch that no longer matches the recorded seed.
+/** The determinism block, in ONE fixed order, emitted UNCONDITIONALLY by
+ * the stock branch below (never gated on `profile` -- see buildViceArgs()'s
+ * own comment above `args`). Exported and frozen so tests and evidence
+ * scripts assert against this single definition instead of a second
+ * hand-copied array, and so no caller can mutate the shared value into a
+ * launch that no longer matches the recorded seed.
  *
- * The order is fixed and load-bearing beyond readability: `REPRO-04` keys
- * captures on an argv digest, so a block whose element order varied between
- * two launches on the same port would produce two digests for one launch
+ * The order is fixed and load-bearing beyond readability: capture records
+ * key on an argv digest, so a block whose element order varied between two
+ * launches on the same port would produce two digests for one launch
  * intent. */
 export const STOCK_DETERMINISM_FLAGS = Object.freeze([
     "-seed",
@@ -115,56 +113,49 @@ export const STOCK_DETERMINISM_FLAGS = Object.freeze([
  * understands neither `-mcpserver` nor `-binarymonitor` flags, and that need
  * does not depend on which backend is configured.
  *
- * `backend: "stock"` (FORKRM-01, plan 52-06: the only value `ViceBackend` has
- * left) returns `-binarymonitor -binarymonitoraddress
- * ip4://<host>:<port>` (docs/phase1-probe-results.md's confirmed real-world
- * command line). The host resolves from `binmonHost` or
- * VICE_BROKER_BINMON_HOST, defaulting to `127.0.0.1` -- deliberately
- * narrow, because VICE's binary
- * monitor is unauthenticated by design and grants full read/write over the
- * emulated machine plus process control to anything that can reach it
- * (planner decision, `02-03-PLAN.md`). Widening the bind away from loopback
- * emits exactly one stderr note per process, naming the resolved bind
- * address and what the exposure grants.
+ * `backend: "stock"` (the only value `ViceBackend` has, now that the fork
+ * backend is gone) returns `-binarymonitor -binarymonitoraddress
+ * ip4://<host>:<port>`, the confirmed real-world command line. The host
+ * resolves from `binmonHost` or VICE_BROKER_BINMON_HOST, defaulting to
+ * `127.0.0.1` -- deliberately narrow, because VICE's binary monitor is
+ * unauthenticated by design and grants full read/write over the emulated
+ * machine plus process control to anything that can reach it. Widening the
+ * bind away from loopback emits exactly one stderr note per process,
+ * naming the resolved bind address and what the exposure grants.
  *
- * Plan 03-04 (DIRECT-06, D-13): when `remoteMonitorPort` is a number, the
- * stock branch APPENDS `-remotemonitor -remotemonitoraddress
- * ip4://<host>:<remoteMonitorPort>`, reusing the SAME resolved `host` value
- * the binmon address already used -- one resolution, not two. When
- * `remoteMonitorPort` is omitted (undefined), the returned argv is
- * byte-identical to what this function always returned -- no
- * `-remotemonitor` at all. `-remotemonitoraddress`'s exact spelling was
- * live-probed against a real fork-3.10 binary and CONFIRMED (RESEARCH.md
- * Assumption A1, closed by 13-PROBE-RESULTS.md §A1: the flag bound a real,
- * accepting text-monitor listener, corroborated independently by
- * `ss -ltnp`). Genuine stock 3.9 was not independently probed in that run --
- * the spelling itself is a symmetrical CLI flag pair and is not
- * version-sensitive, so this is recorded as a low-risk carry-forward rather
- * than implied stock-3.9 coverage. Widening THIS bind away from loopback emits
- * its own one-time stderr note (`warnedRemoteMonitorBindWidened`), naming
- * the resolved address and stating that VICE's TEXT monitor accepts
- * arbitrary monitor commands and is unauthenticated. Phase 41 dials this
- * port (text-connect.ts's textConnect()) and Phase 41-05 (D-16) made it
- * MANDATORY on every stock launch -- a stock launch that cannot bind it now
- * fails the whole acquire rather than launching without it (see D-13's own
- * rationale for why the flag itself is set at launch time and not added
- * later: doing so would require relaunching a live instance, destroying all
- * emulation state).
+ * When `remoteMonitorPort` is a number, the stock branch APPENDS
+ * `-remotemonitor -remotemonitoraddress ip4://<host>:<remoteMonitorPort>`,
+ * reusing the SAME resolved `host` value the binmon address already used --
+ * one resolution, not two. When `remoteMonitorPort` is omitted (undefined),
+ * the returned argv is byte-identical to what this function always
+ * returned -- no `-remotemonitor` at all. `-remotemonitoraddress`'s exact
+ * spelling was live-probed against a real fork-3.10 binary and CONFIRMED:
+ * the flag bound a real, accepting text-monitor listener, corroborated
+ * independently by `ss -ltnp`. Genuine stock 3.9 was not independently
+ * probed in that run -- the spelling itself is a symmetrical CLI flag pair
+ * and is not version-sensitive, so this is recorded as a low-risk
+ * carry-forward rather than implied stock-3.9 coverage. Widening THIS bind
+ * away from loopback emits its own one-time stderr note
+ * (`warnedRemoteMonitorBindWidened`), naming the resolved address and
+ * stating that VICE's TEXT monitor accepts arbitrary monitor commands and
+ * is unauthenticated. text-connect.ts's textConnect() dials this port, and
+ * it is MANDATORY on every stock launch -- a stock launch that cannot bind
+ * it now fails the whole acquire rather than launching without it, because
+ * the flag has to be set at launch time: adding it later would require
+ * relaunching a live instance, destroying all emulation state.
  *
- * Phase 33, plan 33-05 (`D-15`, `REPRO-01`, `REPRO-05`): the stock branch now
- * also emits STOCK_DETERMINISM_FLAGS unconditionally, and takes an optional
- * `profile` for the two additive launch knobs. Deliberately in the same
- * register as tryLaunchOne's own widened `spawn` field below, and for the same
- * reason: `profile` is optional, so every pre-existing caller and every
- * pre-existing test stub keeps compiling and behaving identically, and an
- * ABSENT profile produces exactly the same argv as an empty one or one whose
- * knobs are both `false`. What optionality could NOT save (33-RESEARCH.md P7,
- * and the `D-15` amendment rider dated 2026-09-02): the determinism block is
- * unconditional on stock, so all FIVE stock whole-argv assertions in
- * broker-launch.test.ts move even with `profile` absent -- it is the block and
- * not the profile that moves them. `D-15`'s byte-identity claim therefore
- * survives in full only for the `profile` half: an absent profile adds no
- * flag. */
+ * The stock branch also emits STOCK_DETERMINISM_FLAGS unconditionally, and
+ * takes an optional `profile` for the two additive launch knobs. Deliberately
+ * in the same register as tryLaunchOne's own widened `spawn` field below,
+ * and for the same reason: `profile` is optional, so every pre-existing
+ * caller and every pre-existing test stub keeps compiling and behaving
+ * identically, and an ABSENT profile produces exactly the same argv as an
+ * empty one or one whose knobs are both `false`. What optionality could NOT
+ * save: the determinism block is unconditional on stock, so all FIVE stock
+ * whole-argv assertions in broker-launch.test.ts move even with `profile`
+ * absent -- it is the block and not the profile that moves them. The
+ * byte-identity claim therefore survives in full only for the `profile`
+ * half: an absent profile adds no flag. */
 export function buildViceArgs(port, { backend, mcpHost, binmonHost, viceArgsEnv, remoteMonitorPort, profile, }) {
     const rawViceArgs = viceArgsEnv ?? process.env.VICE_ARGS;
     if (typeof rawViceArgs === "string" && rawViceArgs.trim() !== "") {
@@ -194,76 +185,77 @@ export function buildViceArgs(port, { backend, mcpHost, binmonHost, viceArgsEnv,
         // `-binarymonitor` or the monitor never binds and the subsequent connect
         // hangs in the backlog looking exactly like a wedge.
         //
-        // WORDING CORRECTED (33 review WR-09). This paragraph used to say
-        // "immediately after `-default`", which the `-console` block below now
-        // violates by construction whenever `profile.headless` is set -- leaving
-        // the next editor to find code contradicting the comment and having to
-        // re-derive which one is authoritative. What is load-bearing is the
-        // RELATIVE ORDER (`-default` precedes everything it resets), not
-        // adjacency.
+        // WORDING CORRECTED. This paragraph used to say "immediately after
+        // `-default`", which the `-console` block below now violates by
+        // construction whenever `profile.headless` is set -- leaving the next
+        // editor to find code contradicting the comment and having to re-derive
+        // which one is authoritative. What is load-bearing is the RELATIVE
+        // ORDER (`-default` precedes everything it resets), not adjacency.
         //
         // The `-console` block's own citation was `alive=yes bound=1`, which does
-        // NOT cover this paragraph's property: I-2's failure mode is Drive8Type
-        // silently reverting to 0 (NONE) WHILE THE MONITOR STILL BINDS FINE, so
-        // liveness and boundness cannot tell the good case from the failure being
-        // guarded against. Re-verified against the resource itself
+        // NOT cover this paragraph's property: the failure mode this flag guards
+        // against is Drive8Type silently reverting to 0 (NONE) WHILE THE MONITOR
+        // STILL BINDS FINE, so liveness and boundness cannot tell the good case
+        // from the failure being guarded against. Re-verified against the
+        // resource itself
         // [VERIFIED: live probe 2026-09-03, genuine unpatched stock
         // /usr/bin/x64sc (VICE 3.9), DISPLAY and WAYLAND_DISPLAY both unset]:
         //   [-default -console -drive8type 1541 <determinism> -binarymonitor]
         //     alive=yes bound=1  Drive8Type=1541  Drive8TrueEmulation=1
         // read over `RESOURCE_GET` (0x51) with `-console` interposed. So the
-        // citation now covers the RESOURCE and not only liveness. Confirmed sufficient live in
-        // Phase 8.1's standalone probe (08.1-WALKTHROUGH-EVIDENCE.md §4):
+        // citation now covers the RESOURCE and not only liveness. Confirmed
+        // sufficient live in a standalone probe:
         // `resourceget "Drive8Type"` moved 0 -> 1541 and a `load` over the text
         // monitor succeeded immediately. Deliberately NOT setting
         // -drive8truedrive / Drive8TrueEmulation here: this build's own default
-        // already reads Drive8TrueEmulation=1 (same probe), so 08.2-RESEARCH.md's
-        // primary recommendation is that only -drive8type needs adding.
-        // Assumption A3 in that doc's Assumptions Log (some other stock build
-        // might default Drive8TrueEmulation to 0) is read and deliberately not
-        // pre-emptively defended against here; plan 03's live test is what would
-        // surface it if that assumption is ever wrong on a different build.
+        // already reads Drive8TrueEmulation=1 (same probe), so only
+        // `-drive8type` needs adding.
+        // A different stock build might default Drive8TrueEmulation to 0,
+        // which is read and deliberately not pre-emptively defended against
+        // here; a live test against that build is what would surface it if
+        // this assumption is ever wrong there.
         //
-        // Phase 33, plan 33-05, `-console` at index 1 (`REPRO-05`, `D-15`): the
-        // headless route is `-console`, and its POSITION is as load-bearing as
-        // `-default`'s. `-console` is handled in the SAME `main.c` pre-scan as
-        // `-default` -- that loop `break`s at the first option it does not
-        // recognise and then strips the prefix it handled from argv
+        // The headless route is `-console`, and its POSITION is as
+        // load-bearing as `-default`'s. `-console` is handled in the SAME
+        // `main.c` pre-scan as `-default` -- that loop `break`s at the first
+        // option it does not recognise and then strips the prefix it handled
+        // from argv
         // [CITED: vice-3.8/src/main.c:184-192, 232-238] -- and `console_mode`
         // gates GTK initialisation at two call sites (`ui_init_with_args`,
         // `ui_init`) that BOTH run before the late command-line parser
         // `initcmdline_check_args()` [CITED: vice-3.8/src/main.c:296-345]. A
         // `-console` seen only by the late parser therefore arrives after GTK has
         // already tried and failed. MEASURED 2026-09-02 with `DISPLAY` and
-        // `WAYLAND_DISPLAY` both unset (33-RESEARCH.md P5):
+        // `WAYLAND_DISPLAY` both unset:
         //   [-default -console -binarymonitor]                    alive=yes bound=1
         //   [-default -drive8type 1541 -console -binarymonitor]   alive=no  bound=0  Gtk-WARNING: cannot open display:
         //   [-default -console -drive8type 1541 -binarymonitor]   alive=yes bound=1
         // So `-console` goes immediately after `-default` and BEFORE
-        // `-drive8type` -- which is compatible with the I-2 paragraph above as
-        // corrected (33 review WR-09): that constraint is `-drive8type` AFTER
-        // `-default`, not adjacent to it, and the interposition was re-verified
-        // over `RESOURCE_GET` to leave Drive8Type=1541 rather than only to leave
+        // `-drive8type` -- which is compatible with the paragraph above as
+        // corrected: that constraint is `-drive8type` AFTER `-default`, not
+        // adjacent to it, and the interposition was re-verified over
+        // `RESOURCE_GET` to leave Drive8Type=1541 rather than only to leave
         // the monitor bound. It is pinned by an ordering assertion rather than by
         // this comment -- a bare flag push with no reason is exactly what let the
         // `-default` ordering constraint be rediscovered by a red CI run last
         // time.
         //
-        // Phase 33, plan 33-05, the determinism block (`REPRO-01`): emitted
-        // UNCONDITIONALLY on stock, never gated on `profile`. Read over
-        // `RESOURCE_GET` (0x51) on this build under `-default -drive8type 1541`
-        // [VERIFIED: live probe 2026-09-02, 33-RESEARCH.md M2],
+        // The determinism block is emitted UNCONDITIONALLY on stock, never
+        // gated on `profile`. Read over `RESOURCE_GET` (0x51) on this build
+        // under `-default -drive8type 1541`
+        // [VERIFIED: live probe 2026-09-02],
         // `-raminitrandomchance 0` is the LOAD-BEARING one: the factory value is
         // **10**, i.e. 0.1% of all RAM bits randomly flipped at power-up, and it is
         // the dominant term in the divergence this milestone removes. The
         // `-raminitstartrandom 0` / `-raminitrepeatrandom 0` pair already reads 0
         // at factory and is DEFENSIVE against an operator `vicerc` -- belt and
-        // braces alongside the scratch `XDG_CONFIG_HOME` the I-1 rider threads in
+        // braces alongside the scratch `XDG_CONFIG_HOME` threaded in
         // spawnAndRecordInstance() below.
         //
-        // `+autostart-delay-random` is a FIFTH flag beyond `REPRO-01`'s text
-        // (which names only `-seed` plus the three `raminit*`), recorded here as a
-        // deliberate ADDITION rather than smuggled in. `AutostartDelayRandom`
+        // `+autostart-delay-random` is a FIFTH flag beyond the determinism
+        // block's own headline text (which names only `-seed` plus the three
+        // `raminit*`), recorded here as a deliberate ADDITION rather than
+        // smuggled in. `AutostartDelayRandom`
         // ships at **1** on this build [VERIFIED: same probe], it draws an
         // additional random delay of up to 10 frames
         // [CITED: vice-3.8/src/autostart.c:1432-1436], and -- the effect that is
@@ -273,21 +265,20 @@ export function buildViceArgs(port, { backend, mcpHost, binmonHost, viceArgsEnv,
         // behavioural change and not only a timing one. Pin it once; never toggle
         // it between the two runs of a capture pair.
         //
-        // Phase 33, plan 33-05, `-warp` (`D-15`): position-free (MEASURED
-        // 2026-09-02), placed here only so the argv reads in the order a human
-        // would describe it. Launch-time is the ONLY route on stock: there is no
-        // runtime `WarpMode` resource at all (`RESOURCE_GET` replies `err=0x01`
-        // OBJECT_MISSING on 3.9), so no runtime setter can exist here. Worth
-        // roughly **1.97x** on this host and this launch profile -- 5.23 emulated
-        // seconds against 2.65 over the same 5 s wall clock [MEASURED:
-        // evidence/33-wallclock-control.md, Control B instance 1] -- and NOT the
-        // order of magnitude a reader may assume; `AUTOSTART` additionally turns
-        // warp on by itself during the load whatever argv says, so both loads are
-        // warped either way. It is behaviour-neutral under a frame-anchored
-        // protocol (identical registers and one identical 64K sha256 across a
-        // warped and an unwarped run, same source), which is the precondition
-        // `33-06` needs before `profile.warp` ships; it is NOT neutral for a
-        // wall-clock bracket, which it invalidates by 1.76x.
+        // `-warp` is position-free (MEASURED 2026-09-02), placed here only so
+        // the argv reads in the order a human would describe it. Launch-time is
+        // the ONLY route on stock: there is no runtime `WarpMode` resource at
+        // all (`RESOURCE_GET` replies `err=0x01` OBJECT_MISSING on 3.9), so no
+        // runtime setter can exist here. Worth roughly **1.97x** on this host
+        // and this launch profile -- 5.23 emulated seconds against 2.65 over
+        // the same 5 s wall clock [MEASURED: evidence/33-wallclock-control.md,
+        // Control B instance 1] -- and NOT the order of magnitude a reader may
+        // assume; `AUTOSTART` additionally turns warp on by itself during the
+        // load whatever argv says, so both loads are warped either way. It is
+        // behaviour-neutral under a frame-anchored protocol (identical registers
+        // and one identical 64K sha256 across a warped and an unwarped run, same
+        // source), which is a precondition for shipping `profile.warp`; it is
+        // NOT neutral for a wall-clock bracket, which it invalidates by 1.76x.
         const args = ["-default"];
         if (profile?.headless) {
             args.push("-console");
@@ -331,42 +322,40 @@ function spawnAndRecordInstance(reason, port, deps) {
     const now = deps.now ?? (() => Date.now());
     const viceBin = deps.viceBin ?? process.env.VICE_BIN ?? "x64sc";
     const backend = deps.backend ?? "stock";
-    // Plan 41-05 (D-16): the ONE construction site for a fresh InstanceRecord
-    // asserts the invariant every downstream consumer (HeldLease,
-    // textConnect(), etc.) was written against -- a stock record NEVER lacks a
-    // text-monitor port. acquirePortAndLaunch() above already fails the whole
-    // acquire before ever reaching this function when the second allocation
-    // fails, so a caller that lands here with `backend: "stock"` and no
-    // `remoteMonitorPort` is a defect in THIS module (a call site that bypassed
-    // that guarantee), not a state a stock record may legitimately carry --
-    // throw by name rather than silently writing a record that violates it.
+    // The ONE construction site for a fresh InstanceRecord asserts the
+    // invariant every downstream consumer (HeldLease, textConnect(), etc.) was
+    // written against -- a stock record NEVER lacks a text-monitor port.
+    // acquirePortAndLaunch() above already fails the whole acquire before ever
+    // reaching this function when the second allocation fails, so a caller
+    // that lands here with `backend: "stock"` and no `remoteMonitorPort` is a
+    // defect in THIS module (a call site that bypassed that guarantee), not a
+    // state a stock record may legitimately carry -- throw by name rather
+    // than silently writing a record that violates it.
     // The fork case is real and unaffected: this check is stock-only.
     if (backend === "stock" && deps.remoteMonitorPort === undefined) {
-        throw new Error("spawnAndRecordInstance: backend \"stock\" requires remoteMonitorPort (D-16) -- a stock launch that cannot bind a text-monitor port must fail the acquire before reaching this construction site, never write a portless stock record");
+        throw new Error("spawnAndRecordInstance: backend \"stock\" requires remoteMonitorPort -- a stock launch that cannot bind a text-monitor port must fail the acquire before reaching this construction site, never write a portless stock record");
     }
     const viceArgs = buildViceArgs(port, {
         backend,
         mcpHost: deps.mcpHost,
         binmonHost: deps.binmonHost,
         remoteMonitorPort: deps.remoteMonitorPort,
-        // Phase 33, plan 33-06: the ONE place a launch's profile becomes argv.
-        // The record built below mirrors the SAME value, so an instance's
-        // recorded profile and its actual argv are written in one step and
-        // cannot disagree.
+        // The ONE place a launch's profile becomes argv. The record built
+        // below mirrors the SAME value, so an instance's recorded profile and
+        // its actual argv are written in one step and cannot disagree.
         profile: deps.profile,
     });
     const log = deps.log ?? defaultLog;
-    // I-1 rider (audit §4.4, 08.2-02-PLAN.md Task 2): production stock
-    // launches used to set no scratch XDG_CONFIG_HOME and would read whatever
-    // vicerc the operator's own $HOME already carried -- shared with the
-    // operator's own VICE usage and with the fork build. For backend ===
-    // "stock" only, compute a fresh, isolated config dir with mkdtempSync
-    // (atomic creation, random suffix, 0700 permissions -- the primitive that
-    // makes a collision or a symlink-swap into the operator's real config
-    // unreachable) and pass it as a third options argument carrying `env`
-    // only. Never `shell: true`: the existing array-form spawn(viceBin,
-    // viceArgs) call avoids shell interpretation entirely and that property
-    // must survive this widening.
+    // Production stock launches used to set no scratch XDG_CONFIG_HOME and
+    // would read whatever vicerc the operator's own $HOME already carried --
+    // shared with the operator's own VICE usage and with the fork build. For
+    // backend === "stock" only, compute a fresh, isolated config dir with
+    // mkdtempSync (atomic creation, random suffix, 0700 permissions -- the
+    // primitive that makes a collision or a symlink-swap into the operator's
+    // real config unreachable) and pass it as a third options argument
+    // carrying `env` only. Never `shell: true`: the existing array-form
+    // spawn(viceBin, viceArgs) call avoids shell interpretation entirely and
+    // that property must survive this widening.
     //
     // Scope boundary (do not remove this note): the production broker daemon
     // always supplies its own deps.spawn / deps.spawnFactory, so the widened
@@ -374,13 +363,12 @@ function spawnAndRecordInstance(reason, port, deps) {
     // function's job is only to COMPUTE the value at the one seam that should
     // own it; the forwarding to nodeSpawn() happens at three further hops --
     // makeLoggingSpawn() in vice-broker.mts, and withCrashSupervision()'s
-    // wrapper body and launchSupervised()'s defaultRealSpawn in this file
-    // (plan 41-05, folded todo: a FOURTH hop, the retired warm floor's own
-    // inner stashingSpawn closure in vice-broker.mts, is REMOVED along with
-    // the function that held it). All three now forward the options argument
-    // (plan 08.2-06 closed them in this same phase, with a handleAcquire()
+    // wrapper body and launchSupervised()'s defaultRealSpawn in this file (a
+    // fourth hop, the retired warm floor's own inner stashingSpawn closure in
+    // vice-broker.mts, is REMOVED along with the function that held it). All
+    // three now forward the options argument, with a handleAcquire()
     // composition test that omits buildColdSpawnFactory so an injected stub
-    // cannot fake the proof). If you add another spawn hop, it must forward
+    // cannot fake the proof. If you add another spawn hop, it must forward
     // options too, or production stock launches silently lose their config
     // isolation again.
     //
@@ -415,25 +403,25 @@ function spawnAndRecordInstance(reason, port, deps) {
         viceBin,
         viceArgs,
         dryRun: false,
-        // Plan 41-03 (D-14): non-optional, defaulted to an empty map -- "no
-        // claim on any channel" is an empty map, never an absent field. The
-        // ONE place a fresh InstanceRecord is constructed, so this is the ONE
-        // place this default is set.
+        // Non-optional, defaulted to an empty map -- "no claim on any channel"
+        // is an empty map, never an absent field. The ONE place a fresh
+        // InstanceRecord is constructed, so this is the ONE place this default
+        // is set.
         monitorClients: {},
-        // Plan 41-05 (D-16): key omitted only on the FORK path now -- the guard
-        // above already throws before this point for any stock call with no
+        // Key omitted only on the FORK path now -- the guard above already
+        // throws before this point for any stock call with no
         // remoteMonitorPort, so a stock record reaching this line always
         // supplies the key. "Absent" means fork, never "stock allocation
         // failed" (that state no longer exists).
         ...(deps.remoteMonitorPort === undefined ? {} : { remoteMonitorPort: deps.remoteMonitorPort }),
-        // Phase 33, plan 33-06: same key-omitted-when-undefined idiom as
-        // remoteMonitorPort directly above. An absent request must produce a
-        // record with NO `profile` key at all -- not `profile: undefined` --
-        // because "absent means profile-less" is the property a broker restarted
-        // mid-phase relies on when it reads records written before this field
-        // existed. A copy, not the caller's own object: the record outlives this
-        // call and a caller mutating its profile afterwards must not silently
-        // change what this instance claims it was launched with.
+        // Same key-omitted-when-undefined idiom as remoteMonitorPort directly
+        // above. An absent request must produce a record with NO `profile` key
+        // at all -- not `profile: undefined` -- because "absent means
+        // profile-less" is the property a broker restarted mid-phase relies on
+        // when it reads records written before this field existed. A copy, not
+        // the caller's own object: the record outlives this call and a caller
+        // mutating its profile afterwards must not silently change what this
+        // instance claims it was launched with.
         ...(deps.profile === undefined ? {} : { profile: { ...deps.profile } }),
     };
     deps.state.instances.set(port, record);
@@ -470,45 +458,45 @@ export function tryLaunchOne(reason, port, deps) {
  * allocate-a-port-then-launch sequence -- not merely the synchronous spawn
  * instant tryLaunchOne() alone guards. This closes a genuine race window
  * tryLaunchOne() cannot: nextFreePort()'s own port-in-use probe is
- * asynchronous (plan 02, C4 -- a real bind-and-release check), so two
- * overlapping callers could otherwise BOTH be told the SAME candidate port
- * is free before either commits it to state.instances -- a double-launch on
- * one port, silently overwriting the earlier record. The guard is checked
- * and set SYNCHRONOUSLY before the first `await`, exactly like
- * tryLaunchOne()'s own discipline, so a second concurrent call is refused
- * immediately (`launch_in_flight`) rather than racing on the allocation.
+ * asynchronous (a real bind-and-release check), so two overlapping callers
+ * could otherwise BOTH be told the SAME candidate port is free before
+ * either commits it to state.instances -- a double-launch on one port,
+ * silently overwriting the earlier record. The guard is checked and set
+ * SYNCHRONOUSLY before the first `await`, exactly like tryLaunchOne()'s own
+ * discipline, so a second concurrent call is refused immediately
+ * (`launch_in_flight`) rather than racing on the allocation.
  *
- * Plan 41-05 (folded todo): this guard's own reasoning OUTLIVED the warm
- * floor it was originally written alongside -- it exists because of the
- * 2026-08-01 triple-launch outage (three simultaneous x64sc launches: one
- * SEGV, one exit 1, one exit 0 at the identical spawn second) and is
- * regression-tested (CLAUDE.md), and that history has nothing to do with
- * whether a warm floor exists. Today the only caller of this function is the
- * cold-acquire arm (vice-broker.mts's handleAcquire(), via `serveAcquires()`
- * in runBrokerPass()); the overlap this guard closes is now TWO OR MORE
+ * This guard's own reasoning OUTLIVED the warm floor it was originally
+ * written alongside -- it exists because of the 2026-08-01 triple-launch
+ * outage (three simultaneous x64sc launches: one SEGV, one exit 1, one exit
+ * 0 at the identical spawn second) and is regression-tested (CLAUDE.md),
+ * and that history has nothing to do with whether a warm floor exists.
+ * Today the only caller of this function is the cold-acquire arm
+ * (vice-broker.mts's handleAcquire(), via `serveAcquires()` in
+ * runBrokerPass()); the overlap this guard closes is now TWO OR MORE
  * concurrent acquires -- e.g. two requests arriving over the TCP control
  * listener at nearly the same moment, or one arriving while an EARLIER
  * acquire's own launch is still resolving -- never a warming pass, which no
  * longer exists. This is also the function that restores vice-broker.sh's
  * own process_requests() throttle (its `in_flight` local): whatever launches
  * this broker ever attempts, they never overlap, matching the bash
- * original's declined-to-change behaviour (RESEARCH.md §A1/§C). D-07
- * (01.6.2.1-03-PLAN.md) layers non-preemptive PRIORITY on top of this same
- * "one at a time" guard, never replacing it, and the anti-pattern it names --
- * killing or relaunching preemptively to serve a newer request -- is likewise
- * unaffected by the floor's removal: this function still only ever refuses a
- * second concurrent caller (`launch_in_flight`), and never kills or preempts
- * whichever caller already holds the slot. Among multiple QUEUED acquires,
- * which one wins this slot NEXT, once it frees, falls out of the
- * arrival-ordered pending-acquire structure (broker-control.mts's D-08
- * mechanism) that requeues a refused acquire for the next pass -- not from
- * anything in this function. The refusal below logs which reason currently
- * holds the slot and which reason is waiting, so the decision is
- * reconstructable from the log after an incident. */
+ * original's declined-to-change behaviour. Non-preemptive launch PRIORITY
+ * layers on top of this same "one at a time" guard, never replacing it, and
+ * the anti-pattern it names -- killing or relaunching preemptively to serve
+ * a newer request -- is likewise unaffected by the floor's removal: this
+ * function still only ever refuses a second concurrent caller
+ * (`launch_in_flight`), and never kills or preempts whichever caller
+ * already holds the slot. Among multiple QUEUED acquires, which one wins
+ * this slot NEXT, once it frees, falls out of the arrival-ordered
+ * pending-acquire structure (broker-control.mts's own mechanism) that
+ * requeues a refused acquire for the next pass -- not from anything in this
+ * function. The refusal below logs which reason currently holds the slot
+ * and which reason is waiting, so the decision is reconstructable from the
+ * log after an incident. */
 export async function acquirePortAndLaunch(reason, deps) {
     const log = deps.log ?? defaultLog;
     if (inFlight) {
-        log(`vice-broker: launch-slot decision -- ${inFlightReason ?? "unknown"} holds the slot; ${reason} waits (D-07)`);
+        log(`vice-broker: launch-slot decision -- ${inFlightReason ?? "unknown"} holds the slot; ${reason} waits`);
         return { ok: false, reason: "launch_in_flight" };
     }
     inFlight = true;
@@ -522,14 +510,14 @@ export async function acquirePortAndLaunch(reason, deps) {
         const supervisorDir = join(deps.stateDir, String(port));
         const epochFile = join(supervisorDir, "epoch.json");
         const spawn = deps.spawnFactory ? deps.spawnFactory(port) : deps.spawn;
-        // Plan 03-04 (DIRECT-06, D-13): the second (`-remotemonitor`) port is
-        // resolved HERE, still inside the single in_flight owner's own
-        // try-block, immediately after the primary allocation succeeds -- both
-        // awaits stay inside this SAME try, after the guard's synchronous
-        // check-and-set above; neither is moved, duplicated, or awaited around
-        // that guard. Only ever attempted for `backend === "stock"`, and only
-        // when the caller actually provided the allocator -- every fork launch
-        // and every pre-Phase-3 caller never reaches this branch at all.
+        // The second (`-remotemonitor`) port is resolved HERE, still inside the
+        // single in_flight owner's own try-block, immediately after the primary
+        // allocation succeeds -- both awaits stay inside this SAME try, after
+        // the guard's synchronous check-and-set above; neither is moved,
+        // duplicated, or awaited around that guard. Only ever attempted for
+        // `backend === "stock"`, and only when the caller actually provided the
+        // allocator -- every fork launch and every caller before this feature
+        // existed never reaches this branch at all.
         let remoteMonitorPort;
         if (deps.backend === "stock" && deps.allocateRemoteMonitorPort) {
             const remoteResult = await deps.allocateRemoteMonitorPort(deps.state, new Set([port]));
@@ -548,12 +536,12 @@ export async function acquirePortAndLaunch(reason, deps) {
                 remoteMonitorPort = remoteResult.port;
             }
             else {
-                // Plan 41-05 (D-16): FAIL, never degrade. Owner direction, verbatim:
-                // "it should not be possible, vice must be started witht the text
-                // channel." A stock launch that cannot bind a text-monitor port
-                // fails the whole acquire -- no process is spawned. The PRIMARY port
-                // allocated moments earlier is not yet in `state.instances` and was
-                // never added to `state.blockedPorts` by this function (only
+                // FAIL, never degrade. Owner direction, verbatim: "it should not be
+                // possible, vice must be started witht the text channel." A stock
+                // launch that cannot bind a text-monitor port fails the whole
+                // acquire -- no process is spawned. The PRIMARY port allocated
+                // moments earlier is not yet in `state.instances` and was never
+                // added to `state.blockedPorts` by this function (only
                 // `nextFreePort()`'s own in-use probe blocks a candidate, and that
                 // never ran against the winning candidate) -- so it is already
                 // allocatable again on the very next call with no further release
@@ -561,7 +549,7 @@ export async function acquirePortAndLaunch(reason, deps) {
                 // it. This failure arm must NEVER call spawnAndRecordInstance() or
                 // otherwise leave a port "spoken for" on the caller's behalf.
                 log(`vice-broker: second (-remotemonitor) port allocation failed (${remoteResult.reason}) -- ` +
-                    `abandoning the stock launch; the text-monitor port is mandatory on every stock launch (D-16) and the acquire fails`);
+                    `abandoning the stock launch; the text-monitor port is mandatory on every stock launch and the acquire fails`);
                 return { ok: false, reason: "no_free_text_port" };
             }
         }
@@ -589,17 +577,17 @@ export async function acquirePortAndLaunch(reason, deps) {
  * deleting the record AND handing its second (`-remotemonitor`) port back to
  * the allocator in the same step.
  *
- * CR-02 (03-REVIEW.md): `acquirePortAndLaunch()` above adds every allocated
- * remote-monitor port to `state.blockedPorts`, and until this function existed
- * NOTHING ever removed one. `nextFreePort()` never reconsiders a blocked
- * candidate for the lifetime of the process, so every teardown of a stock
- * instance permanently consumed one more port out of the fixed
- * PORT_SCAN_CEILING window even though the OS port was free again the instant
- * the owning process exited -- a long-running broker (the explicit design goal
- * of an on-demand pool with crash supervision, per plan 41-05 launched
- * strictly on demand rather than kept warm) eventually exhausts its band and
- * answers `no_free_port` to ordinary launches purely
- * from routine churn, with no operator recourse short of a broker restart.
+ * `acquirePortAndLaunch()` above adds every allocated remote-monitor port to
+ * `state.blockedPorts`, and until this function existed NOTHING ever removed
+ * one. `nextFreePort()` never reconsiders a blocked candidate for the
+ * lifetime of the process, so every teardown of a stock instance permanently
+ * consumed one more port out of the fixed PORT_SCAN_CEILING window even
+ * though the OS port was free again the instant the owning process exited
+ * -- a long-running broker (the explicit design goal of an on-demand pool
+ * with crash supervision, launched strictly on demand rather than kept
+ * warm) eventually exhausts its band and answers `no_free_port` to ordinary
+ * launches purely from routine churn, with no operator recourse short of a
+ * broker restart.
  *
  * A RESPAWN is deliberately NOT a call site: the replacement instance keeps
  * BOTH the primary port and the remote-monitor port of the instance it
@@ -660,7 +648,7 @@ async function defaultHttpProbe(port, timeoutMs) {
     }
 }
 // ---------------------------------------------------------------------------
-// WR-01: the STOCK readiness route.
+// The STOCK readiness route.
 //
 // probeReady() below used to POST http://127.0.0.1:<port>/mcp unconditionally
 // and require both "version" and "machine" in the body. On the stock backend
@@ -681,8 +669,9 @@ async function defaultHttpProbe(port, timeoutMs) {
 // probe-binmon.mjs. What is written here is the minimum a READINESS check needs:
 // one request header out, one response header in, four bytes checked.
 // ---------------------------------------------------------------------------
-/** Hand-copied from docs/phase0-binmon-findings.md §5 -- see the block comment
- * above for why these are not imported from stock-protocol.ts. */
+/** Hand-copied from this project's own measured binary-monitor wire format
+ * (the same constants stock-protocol.ts defines) -- see the block comment
+ * above for why these are not imported from stock-protocol.ts directly. */
 const BINMON_STX = 0x02;
 const BINMON_API_VERSION = 0x02;
 const BINMON_REQUEST_HEADER_LEN = 11;
@@ -708,15 +697,15 @@ function binmonRequest(commandType, requestId) {
  * collides between the two, which is exactly why demux must key on it. */
 const BINMON_UNSOLICITED_REQUEST_ID = 0xffffffff;
 /**
- * WR-01: one PING (0x81) over the binary monitor, requiring a WELL-FORMED 0x81
+ * One PING (0x81) over the binary monitor, requiring a WELL-FORMED 0x81
  * reply -- STX, the expected api_version, response type 0x81, error code 0x00,
  * and this probe's own request id. A bare TCP accept is explicitly insufficient
  * here for exactly the reason probeReady()'s own comment gives for the HTTP
  * route: a C64 can accept a connection before it has finished booting.
  *
- * quick task 260818-obc (live-discovered): a NEW binmon connection ALWAYS
- * emits an unsolicited REGISTER_INFO (0x31) frame at request-id 0xffffffff
- * the instant it opens (CLAUDE.md's own Protocol constraint) -- BEFORE this
+ * A live-discovered defect: a NEW binmon connection ALWAYS emits an
+ * unsolicited REGISTER_INFO (0x31) frame at request-id 0xffffffff the
+ * instant it opens (CLAUDE.md's own Protocol constraint) -- BEFORE this
  * probe's own PING reply ever arrives. The naive "the first 12 bytes ARE the
  * reply" read this code used to do treated that event frame's OWN response-
  * type byte (0x31) as a malformed PING reply and answered `false` forever,
@@ -732,8 +721,8 @@ const BINMON_UNSOLICITED_REQUEST_ID = 0xffffffff;
  * ViceMonitorClient chief among them).
  *
  * Then EXIT (0xaa), unconditionally, before closing -- because the PING ITSELF
- * HALTS THE MACHINE. Any inbound byte does (docs/phase0-binmon-findings.md §4,
- * and CR-02, which fixed the same omission in the connect handshake). A
+ * HALTS THE MACHINE. Any inbound byte does, and this project's own connect
+ * handshake had the same omission and was fixed for the same reason. A
  * readiness probe that left every warm instance frozen would be a worse defect
  * than the one it fixes: the emulator would be "ready" and stopped.
  *
@@ -821,32 +810,29 @@ async function defaultBinmonProbe(port, timeoutMs) {
         });
     });
 }
-/** D-05, AS AMENDED BY P-05 -- this comment is the amendment's record, kept
- * in the exact place a three-branch description used to sit, per this
- * plan's own instruction that a code reader must meet the amendment here,
- * not merely in the plan text (`01.6.2.1-02-PLAN.md`) or the validation
- * ledger (`01.6.2-VALIDATION.md`, consolidated by plan 06).
+/** This comment records why the readiness probe below looks the way it
+ * does, kept in the exact place a longer, three-branch description used to
+ * sit.
  *
- * D-05 (locked, `01.6.2-CONTEXT.md`) originally specified the probe as a
- * bare in-process TCP connect to the instance's own monitor port, with a
- * short timeout. The code that landed instead argued against that wording,
- * in its OWN comment: "a bare TCP accept is explicitly not sufficient (a
- * C64 can accept a connection before it has finished booting)" -- a
- * booting emulator promoted to ready on nothing more than an accepted
- * connection is exactly Defect 3's failure shape reappearing, here on the
- * plan-01 acquire hot path.
+ * The probe was originally specified as a bare in-process TCP connect to
+ * the instance's own monitor port, with a short timeout. The code that
+ * landed instead argued against that wording, in its OWN comment: "a bare
+ * TCP accept is explicitly not sufficient (a C64 can accept a connection
+ * before it has finished booting)" -- a booting emulator promoted to ready
+ * on nothing more than an accepted connection is exactly the kind of false
+ * positive this probe exists to prevent.
  *
- * P-05 amends D-05: the ping-shaped request body stays -- it is what
- * proves the emulator ANSWERS, not merely that a port is bound, which is
- * the whole difference between a liveness check and a readiness check. The
- * two OTHER branches the landed code carried (an external-command
- * mechanism, and a "neither mechanism available -> report ready
- * unconditionally" fallback) retire outright, per P-06: with no second
- * mechanism to prefer and no "no mechanism" state left to report, there is
- * no longer a pair of indistinguishable states (a deliberately-zero warm
- * floor and a broken host) for an operator to confuse in the logs. D-05's
- * own intent -- exactly one check, no external command, no ambiguity -- is
- * fully honoured by this collapse, not reversed by it.
+ * The ping-shaped request body stays -- it is what proves the emulator
+ * ANSWERS, not merely that a port is bound, which is the whole difference
+ * between a liveness check and a readiness check. Two other mechanisms the
+ * landed code originally carried (an external-command mechanism, and a
+ * "neither mechanism available -> report ready unconditionally" fallback)
+ * were retired outright: with no second mechanism to prefer and no "no
+ * mechanism" state left to report, there is no longer a pair of
+ * indistinguishable states (a deliberately-zero warm floor and a broken
+ * host) for an operator to confuse in the logs. The original intent --
+ * exactly one check, no external command, no ambiguity -- is fully
+ * honoured by this collapse, not reversed by it.
  *
  * No retry loop, deliberately: a still-booting instance simply fails THIS
  * pass and is re-probed on the next one (promoteLaunchingInstances()'s own
@@ -858,7 +844,7 @@ async function defaultBinmonProbe(port, timeoutMs) {
 export async function probeReady(port, deps = {}) {
     const timeoutS = Number(deps.probeTimeoutSEnv ?? process.env.VICE_BROKER_PROBE_TIMEOUT_S) || DEFAULT_PROBE_TIMEOUT_S;
     const timeoutMs = timeoutS * 1000;
-    // WR-01: the route is chosen by the backend, exactly like buildViceArgs()'s
+    // The route is chosen by the backend, exactly like buildViceArgs()'s
     // own argv choice, and from the SAME threaded-down verdict. The fork arm below
     // is byte-identical to what this function always did, including the
     // omitted-backend default -- a fork deployment sees no behaviour change.
@@ -880,7 +866,7 @@ export async function probeReady(port, deps = {}) {
 export async function promoteLaunchingInstances(deps) {
     const log = deps.log ?? defaultLog;
     const now = deps.now ?? (() => Date.now());
-    // WR-01: the DEFAULT probe follows this call's own backend, so a caller that
+    // The DEFAULT probe follows this call's own backend, so a caller that
     // threads `backend` and omits `probe` gets a matching readiness route
     // rather than an HTTP POST at a binary-monitor port. An explicitly
     // injected `probe` still wins, unchanged.
@@ -902,22 +888,21 @@ export async function promoteLaunchingInstances(deps) {
  * comment names the ordering as load-bearing: "the spare invariant is
  * always re-evaluated against the freshest possible grant/teardown
  * state"). The bash version's third concern, the grant sweep, does NOT
- * appear here -- it is one of criterion F's six retiring file-lease
- * mechanisms; the TCP connection itself is the lease (D-12). The
- * broker-instances.json projection write does not appear either, per D-24
- * (see broker-state.mts's own FINDING 2 comment). Takes plain callbacks
- * rather than the full BrokerState/deps shape so a test can inject two
- * instrumented no-op functions and assert call ORDER without needing a
- * real broker, a real port or a real launch.
+ * appear here -- it is one of several retiring file-lease mechanisms; the
+ * TCP connection itself is the lease. The broker-instances.json projection
+ * write does not appear either (see broker-state.mts's own FINDING 2
+ * comment). Takes plain callbacks rather than the full BrokerState/deps
+ * shape so a test can inject two instrumented no-op functions and assert
+ * call ORDER without needing a real broker, a real port or a real launch.
  *
- * Plan 41-05 (folded todo): the warm floor that D-07 (01.6.2.1-03-PLAN.md)
- * originally reasoned about here is GONE -- `promoteLaunching` never calls
+ * The warm floor that non-preemptive launch priority originally reasoned
+ * about here is GONE -- `promoteLaunching` never calls
  * acquirePortAndLaunch() and so never competes for the single in-flight
  * launch slot the way a warm-floor spare launch used to. `serveAcquires()`
  * (via its own drainPendingAcquires()) is now the ONLY caller in this pass
- * that ever launches anything, so D-07's original "which reason wins a
- * freed slot" question has nothing left to decide BETWEEN these two steps --
- * that reasoning still applies WITHIN the acquire arm itself (two overlapping
+ * that ever launches anything, so the original "which reason wins a freed
+ * slot" question has nothing left to decide BETWEEN these two steps -- that
+ * reasoning still applies WITHIN the acquire arm itself (two overlapping
  * acquires still resolve through the single in-flight owner
  * (acquirePortAndLaunch()'s own invariant comment), which this reordering
  * never weakens). What the fixed order still buys: promoting AFTER serving
@@ -932,14 +917,14 @@ export async function runBrokerPass(deps) {
     await deps.promoteLaunching();
 }
 // ===========================================================================
-// Per-child supervision (Plan 03, Task 2 -- C2/D-23): absorbs
-// resources/vice-supervisor.sh WHOLESALE. The respawn loop becomes an
-// exit-event handler installed on the spawned child; the backoff shape
-// (initial delay, doubling, ceiling), the crash-loop give-up (too many
-// crashes inside a window), and the per-instance boot/crash log are ported
-// exactly, per D-1's own configuration knobs -- VICE_RESTART_BACKOFF_S,
-// VICE_RESTART_BACKOFF_MAX_S, VICE_MAX_RESTARTS, VICE_CRASH_WINDOW_S all
-// keep their exact names and semantics.
+// Per-child supervision: absorbs resources/vice-supervisor.sh WHOLESALE. The
+// respawn loop becomes an exit-event handler installed on the spawned
+// child; the backoff shape (initial delay, doubling, ceiling), the
+// crash-loop give-up (too many crashes inside a window), and the
+// per-instance boot/crash log are ported exactly, keeping the same
+// configuration knobs -- VICE_RESTART_BACKOFF_S, VICE_RESTART_BACKOFF_MAX_S,
+// VICE_MAX_RESTARTS, VICE_CRASH_WINDOW_S all keep their exact names and
+// semantics.
 // ===========================================================================
 function resolveMs(envVar, defaultSeconds, override) {
     if (typeof override === "number")
@@ -996,12 +981,11 @@ async function handleExit(reason, port, deps) {
         return;
     }
     const log = deps.log ?? defaultLog;
-    // Plan 05 (BROK-02/PROTO-08), promoted to a per-channel map by plan 41-03
-    // (D-14): the process behind this instance's monitor sockets has just
-    // exited, by every path this function can take (crash, recycle, or a
-    // deliberate teardown) -- clear EVERY channel's ownership record HERE,
-    // once, before any of those paths branch, so a client that died without
-    // releasing can never hold this lock forever on any channel. Redundant
+    // The process behind this instance's monitor sockets has just exited, by
+    // every path this function can take (crash, recycle, or a deliberate
+    // teardown) -- clear EVERY channel's ownership record HERE, once, before
+    // any of those paths branch, so a client that died without releasing can
+    // never hold this lock forever on any channel. Redundant
     // with the respawn/delete paths below (a fresh InstanceRecord never
     // carries this forward; a deleted one has no field to carry), but
     // explicit for the same reason broker-state.mts's own header comment
@@ -1024,20 +1008,19 @@ async function handleExit(reason, port, deps) {
             const preKillState = record.state;
             const preKillCrashTimes = record.crashTimes ?? [];
             const preKillBackoffMs = record.backoffMs ?? resolveMs("VICE_RESTART_BACKOFF_S", 3, deps.initialBackoffMs);
-            // CR-02 (03-REVIEW.md): the second (`-remotemonitor`) port is carried
-            // forward across the replacement exactly like the primary port is --
-            // captured BEFORE launchSupervised() overwrites this port's map entry
-            // with a brand new record, for the same reason the three values above
-            // are.
+            // The second (`-remotemonitor`) port is carried forward across the
+            // replacement exactly like the primary port is -- captured BEFORE
+            // launchSupervised() overwrites this port's map entry with a brand
+            // new record, for the same reason the three values above are.
             const preKillRemoteMonitorPort = record.remoteMonitorPort;
-            // Phase 33, plan 33-06 (D-16, T-33-24): the launch PROFILE is carried
-            // forward for exactly the reason CR-02 carries the remote-monitor port
-            // forward, and the failure it prevents is sharper. Without this, a
-            // recycled `{warp:true}` instance would come back UNWARPED while its
-            // fresh record still claimed `profile:{warp:true}` -- after which
-            // profileEligible() (vice-broker.mts) would happily hand that instance
-            // to the next warp request. That is precisely the undetectable lie
-            // D-16 exists to structurally exclude, reintroduced one respawn later.
+            // The launch PROFILE is carried forward for exactly the reason the
+            // remote-monitor port is carried forward above, and the failure it
+            // prevents is sharper. Without this, a recycled `{warp:true}`
+            // instance would come back UNWARPED while its fresh record still
+            // claimed `profile:{warp:true}` -- after which profileEligible()
+            // (vice-broker.mts) would happily hand that instance to the next warp
+            // request. That is precisely the undetectable lie this carry-forward
+            // exists to structurally exclude, reintroduced one respawn later.
             // Captured BEFORE launchSupervised() overwrites this port's map entry
             // with a brand new record, same as the four values above.
             const preKillProfile = record.profile;
@@ -1061,7 +1044,7 @@ async function handleExit(reason, port, deps) {
             deps.onOutcome?.("recycled", port);
             return;
         }
-        // CR-02: a deliberate teardown is the END of this instance -- its
+        // A deliberate teardown is the END of this instance -- its
         // remote-monitor port must go back to the allocator with it.
         deleteInstanceRecord(deps.state, port);
         deps.onOutcome?.("deliberate_teardown", port);
@@ -1075,7 +1058,7 @@ async function handleExit(reason, port, deps) {
     if (crashTimes.length >= maxRestarts) {
         log(`vice-broker: giving up on port ${port} after ${crashTimes.length} crashes within ${crashWindowMs}ms -- ` +
             `this is not a transient crash; check VICE_ARGS and whether the port is already bound`);
-        // CR-02: giving up is likewise terminal for this instance -- release its
+        // Giving up is likewise terminal for this instance -- release its
         // remote-monitor port rather than leaking it out of the allocation band.
         deleteInstanceRecord(deps.state, port);
         deps.onOutcome?.("given_up", port);
@@ -1086,13 +1069,13 @@ async function handleExit(reason, port, deps) {
     await sleepMs(currentBackoffMs);
     const maxBackoffMs = resolveMs("VICE_RESTART_BACKOFF_MAX_S", 30, deps.maxBackoffMs);
     const nextBackoffMs = Math.min(currentBackoffMs * 2, maxBackoffMs);
-    // CR-02: same carry-forward as the recycle branch above -- a crash must not
+    // Same carry-forward as the recycle branch above -- a crash must not
     // silently strip `-remotemonitor` (and its InstanceRecord field) off the
-    // replacement, which is what made D-13's "the instance record carries it"
-    // stop being true the first time an instance was replaced.
-    // Phase 33, plan 33-06: same carry-forward as the recycle branch above --
-    // an unexplained crash must not silently strip `-warp`/`-console` off the
-    // replacement while leaving the record claiming them (D-16, T-33-24).
+    // replacement, which would otherwise make the instance record's claim to
+    // carry that field stop being true the first time an instance was
+    // replaced. Same reasoning applies to the launch profile -- an
+    // unexplained crash must not silently strip `-warp`/`-console` off the
+    // replacement while leaving the record claiming them.
     const respawned = launchSupervised(reason, port, deps, crashTimes, nextBackoffMs, record.remoteMonitorPort, record.profile);
     deps.onOutcome?.(respawned ? "respawned" : "given_up", port);
 }
@@ -1118,12 +1101,11 @@ async function handleExit(reason, port, deps) {
  * a second inline listener, is what keeps the "exactly one installation
  * point" invariant a structural gate (broker-launch.test.ts) can hold. */
 export function withCrashSupervision(reason, port, baseSpawn, deps) {
-    // I-1 rider (08.2-06-PLAN.md, Task 1): forwards a third options argument
-    // in the BODY, not just the type -- this is the hop that matters most,
-    // because it wraps every real launch path (cold acquire and every
-    // respawn -- plan 41-05 retires the warm floor, the third path this
-    // comment used to name). A type-only widening would still silently drop a
-    // caller's options at this call site.
+    // Forwards a third options argument in the BODY, not just the type --
+    // this is the hop that matters most, because it wraps every real launch
+    // path (cold acquire and every respawn -- a warm floor used to be a
+    // third path here and has since been retired). A type-only widening
+    // would still silently drop a caller's options at this call site.
     return (cmd, args, options) => {
         const child = baseSpawn(cmd, args, options);
         child.once("exit", () => {
@@ -1133,7 +1115,7 @@ export function withCrashSupervision(reason, port, baseSpawn, deps) {
     };
 }
 /** Launches (or relaunches) a supervised instance: spawns through
- * tryLaunchOne() (the SAME single guarded primitive plan 02 established --
+ * tryLaunchOne() (the SAME single guarded primitive established above --
  * "spawn again through the SAME single guarded launch function", never a
  * second, parallel spawn path), writes the per-instance boot/crash log at
  * the path shape the retiring supervisor used (a `logs/` directory under
@@ -1148,26 +1130,26 @@ export function withCrashSupervision(reason, port, baseSpawn, deps) {
  * fact that spawnAndRecordInstance() creates a BRAND NEW InstanceRecord
  * object on every launch, replacing the old one at the same port key.
  *
- * CR-02 (03-REVIEW.md): `remoteMonitorPort` is threaded the SAME way and for
- * the same reason -- it belongs to the instance, not to a single spawn of it.
- * The replacement reuses the port the crashed/recycled process just vacated
- * (already reserved in `state.blockedPorts`, so nothing else can have taken it
+ * `remoteMonitorPort` is threaded the SAME way and for the same reason --
+ * it belongs to the instance, not to a single spawn of it. The replacement
+ * reuses the port the crashed/recycled process just vacated (already
+ * reserved in `state.blockedPorts`, so nothing else can have taken it
  * meanwhile), exactly as it reuses the primary `port` argument; this function
  * stays fully synchronous and never allocates. `undefined` is the correct
  * value for a FIRST launch through superviseChild() and for every fork launch,
  * which is why the parameter is optional.
  *
- * Phase 33, plan 33-06 (D-16): `profile` is threaded the SAME way and for a
- * sharper version of the same reason -- it belongs to the instance, not to a
- * single spawn of it, and warp is fixed at spawn (there is no runtime
- * `WarpMode` resource on stock at all). A replacement that dropped it would
- * come back unwarped while its record still claimed warp, which is exactly the
- * mismatch-between-grant-and-request that D-16's eligibility rule exists to
+ * `profile` is threaded the SAME way and for a sharper version of the same
+ * reason -- it belongs to the instance, not to a single spawn of it, and
+ * warp is fixed at spawn (there is no runtime `WarpMode` resource on stock
+ * at all). A replacement that dropped it would come back unwarped while
+ * its record still claimed warp, which is exactly the
+ * mismatch-between-grant-and-request that this carry-forward exists to
  * make impossible. `undefined` is correct for a FIRST launch through
  * superviseChild() -- production has no profile-less first-launch call site
- * of its own left after plan 41-05 retires the warm floor, but this
- * module's own unit tests still drive one directly -- and for every fork
- * launch, which is why this parameter is optional too. */
+ * of its own left now that the warm floor is retired, but this module's
+ * own unit tests still drive one directly -- and for every fork launch,
+ * which is why this parameter is optional too. */
 function launchSupervised(reason, port, deps, crashTimes, backoffMs, remoteMonitorPort, profile) {
     const supervisorDir = join(deps.stateDir, String(port));
     const epochFile = deps.epoch.epochPathFor(deps.stateDir, port);
@@ -1184,15 +1166,15 @@ function launchSupervised(reason, port, deps, crashTimes, backoffMs, remoteMonit
     const logFileName = `${basename(viceBin)}-${Date.now()}-e${epoch}.log`;
     const logPath = join(logDir, logFileName);
     const logRelPath = `logs/${logFileName}`;
-    // I-1 rider (08.2-06-PLAN.md, Task 1): forwards a third options argument
-    // and MERGES it with the per-instance log stdio -- caller options
-    // spread FIRST, `stdio` set LAST, so the per-instance log fd always
-    // wins. Never the other order: a caller-supplied `stdio` would silently
-    // redirect a crash-respawn's output away from the log file the epoch
-    // record names, and the forensic per-instance log (D-23) would point at
-    // a file that received nothing. Without this fix, a stock instance that
-    // crashes and respawns comes back reading the operator's real `vicerc`
-    // even though its original launch was isolated.
+    // Forwards a third options argument and MERGES it with the per-instance
+    // log stdio -- caller options spread FIRST, `stdio` set LAST, so the
+    // per-instance log fd always wins. Never the other order: a
+    // caller-supplied `stdio` would silently redirect a crash-respawn's
+    // output away from the log file the epoch record names, and the
+    // forensic per-instance log would point at a file that received nothing.
+    // Without this fix, a stock instance that crashes and respawns comes back
+    // reading the operator's real `vicerc` even though its original launch
+    // was isolated.
     const defaultRealSpawn = (cmd, args, options) => {
         const fd = openSync(logPath, "a");
         return nodeSpawn(cmd, args, { ...options, stdio: ["ignore", fd, fd] });
@@ -1249,16 +1231,16 @@ function launchSupervised(reason, port, deps, crashTimes, backoffMs, remoteMonit
  * mirroring resources/vice-supervisor.sh's own respawn loop but expressed
  * as an event-loop exit handler instead of a `while true` poll.
  *
- * Plan 41-05 (D-16): `remoteMonitorPort` is an OPTIONAL fourth parameter,
- * threaded straight through to launchSupervised() exactly like every other
- * optional trailing parameter in this file. A
- * `backend: "stock"` caller MUST supply it: spawnAndRecordInstance()'s own
- * construction-site assertion (D-16) throws otherwise, since this function
- * is a genuine first-launch call site, not merely a respawn. This is not a
- * production stock first-launch path today (only acquirePortAndLaunch() is)
- * -- it exists for this module's own unit tests to drive a supervised first
- * launch directly, and the parameter exists so a stock test case can do so
- * without violating the same guarantee production code enforces. */
+ * `remoteMonitorPort` is an OPTIONAL fourth parameter, threaded straight
+ * through to launchSupervised() exactly like every other optional trailing
+ * parameter in this file. A `backend: "stock"` caller MUST supply it:
+ * spawnAndRecordInstance()'s own construction-site assertion throws
+ * otherwise, since this function is a genuine first-launch call site, not
+ * merely a respawn. This is not a production stock first-launch path today
+ * (only acquirePortAndLaunch() is) -- it exists for this module's own unit
+ * tests to drive a supervised first launch directly, and the parameter
+ * exists so a stock test case can do so without violating the same
+ * guarantee production code enforces. */
 export function superviseChild(reason, port, deps, remoteMonitorPort) {
     const initialBackoffMs = resolveMs("VICE_RESTART_BACKOFF_S", 3, deps.initialBackoffMs);
     return launchSupervised(reason, port, deps, [], initialBackoffMs, remoteMonitorPort);