muonroi-cli 1.8.4 → 1.9.0

package/dist/src/ui/utils/tool-summary.js

@@ -0,0 +1,91 @@
+/**
+ * src/ui/utils/tool-summary.ts
+ *
+ * Phrasing for the tool-group panel. Pure string helpers, no React, so the
+ * wording is unit-testable and the component stays presentational.
+ *
+ * Active:  "Reading 2 files…"          (header, present participle)
+ * Done:    "Read 2 files, ran 1 shell command"   (past-tense recap)
+ *
+ * Counting is per CATEGORY, not per tool name: read_file and
+ * mcp__filesystem__read_text_file are both "files" to a reader.
+ */
+import { verbForTool } from "./tools.js";
+const CATEGORIES = {
+    read: { gerund: "Reading", past: "read", noun: "file", nounPlural: "files" },
+    write: { gerund: "Writing", past: "wrote", noun: "file", nounPlural: "files" },
+    edit: { gerund: "Editing", past: "edited", noun: "file", nounPlural: "files" },
+    bash: { gerund: "Running", past: "ran", noun: "shell command", nounPlural: "shell commands" },
+    search: { gerund: "Searching", past: "ran", noun: "search", nounPlural: "searches" },
+    agent: { gerund: "Exploring", past: "ran", noun: "sub-agent", nounPlural: "sub-agents" },
+    other: { gerund: "Working", past: "ran", noun: "tool", nounPlural: "tools" },
+};
+/** Stable phrase order so the recap doesn't reshuffle as items land. */
+const ORDER = ["read", "write", "edit", "bash", "search", "agent", "other"];
+export function categoryForTool(name) {
+    if (name === "write_file" || /^mcp_+filesystem__write_file$/.test(name))
+        return "write";
+    if (name === "edit_file" || /^mcp_+filesystem__edit_file$/.test(name))
+        return "edit";
+    if (name === "bash")
+        return "bash";
+    if (name === "task" || name === "delegate")
+        return "agent";
+    // Fall back to the existing verb vocabulary so a new tool inherits sane
+    // phrasing without being enumerated here twice.
+    const verb = verbForTool(name);
+    if (verb === "Reading")
+        return "read";
+    if (verb === "Searching")
+        return "search";
+    return "other";
+}
+function countByCategory(toolNames) {
+    const counts = new Map();
+    for (const n of toolNames) {
+        const c = categoryForTool(n);
+        counts.set(c, (counts.get(c) ?? 0) + 1);
+    }
+    return counts;
+}
+function phrase(cat, n, past) {
+    const noun = n === 1 ? cat.noun : cat.nounPlural;
+    return past ? `${cat.past} ${n} ${noun}` : `${cat.gerund} ${n} ${noun}`;
+}
+/**
+ * Header while the group runs: "Reading 2 files…".
+ * With a mixed batch the dominant category wins and the rest are summed into a
+ * trailing "+N more" so the header never claims work it isn't doing.
+ */
+export function activeToolGroupHeader(toolNames) {
+    if (toolNames.length === 0)
+        return "Working…";
+    const counts = countByCategory(toolNames);
+    let bestKey = "other";
+    let best = 0;
+    for (const key of ORDER) {
+        const c = counts.get(key) ?? 0;
+        if (c > best) {
+            best = c;
+            bestKey = key;
+        }
+    }
+    const rest = toolNames.length - best;
+    const head = phrase(CATEGORIES[bestKey], best, false);
+    return rest > 0 ? `${head} +${rest} more…` : `${head}…`;
+}
+/** Past-tense recap once the group closes: "Read 2 files, ran 1 shell command". */
+export function doneToolGroupSummary(toolNames) {
+    if (toolNames.length === 0)
+        return "Done";
+    const counts = countByCategory(toolNames);
+    const parts = [];
+    for (const key of ORDER) {
+        const n = counts.get(key) ?? 0;
+        if (n > 0)
+            parts.push(phrase(CATEGORIES[key], n, true));
+    }
+    const joined = parts.join(", ");
+    return joined.charAt(0).toUpperCase() + joined.slice(1);
+}
+//# sourceMappingURL=tool-summary.js.map

package/dist/src/usage/downgrade.js

@@ -7,7 +7,7 @@
  *
  * Plan 06 (status bar) subscribes to DowngradeEvent for UI updates.
  */
