muonroi-cli 1.8.5 → 1.9.0

package/dist/src/ui/utils/agent-activities.d.ts

@@ -0,0 +1,39 @@
+/**
+ * src/ui/utils/agent-activities.ts
+ *
+ * Collect every sub-agent / background job the main agent has spawned this
+ * session, for the rail's Agents block.
+ *
+ * Derived entirely from state the UI already holds — the transcript entries and
+ * the in-flight tool calls. Spawning goes through tools (`task`, `delegate`,
+ * `bash background:true`), so the tool stream IS the record; there is no need
+ * for a parallel registry in core, and nothing here can drift out of sync with
+ * what the transcript shows.
+ *
+ * Running entries come from activeToolCalls (no result yet), finished ones from
+ * tool_result / tool_group items. A call that is both (still streaming while an
+ * earlier identical call finished) is keyed by tool-call id, so it appears once.
+ */
+import type { ChatEntry, ToolCall } from "../../types/index.js";
+export type ActivityKind = "subagent" | "delegate" | "background";
+export type ActivityStatus = "running" | "done" | "failed";
+export interface AgentActivity {
+    /** Tool-call id — stable across the running → finished transition. */
+    id: string;
+    kind: ActivityKind;
+    /** Short line for the rail row, e.g. an explore agent's description. */
+    label: string;
+    /** Sub-agent type ("explore", "general", …). Empty for background shells. */
+    agent: string;
+    status: ActivityStatus;
+    /** Full text shown when the row is opened: the prompt/command, then output. */
+    detail: string;
+}
+/** The activity kind a tool call represents, or null if it spawns nothing. */
+export declare function activityKindFor(tc: ToolCall): ActivityKind | null;
+/**
+ * Every activity in the session, oldest first. Later state for the same
+ * tool-call id wins, so a call that finishes replaces its own running row
+ * instead of adding a second one.
+ */
+export declare function collectAgentActivities(messages: ChatEntry[], activeToolCalls?: ToolCall[]): AgentActivity[];

package/dist/src/ui/utils/agent-activities.js

@@ -0,0 +1,96 @@
+/**
+ * src/ui/utils/agent-activities.ts
+ *
+ * Collect every sub-agent / background job the main agent has spawned this
+ * session, for the rail's Agents block.
+ *
+ * Derived entirely from state the UI already holds — the transcript entries and
+ * the in-flight tool calls. Spawning goes through tools (`task`, `delegate`,
+ * `bash background:true`), so the tool stream IS the record; there is no need
+ * for a parallel registry in core, and nothing here can drift out of sync with
+ * what the transcript shows.
+ *
+ * Running entries come from activeToolCalls (no result yet), finished ones from
+ * tool_result / tool_group items. A call that is both (still streaming while an
+ * earlier identical call finished) is keyed by tool-call id, so it appears once.
+ */
+const KIND_BY_TOOL = {
+    task: "subagent",
+    delegate: "delegate",
+};
+function parseArgs(tc) {
+    try {
+        const parsed = JSON.parse(tc.function.arguments || "{}");
+        return parsed && typeof parsed === "object" ? parsed : {};
+    }
+    catch (err) {
+        // Arguments stream in as partial JSON while a call assembles — an
+        // unparseable value here is expected mid-flight, not an error.
+        return {};
+    }
+}
+function str(value) {
+    return typeof value === "string" ? value : "";
+}
+/** The activity kind a tool call represents, or null if it spawns nothing. */
+export function activityKindFor(tc) {
+    const name = tc.function.name;
+    const known = KIND_BY_TOOL[name];
+    if (known)
+        return known;
+    // A backgrounded shell is a spawned job too — but only when it actually
+    // backgrounds. A normal bash call is just a tool, not an activity.
+    if (name === "bash" && parseArgs(tc).background === true)
+        return "background";
+    return null;
+}
+function toActivity(tc, result) {
+    const kind = activityKindFor(tc);
+    if (!kind)
+        return null;
+    const args = parseArgs(tc);
+    const agent = kind === "background" ? "" : str(args.agent);
+    const command = str(args.command);
+    const label = (kind === "background" ? command : str(args.description) || str(args.prompt)) || tc.function.name;
+    const request = kind === "background" ? command : str(args.prompt);
+    let status = "running";
+    if (result)
+        status = result.success ? "done" : "failed";
+    const output = result ? (result.success ? result.output || "" : result.error || "") : "";
+    const detail = [request, output].filter((s) => s.trim().length > 0).join("\n\n");
+    return { id: tc.id, kind, label: label.replace(/\s+/g, " ").trim(), agent, status, detail };
+}
+/**
+ * Every activity in the session, oldest first. Later state for the same
+ * tool-call id wins, so a call that finishes replaces its own running row
+ * instead of adding a second one.
+ */
+export function collectAgentActivities(messages, activeToolCalls = []) {
+    const byId = new Map();
+    const add = (tc, result) => {
+        if (!tc)
+            return;
+        const activity = toActivity(tc, result);
+        if (activity)
+            byId.set(activity.id, activity);
+    };
+    for (const entry of messages) {
+        if (entry.type === "tool_result") {
+            add(entry.toolCall, entry.toolResult);
+            continue;
+        }
+        if (entry.type === "tool_group") {
+            for (const item of entry.toolGroup?.items ?? [])
+                add(item.toolCall, item.result);
+        }
+    }
+    // In-flight calls fill in only what the transcript does not already have.
+    // activeToolCalls is not always cleared the instant a result lands, so adding
+    // one unconditionally would flip a finished row back to "running".
+    for (const tc of activeToolCalls) {
+        if (!byId.has(tc.id))
+            add(tc, undefined);
+    }
+    return [...byId.values()];
+}
+//# sourceMappingURL=agent-activities.js.map

