muonroi-cli 1.8.5 → 1.9.0

package/dist/src/utils/loop-profiler.d.ts

@@ -0,0 +1,102 @@
+/**
+ * src/utils/loop-profiler.ts
+ *
+ * Rolling V8 CPU profiler — the instrument that names the culprit when the
+ * event loop blocks (see `event-loop-monitor.ts` for the incident this exists
+ * for).
+ *
+ * Why a CPU profile and not a stack dump: while the JS thread is blocked, NO
+ * JS can run — you cannot ask the process what it is doing, because asking is
+ * itself JS. V8's sampling profiler runs on its OWN thread and samples the JS
+ * thread regardless of whether that thread is stuck, so the profile taken
+ * across a block contains the blocking frames. Verified under Bun 1.3.13: a
+ * deliberate 400ms synchronous block yielded 54 samples.
+ *
+ * Rolling segments keep the retained profile small without losing the block:
+ * rotation is loop-driven, so it CANNOT run during a block — whichever segment
+ * is in flight when the loop freezes stays in flight for the whole freeze, and
+ * is still open when the monitor detects the block right after. So `capture()`
+ * always writes a profile containing the entire block, however long it ran.
+ *
+ * Off by default (`MUONROI_LOOP_PROFILE=1` to arm) — continuous profiling has a
+ * real, if small, cost and this is a diagnostic, not a feature.
+ */
+/** Minimal shape of the V8 CPU profile we consume (`Profiler.stop` result). */
+interface CpuProfileNode {
+    id: number;
+    callFrame: {
+        functionName?: string;
+        url?: string;
+        lineNumber?: number;
+    };
+    children?: number[];
+}
+interface CpuProfile {
+    nodes: CpuProfileNode[];
+    samples?: number[];
+}
+/**
+ * Reduce a CPU profile to the single hottest stack, leaf-first.
+ *
+ * Why not just the top frame: samples land on the LEAF, which for a blocking
+ * loop is whatever primitive it calls (`Date.now`, a regex step, a syscall) —
+ * true but useless. Verified on a synthetic 3s block: the leaf was `now` with
+ * 188 samples while the actual culprit `theGuiltyFunction` had 4. The CALLERS
+ * are the answer, so we walk up from the hottest leaf and return the chain.
+ *
+ * This is what makes the profile readable from debug.log alone, without
+ * requiring anyone to open Chrome DevTools.
+ *
+ * Pure — unit-testable with a hand-built profile.
+ *
+ * @param maxFrames how many frames of the chain to return, leaf-first
+ * @returns frames like `theGuiltyFunction (file.ts:12)`, or [] if unusable
+ */
+export declare function summarizeHotStack(profile: CpuProfile, maxFrames?: number): string[];
+/** What a successful {@link LoopProfiler.capture} produced. */
+export interface CaptureResult {
+    /** Path of the written `.cpuprofile` (open in Chrome DevTools for detail). */
+    file: string;
+    /** Hottest stack, leaf-first — readable without DevTools. See {@link summarizeHotStack}. */
+    hotStack: string[];
+}
+/** A rolling CPU profiler. All methods are best-effort and never throw. */
+export interface LoopProfiler {
+    /**
+     * Discard the current segment and start a fresh one. Call periodically from
+     * the event loop to bound profile size — it is a no-op during a block, which
+     * is exactly what preserves the evidence.
+     */
+    rotate(): void;
+    /**
+     * Stop the current segment, write it to disk, and start a fresh one.
+     *
+     * Async because the inspector delivers `Profiler.stop` on a later tick
+     * (measured under Bun 1.3.13 — the callback does NOT run synchronously). The
+     * loop is already free by the time this is called, so awaiting is safe.
+     *
+     * @returns the profile path plus the hottest stack, or null on failure.
+     */
+    capture(reason: string): Promise<CaptureResult | null>;
+    /** Stop profiling and disconnect. Idempotent. */
+    dispose(): void;
+}
+/** Options for {@link createLoopProfiler}. */
+export interface LoopProfilerOpts {
+    /**
+     * V8 sampling interval in microseconds. 10_000 (10ms) is ~100 samples/sec —
+     * plenty to identify a multi-second blocking frame, at a fraction of the cost
+     * of the 1ms default.
+     */
+    samplingIntervalUs?: number;
+    /** Directory for `.cpuprofile` files. Defaults to `~/.muonroi-cli/profiles`. */
+    dir?: string;
+}
+/**
+ * Create and arm a rolling CPU profiler.
+ *
+ * Returns null when the inspector is unavailable (some runtimes/builds) — the
+ * caller keeps the block detector, just without stacks. Never throws.
+ */
+export declare function createLoopProfiler(opts?: LoopProfilerOpts): Promise<LoopProfiler | null>;
+export {};

