@henols/vice-mcp 0.2.1 → 0.2.3

package/repo-root.ts

@@ -39,6 +39,19 @@
 // `scripts/` segment. Branch 4's hop count below moved from four levels to
 // three to match. Branches 1-3 are depth-independent (an env var check, then
 // a `.git` ancestor walk) and needed no change.
+//
+// FOURTH MOVE (phase 16-04, 2026-08-23): the module directory relocated
+// again, from `.claude/mcp/vice/` to `src/mcp/vice/` (packaging and repo
+// shape). `src`/`mcp`/`vice` is the same three path segments below the
+// repository root as the old `.claude`/`mcp`/`vice` shape -- this is
+// reviewed and confirmed, not assumed, from the segment count itself. Branch
+// 4's hop count was therefore reviewed and deliberately left unchanged: this
+// move relocates the same flat, three-segment shape elsewhere directly under
+// the root, which is a different move from nesting authored sources one
+// level deeper INSIDE this directory (which would make four, and IS what
+// branches 1-3's depth-independence and branch 4's fixed hop count would not
+// survive). See repo-root.test.ts's own standing caution for that
+// distinction, drawn explicitly there for the first time by this move.
 import { existsSync } from "node:fs";
 import { fileURLToPath } from "node:url";
 import { dirname, join, resolve, sep } from "node:path";
@@ -62,6 +75,8 @@ let warnedNoMarkerFound = false;
 export interface RepoRootOptions {
   from?: string;
   env?: NodeJS.ProcessEnv;
+  /** Test seam for the marker walk; production uses node:fs existsSync. */
+  exists?: (path: string) => boolean;
 }
 
 /**
@@ -84,7 +99,7 @@ function isInside(child: string, parent: string): boolean {
  *      Claude Code exports for the workspace it is driving. This is the ONLY
  *      branch that is correct when this module is consumed as an installed
  *      plugin: the MCP's own files then live under the plugin install dir
- *      (e.g. `~/.claude/plugins/<marketplace>/<plugin>/.claude/mcp/vice/`),
+ *      (e.g. `~/.claude/plugins/<marketplace>/<plugin>/src/mcp/vice/`),
  *      NOT inside the project the user is working in, so neither the
  *      `from`-relative `.git` walk (branch 2, which would find the plugin's
  *      OWN checkout) nor a CONTAINER_WORKSPACE_PATH containment check
@@ -108,13 +123,13 @@ function isInside(child: string, parent: string): boolean {
  *      be exactly the quiet-wrong-answer failure class this file exists to
  *      prevent, so this path emits a one-time stderr note naming both paths.
  *   4. Otherwise, three levels up from `from`, with a one-time stderr note.
- *      Last resort only -- three levels is what `<root>/.claude/mcp/<server>/`
+ *      Last resort only -- three levels is what `<root>/src/mcp/<server>/`
  *      implies. In this repo branch 4 never actually runs (there is always a
  *      `.git` ancestor), which is exactly why the paired synthetic test in
  *      repo-root.test.ts is the only thing that would catch a wrong hop
  *      count here.
  */