package/dist/src/ui/utils/group-tool-entries.d.ts

@@ -0,0 +1,26 @@
+/**
+ * src/ui/utils/group-tool-entries.ts
+ *
+ * Rebuild the tool_group panels when a flat transcript is (re)loaded.
+ *
+ * WHY: the live turn renders tool calls inside a `tool_group` ChatEntry, but the
+ * persisted transcript stores one `tool_result` entry per call. Anything that
+ * replaces the message list with `agent.getChatEntries()` — the end-of-turn
+ * resync in finalizeActiveTurn, session load, resume — therefore DESTROYED the
+ * group and dropped the transcript back to one flat "→ <tool>" line per call.
+ * That is what a user sees after the answer lands, so the nice
+ * "Read 2 files, ran 1 shell command" recap only ever existed mid-turn.
+ *
+ * This folds consecutive tool_result entries back into a done/failed group.
+ */
+import type { ChatEntry } from "../../types/index.js";
+/**
+ * Fold runs of consecutive groupable tool_result entries into one tool_group
+ * entry each. Non-tool entries and rich results pass through untouched, so the
+ * transcript keeps its order. A run of one is still grouped: the recap line
+ * ("Read 1 file") is what stays visible once collapsed.
+ *
+ * `tool_call` entries are dropped inside a run — they are the pending twin of a
+ * result that is already represented by the item.
+ */
+export declare function groupToolEntries(entries: ChatEntry[]): ChatEntry[];

package/dist/src/ui/utils/group-tool-entries.js