package/dist/src/utils/loop-profiler.js

@@ -0,0 +1,202 @@
+/**
+ * src/utils/loop-profiler.ts
+ *
+ * Rolling V8 CPU profiler — the instrument that names the culprit when the
+ * event loop blocks (see `event-loop-monitor.ts` for the incident this exists
+ * for).
+ *
+ * Why a CPU profile and not a stack dump: while the JS thread is blocked, NO
+ * JS can run — you cannot ask the process what it is doing, because asking is
+ * itself JS. V8's sampling profiler runs on its OWN thread and samples the JS
+ * thread regardless of whether that thread is stuck, so the profile taken
+ * across a block contains the blocking frames. Verified under Bun 1.3.13: a
+ * deliberate 400ms synchronous block yielded 54 samples.
+ *
+ * Rolling segments keep the retained profile small without losing the block:
+ * rotation is loop-driven, so it CANNOT run during a block — whichever segment
+ * is in flight when the loop freezes stays in flight for the whole freeze, and
+ * is still open when the monitor detects the block right after. So `capture()`
+ * always writes a profile containing the entire block, however long it ran.
+ *
+ * Off by default (`MUONROI_LOOP_PROFILE=1` to arm) — continuous profiling has a
+ * real, if small, cost and this is a diagnostic, not a feature.
+ */
+import fs from "node:fs";
+import os from "node:os";
+import path from "node:path";
+import { logger } from "./logger.js";
+/** Frames V8 synthesises; naming one as the culprit tells nobody anything. */
+const SYNTHETIC_FRAMES = new Set(["(root)", "(program)", "(idle)", "(garbage collector)", "(anonymous)", ""]);
+/**
+ * Reduce a CPU profile to the single hottest stack, leaf-first.
+ *
+ * Why not just the top frame: samples land on the LEAF, which for a blocking
+ * loop is whatever primitive it calls (`Date.now`, a regex step, a syscall) —
+ * true but useless. Verified on a synthetic 3s block: the leaf was `now` with
+ * 188 samples while the actual culprit `theGuiltyFunction` had 4. The CALLERS
+ * are the answer, so we walk up from the hottest leaf and return the chain.
+ *
+ * This is what makes the profile readable from debug.log alone, without
+ * requiring anyone to open Chrome DevTools.
+ *
+ * Pure — unit-testable with a hand-built profile.
+ *
+ * @param maxFrames how many frames of the chain to return, leaf-first
+ * @returns frames like `theGuiltyFunction (file.ts:12)`, or [] if unusable
+ */
+export function summarizeHotStack(profile, maxFrames = 8) {
+    const samples = profile?.samples;
+    const nodes = profile?.nodes;
+    if (!Array.isArray(samples) || !Array.isArray(nodes) || samples.length === 0)
+        return [];
+    const byId = new Map();
+    const parentOf = new Map();
+    for (const n of nodes) {
+        byId.set(n.id, n);
+        for (const c of n.children ?? [])
+            parentOf.set(c, n.id);
+    }
+    const selfCounts = new Map();
+    for (const s of samples)
+        selfCounts.set(s, (selfCounts.get(s) ?? 0) + 1);
+    let hottest = -1;
+    let best = -1;
+    for (const [id, count] of selfCounts) {
+        if (count > best) {
+            best = count;
+            hottest = id;
+        }
+    }
+    if (hottest < 0)
+        return [];
+    const frames = [];
+    const seen = new Set();
+    let cur = hottest;
+    while (cur !== undefined && !seen.has(cur) && frames.length < maxFrames) {
+        seen.add(cur);
+        const node = byId.get(cur);
+        if (!node)
+            break;
+        const name = node.callFrame?.functionName ?? "";
+        if (!SYNTHETIC_FRAMES.has(name)) {
+            const url = node.callFrame?.url ?? "";
+            const short = url ? `${url.split(/[\\/]/).pop()}:${(node.callFrame?.lineNumber ?? 0) + 1}` : "native";
+            frames.push(`${name} (${short})`);
+        }
+        cur = parentOf.get(cur);
+    }
+    return frames;
+}
+/**
+ * Create and arm a rolling CPU profiler.
+ *
+ * Returns null when the inspector is unavailable (some runtimes/builds) — the
+ * caller keeps the block detector, just without stacks. Never throws.
+ */
+export async function createLoopProfiler(opts = {}) {
+    const samplingIntervalUs = opts.samplingIntervalUs ?? 10_000;
+    const dir = opts.dir ?? path.join(os.homedir(), ".muonroi-cli", "profiles");
+    let session;
+    try {
+        const inspector = await import("node:inspector");
+        session = new inspector.Session();
+        session.connect();
+    }
+    catch (err) {
+        logger.warn("cli", `[loop-profiler] inspector unavailable — block reports will have no stacks: ${err?.message}`, { error: err });
+        return null;
+    }
+    /** Promise-free post: the profiler is driven from timer callbacks. */
+    const post = (method, params) => {
+        try {
+            session.post(method, params, (err) => {
+                if (err) {
+                    logger.warn("cli", `[loop-profiler] ${method} failed: ${err.message}`, { error: err });
+                }
+            });
+        }
+        catch (err) {
+            logger.warn("cli", `[loop-profiler] ${method} threw: ${err?.message}`, { error: err });
+        }
+    };
+    let disposed = false;
+    const start = () => {
+        post("Profiler.setSamplingInterval", { interval: samplingIntervalUs });
+        post("Profiler.start");
+    };
+    try {
+        post("Profiler.enable");
+        start();
+    }
+    catch (err) {
+        logger.warn("cli", `[loop-profiler] failed to arm: ${err?.message}`, { error: err });
+        return null;
+    }
+    /**
+     * Stop the current segment and resolve with its profile (null on failure).
+     * Restarts a fresh segment unless disposing.
+     */
+    const stopSegment = (restart) => new Promise((resolve) => {
+        try {
+            session.post("Profiler.stop", (err, res) => {
+                if (err) {
+                    logger.warn("cli", `[loop-profiler] Profiler.stop failed: ${err.message}`, { error: err });
+                    resolve(null);
+                }
+                else {
+                    resolve(res?.profile ?? null);
+                }
+                if (restart && !disposed)
+                    start();
+            });
+        }
+        catch (err) {
+            logger.warn("cli", `[loop-profiler] Profiler.stop threw: ${err?.message}`, { error: err });
+            resolve(null);
+        }
+    });
+    return {
+        rotate() {
+            if (disposed)
+                return;
+            // Drop the segment on the floor — it contained no block worth keeping.
+            void stopSegment(true);
+        },
+        async capture(reason) {
+            if (disposed)
+                return null;
+            const profile = await stopSegment(true);
+            if (!profile)
+                return null;
+            try {
+                fs.mkdirSync(dir, { recursive: true });
+                const stamp = new Date().toISOString().replace(/[:.]/g, "-");
+                const safeReason = reason.replace(/[^a-z0-9_-]/gi, "_").slice(0, 40);
+                const file = path.join(dir, `loop-block-${stamp}-${safeReason}.cpuprofile`);
+                fs.writeFileSync(file, JSON.stringify(profile), "utf8");
+                return { file, hotStack: summarizeHotStack(profile) };
+            }
+            catch (err) {
+                logger.error("cli", `[loop-profiler] failed to write profile: ${err?.message}`, {
+                    error: err,
+                    dir,
+                });
+                return null;
+            }
+        },
+        dispose() {
+            if (disposed)
+                return;
+            disposed = true;
+            void stopSegment(false);
+            try {
+                post("Profiler.disable");
+                session.disconnect();
+            }
+            catch (err) {
+                logger.warn("cli", `[loop-profiler] disconnect failed: ${err?.message}`, { error: err });
+            }
+        },
+    };
+}
+//# sourceMappingURL=loop-profiler.js.map