-import { getModelByTier } from "../models/registry.js";
+import { getRoutedModelByTier } from "../router/peak-hour.js";
 import { getDefaultProvider } from "../utils/settings.js";
 function buildDowngradeChain() {
     const provider = getDefaultProvider() ?? undefined;
@@ -15,7 +15,7 @@ function buildDowngradeChain() {
     const seen = new Set();
     const chain = [];
     for (const tier of tiers) {
-        const m = getModelByTier(tier, provider);
+        const m = getRoutedModelByTier(tier, provider);
         if (m && !seen.has(m.id)) {
             chain.push(m.id);
             seen.add(m.id);

package/dist/src/usage/product-ledger.js

@@ -24,12 +24,12 @@ async function ensureDirectory(filePath) {
 export async function appendProductLedger(productRunId, entry, homeOverride) {
     const filePath = getProductLedgerPath(productRunId, homeOverride);
     await ensureDirectory(filePath);
-    // Ensure file exists for lockfile to target
+    // Ensure file exists for lockfile to target without truncating it concurrently
     try {
         await fs.access(filePath);
     }
     catch {
-        await fs.writeFile(filePath, "");
+        await fs.appendFile(filePath, "");
     }
     const releaseLock = await lockfile.lock(filePath, {
         retries: { retries: 10, minTimeout: 10, maxTimeout: 100 },

package/dist/src/utils/event-loop-monitor.d.ts

@@ -0,0 +1,85 @@
+/**
+ * src/utils/event-loop-monitor.ts
+ *
+ * Event-loop block detector.
+ *
+ * Root cause it addresses (observed live, 2026-07-16, session 90c3ff533826):
+ * the TUI froze for 304.5s mid-turn — keystrokes and mouse clicks produced
+ * nothing during the freeze, then ALL replayed at once when it ended (the
+ * signature of a blocked event loop, not a stalled render). Crucially the
+ * 120s provider stall watchdog (tool-engine.ts) did NOT rescue the turn at its
+ * deadline: `stall_rescue` landed at 09:05:47, 6.7s AFTER the loop recovered at
+ * 09:05:41. A setTimeout cannot fire while the loop is blocked, so every
+ * existing guard in this codebase is blind to this failure mode BY
+ * CONSTRUCTION — they are all loop-driven. Same pattern measured across 4
+ * models / 4 providers (grok-composer 304.5s, deepseek-v4-flash 320.2s,
+ * kimi-k2.7-code 329.7s + 314.8s), so it is not a provider quirk.
+ *
+ * This module is the missing instrument: a timer that measures its OWN lateness.
+ * It cannot prevent a block (it is loop-driven too), but the drift it observes
+ * on the first tick AFTER the loop frees up measures the block that just
+ * happened. Pair it with the CPU profiler in `loop-profiler.ts`, whose V8
+ * sampling thread runs INDEPENDENTLY of the JS thread and therefore captures
+ * the culprit stack DURING the block.
+ *
+ * Deliberately dependency-free and cheap: one unref'd interval, no allocation
+ * per tick. `detectBlock` is pure so the drift maths is unit-testable without
+ * timers.
+ */
+/** A detected event-loop block, reported to `onBlock`. */
+export interface EventLoopBlock {
+    /**
+     * How long the loop was blocked, in ms. Measured as the monitor tick's own
+     * lateness, so it UNDER-reports by up to one tick interval (a block shorter
+     * than the tick can hide entirely between two ticks). Treat it as a lower
+     * bound.
+     */
+    blockedMs: number;
+    /** What the process last said it was doing — see {@link setLoopBreadcrumb}. */
+    breadcrumb: string | null;
+    /** ISO timestamp of the tick that observed the block (i.e. after it ended). */
+    detectedAt: string;
+}
+/**
+ * Decide whether an interval tick's lateness constitutes a block.
+ *
+ * A healthy tick fires ~`tickMs` after the previous one; the loop being busy
+ * pushes it later. Lateness beyond `thresholdMs` is reported as a block of that
+ * duration. Pure so the drift maths is testable without real timers.
+ *
+ * @param expectedAt when this tick was due (monotonic ms)
+ * @param actualAt when it actually ran (monotonic ms)
+ * @param thresholdMs report only blocks at least this long; <= 0 disables
+ * @returns block duration in ms, or null when the tick was on time
+ */
+export declare function detectBlock(expectedAt: number, actualAt: number, thresholdMs: number): number | null;
+/**
+ * Record what the process is about to do, so a block report can name a suspect
+ * instead of just a duration. Call it around anything that could plausibly run
+ * long and synchronously (tool execution, a stream step). Cheap — a single
+ * assignment; safe to call on a hot path.
+ *
+ * Pass null to clear. Not a stack: last writer wins, by design — the goal is a
+ * hint for the profile, and the profile is the real evidence.
+ */
+export declare function setLoopBreadcrumb(label: string | null): void;
+/** The current breadcrumb, or null. */
+export declare function getLoopBreadcrumb(): string | null;
+/** Options for {@link startEventLoopMonitor}. */
+export interface EventLoopMonitorOpts {
+    /** Report blocks at least this long. <= 0 disables the monitor entirely. */
+    thresholdMs: number;
+    /**
+     * How often to check. Bounds both the detection granularity and the amount a
+     * block can be under-reported by. 500ms costs ~2 wakeups/sec.
+     */
+    tickMs?: number;
+    /** Called once per detected block. Must not throw (it is guarded anyway). */
+    onBlock: (block: EventLoopBlock) => void;
+}
+/**
+ * Start watching for event-loop blocks. Returns a stop function (idempotent).
+ *
+ * The interval is unref'd so it never keeps the process alive on its own.
+ */
+export declare function startEventLoopMonitor(opts: EventLoopMonitorOpts): () => void;

package/dist/src/utils/event-loop-monitor.js

@@ -0,0 +1,107 @@
+/**
+ * src/utils/event-loop-monitor.ts
+ *
+ * Event-loop block detector.
+ *
+ * Root cause it addresses (observed live, 2026-07-16, session 90c3ff533826):
+ * the TUI froze for 304.5s mid-turn — keystrokes and mouse clicks produced
+ * nothing during the freeze, then ALL replayed at once when it ended (the
+ * signature of a blocked event loop, not a stalled render). Crucially the
+ * 120s provider stall watchdog (tool-engine.ts) did NOT rescue the turn at its
+ * deadline: `stall_rescue` landed at 09:05:47, 6.7s AFTER the loop recovered at
+ * 09:05:41. A setTimeout cannot fire while the loop is blocked, so every
+ * existing guard in this codebase is blind to this failure mode BY
+ * CONSTRUCTION — they are all loop-driven. Same pattern measured across 4
+ * models / 4 providers (grok-composer 304.5s, deepseek-v4-flash 320.2s,
+ * kimi-k2.7-code 329.7s + 314.8s), so it is not a provider quirk.
+ *
+ * This module is the missing instrument: a timer that measures its OWN lateness.
+ * It cannot prevent a block (it is loop-driven too), but the drift it observes
+ * on the first tick AFTER the loop frees up measures the block that just
+ * happened. Pair it with the CPU profiler in `loop-profiler.ts`, whose V8
+ * sampling thread runs INDEPENDENTLY of the JS thread and therefore captures
+ * the culprit stack DURING the block.
+ *
+ * Deliberately dependency-free and cheap: one unref'd interval, no allocation
+ * per tick. `detectBlock` is pure so the drift maths is unit-testable without
+ * timers.
+ */
+import { logger } from "./logger.js";
+/**
+ * Decide whether an interval tick's lateness constitutes a block.
+ *
+ * A healthy tick fires ~`tickMs` after the previous one; the loop being busy
+ * pushes it later. Lateness beyond `thresholdMs` is reported as a block of that
+ * duration. Pure so the drift maths is testable without real timers.
+ *
+ * @param expectedAt when this tick was due (monotonic ms)
+ * @param actualAt when it actually ran (monotonic ms)
+ * @param thresholdMs report only blocks at least this long; <= 0 disables
+ * @returns block duration in ms, or null when the tick was on time
+ */
+export function detectBlock(expectedAt, actualAt, thresholdMs) {
+    if (!(thresholdMs > 0))
+        return null;
+    const lateBy = actualAt - expectedAt;
+    if (!Number.isFinite(lateBy) || lateBy < thresholdMs)
+        return null;
+    return Math.round(lateBy);
+}
+let _breadcrumb = null;
+/**
+ * Record what the process is about to do, so a block report can name a suspect
+ * instead of just a duration. Call it around anything that could plausibly run
+ * long and synchronously (tool execution, a stream step). Cheap — a single
+ * assignment; safe to call on a hot path.
+ *
+ * Pass null to clear. Not a stack: last writer wins, by design — the goal is a
+ * hint for the profile, and the profile is the real evidence.
+ */
+export function setLoopBreadcrumb(label) {
+    _breadcrumb = label;
+}
+/** The current breadcrumb, or null. */
+export function getLoopBreadcrumb() {
+    return _breadcrumb;
+}
+/**
+ * Start watching for event-loop blocks. Returns a stop function (idempotent).
+ *
+ * The interval is unref'd so it never keeps the process alive on its own.
+ */
+export function startEventLoopMonitor(opts) {
+    const { thresholdMs, onBlock } = opts;
+    const tickMs = opts.tickMs && opts.tickMs > 0 ? opts.tickMs : 500;
+    if (!(thresholdMs > 0))
+        return () => { };
+    let expectedAt = performance.now() + tickMs;
+    const timer = setInterval(() => {
+        const actualAt = performance.now();
+        const blockedMs = detectBlock(expectedAt, actualAt, thresholdMs);
+        expectedAt = actualAt + tickMs;
+        if (blockedMs === null)
+            return;
+        try {
+            onBlock({
+                blockedMs,
+                breadcrumb: getLoopBreadcrumb(),
+                detectedAt: new Date().toISOString(),
+            });
+        }
+        catch (err) {
+            logger.error("cli", `[event-loop-monitor] onBlock handler threw: ${err?.message}`, {
+                error: err,
+                blockedMs,
+            });
+        }
+    }, tickMs);
+    timer.unref?.();
+    let stopped = false;
+    return () => {
+        if (stopped)
+            return;
+        stopped = true;
+        clearInterval(timer);
+    };
+}
+//# sourceMappingURL=event-loop-monitor.js.map

package/dist/src/utils/install-manager.js

@@ -194,7 +194,8 @@ export function detectInstallMethod(homeDir = os.homedir()) {
     }
     // Not under node_modules and not launched by node/bun → standalone binary.
     const exeBase = ((process.execPath || "").replace(/\\/g, "/").split("/").pop() ?? "").toLowerCase();
-    if (!modPath.includes("/node_modules/") && !/^(node|bun)(\.exe)?$/.test(exeBase)) {
+    const isNodeOrBunRunner = /^(node|bun)(\.exe|-[\d.]+)?$/i.test(exeBase);
+    if (!modPath.includes("/node_modules/") && !isNodeOrBunRunner) {
         return "compiled";
     }
     // Linked/source build run from a git checkout (e.g. `bun link`, a symlinked

package/dist/src/utils/llm-deadline.d.ts

@@ -50,3 +50,17 @@ export declare function withDeadlineRace<T>(fn: () => Promise<T>, deadlineMs: nu
  * The short grace lets the normal fetch-level abort win first when it's quick.
  */
 abortSignal?: AbortSignal, abortGraceMs?: number): Promise<T>;
+/**
+ * Wall-clock backstop (ms) for an isolated sub-agent task (`runIsolatedTask`).
+ *
+ * The council `generate()` chokepoint and the sprint impl/verify stages already
+ * have deadlines, but the *other* `runIsolatedTask` await points — plan-adherence
+ * review + fix, council research, grounding-verify — were bare `await`s. A
+ * provider that hangs on the JS side after the sub-agent's stream finishes wedges
+ * the whole pipeline with no error (observed live: run mrhc43f0fb9b impl, and the
+ * scoping stall). Wrap those calls in `withDeadlineRace(fn, getIsolatedTaskDeadlineMs(), ...)`
+ * so a hang surfaces as a rejection the caller already handles. Generous by
+ * default so a legitimately long tool-using sub-agent is not cut short; override
+ * with MUONROI_IDEAL_ISOLATED_TASK_MS. Clamped to [60s, 30min].
+ */
+export declare function getIsolatedTaskDeadlineMs(): number;

package/dist/src/utils/llm-deadline.js

@@ -106,4 +106,23 @@ abortSignal, abortGraceMs = 1500) {
             abortSignal.removeEventListener("abort", abortListener);
     }
 }
+/**
+ * Wall-clock backstop (ms) for an isolated sub-agent task (`runIsolatedTask`).
+ *
+ * The council `generate()` chokepoint and the sprint impl/verify stages already
+ * have deadlines, but the *other* `runIsolatedTask` await points — plan-adherence
+ * review + fix, council research, grounding-verify — were bare `await`s. A
+ * provider that hangs on the JS side after the sub-agent's stream finishes wedges
+ * the whole pipeline with no error (observed live: run mrhc43f0fb9b impl, and the
+ * scoping stall). Wrap those calls in `withDeadlineRace(fn, getIsolatedTaskDeadlineMs(), ...)`
+ * so a hang surfaces as a rejection the caller already handles. Generous by
+ * default so a legitimately long tool-using sub-agent is not cut short; override
+ * with MUONROI_IDEAL_ISOLATED_TASK_MS. Clamped to [60s, 30min].
+ */
+export function getIsolatedTaskDeadlineMs() {
+    const raw = Number.parseInt(process.env.MUONROI_IDEAL_ISOLATED_TASK_MS ?? "", 10);
+    if (Number.isFinite(raw) && raw >= 60_000 && raw <= 1_800_000)
+        return raw;
+    return 900_000; // 15 min backstop
+}
 //# sourceMappingURL=llm-deadline.js.map

package/dist/src/utils/logger.js

@@ -1,6 +1,6 @@
-import * as fs from "fs";
-import * as path from "path";
+import fs from "fs";
 import * as os from "os";
+import * as path from "path";
 const LEVEL_WEIGHTS = {
     debug: 0,
     info: 1,

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 {};