@@ -0,0 +1,111 @@
+/**
+ * src/ui/utils/group-tool-entries.ts
+ *
+ * Rebuild the tool_group panels when a flat transcript is (re)loaded.
+ *
+ * WHY: the live turn renders tool calls inside a `tool_group` ChatEntry, but the
+ * persisted transcript stores one `tool_result` entry per call. Anything that
+ * replaces the message list with `agent.getChatEntries()` — the end-of-turn
+ * resync in finalizeActiveTurn, session load, resume — therefore DESTROYED the
+ * group and dropped the transcript back to one flat "→ <tool>" line per call.
+ * That is what a user sees after the answer lands, so the nice
+ * "Read 2 files, ran 1 shell command" recap only ever existed mid-turn.
+ *
+ * This folds consecutive tool_result entries back into a done/failed group.
+ */
+/**
+ * Tool results whose own renderer shows something a tool-group item line cannot
+ * (a plan, a sub-agent run, an image, streaming process logs). These stay as
+ * standalone entries and also break a run, so ordering is preserved.
+ */
+function rendersRichResult(entry) {
+    const name = entry.toolCall?.function.name ?? "";
+    const r = entry.toolResult;
+    if (!r)
+        return true;
+    if (r.plan || r.task || r.delegation || r.backgroundProcess || (r.media?.length ?? 0) > 0)
+        return true;
+    return (name === "generate_plan" ||
+        name === "task" ||
+        name === "delegate" ||
+        name === "delegation_list" ||
+        name === "delegation_read" ||
+        name === "lsp" ||
+        name === "process_logs" ||
+        name === "process_stop" ||
+        name === "process_list");
+}
+function groupable(entry) {
+    return entry.type === "tool_result" && !!entry.toolCall && !rendersRichResult(entry);
+}
+function toItem(entry) {
+    const at = entry.timestamp instanceof Date ? entry.timestamp.getTime() : Date.now();
+    const failed = entry.toolResult?.success === false;
+    return {
+        toolCall: entry.toolCall,
+        result: entry.toolResult,
+        startedAt: at,
+        finishedAt: at,
+        ...(failed ? { failed: true } : {}),
+    };
+}
+/**
+ * Fold runs of consecutive groupable tool_result entries into one tool_group
+ * entry each. Non-tool entries and rich results pass through untouched, so the
+ * transcript keeps its order. A run of one is still grouped: the recap line
+ * ("Read 1 file") is what stays visible once collapsed.
+ *
+ * `tool_call` entries are dropped inside a run — they are the pending twin of a
+ * result that is already represented by the item.
+ */
+export function groupToolEntries(entries) {
+    const out = [];
+    let run = [];
+    const flush = () => {
+        if (run.length === 0)
+            return;
+        const items = run.map(toItem);
+        const first = run[0];
+        const last = run[run.length - 1];
+        const startedAt = items[0].startedAt;
+        const finishedAt = items[items.length - 1].finishedAt ?? startedAt;
+        out.push({
+            type: "tool_group",
+            content: "",
+            timestamp: first.timestamp,
+            ...(first.modeColor ? { modeColor: first.modeColor } : {}),
+            ...(first.remoteKey ? { remoteKey: first.remoteKey } : {}),
+            ...(first.sourceLabel ? { sourceLabel: first.sourceLabel } : {}),
+            toolGroup: {
+                // Deterministic id: the same transcript must rebuild to the same ids, or
+                // React remounts every group on each resync and expansion state is lost.
+                id: `tg-restored-${startedAt}-${items.length}-${last.toolCall?.id ?? "x"}`,
+                state: items.some((i) => i.failed) ? "failed" : "done",
+                items,
+                startedAt,
+                finishedAt,
+                // The persisted entries carry a write-time timestamp, not the tool's real
+                // wall-clock span, so any duration derived here is fiction (a 10s turn
+                // rebuilt as "23ms"). Flag it and let the header omit the number rather
+                // than print a confident lie.
+                restored: true,
+            },
+        });
+        run = [];
+    };
+    for (const entry of entries) {
+        if (groupable(entry)) {
+            run.push(entry);
+            continue;
+        }
+        // A pending tool_call adjacent to a run is already covered by the run's
+        // items; dropping it prevents a duplicate line above the group.
+        if (entry.type === "tool_call" && run.length > 0)
+            continue;
+        flush();
+        out.push(entry);
+    }
+    flush();
+    return out;
+}
+//# sourceMappingURL=group-tool-entries.js.map

package/dist/src/ui/utils/tool-summary.d.ts

@@ -0,0 +1,21 @@
+/**
+ * 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.
+ */
+export declare function categoryForTool(name: string): string;
+/**
+ * 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 declare function activeToolGroupHeader(toolNames: readonly string[]): string;
+/** Past-tense recap once the group closes: "Read 2 files, ran 1 shell command". */
+export declare function doneToolGroupSummary(toolNames: readonly string[]): string;

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/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/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