@henols/vice-mcp 0.2.2 → 0.2.4

package/resources/broker-launch.mjs

@@ -2,29 +2,32 @@
 // Compiled by `tsc` from broker-launch.mts. Edit the TypeScript source and rebuild;
 // changes made directly to this file are silently overwritten by the next build, and are never
 // deployed to the host on their own -- install-resources.mjs copies THIS file's on-disk contents
-// verbatim to tools/, so an edit made only here reaches the host but is lost on the very next
+// verbatim to .c64-re-tools/bin/, so an edit made only here reaches the host but is lost on the very next
 // 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),
-// serialised warm-floor maintenance (one launch per pass, never more), and
-// the fixed-order evaluation pass both surviving concerns run through.
+// 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() --
+// 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";
@@ -33,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
@@ -50,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. */
@@ -65,12 +67,43 @@ 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;
+/** 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;
+/** 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: 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",
+    String(STOCK_DETERMINISM_SEED),
+    "-raminitstartrandom",
+    "0",
+    "-raminitrepeatrandom",
+    "0",
+    "-raminitrandomchance",
+    "0",
+    "+autostart-delay-random",
+]);
 /** Resolves the emulator's own argument vector for the given `backend`. The
  * `VICE_ARGS` full-override short-circuit (matching
  * resources/vice-supervisor.sh's own VICE_ARGS convention exactly) is
@@ -80,42 +113,50 @@ let warnedRemoteMonitorBindWidened = false;
  * understands neither `-mcpserver` nor `-binarymonitor` flags, and that need
  * does not depend on which backend is configured.
  *
- * `backend: "fork"` returns exactly the pre-Phase-2 shape, byte-identical:
- * the MCP server flag, the MCP server host from `mcpHost` or
- * VICE_BROKER_MCP_HOST (default `0.0.0.0`), and the MCP server port.
+ * `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.
  *
- * `backend: "stock"` 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
- * narrower than the fork path's `0.0.0.0` default, 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.
+ * 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.
  *
- * 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 3 dials
- * nothing on this port; only the launch flag lands now (see D-13's own
- * rationale: adding the flag later would require relaunching a live
- * instance, destroying all emulation state). */
-export function buildViceArgs(port, { backend, mcpHost, binmonHost, viceArgsEnv, remoteMonitorPort, }) {
+ * 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() !== "") {
         return rawViceArgs.trim().split(/\s+/);
@@ -138,22 +179,116 @@ export function buildViceArgs(port, { backend, mcpHost, binmonHost, viceArgsEnv,
         // first element: it is VICE's reset-to-compiled-in-defaults instruction,
         // not an inert "these are the baselines" no-op, so any flag emitted
         // before it (including -drive8type) is silently clobbered back to its
-        // compiled-in value. `-drive8type 1541` therefore has to come
-        // immediately after `-default`, and -- per CLAUDE.md's documented
-        // constraint -- `-default` also has to come before `-binarymonitor` or
-        // the monitor never binds and the subsequent connect hangs in the
-        // backlog looking exactly like a wedge. Confirmed sufficient live in
-        // Phase 8.1's standalone probe (08.1-WALKTHROUGH-EVIDENCE.md §4):
+        // compiled-in value. `-drive8type 1541` therefore has to come AFTER
+        // `-default` -- not necessarily IMMEDIATELY after -- and -- per
+        // CLAUDE.md's documented constraint -- `-default` also has to come before
+        // `-binarymonitor` or the monitor never binds and the subsequent connect
+        // hangs in the backlog looking exactly like a wedge.
+        //
+        // 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: 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 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.
-        const args = ["-default", "-drive8type", "1541", "-binarymonitor", "-binarymonitoraddress", `ip4://${host}:${port}`];
+        // 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.
+        //
+        // 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:
+        //   [-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 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.
+        //
+        // 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` threaded in
+        // spawnAndRecordInstance() below.
+        //
+        // `+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
+        // easy to miss -- it also SELECTS WHICH keyboard-buffer feed injects `RUN`
+        // (`kbdbuf_feed_runcmd` when set, `kbdbuf_feed` when clear)
+        // [CITED: vice-3.8/src/autostart.c:882-886]. Disabling it is therefore a
+        // behavioural change and not only a timing one. Pin it once; never toggle
+        // it between the two runs of a capture pair.
+        //
+        // `-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");
+        }
+        args.push("-drive8type", "1541");
+        args.push(...STOCK_DETERMINISM_FLAGS);
+        if (profile?.warp) {
+            args.push("-warp");
+        }
+        args.push("-binarymonitor", "-binarymonitoraddress", `ip4://${host}:${port}`);
         if (typeof remoteMonitorPort === "number") {
             if (host !== "127.0.0.1" && !warnedRemoteMonitorBindWidened) {
                 warnedRemoteMonitorBindWidened = true;
@@ -186,42 +321,56 @@ function spawnAndRecordInstance(reason, port, deps) {
     const spawnFn = deps.spawn ?? ((cmd, args, opts) => nodeSpawn(cmd, args, opts));
     const now = deps.now ?? (() => Date.now());
     const viceBin = deps.viceBin ?? process.env.VICE_BIN ?? "x64sc";
-    const backend = deps.backend ?? "fork";
+    const backend = deps.backend ?? "stock";
+    // 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 -- 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,
+        // 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. For backend === "fork", spawnFn is called
-    // with NO third argument at all, so the fork path's observable behaviour
-    // stays bit-for-bit what it was (BACK-02 is a standing gate and the fork
-    // backend has been the sole production backend across all of v0.1.x).
+    // 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
     // default wrapper above is dead code on the real launch paths. This
     // function's job is only to COMPUTE the value at the one seam that should
-    // own it; the forwarding to nodeSpawn() happens at four further hops --
-    // makeLoggingSpawn() and maintainWarmFloorForRealBroker's inner
-    // stashingSpawn in vice-broker.mts, and withCrashSupervision()'s wrapper
-    // body and launchSupervised()'s defaultRealSpawn in this file. All four
-    // now forward the options argument (plan 08.2-06 closed them in this same
-    // phase, with a handleAcquire() composition test that omits
-    // buildColdSpawnFactory so an injected stub cannot fake the proof). If you
-    // add a fifth spawn hop, it must forward options too, or production stock
-    // launches silently lose their config isolation again.
+    // 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 (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
+    // options too, or production stock launches silently lose their config
+    // isolation again.
     //
     // Scratch-dir lifetime: this function deliberately does NOT clean the
     // directory up -- the spawned emulator process outlives this function's
@@ -254,7 +403,26 @@ function spawnAndRecordInstance(reason, port, deps) {
         viceBin,
         viceArgs,
         dryRun: false,
+        // 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: {},
+        // 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 }),
+        // 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);
     return record;
@@ -271,10 +439,10 @@ function spawnAndRecordInstance(reason, port, deps) {
  *
  * This is the RIGHT primitive when the port is already decided and fixed
  * (most tests; any future caller with its own allocation scheme). It is
- * deliberately NOT what handleAcquire or maintainWarmFloor call for a
- * FRESH port, because nextFreePort() itself is asynchronous (a real
- * port-in-use probe requires it) -- see acquirePortAndLaunch()'s own
- * header comment for the race that creates and how it is closed. */
+ * deliberately NOT what handleAcquire calls for a FRESH port, because
+ * nextFreePort() itself is asynchronous (a real port-in-use probe requires
+ * it) -- see acquirePortAndLaunch()'s own header comment for the race that
+ * creates and how it is closed. */
 export function tryLaunchOne(reason, port, deps) {
     if (inFlight)
         return null;
@@ -290,34 +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 (a cold acquire arriving over the TCP control
- * listener at any moment, and a warm-floor pass on its own poll timer)
+ * 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
+ * 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.
  *
- * This is also the function that restores vice-broker.sh's own
- * process_requests() throttle (its `in_flight` local, checked before a
- * COLD launch, not only before a warm one): a cold acquire and a
- * warm-floor pass can never launch simultaneously, 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: this function still only ever
- * refuses a second concurrent caller (`launch_in_flight`), and never kills
- * or preempts whichever caller already holds the slot -- which reason wins
- * this slot NEXT, once it frees, falls out of runBrokerPass()'s own fixed
- * evaluation order (that function's own invariant comment), 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. */
+ * 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. 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;
@@ -331,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]));
@@ -351,16 +530,27 @@ export async function acquirePortAndLaunch(reason, deps) {
                 // does. `state.blockedPorts` is a plain Set the type import already
                 // describes, so mutating it directly needs no value import at all --
                 // exactly the same discipline handleExit()'s own
-                // `record.monitorClient = undefined` uses in place of
+                // `record.monitorClients = {}` uses in place of
                 // clearMonitorClient().
                 deps.state.blockedPorts.add(remoteResult.port);
                 remoteMonitorPort = remoteResult.port;
             }
             else {
-                // Degrade, never fail: a port nothing dials yet (Phase 3 builds no
-                // text-monitor client) must never make the backend unavailable.
+                // 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
+                // step; a discriminating-power test proves this rather than assuming
+                // 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}) -- ` +
-                    `launching WITHOUT -remotemonitor; nothing in Phase 3 dials the text-monitor port anyway`);
+                    `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" };
             }
         }
         const record = spawnAndRecordInstance(reason, port, {
@@ -374,6 +564,7 @@ export async function acquirePortAndLaunch(reason, deps) {
             backend: deps.backend,
             binmonHost: deps.binmonHost,
             remoteMonitorPort,
+            profile: deps.profile,
         });
         return { ok: true, record };
     }
@@ -386,16 +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 and a warm floor) 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
@@ -456,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
@@ -477,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;
@@ -504,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,
@@ -528,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.
  *
@@ -617,36 +810,33 @@ 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 (maintainWarmFloor()'s own per-pass
- * cadence, or a later grant-time re-probe) -- this is what makes the
+ * pass and is re-probed on the next one (promoteLaunchingInstances()'s own
+ * per-pass cadence, or a later grant-time re-probe) -- this is what makes the
  * shortened ~1s default below safe rather than reckless: a slow host is
  * re-probed, never starved, and the seconds-valued timeout knob
  * (VICE_BROKER_PROBE_TIMEOUT_S) still lets an operator on a slow host raise
@@ -654,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.
@@ -665,61 +855,22 @@ export async function probeReady(port, deps = {}) {
     const httpProbe = deps.httpProbe ?? defaultHttpProbe;
     return httpProbe(port, timeoutMs);
 }
-// ---------------------------------------------------------------------------
-// Serialised warm-floor maintenance
-// ---------------------------------------------------------------------------
-function resolveWarmFloor(override) {
-    if (typeof override === "number")
-        return override;
-    const raw = process.env.VICE_BROKER_WARM_FLOOR;
-    if (raw === undefined || raw === "")
-        return 1;
-    const n = Number(raw);
-    return Number.isFinite(n) ? n : 1;
-}
-function resolveCeiling(override) {
-    if (typeof override === "number")
-        return override;
-    const raw = process.env.VICE_BROKER_MAX;
-    if (raw === undefined || raw === "")
-        return 16;
-    const n = Number(raw);
-    return Number.isFinite(n) ? n : 16;
-}
-/** Promotes launching instances via probe, then -- unless a launch is
- * already in flight -- launches AT MOST ONE instance toward the warm floor
- * and returns. Never loops to reach the floor in one call: reaching
- * VICE_BROKER_WARM_FLOOR this way costs one
- * additional CALL per warm instance instead of one call total, which is the exact
- * trade the 2026-08-01 outage made non-negotiable (three simultaneous
- * x64sc launches: one SEGV, one exit 1, one exit 0 at the identical spawn
- * second). `async`/`await` makes launching everything needed in one go
- * look free and idiomatic; it is actively dangerous here. DO NOT gather
- * several pending launches into a single concurrent await, and do not
- * "helpfully" loop this function internally until the floor is met.
- *
- * D-05's probe-live floor evaluation (count_ready() trusting probe-live
- * instances rather than a recorded `ready` state) is explicitly Phase
- * 01.6.2.1's criterion L, NOT this plan's -- countReady() here still
- * counts by RECORDED state, exactly like the bash original's count_ready()
- * before Decision 5.2. A reviewer must not mistake this for an oversight:
- * it is the declined-for-this-phase choice RESEARCH.md §A1 recommends, and
- * grant_from_spare()'s own live re-probe at GRANT time (broker-kill.mts /
- * plan 04's territory) is a separate, already-correct mechanism this plan
- * does not touch. */
-export async function maintainWarmFloor(deps) {
+/** Promotes every `launching` instance whose readiness probe now succeeds to
+ * `ready`, recording its readiness timestamp and logging the elapsed boot
+ * time. Runs regardless of whether a launch is in flight -- promotion and a
+ * NEW launch starting are independent concerns; an already-launched instance
+ * becomes usable the moment it answers, whether or not this same pass goes on
+ * to start anything further. No retry loop: a still-booting instance simply
+ * fails THIS pass and is re-probed on the next one (runBrokerPass()'s own
+ * per-tick cadence). */
+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
-    // threads `backend` for the launch argv 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.
-    const probe = deps.probe ?? ((port) => probeReady(port, { backend: deps.backend ?? "fork" }));
-    // Step 1: promote every "launching" instance whose probe now succeeds.
-    // Runs regardless of whether a launch is in flight -- promotion and
-    // speculative warming are independent concerns; an already-launched
-    // instance becomes usable the moment it answers, whether or not this
-    // pass goes on to warm anything further.
+    // 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.
+    const probe = deps.probe ?? ((port) => probeReady(port, { backend: deps.backend ?? "stock" }));
     for (const record of deps.state.instances.values()) {
         if (record.state !== "launching")
             continue;
@@ -732,103 +883,48 @@ export async function maintainWarmFloor(deps) {
             log(`vice-broker: port ${record.port} launching -> ready (${elapsedMs}ms)`);
         }
     }
-    // Step 2 (P-06: the warm-zero "no readiness mechanism" branch that used
-    // to sit here is GONE -- the surviving probe mechanism is in-process and
-    // always available, so there is no "no mechanism" state left to warm
-    // zero against). No new boot starts while one is already under way --
-    // THE single in-flight counter (countLaunching) both this function and a
-    // cold acquire (vice-broker.mts's handleAcquire) consult.
-    if (deps.countLaunching(deps.state) > 0) {
-        // D-07's launch-slot decision log line, this decision point's own half:
-        // name WHICH reason currently holds the slot (the launching record's
-        // own `reason`, whichever call produced it -- cold acquire or an
-        // earlier warming pass), not merely that warming is waiting.
-        const inFlightRecord = Array.from(deps.state.instances.values()).find((r) => r.state === "launching");
-        const winningReason = inFlightRecord?.reason ?? "unknown";
-        log(`vice-broker: launch-slot decision -- ${winningReason} holds the slot; spare waits (D-07)`);
-        return;
-    }
-    const ready = deps.countReady(deps.state);
-    const total = deps.countTotal(deps.state);
-    const warmFloor = resolveWarmFloor(deps.warmFloor);
-    const ceiling = resolveCeiling(deps.ceiling);
-    if (!(ready < warmFloor && total < ceiling)) {
-        return;
-    }
-    // acquirePortAndLaunch() holds the SAME single in_flight owner across
-    // its own async port allocation -- not merely tryLaunchOne()'s
-    // synchronous spawn instant. This is what actually closes the race
-    // between this warm-floor launch and a cold acquire (vice-broker.mts's
-    // handleAcquire) arriving over the TCP control listener at any moment:
-    // the countLaunching() check just above is a cheap PRE-check (bails
-    // early when a launch is already recorded), but nextFreePort() is
-    // itself asynchronous, so without the guard held across the allocation
-    // too, two overlapping callers could still both be told the same
-    // candidate port is free before either commits it.
-    const result = await acquirePortAndLaunch("spare", {
-        state: deps.state,
-        stateDir: deps.stateDir,
-        allocatePort: deps.allocatePort,
-        allocateRemoteMonitorPort: deps.allocateRemoteMonitorPort,
-        spawn: deps.spawn,
-        spawnFactory: deps.spawnFactory,
-        now: deps.now,
-        viceBin: deps.viceBin,
-        mcpHost: deps.mcpHost,
-        backend: deps.backend,
-        binmonHost: deps.binmonHost,
-    });
-    if (result.ok) {
-        log(`vice-broker: warmed 1 warm instance this pass -- ${ready + 1} of ${warmFloor} ready, remainder warmed on later passes`);
-        deps.onLaunched?.(result.record);
-    }
-    else if (result.reason === "no_free_port") {
-        log(`vice-broker: no free port available -- warming no further warm instances; ${ready} of ${warmFloor} ready`);
-    }
-    else {
-        // A launch started (cold or warm) between this function's own
-        // countLaunching() check above and this call -- a narrow window
-        // closed by the guard rather than assumed impossible.
-        log("vice-broker: a warm-floor launch was attempted but a launch was already in flight -- deferring to a later pass");
-    }
 }
 /** The fixed pass order (mirrors vice-broker.sh's own broker_once(), whose
  * 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.
  *
- * D-07 (01.6.2.1-03-PLAN.md): THIS is where launch priority actually lives
- * -- serving acquires before maintaining the warm floor is what lets a
- * request-driven launch win a freed slot before a warming launch, within
- * one pass, on top of the single in-flight owner (acquirePortAndLaunch()'s
- * own invariant comment) that this order never weakens. Inverting this
- * order lets a warming launch take the slot first and go untested against
- * a concurrently arriving acquire, which is exactly the regression
- * broker-launch.test.ts's own D-07 priority test is written to catch (its
- * own discriminating-power demonstration inverts this exact order and
- * observes the test go red). Priority decides only which reason wins the
- * NEXT freed slot -- it is never a substitute for the lock, and it never
- * kills or abandons whichever boot is already in flight. */
+ * 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 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
+ * means an instance that becomes probe-ready DURING this exact tick is not
+ * available to any acquire THIS SAME pass -- selectWarmInstance() sees it on
+ * the NEXT pass instead, a bound of one poll interval (VICE_BROKER_POLL_MS),
+ * never a correctness gap, since a cold acquire finding no ready candidate
+ * falls straight through to its own dedicated cold launch rather than
+ * waiting on one. */
 export async function runBrokerPass(deps) {
     await deps.serveAcquires();
-    await deps.maintainWarmFloor();
+    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")
@@ -857,9 +953,11 @@ function resolveCount(envVar, defaultValue, override) {
  *   UNEXPLAINED exit, not this one. The pre-kill crash history and backoff
  *   are carried forward UNCHANGED, and a pre-kill "granted" state is
  *   restored on the fresh record -- the relaunch primitive always creates a
- *   new record in the "launching" state, and leaving it there would let the
- *   warm floor's own ready-count numerator mistake a recycled session's own
- *   machine for an available warm instance.
+ *   new record in the "launching" state, and leaving it there (once
+ *   promoted to "ready" by the next probe pass) would let a LATER,
+ *   UNRELATED acquire's own selectWarmInstance() walk (vice-broker.mts)
+ *   mistake a recycled session's own machine for an available candidate to
+ *   grant out from under the session that already owns it.
  * - deliberateKill set WITHOUT respawnAfterKill -> "deliberate_teardown":
  *   drop the instance, no respawn. This is T-01.6.2-21's whole point --
  *   without reading this flag, every deliberate teardown would respawn
@@ -883,22 +981,24 @@ async function handleExit(reason, port, deps) {
         return;
     }
     const log = deps.log ?? defaultLog;
-    // Plan 05 (BROK-02/PROTO-08): the process behind this instance's monitor
-    // socket has just exited, by every path this function can take (crash,
-    // recycle, or a deliberate teardown) -- clear the ownership record HERE,
-    // once, before any of those paths branch, so a client that died without
-    // releasing can never hold this lock forever. Redundant with the
-    // respawn/delete paths below (a fresh InstanceRecord never carries this
-    // field forward; a deleted one has no field to carry), but explicit for
-    // the same reason broker-state.mts's own header comment names this as one
-    // of the three required clearing sites. Assigned directly (not via
-    // broker-state.mjs's clearMonitorClient()) -- this module's own
+    // 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
+    // names this as one of the required clearing sites. Assigned directly
+    // (not via broker-state.mjs's clearMonitorClient()) -- this module's own
     // type-only import of that sibling (see this file's own header comment a
     // few lines above) is load-bearing: a VALUE import would turn "./broker-
     // state.mjs" into a real runtime resolution this file cannot satisfy when
     // loaded directly (as broker-launch.test.ts does), rather than the
-    // compiled resources/ sibling this specifier is actually shaped for.
-    record.monitorClient = undefined;
+    // compiled resources/ sibling this specifier is actually shaped for. `{}`
+    // (not `undefined`) since `monitorClients` is non-optional -- "no claim
+    // on any channel" is an empty map.
+    record.monitorClients = {};
     if (record.deliberateKill) {
         if (record.respawnAfterKill) {
             // Recycle. Capture the pre-kill state, crash history and backoff
@@ -908,13 +1008,23 @@ 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;
-            const respawned = launchSupervised(reason, port, deps, preKillCrashTimes, preKillBackoffMs, preKillRemoteMonitorPort);
+            // 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;
+            const respawned = launchSupervised(reason, port, deps, preKillCrashTimes, preKillBackoffMs, preKillRemoteMonitorPort, preKillProfile);
             if (respawned && preKillState === "granted") {
                 respawned.state = "granted";
             }
@@ -934,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);
@@ -948,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);
@@ -959,11 +1069,14 @@ 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.
-    const respawned = launchSupervised(reason, port, deps, crashTimes, nextBackoffMs, record.remoteMonitorPort);
+    // 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);
 }
 /** The single exit-listener installation point in the whole module tree.
@@ -988,11 +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, warm floor, and
-    // every respawn). 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", () => {
@@ -1002,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
@@ -1017,15 +1130,27 @@ 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. */
-function launchSupervised(reason, port, deps, crashTimes, backoffMs, remoteMonitorPort) {
+ * which is why the parameter is optional.
+ *
+ * `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 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);
     const logDir = deps.epoch.instanceLogDirFor(deps.stateDir, port);
@@ -1041,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] });
@@ -1067,6 +1192,7 @@ function launchSupervised(reason, port, deps, crashTimes, backoffMs, remoteMonit
         backend: deps.backend,
         binmonHost: deps.binmonHost,
         remoteMonitorPort,
+        profile,
         log: deps.log,
     });
     if (!record)
@@ -1103,8 +1229,19 @@ function launchSupervised(reason, port, deps, crashTimes, backoffMs, remoteMonit
  * (crash respawn with backoff, crash-loop give-up, kill-never-recycle via
  * the deliberate-kill marker, and the per-instance boot/crash log), exactly
  * mirroring resources/vice-supervisor.sh's own respawn loop but expressed
- * as an event-loop exit handler instead of a `while true` poll. */
-export function superviseChild(reason, port, deps) {
+ * as an event-loop exit handler instead of a `while true` poll.
+ *
+ * `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);
+    return launchSupervised(reason, port, deps, [], initialBackoffMs, remoteMonitorPort);
 }