-export function repoRoot({ from = HERE, env = process.env }: RepoRootOptions = {}): string {
+export function repoRoot({ from = HERE, env = process.env, exists = existsSync }: RepoRootOptions = {}): string {
   // Branch 0 (plugin-consumption signal): Claude Code sets CLAUDE_PROJECT_DIR
   // to the root of the workspace it is driving. When this module runs as an
   // installed plugin its own files sit outside that workspace, so this is the
@@ -134,7 +149,7 @@ export function repoRoot({ from = HERE, env = process.env }: RepoRootOptions = {
 
   let dir = resolve(from);
   while (true) {
-    if (existsSync(join(dir, ".git"))) {
+    if (exists(join(dir, ".git"))) {
       return dir;
     }
     const parent = dirname(dir);
@@ -160,18 +175,102 @@ export function repoRoot({ from = HERE, env = process.env }: RepoRootOptions = {
     const fallback = resolve(from, "..", "..", "..");
     console.error(
       `warn: could not find a .git ancestor above ${from} and CONTAINER_WORKSPACE_PATH is not set -- ` +
-        `falling back to three levels up (${fallback}), the shape <root>/.claude/mcp/<server>/ implies. ` +
+        `falling back to three levels up (${fallback}), the shape <root>/src/mcp/<server>/ implies. ` +
         `This is a last resort; if it's wrong, set CONTAINER_WORKSPACE_PATH or run from inside a git repo.`
     );
   }
   return resolve(from, "..", "..", "..");
 }
 
+/** The ONE definition of the tool-written root every writer in this codebase
+ * ultimately derives its location from (D-33, 2026-09-08 clean-break
+ * consolidation): `join(repoRoot(...), ".c64-re-tools")`.
+ *
+ * CORRECTED 2026-09-08 (gap `G-40-1`; see
+ * .planning/notes/ghidra-dot-path-check-semantics.md): this comment used to
+ * claim (a) that the Ghidra runs directory was among the writers resolving
+ * through THIS function, and (b) that the literal string below had exactly
+ * one non-comment occurrence in the codebase. Both were false when written,
+ * and neither was ever measured before being written down. The corrected
+ * picture:
+ *
+ *   - FIVE files call `toolsDir()`/`supervisorDir()` directly, across FOUR
+ *     distinct subdirectories: incident-record.ts (`incidents`),
+ *     stock-paths.ts (`snapshots`), vice-proxy.ts (`bin`, reading back the
+ *     deployed launcher path), and vice.ts + vice-broker-client.ts, both via
+ *     `supervisorDir()` (`supervisor`, the broker state directory -- one
+ *     writer, two readers).
+ *   - FOUR files cannot import this container-side module at all, so each
+ *     joins `".c64-re-tools"` with its own trailing segment(s) directly,
+ *     matching this function's shape by CONVENTION, never by shared code:
+ *     install-resources.ts's `installTargetDir()` (`bin` -- module-cycle
+ *     avoidance, since THIS file's own bottom-of-module call invokes it),
+ *     vice-broker.mts's `parseArgs()` state-dir fallback (`supervisor` --
+ *     host-bound, compiled separately by build.ts), host-tool.mts's
+ *     `oracle.run` scratch directory (`runs/oracle` -- host-bound), and
+ *     ghidra-project.mts's `ghidraRunsRoot()`/`ghidraRunsRealRoot()`
+ *     (`runs/ghidra` -- host-bound, reached through a symlinked alias
+ *     handle, see below). Every one of these four must keep its literal
+ *     equal to `join(toolsDir(...), <same segments>)`, by convention, or the
+ *     two halves of this codebase silently disagree on where the root is.
+ *
+ * The Ghidra runs root is emphatically NOT, and never was, one of the five
+ * files that call this function directly -- it is host-bound
+ * (ghidra-project.mts) and cannot import this file at all.
+ *
+ * The literal string ".c64-re-tools" therefore has exactly 6 non-comment
+ * occurrences in this codebase, across 5 files. repo-root.test.ts's census
+ * gate reads BOTH the count and this file list straight out of this
+ * sentence and the bullet list below -- never duplicated by hand a second
+ * time in the test -- and compares both against the real tree, with a
+ * planted-violation control proving the comparison predicate actually
+ * fires. That is the mechanism that stops this specific claim going false
+ * again (threat `T-40-10-02`):
+ *   - repo-root.ts -- this definition, the line below (1)
+ *   - install-resources.ts -- `installTargetDir()`'s `bin` join (1)
+ *   - vice-broker.mts -- `parseArgs()`'s state-dir fallback, BOTH branches
+ *     of one ternary on the same line (2)
+ *   - ghidra-project.mts -- `GHIDRA_RUNS_HANDLE_TARGET`, the alias handle's
+ *     relative symlink target (1)
+ *   - host-tool.mts -- `oracle.run`'s scratch-directory join (1)
+ *
+ * The Ghidra alias handle: a non-dotted sibling of this root
+ * (`<repoRoot>/c64-re-tools`, no leading dot), a symlink whose RELATIVE
+ * target is this root's own directory name, minted host-side by the broker
+ * at startup (vice-broker.mts) and re-asserted, idempotently, as a
+ * precondition by ghidra-project.mts's `ensureGhidraRunsHandle()` on every
+ * resolve -- refused BY NAME, never repaired, when something unexpected
+ * already sits at the handle path. It exists because Ghidra's own
+ * project-location refusal binds the ABSOLUTIZED path argument it is
+ * handed (`ProjectLocator` calls `java.io.File.getAbsolutePath()`, never
+ * `getCanonicalPath()` -- MEASURED from the class's own bytecode -- so it
+ * absolutizes a relative argument but does not resolve a symlink), so a
+ * tool that refuses a dot-prefixed segment in the path it is HANDED can
+ * still be pointed, indirectly, at bytes that live physically inside this
+ * one root. The superseded method that produced the original overstated
+ * claim was running this project's OWN dot-segment-refusal check
+ * (`hasDotPrefixedSegment()`) against a synthetic string -- which observes
+ * this project, never Ghidra. See
+ * .planning/notes/ghidra-dot-path-check-semantics.md for the full live
+ * measurement against real Ghidra 12.1.3.
+ *
+ * This is a clean break, not a migration: no code path falls back to any of
+ * the five previous locations when the new one is absent, and there is no
+ * opt-back-in environment variable. A pre-existing tree at one of the old
+ * locations is simply left on disk, unread, for the user to delete by hand.
+ * `VICE_POOL_DIR` / `VICE_EPOCH_FILE` / `VICE_SUPERVISOR_DIR` /
+ * `VICE_INCIDENTS_DIR` are unaffected by this move -- they still override
+ * their respective resolved default, exactly as before; only the DEFAULT
+ * moved. */
+export function toolsDir(opts: RepoRootOptions = {}): string {
+  return join(repoRoot(opts), ".c64-re-tools");
+}
+
 /** The one shared directory name every module in this skill reads/writes
- * host-synchronised state through -- `join(repoRoot(...), ".vice-supervisor")`,
- * so the literal directory name also has exactly one definition. */
+ * host-synchronised state through -- `join(toolsDir(...), "supervisor")`,
+ * a subdirectory of the single tool-written root `toolsDir()` owns. */
 export function supervisorDir(opts: RepoRootOptions = {}): string {
-  return join(repoRoot(opts), ".vice-supervisor");
+  return join(toolsDir(opts), "supervisor");
 }
 
 // Fires once per process, on whatever entry point happens to import THIS

package/resources/backend-detect.mjs

@@ -2,126 +2,53 @@
 // Compiled by `tsc` from backend-detect.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.
 // backend-detect.mts
 //
-// The ONE place that decides which VICE build a binary is, and the ONE
-// reader of VICE_BACKEND anywhere in this tree (D-01). Everything else that
-// needs to know "fork or stock" -- broker-launch.mts's buildViceArgs(),
-// vice-broker.mts's startup wiring, and plan 02-08's later connect handshake
-// -- calls resolvedBackend() below and threads its answer down, exactly like
-// vice.ts's mcpHost() documents for its own container-versus-host question:
-// a SECOND independent reader of the same signal is a bug waiting to
-// happen the moment one copy is updated and the other is not (mcpHost()'s
-// own "three inlined copies" incident is the exact regression this file
-// exists to keep from recurring here).
+// FORKRM-01 (plan 52-06): this file used to be the ONE place that decided
+// which VICE build a binary is (the fork's `-mcpserver` flag versus stock's
+// `-binarymonitor`-only surface) and the ONE reader of an environment
+// override naming a backend, anywhere in this tree. There is only one
+// backend now, so there is nothing left to detect between: the `--help`
+// probe (its own spawn, its fork/stock/unknown classifier) and the
+// environment override are both deleted outright, not merely unreachable.
 //
-// WHAT NOT TO DO:
-//   - Do not call resolvedBackend()/probeBackend() per acquire, per launch,
-//     or per connect. The broker resolves the backend exactly ONCE, at
-//     process startup (vice-broker.mts's run()), and passes the resolved
-//     value down through every real launch call site -- see this module's
-//     own module-level memo below, which exists as a second line of defence
-//     against an accidental extra call, not as the PRIMARY mechanism (that
-//     is the caller only ever invoking this once).
-//   - Do not call this from inside broker-launch.mts's `inFlight`
-//     single-owner launch guard. This is a possibly-blocking child-process
-//     spawn (probeBackend()'s --help probe); anything that can block inside
-//     that synchronous check-and-set window is the exact failure class the
-//     2026-08-01 triple-launch outage came from (D-03/T-02-25).
-//   - Do not add a trial-launch fallback (launch the binary for real and
-//     watch what happens) as a second detection mechanism. The `--help`
-//     probe below runs entirely outside any launch-guarded critical section
-//     BY CONSTRUCTION -- a trial launch would not. It would also depend on
-//     RESEARCH.md's assumption A1 (stock's argument parser rejects an
-//     unknown flag rather than ignoring it), which is UNVERIFIED against a
-//     real stock binary; see docs/phase2-backend-probe-evidence.md.
+// What SURVIVES, and why:
+//   - Binary-path resolution (`resolveBinPath`/`binPathFields`, WR-05) --
+//     `vice_ping`'s `resolvedBinaryPath` field and host-tool.mts's sibling
+//     binary resolution (`c1541`/`petcat`) both still need "which file did
+//     you actually mean", independent of any backend concept.
+//   - The on-disk identity/capability cache (BACK-04) -- it still records
+//     something worth caching once the backend verdict is gone: the version
+//     quad and CPU-history capability a live connect handshake (plan 02-08,
+//     stock-connect.ts) attaches to a resolved binary's identity
+//     (`resolvedPath`/`mtimeMs`/`sizeBytes`). `readCapabilityRecord()`/
+//     `writeCapabilityRecord()` are unchanged in shape; only the cache
+//     record's `backend` field is gone, since it never meant anything once
+//     there was nothing to distinguish.
+//
+// `ViceBackend` is NARROWED to a single literal (`"stock"`), not deleted:
+// text-capability-probe.ts and stock-connect.ts (both out of this plan's
+// scope -- plan 52-07 owns text-capability-probe.ts's own registry-shaped
+// fork references) still import it as a type-only import, and deleting it
+// outright would break their compile for no benefit this plan is scoped to
+// deliver.
 //
-// ENVIRONMENT CONSTRAINT (2026-08-13, explicit user scope override): no real
-// stock or fork VICE binary is reachable from the environment this plan
-// executed in, and the user's own ruling for this plan is "we can't do
-// tests with deciding what vice is". Every test in backend-detect.test.ts
-// therefore drives this module's OVERRIDE path, its on-disk CACHE lifecycle,
-// and classifyHelpOutput()'s STRING-PARSING logic against fixture strings
-// authored in the test file -- never a real spawned binary. The `--help`
-// discriminator itself (does a real stock build's --help output actually
-// contain "-binarymonitor" and omit "-mcpserver", the way classifyHelpOutput()
-// below assumes) is recorded as an OPEN, not a VERIFIED, question in
-// docs/phase2-backend-probe-evidence.md section 2 -- that document's verdict
-// is deliberately left standing; nothing in this file's own tests attempts to
-// resolve it, and no fixture string anywhere in this tree should ever be
-// presented as real captured output from either build. See the follow-up
-// todo tracked under .planning/todos/pending/ for what a real-hardware run
-// must still confirm.
-import { spawnSync } from "node:child_process";
+// WHAT NOT TO DO:
+//   - Do not reintroduce an environment-variable backend override, a
+//     --help probe, or any other backend-discrimination mechanism. There is
+//     one binary shape now; a second detection mechanism would be solving a
+//     problem that no longer exists.
+//   - Do not call resolvedBackend() from inside broker-launch.mts's
+//     `inFlight` single-owner launch guard. This still performs filesystem
+//     I/O (a stat call and, on a fresh or changed identity, a cache write);
+//     anything that can block inside that synchronous check-and-set window
+//     is the exact failure class the 2026-08-01 triple-launch outage came
+//     from (D-03/T-02-25) -- unchanged reasoning from before this plan, only
+//     the mechanism inside resolvedBackend() changed.
 import { existsSync, readFileSync, writeFileSync, chmodSync, renameSync, mkdirSync, statSync, } from "node:fs";
 import { join, resolve as resolvePath } from "node:path";
-// ---------------------------------------------------------------------------
-// classifyHelpOutput() -- pure string classification, no I/O at all.
-// ---------------------------------------------------------------------------
-/** Matches on the literal flag tokens D-02 names as the discriminator: the
- * fork's `-mcpserver` flag versus stock's `-binarymonitor`-only surface.
- * `"fork"` wins when BOTH tokens appear (the fork's own VICE tree is a 3.10
- * checkout and accepts both flags) -- checked FIRST, deliberately, so a
- * build that advertises both is classified by the flag that actually makes
- * it the fork, not merely "also has stock's flag too". `"unknown"` when
- * NEITHER token appears -- a real --help transcript that does not match
- * either shape, a probe that spawned nothing at all (empty text), or
- * anything else this function was never taught to recognise. Never throws;
- * pure function of the text it is given. */
-export function classifyHelpOutput(text) {
-    const hasFork = text.includes("-mcpserver");
-    const hasStock = text.includes("-binarymonitor");
-    if (hasFork)
-        return "fork";
-    if (hasStock)
-        return "stock";
-    return "unknown";
-}
-// ---------------------------------------------------------------------------
-// probeBackend() -- the --help probe. spawnSync only, argv array, shell:
-// false, never a shell string and never string interpolation of binPath
-// into a command line (T-02-03's mitigation). Bounded by a 5000ms timeout
-// with kill-on-timeout so a hostile or hung binary cannot stall broker
-// startup (T-02-25's second mitigation half).
-// ---------------------------------------------------------------------------
-const PROBE_TIMEOUT_MS = 5000;
-/** `--help` first, falling back to `-help` then `-?` ONLY when a run exits
- * non-zero with EMPTY combined output -- a run that exits non-zero but
- * still printed something (some builds write usage to stderr and exit 1) is
- * already usable and is not retried further. */
-const HELP_FLAG_CANDIDATES = ["--help", "-help", "-?"];
-function defaultSpawnHelp(binPath, flag) {
-    try {
-        const result = spawnSync(binPath, [flag], {
-            encoding: "utf8",
-            timeout: PROBE_TIMEOUT_MS,
-            killSignal: "SIGKILL",
-        });
-        const text = `${result.stdout ?? ""}${result.stderr ?? ""}`;
-        return { text, exitedZero: result.status === 0 };
-    }
-    catch {
-        return { text: "", exitedZero: false };
-    }
-}
-/** Runs the fallback ladder above against `binPath` and classifies whatever
- * text the LAST attempted flag produced. Never throws -- every failure mode
- * (spawn error, timeout, empty output, an exit code the caller does not
- * recognise) flows through to classifyHelpOutput() as ordinary text, which
- * itself never throws either. */
-export function probeBackend(binPath, deps = {}) {
-    const spawnHelp = deps.spawnHelp ?? defaultSpawnHelp;
-    let text = "";
-    for (const flag of HELP_FLAG_CANDIDATES) {
-        const outcome = spawnHelp(binPath, flag);
-        text = outcome.text;
-        if (outcome.exitedZero || text.trim() !== "")
-            break;
-    }
-    return classifyHelpOutput(text);
-}
 /** The client-side capability-decision schema version stamped into every
  * capability record this module writes (see BackendCacheRecord's own field
  * comment). BUMP THIS whenever the client's capability probing or the
@@ -165,8 +92,7 @@ function readCacheRecord(supervisorDir) {
         return null;
     if (typeof parsed.resolvedPath !== "string" ||
         typeof parsed.mtimeMs !== "number" ||
-        typeof parsed.sizeBytes !== "number" ||
-        (parsed.backend !== "fork" && parsed.backend !== "stock")) {
+        typeof parsed.sizeBytes !== "number") {
         return null;
     }
     const record = {
@@ -174,7 +100,6 @@ function readCacheRecord(supervisorDir) {
         resolvedPath: parsed.resolvedPath,
         mtimeMs: parsed.mtimeMs,
         sizeBytes: parsed.sizeBytes,
-        backend: parsed.backend,
         probedAt: typeof parsed.probedAt === "string" ? parsed.probedAt : "",
     };
     if (typeof parsed.versionQuad === "string")
@@ -186,10 +111,10 @@ function readCacheRecord(supervisorDir) {
     return record;
 }
 /** Tmp-sibling -> chmod 0600 -> content -> rename, the SAME atomic-write
- * discipline refresh-manifest.ts's writeManifestAtomic() and vice-broker.mts's
- * writeBrokerRecordFile() both already use -- a crash mid-write can only ever
- * leave a stray tmp sibling behind, never a truncated or empty file at the
- * real cache path that a later read would wrongly accept. */
+ * discipline vice-broker.mts's writeBrokerRecordFile() already uses -- a
+ * crash mid-write can only ever leave a stray tmp sibling behind, never a
+ * truncated or empty file at the real cache path that a later read would
+ * wrongly accept. */
 function writeCacheRecordAtomic(supervisorDir, record) {
     mkdirSync(supervisorDir, { recursive: true });
     const finalPath = cachePathFor(supervisorDir);
@@ -223,133 +148,73 @@ function defaultStat(resolvedPath) {
         return null;
     }
 }
-function defaultLog(line) {
-    process.stderr.write(`${line}\n`);
-}
-// Memoised answer for the probe/cache path ONLY -- the override path
-// (VICE_BACKEND set) is always answered fresh, on every call, straight from
-// the environment, and never touches this memo (an explicit override can
-// legitimately differ from call to call within, e.g., a test process driving
-// many scenarios; the detected-backend answer for a fixed binary cannot).
-// This is what makes resolvedBackend() answer "once per long-running
-// process" for the case that actually spawns something, while never
-// requiring a caller to somehow signal "this is a fresh scenario" the way
-// container-guard.mts's isInsideContainer() asks callers to pass explicit
-// deps to bypass ITS OWN memo -- here, the override/no-override distinction
-// already IS that signal.
+// Memoised answer -- a long-running process (the real broker) resolves once
+// per process lifetime; a test suite driving many scenarios calls
+// resetResolvedBackendForTests() between them (see that function's own
+// comment).
 let memoisedResult = null;
-// D-06: gates the "detected backend X for binary Y" stderr note so a
-// long-running broker (or a test suite driving resolvedBackend() many times)
-// emits it at most once per process -- repo-root.ts's warnedEnvOutsideFrom/
-// warnedNoMarkerFound pattern, reused here verbatim.
-let warnedBackendUnset = false;
-function emitDetectedNote(result, viceBin, log) {
-    if (warnedBackendUnset)
-        return;
-    warnedBackendUnset = true;
-    log(`vice-broker: detected backend "${result.backend}" for ${viceBin} (source: ${result.source}) -- ` +
-        `set VICE_BACKEND=stock or VICE_BACKEND=fork to override this detection explicitly`);
-}
-/** Test-only escape hatch: clears the in-process memo and the D-06
- * one-time-note gate. Never called by any real production code path --
- * vice-broker.mts calls resolvedBackend() exactly once per real process
- * lifetime and has no reason to ever reset it; this exists solely so
- * backend-detect.test.ts can drive many distinct scenarios (cache hit, cache
- * miss, indeterminate, ...) in one shared test process without one
- * scenario's memoised answer contaminating the next -- mirroring
- * broker-launch.test.ts's own discipline of restoring module-level state
- * between test cases, made explicit here rather than left to careful test
- * ordering, since this module's memo (unlike buildViceArgs()'s one-time
- * note) has no natural "always widens the same way" ordering to exploit. */
+/** Test-only escape hatch: clears the in-process memo. Never called by any
+ * real production code path -- vice-broker.mts calls resolvedBackend()
+ * exactly once per real process lifetime and has no reason to ever reset it;
+ * this exists solely so backend-detect.test.ts can drive many distinct
+ * scenarios (fresh identity, matching cached identity, changed identity, ...)
+ * in one shared test process without one scenario's memoised answer
+ * contaminating the next. */
 export function resetResolvedBackendForTests() {
     memoisedResult = null;
-    warnedBackendUnset = false;
 }
-/** Honours VICE_BACKEND FIRST, returning immediately without spawning
- * anything when it names `stock` or `fork` (BACK-01: one optional config
- * value switches backends, no code edit). Otherwise consults the on-disk
- * cache (when `supervisorDir` is given and the binary's current
- * `{ resolvedPath, mtimeMs, sizeBytes }` all match the stored record); on a
- * miss, probes via probeBackend() and writes the cache. Memoises the
- * probe/cache answer in a module-level variable so a long-running process
- * resolves once (see the memo's own comment above for what "once" means
- * here). Never throws: a probe that classifies "unknown" (including a
- * spawn failure or a timeout, both of which probeBackend() already reduces
- * to "unknown") returns a defined `{ backend: "fork", source:
- * "indeterminate", ... }` outcome instead -- "fork" because that is the
- * pre-Phase-2 behaviour every existing install already has, so an
- * undetectable binary degrades to what already worked rather than to
- * nothing. */
-/** WR-05: the ONE place `binPath`/`binPathResolved` are derived, so the four
- * return paths below cannot disagree about what "the binary" means. A resolved
- * absolute path when there is one; the configured name, flagged as unresolved,
- * when there is not. */
+/** WR-05: the ONE place `binPath`/`binPathResolved` are derived, so a
+ * resolved absolute path when there is one, or the configured name flagged
+ * as unresolved when there is not, is computed identically everywhere this
+ * file returns it. */
 function binPathFields(resolvedPath, viceBin) {
     return resolvedPath !== null ? { binPath: resolvedPath, binPathResolved: true } : { binPath: viceBin, binPathResolved: false };
 }
+/** Resolves the emulator binary's identity and (re)initialises the on-disk
+ * identity/capability cache record for it when a `supervisorDir` is given.
+ * Memoises the answer in a module-level variable so a long-running process
+ * resolves once (see the memo's own comment above for what "once" means
+ * here). Never throws.
+ *
+ * FORKRM-01: there is nothing left to detect -- `backend` is always
+ * `"stock"`. What this function still does is identity resolution (WR-05's
+ * `binPath`/`binPathResolved`) and cache bookkeeping for BACK-04's capability
+ * record: when the resolved binary's identity (`resolvedPath`/`mtimeMs`/
+ * `sizeBytes`) does not match whatever is already on file -- no record at
+ * all, or a record describing a DIFFERENT binary (replaced in place, or a
+ * fresh install) -- a fresh identity record is written, with no stale
+ * capability fields carried over from a different binary's answer. A
+ * matching identity is left untouched, so a capability answer already
+ * recorded for THIS binary survives. */
 export function resolvedBackend(deps = {}) {
+    if (memoisedResult !== null)
+        return memoisedResult;
     const env = deps.env ?? process.env;
     const viceBin = deps.viceBin ?? env.VICE_BIN ?? "x64sc";
-    // A direct read of the real environment on the right of this ternary
-    // (rather than the generic `env` local above) is deliberate: this file is
-    // grep-gated, tree-wide, as the ONE place that ever names this variable
-    // directly against the real environment -- `deps.env` (the test-injection
-    // seam) still takes precedence when supplied, exactly like every other
-    // field on this options object.
-    const override = deps.env ? deps.env.VICE_BACKEND : process.env.VICE_BACKEND;
     const resolveBinPath = deps.resolveBinPath ?? defaultResolveBinPath;
-    if (override === "stock" || override === "fork") {
-        // WR-05: an explicit backend override still resolves the PATH, so
-        // `vice_ping` reports a real file rather than the bare name. This is a
-        // filesystem lookup only -- existsSync per PATH entry -- and NEVER a spawn,
-        // so the override path keeps its "answered fresh, straight from the
-        // environment, spawns nothing" property.
-        return { backend: override, source: "override", ...binPathFields(resolveBinPath(viceBin, env), viceBin) };
-    }
-    if (memoisedResult !== null)
-        return memoisedResult;
-    const log = deps.log ?? defaultLog;
     const stat = deps.stat ?? defaultStat;
-    const probe = deps.probe ?? ((bin) => probeBackend(bin));
     const now = deps.now ?? (() => Date.now());
     const resolvedPath = resolveBinPath(viceBin, env);
     const identity = resolvedPath ? stat(resolvedPath) : null;
     const cacheEligible = resolvedPath !== null && identity !== null && typeof deps.supervisorDir === "string";
     if (cacheEligible) {
-        const cached = readCacheRecord(deps.supervisorDir);
-        if (cached &&
-            cached.resolvedPath === resolvedPath &&
-            cached.mtimeMs === identity.mtimeMs &&
-            cached.sizeBytes === identity.sizeBytes) {
-            const result = { backend: cached.backend, source: "cache", ...binPathFields(resolvedPath, viceBin) };
-            memoisedResult = result;
-            emitDetectedNote(result, viceBin, log);
-            return result;
+        const existing = readCacheRecord(deps.supervisorDir);
+        const identityMatches = existing !== null &&
+            existing.resolvedPath === resolvedPath &&
+            existing.mtimeMs === identity.mtimeMs &&
+            existing.sizeBytes === identity.sizeBytes;
+        if (!identityMatches) {
+            writeCacheRecordAtomic(deps.supervisorDir, {
+                version: 1,
+                resolvedPath: resolvedPath,
+                mtimeMs: identity.mtimeMs,
+                sizeBytes: identity.sizeBytes,
+                probedAt: new Date(now()).toISOString(),
+            });
         }
     }
-    const verdict = probe(viceBin);
-    if (verdict === "unknown") {
-        const note = `vice-broker: could not determine whether ${viceBin} is the stock or fork VICE build -- ` +
-            `its --help output matched neither the -mcpserver nor the -binarymonitor discriminator. ` +
-            `Set VICE_BACKEND=stock or VICE_BACKEND=fork explicitly.`;
-        log(note);
-        const result = { backend: "fork", source: "indeterminate", ...binPathFields(resolvedPath, viceBin), note };
-        memoisedResult = result;
-        return result;
-    }
-    if (cacheEligible) {
-        writeCacheRecordAtomic(deps.supervisorDir, {
-            version: 1,
-            resolvedPath: resolvedPath,
-            mtimeMs: identity.mtimeMs,
-            sizeBytes: identity.sizeBytes,
-            backend: verdict,
-            probedAt: new Date(now()).toISOString(),
-        });
-    }
-    const result = { backend: verdict, source: "probe", ...binPathFields(resolvedPath, viceBin) };
+    const result = { backend: "stock", ...binPathFields(resolvedPath, viceBin) };
     memoisedResult = result;
-    emitDetectedNote(result, viceBin, log);
     return result;
 }
 /** Reads whatever capability answers (BACK-04) are on record for `binPath`
@@ -383,15 +248,13 @@ export function readCapabilityRecord(binPath, deps = {}) {
         result.capabilitySchema = existing.capabilitySchema;
     return result;
 }
-/** Attaches `{ versionQuad, cpuHistoryAvailable }` to the EXISTING backend
- * verdict already on record for `binPath`'s resolved identity -- a no-op,
- * never a throw, when there is no such matching record yet (no supervisorDir
+/** Attaches `{ versionQuad, cpuHistoryAvailable }` to the EXISTING identity
+ * record already on file for `binPath`'s resolved identity -- a no-op, never
+ * a throw, when there is no such matching record yet (no supervisorDir
  * given, the binary cannot be resolved or stat'd, or the cache names a
- * different binary or has no verdict at all). This function never invents a
- * backend verdict of its own: it can only EXTEND a record resolvedBackend()
- * already wrote, since a `--help` probe has no way to observe a version
- * quad and this function must not silently fabricate the field it did not
- * observe either. */
+ * different binary or has no record at all). This function never invents an
+ * identity record of its own: it can only EXTEND a record resolvedBackend()
+ * already wrote. */
 export function writeCapabilityRecord(binPath, capability, deps = {}) {
     if (typeof deps.supervisorDir !== "string")
         return;
@@ -412,7 +275,6 @@ export function writeCapabilityRecord(binPath, capability, deps = {}) {
         resolvedPath,
         mtimeMs: identity.mtimeMs,
         sizeBytes: identity.sizeBytes,
-        backend: existing.backend,
         probedAt: existing.probedAt,
         versionQuad: capability.versionQuad,
         cpuHistoryAvailable: capability.cpuHistoryAvailable,