package/dist/src/utils/settings.d.ts

@@ -78,6 +78,12 @@ export interface ProviderKeyConfig {
 }
 export interface UserSettings {
     apiKey?: string;
+    /**
+     * One-time guard: true once legacy keychain/settings API keys have been
+     * migrated into the env-store (`~/.muonroi-cli/.env`). See
+     * `migrateLegacyKeysToEnv` in src/providers/keychain.ts.
+     */
+    keysMigratedToEnv?: boolean;
     defaultModel?: string;
     /**
      * Preferred provider. When set, the splash/config UI hides the model
@@ -384,6 +390,27 @@ export declare function getProviderStallTimeoutMs(): number;
  * override: MUONROI_PROVIDER_PROGRESS_TIMEOUT_MS.
  */
 export declare function getProviderProgressTimeoutMs(): number;
+/**
+ * Event-loop block reporting threshold (ms). The monitor
+ * (`src/utils/event-loop-monitor.ts`) reports a block when its own tick runs at
+ * least this late — evidence that the JS thread was stuck and NO timer could
+ * fire, which is why the provider stall watchdogs above cannot see this class
+ * of freeze (measured live 2026-07-16: a 304.5s TUI freeze that the 120s stall
+ * watchdog only rescued 6.7s AFTER the loop recovered).
+ *
+ * 2s is well clear of ordinary GC pauses and heavy renders while still catching
+ * anything a user would call a freeze. Range 250–60_000; 0 disables.
+ * Default 2_000. Env override: MUONROI_LOOP_BLOCK_THRESHOLD_MS.
+ */
+export declare function getLoopBlockThresholdMs(): number;
+/**
+ * Whether to run the rolling CPU profiler (`src/utils/loop-profiler.ts`) so a
+ * reported event-loop block comes with the culprit's stack rather than just a
+ * duration. OFF by default: continuous V8 sampling costs a little on every
+ * session, and this is a diagnostic for a sporadic bug, not a feature. Arm it
+ * when hunting a freeze. Env: MUONROI_LOOP_PROFILE=1 (0/unset disables).
+ */
+export declare function isLoopProfileEnabled(): boolean;
 /**
  * Number of times to AUTOMATICALLY re-issue a streaming model call after the
  * stall watchdog fires WITHOUT any chunk having arrived (a time-to-first-byte

package/dist/src/utils/settings.js

@@ -275,10 +275,12 @@ export function saveProjectSettings(partial) {
 }
 export function getApiKey() {
     // Test escape hatch (api-key harness spec): suppress all key sources so the
-    // boot flow reaches the API-key modal. See src/index.ts resolveKeyForModel.
+    // boot flow reaches the provider picker. See src/index.ts resolveKeyForModel.
     if (process.env.MUONROI_TEST_NO_KEYCHAIN === "1")
         return undefined;
-    return process.env.MUONROI_API_KEY || loadUserSettings().apiKey;
+    // Env-only: the legacy plaintext `settings.apiKey` is migrated to the
+    // env-store on first run (migrateLegacyKeysToEnv) and no longer read here.
+    return process.env.MUONROI_API_KEY || undefined;
 }
 export function getBaseURL(provider) {
     if (process.env.MUONROI_BASE_URL)
@@ -662,6 +664,40 @@ export function getProviderProgressTimeoutMs() {
     }
     return 300_000;
 }
+/**
+ * Event-loop block reporting threshold (ms). The monitor
+ * (`src/utils/event-loop-monitor.ts`) reports a block when its own tick runs at
+ * least this late — evidence that the JS thread was stuck and NO timer could
+ * fire, which is why the provider stall watchdogs above cannot see this class
+ * of freeze (measured live 2026-07-16: a 304.5s TUI freeze that the 120s stall
+ * watchdog only rescued 6.7s AFTER the loop recovered).
+ *
+ * 2s is well clear of ordinary GC pauses and heavy renders while still catching
+ * anything a user would call a freeze. Range 250–60_000; 0 disables.
+ * Default 2_000. Env override: MUONROI_LOOP_BLOCK_THRESHOLD_MS.
+ */
+export function getLoopBlockThresholdMs() {
+    const envRaw = process.env.MUONROI_LOOP_BLOCK_THRESHOLD_MS;
+    if (envRaw !== undefined && envRaw !== "") {
+        const n = Number(envRaw);
+        if (Number.isFinite(n) && n === 0)
+            return 0; // explicit disable
+        if (Number.isFinite(n) && n >= 250 && n <= 60_000)
+            return Math.floor(n);
+    }
+    return 2_000;
+}
+/**
+ * Whether to run the rolling CPU profiler (`src/utils/loop-profiler.ts`) so a
+ * reported event-loop block comes with the culprit's stack rather than just a
+ * duration. OFF by default: continuous V8 sampling costs a little on every
+ * session, and this is a diagnostic for a sporadic bug, not a feature. Arm it
+ * when hunting a freeze. Env: MUONROI_LOOP_PROFILE=1 (0/unset disables).
+ */
+export function isLoopProfileEnabled() {
+    const raw = process.env.MUONROI_LOOP_PROFILE?.trim().toLowerCase();
+    return raw === "1" || raw === "true" || raw === "yes" || raw === "on";
+}
 /**
  * Number of times to AUTOMATICALLY re-issue a streaming model call after the
  * stall watchdog fires WITHOUT any chunk having arrived (a time-to-first-byte

package/dist/src/utils/side-question.d.ts

@@ -1,4 +1,3 @@
-import type { ProviderFactory as LegacyProvider } from "../providers/runtime.js";
 export interface SideQuestionResult {
     response: string;
     usage?: {
@@ -7,4 +6,4 @@ export interface SideQuestionResult {
         outputTokens?: number;
     };
 }
-export declare function runSideQuestion(question: string, provider: LegacyProvider, modelId: string, conversationContext: string, signal?: AbortSignal): Promise<SideQuestionResult>;
+export declare function runSideQuestion(question: string, modelId: string, conversationContext: string, signal?: AbortSignal): Promise<SideQuestionResult>;

package/dist/src/utils/side-question.js

@@ -3,8 +3,8 @@ import { resolveModelRuntime } from "../providers/runtime.js";
 const SIDE_QUESTION_SYSTEM = `You are a helpful coding assistant answering a quick side question. The user is in the middle of a coding session and needs a fast, concise answer. Keep your response short and focused — this is a side question, not the main task.
 
 If conversation context is provided below, use it to give a more relevant answer.`;
-export async function runSideQuestion(question, provider, modelId, conversationContext, signal) {
-    const runtime = resolveModelRuntime(provider, modelId);
+export async function runSideQuestion(question, modelId, conversationContext, signal) {
+    const runtime = resolveModelRuntime(modelId);
     const system = conversationContext
         ? `${SIDE_QUESTION_SYSTEM}\n\n<conversation_context>\n${conversationContext}\n</conversation_context>`
         : SIDE_QUESTION_SYSTEM;

package/dist/src/verify/entrypoint.js

@@ -1,3 +1,4 @@
+import { VERIFY_FAIL_MARKER, VERIFY_PASS_MARKER } from "../product-loop/verify-result.js";
 import { ensureVerifyCheckpoint } from "./checkpoint.js";
 import { loadVerifyEnvironment } from "./environment.js";
 import { buildBrowserGuidance, buildEvidenceGuidance, buildReadinessGuidance } from "./evidence.js";
@@ -69,6 +70,51 @@ export function buildVerifyTaskPrompt(cwd, settings, recipeOverride, sandboxMode
             "Phase 1 — Setup:",
             "- Probe the host for runtimes. If missing, attempt to install them or report as blockers.",
         ];
+    // Does this project actually expose a long-running app to start + smoke-test in
+    // a browser? Only then are Phase 3 (start app) / Phase 4 (browser QA) applicable.
+    // A CLI/library/script project (pytest-only Python, a Go/Rust binary, a plain
+    // script) has smokeKind "cli"/"none" and no startCommand — forcing "Start the
+    // app (REQUIRED)" + "browser QA (REQUIRED)" there is contradictory: the sub-agent
+    // cannot satisfy them, so it emits NEITHER verdict marker → parseVerifyResult →
+    // UNKNOWN → engineering-floor fails → the sprint retries forever on a passing
+    // build. Gate the runtime/browser phases and the verdict rule on this flag.
+    const hasRuntimeSmoke = profile.recipe.smokeKind === "http" && Boolean(profile.recipe.startCommand);
+    const runtimePhases = hasRuntimeSmoke
+        ? [
+            "Phase 3 — Start the app (REQUIRED, do not skip):",
+            "- Start the app using startCommand from the recipe, running it in the background.",
+            "- Wait for the app to be ready: use a curl readiness loop or `agent-browser wait --load networkidle`.",
+            "- If the app fails to start, report the error but still attempt to capture evidence (logs, screenshots).",
+            "",
+            "Phase 4 — Browser QA testing (REQUIRED, do not skip):",
+            "- You are a QA tester. Open the app in the browser and test it like a human would.",
+            `- agent-browser commands run on the HOST${sandboxMode === "shuru" ? ", not the sandbox" : ""}. They WILL work. Do not skip them.`,
+            "- Record a video of the entire browser session.",
+            "- Navigate the app: click links, buttons, menus. Verify pages load correctly.",
+            "- Check for JavaScript console errors.",
+            "- Spend 3-5 interactions testing the critical path. Take screenshots after each.",
+            "- This is the most important phase. Build/lint passing means nothing if the app doesn't actually work.",
+            "",
+            "Phase 5 — Teardown:",
+            "- Stop recording, close browser, THEN stop the dev server.",
+        ]
+        : [
+            "Phase 3 — Runtime smoke (CLI / library / script — there is NO long-running app to start):",
+            '- This project exposes no HTTP server or startable app (smokeKind is not "http"), so there is NOTHING to start in the background and NO browser QA to run.',
+            "- Do the equivalent CLI smoke instead: run the built binary / script (or the recipe's smoke command) once and confirm it produces the expected output and a zero exit code.",
+            "- Capture the exact command and its output as evidence.",
+            "- Browser and app-start phases are NOT APPLICABLE here — skipping them is CORRECT and is NOT a failure. Do NOT treat their absence as a blocker.",
+        ];
+    const verdictRule = hasRuntimeSmoke
+        ? [
+            `- After the report, emit the verdict on its own final line: exactly \`${VERIFY_PASS_MARKER}\` if install/build/test and the smoke/QA phases all succeeded, otherwise exactly \`${VERIFY_FAIL_MARKER}\`.`,
+            `- Emit \`${VERIFY_FAIL_MARKER}\` on ANY failed or skipped required phase (build error, failing test, app did not start, blocking console error). Do NOT emit \`${VERIFY_PASS_MARKER}\` if you could not actually run the recipe.`,
+        ]
+        : [
+            `- After the report, emit the verdict on its own final line: exactly \`${VERIFY_PASS_MARKER}\` if install/build/test (and the CLI smoke, if any) all succeeded, otherwise exactly \`${VERIFY_FAIL_MARKER}\`.`,
+            `- This is a CLI/library/script project with no app to start: the browser and app-start phases are N/A, NOT failures. Do NOT withhold \`${VERIFY_PASS_MARKER}\` merely because they were not run.`,
+            `- Emit \`${VERIFY_FAIL_MARKER}\` ONLY on a real failure: an install/build error, a failing test, or a CLI smoke that produced the wrong result. Do NOT emit \`${VERIFY_PASS_MARKER}\` if you could not actually run the recipe's tests.`,
+        ];
     return [
         "Run a local verification pass for the current workspace.",
         "",
@@ -90,22 +136,7 @@ export function buildVerifyTaskPrompt(cwd, settings, recipeOverride, sandboxMode
         "Phase 2 — Build and test:",
         "- Run installCommands, buildCommands, and testCommands from the recipe.",
         "",
-        "Phase 3 — Start the app (REQUIRED, do not skip):",
-        "- Start the app using startCommand from the recipe, running it in the background.",
-        "- Wait for the app to be ready: use a curl readiness loop or `agent-browser wait --load networkidle`.",
-        "- If the app fails to start, report the error but still attempt to capture evidence (logs, screenshots).",
-        "",
-        "Phase 4 — Browser QA testing (REQUIRED, do not skip):",
-        "- You are a QA tester. Open the app in the browser and test it like a human would.",
-        `- agent-browser commands run on the HOST${sandboxMode === "shuru" ? ", not the sandbox" : ""}. They WILL work. Do not skip them.`,
-        "- Record a video of the entire browser session.",
-        "- Navigate the app: click links, buttons, menus. Verify pages load correctly.",
-        "- Check for JavaScript console errors.",
-        "- Spend 3-5 interactions testing the critical path. Take screenshots after each.",
-        "- This is the most important phase. Build/lint passing means nothing if the app doesn't actually work.",
-        "",
-        "Phase 5 — Teardown:",
-        "- Stop recording, close browser, THEN stop the dev server.",
+        ...runtimePhases,
         ...buildReadinessGuidance(profile),
         ...buildBrowserGuidance(profile),
         ...buildRetryGuidance(profile),
@@ -122,6 +153,10 @@ export function buildVerifyTaskPrompt(cwd, settings, recipeOverride, sandboxMode
         "- The Summary must say what recipe/source of truth you used and whether you changed the inferred/default one.",
         "- Evidence is mandatory even on failure. If you captured screenshots, video, or logs, include their exact workspace-relative file paths in the Evidence section.",
         "- Use markdown links for artifact paths when practical, otherwise include the plain relative paths.",
+        "",
+        "Verdict marker (MANDATORY — the loop parses this, an absent marker scores the sprint 0.00):",
+        ...verdictRule,
+        "- The marker is the last line, nothing after it.",
     ].join("\n");
 }
 export function createVerifyTaskRequest(cwd, settings, recipeOverride, sandboxMode = "shuru") {

package/dist/src/verify/orchestrator.d.ts

@@ -1,5 +1,5 @@
 import type { TaskRequest, ToolResult, VerifyRecipe } from "../types/index.js";
-import type { SandboxSettings } from "../utils/settings.js";
+import { type SandboxSettings } from "../utils/settings.js";
 import { type PreparedVerifyCheckpoint } from "./checkpoint.js";
 import { type VerifyProjectProfile } from "./recipes.js";
 export interface VerifyAgentLike {

package/dist/src/verify/orchestrator.js

@@ -1,3 +1,4 @@
+import { getCurrentSandboxMode } from "../utils/settings.js";
 import { ensureVerifyCheckpoint } from "./checkpoint.js";
 import { buildVerifyTaskPrompt } from "./entrypoint.js";
 import { loadVerifyEnvironment, saveVerifyEnvironment } from "./environment.js";
@@ -39,8 +40,21 @@ export async function prepareVerifyRun(agent, options = {}) {
         }
     }
     const sandboxSettings = buildRuntimeSandboxSettings(profile);
-    options.onProgress?.("Preparing verify checkpoint");
-    const checkpoint = await ensureVerifyCheckpoint(cwd, profile, sandboxSettings);
+    // Sandbox "off" → run the recipe directly on the host; do NOT bootstrap a
+    // `shuru` checkpoint. ensureVerifyCheckpoint spawns `shuru checkpoint …`
+    // whenever the recipe has installCommands, regardless of mode — on a host
+    // without shuru installed that throws "Executable not found in $PATH: shuru",
+    // which parseVerifyResult maps to ERROR (never PASS), pinning the sprint score
+    // at 0.00. Skip it when the sole source of truth (getCurrentSandboxMode) is off.
+    const checkpoint = getCurrentSandboxMode() === "off"
+        ? { created: false }
+        : await (async () => {
+            options.onProgress?.("Preparing verify checkpoint");
+            return ensureVerifyCheckpoint(cwd, profile, sandboxSettings);
+        })();
+    if (getCurrentSandboxMode() === "off") {
+        options.onProgress?.("Sandbox off — running verify on host (no shuru checkpoint)");
+    }
     if (checkpoint.checkpointName) {
         sandboxSettings.from = checkpoint.checkpointName;
         if (checkpoint.guestWorkdir) {
@@ -57,7 +71,10 @@ export async function prepareVerifyRun(agent, options = {}) {
     const taskRequest = {
         agent: "verify",
         description: "Run local verification",
-        prompt: buildVerifyTaskPrompt(cwd, sandboxSettings, profile.recipe),
+        // Thread the resolved mode so the prompt tells the sub-agent to run "on the
+        // host" instead of "inside the active Shuru sandbox" when sandbox is off
+        // (the param defaults to "shuru", which was wrong for an off host).
+        prompt: buildVerifyTaskPrompt(cwd, sandboxSettings, profile.recipe, getCurrentSandboxMode()),
     };
     return {
         profile,

package/package.json

@@ -3,7 +3,7 @@
   "workspaces": [
     "packages/*"
   ],
-  "version": "1.8.5",
+  "version": "1.9.0",
   "description": "BYOK AI coding agent with multi-model council debate, role-based routing, and auto-compact.",
   "repository": {
     "type": "git",
@@ -98,7 +98,6 @@
     "diff": "^8.0.3",
     "fast-xml-parser": "^4.4.1",
     "gpt-tokenizer": "^3.4.0",
-    "keytar": "7.9.0",
     "ollama-ai-provider-v2": "1.5.5",
     "proper-lockfile": "^4.1.2",
     "react": "19.2.5",

package/dist/src/cli/bw-vault.d.ts

@@ -1,55 +0,0 @@
-import { type SpawnSyncReturns } from "node:child_process";
-/**
- * Thin wrapper around the Bitwarden CLI for writing secrets into the user's
- * vault. Mirrors the assumptions of `runKeysImportBw`: the secret lives in the
- * `notes` field of a Secure Note item named `<prefix><id>`.
- *
- * Auth contract: caller must have `bw` in PATH and `BW_SESSION` exported.
- * On any error the returned object has `ok: false` so callers can degrade
- * gracefully (e.g. fall back to writing only the OS keychain).
- */
-export interface BwWriteResult {
-    ok: boolean;
-    action?: "created" | "updated";
-    error?: string;
-}
-type Runner = (cmd: string, args: string[], input?: string) => SpawnSyncReturns<string>;
-/**
- * Write `notes` into a vault item named `name`. Creates a Secure Note if
- * absent; updates the notes field if present. Calls `bw sync` after a write
- * so subsequent `bw get` calls see the new value.
- */
-export declare function writeBwSecureNote(name: string, notes: string, options?: {
-    runner?: Runner;
-}): Promise<BwWriteResult>;
-export interface BwUnlockResult {
-    ok: boolean;
-    session?: string;
-    error?: string;
-}
-/**
- * Unlock the BW vault with a master password and return the session token
- * in-memory only. Caller passes the returned session to subsequent calls;
- * we never write to BW_SESSION env or persist it to disk.
- */
-export declare function unlockWithPassword(password: string, options?: {
-    runner?: Runner;
-}): Promise<BwUnlockResult>;
-export interface BwListedNote {
-    name: string;
-    notes: string;
-}
-/**
- * List Secure Notes whose name starts with `prefix`. Used by the in-TUI
- * sync flow to discover which providers have keys stored in the vault.
- */
-export declare function listSecureNotesByPrefix(session: string, prefix: string, options?: {
-    runner?: Runner;
-}): Promise<{
-    ok: true;
-    items: BwListedNote[];
-} | {
-    ok: false;
-    error: string;
-}>;
-export {};