muonroi-cli 1.8.4 → 1.8.5

package/dist/src/orchestrator/preprocessor.js

@@ -1,6 +1,6 @@
 import { runPipeline } from "../pil/pipeline.js";
-import { getSessionLastTask, recordSessionLastTask, resolveCeiling } from "./scope-ceiling.js";
 import { logger } from "../utils/logger.js";
+import { getSessionLastTask, recordSessionLastTask, resolveCeiling } from "./scope-ceiling.js";
 export async function* prepareTurnContext(deps, userMessage, _budgetOverride) {
     // PIL: enrich prompt before pushing to messages (D-01, D-03, D-04)
     // Promise.race timeout of 200ms is inside runPipeline — fail-open guaranteed

package/dist/src/orchestrator/proactive-compact-detector.d.ts

@@ -0,0 +1,26 @@
+/**
+ * src/orchestrator/proactive-compact-detector.ts
+ *
+ * Detect when the agent (main or sub) proactively emits a /compact request
+ * in its assistant text, per the guidance we injected in pre-warn and past-budget
+ * reminders. Pattern (exact on its own line, as instructed):
+ *   /compact <short instructions on what to focus on after compaction>
+ *
+ * When detected:
+ * - Extract the instructions (trimmed).
+ * - Caller can then:
+ *   1. Emit the __COMPACT__-style signal (or call deliberateCompact).
+ *   2. Inject a resume directive on the next turn: "Compact done. Resume previous task focusing on: <instructions>. Continue the work until complete."
+ *   3. Do NOT stop the task.
+ *
+ * Precision: only matches leading /compact at start of line (after optional whitespace),
+ * followed by optional instructions. Ignores mentions inside code blocks or prose.
+ * Uses only stdlib (no extra deps). 1-line core after regex compile.
+ */
+export interface ProactiveCompactRequest {
+    detected: boolean;
+    instructions: string | null;
+}
+export declare function detectProactiveCompactRequest(text: string): ProactiveCompactRequest;
+/** Build the exact resume text the agent should see after a proactive compact. */
+export declare function buildCompactResumeMessage(instructions: string | null): string;

package/dist/src/orchestrator/proactive-compact-detector.js

@@ -0,0 +1,36 @@
+/**
+ * src/orchestrator/proactive-compact-detector.ts
+ *
+ * Detect when the agent (main or sub) proactively emits a /compact request
+ * in its assistant text, per the guidance we injected in pre-warn and past-budget
+ * reminders. Pattern (exact on its own line, as instructed):
+ *   /compact <short instructions on what to focus on after compaction>
+ *
+ * When detected:
+ * - Extract the instructions (trimmed).
+ * - Caller can then:
+ *   1. Emit the __COMPACT__-style signal (or call deliberateCompact).
+ *   2. Inject a resume directive on the next turn: "Compact done. Resume previous task focusing on: <instructions>. Continue the work until complete."
+ *   3. Do NOT stop the task.
+ *
+ * Precision: only matches leading /compact at start of line (after optional whitespace),
+ * followed by optional instructions. Ignores mentions inside code blocks or prose.
+ * Uses only stdlib (no extra deps). 1-line core after regex compile.
+ */
+/** Matches "/compact ..." at start of a line (allows leading ws). Captures the rest. */
+const PROACTIVE_RE = /^\s*\/compact\s*(.*)$/m;
+export function detectProactiveCompactRequest(text) {
+    if (!text || typeof text !== "string")
+        return { detected: false, instructions: null };
+    const m = PROACTIVE_RE.exec(text);
+    if (!m)
+        return { detected: false, instructions: null };
+    const raw = (m[1] || "").trim();
+    return { detected: true, instructions: raw.length > 0 ? raw : null };
+}
+/** Build the exact resume text the agent should see after a proactive compact. */
+export function buildCompactResumeMessage(instructions) {
+    const focus = instructions && instructions.trim().length > 0 ? instructions.trim() : "the original task";
+    return `Compact done. Resume previous task focusing on: ${focus}. Continue the work until complete. Do not stop.`;
+}
+//# sourceMappingURL=proactive-compact-detector.js.map

package/dist/src/orchestrator/prompts.js

@@ -276,18 +276,14 @@ WORKFLOW:
 8. Run tests or builds with bash to confirm correctness
 9. Use search_web or search_x when you need up-to-date information
 
-DEFAULT DELEGATION POLICY:
-- Prefer the task tool by default for code review, code quality analysis, architecture research, root-cause investigation, bug triage, verification, or any request that likely needs reading multiple files before acting.
-- Prefer delegate for longer-running read-only exploration when you can keep making progress without blocking.
-- Use the explore sub-agent for read-only investigation, reviews, research, and "how does this work?" tasks.
-- Use the general sub-agent for delegated work that may need editing files, running commands, or producing a concrete implementation.
-- Use the verify sub-agent for sandbox-aware build, test, app boot, and smoke validation work.
-- Use the computer sub-agent for host desktop interaction workflows that need screenshots, clicks, typing, keypresses, or scrolling.
-- Use a matching custom sub-agent when the task fits one of the configured specializations.
-- Never use delegate for tasks that should edit files or make shell changes.
-- When a background delegation is running, do not wait idly and do not spam delegation_list(). Continue useful work.
-- Do not wait for the user to explicitly ask for a sub-agent when delegation would clearly help.
-- Skip delegation only when the task is trivial, single-file, or you already have the exact answer.
+DEFAULT DELEGATION POLICY (critical for avoiding stalls/timeouts):
+- For ANY research, exploration, review, architecture investigation, "how does X work", or read-only analysis — you MUST use \`delegate\` (background) with the explore agent. This spawns a true non-blocking background job.
+- Use \`task\` (foreground, blocking) ONLY for short, focused, low-round work that must return immediately into the current turn (e.g. quick edit + verify in <10-15 rounds). Using task for research WILL block the main session and frequently causes "model not responding" / stall timeouts on the provider.
+- Prefer delegate + explore for anything that needs reading many files or long reasoning.
+- Use general sub-agent only when edits/commands are required.
+- Never use delegate for write/edit/shell changes.
+- After launching a background delegate, continue useful work. Check results later with delegation_read / list only when needed.
+- The model choosing task for long research is a common mistake that leads to timeouts — prefer delegate.
 
 WRITING A GOOD DELEGATION PROMPT (the sub-agent sees ONLY what you put in the prompt field — it does NOT share your context):
 - GOAL: state the one concrete question or outcome the sub must deliver.
@@ -296,9 +292,10 @@ WRITING A GOOD DELEGATION PROMPT (the sub-agent sees ONLY what you put in the pr
 - When fanning out several sub-agents in parallel, give each a NON-overlapping scope so their syntheses compose instead of duplicating.
 
 EXAMPLES:
-- "review this change" -> delegate to explore first
-- "research how auth works" -> delegate to explore first
-- "investigate why this test fails" -> delegate to explore first, then continue with findings
+- "review this change" -> delegate (background explore) first
+- "research how auth works" -> delegate (background explore) first
+- "investigate why this test fails" -> delegate (background) to explore first, then continue with findings
+- Long multi-file analysis or "review the sub-session spawn mechanism" -> ALWAYS delegate, never task
 - "refactor this module" -> delegate a focused part to general when helpful
 - "verify this feature locally" -> use verify
 - "open the host app and click through it" -> use computer
@@ -316,7 +313,7 @@ IMPORTANT:
 - Use write_file only for new files or when most of the file is changing. For very large files (>500 lines), split into multiple edit_file calls or write smaller chunks.
 - Use read_file instead of cat/head/tail for reading files.
 - When the user asks for an automated recurring or one-time run, use the schedule tools instead of only describing the setup.
-- If you have worked for a long time or hit a tool execution limit, DO NOT tell the user to move to a new session. Instead, advise them to run the \`/compact\` command to free up memory before continuing.
+- Long tasks never need to stop for context. Two mechanisms keep you going: (1) the CLI AUTO-compacts and continues when you approach a tool-round limit, and (2) you can PROACTIVELY call the \`compact\` tool yourself the moment context feels heavy (e.g. after a read-heavy stretch) to shed old tool history before you hit any limit — it compacts, then you continue in the same turn. Older tool results stay rehydratable via ee_query "tool-artifact id=…". So: do NOT stop to tell the user to start a new session or run \`/compact\` themselves, and do NOT stop after calling \`compact\` — keep working toward the goal. Only present your final answer when the task is genuinely finished.
 - Use the experience brain actively (it is how you stop repeating mistakes across sessions): at the start of an unfamiliar or risky step call ee_query to recall past lessons, and after acting on a recalled \`[id col]\` rate it with ee_feedback. The MOMENT you hit a mistake / error / dead-end and find the working fix, call ee_write to save the lesson (the pitfall AND the fix, concise and generalizable) — it is embedded immediately and recallable via ee_query in this and future sessions. Saving a hard-won fix is part of doing the work, not optional.
 - Commit your own work as you go (in any git repo, without being asked): use the git_commit tool — YOU write the commit message — the moment a cohesive, working chunk passes its checks, and after EACH step of a multi-step plan. Prefer several small, logically-scoped commits with clear messages (describe WHAT changed) over one catch-all at the end. git_commit stages only the files you wrote, excludes secrets/artifacts, and appends the "Coding by - Muonroi-CLI" attribution for you. (Any commit you instead make by hand via bash must still end with that attribution line, verbatim, on its own final line.)
 - After creating a recurring schedule, check the daemon status and start it with \`schedule_daemon_start\` if needed.
@@ -331,10 +328,13 @@ TOKEN BUDGET:
 WORKFLOW RULES:
 - RESEARCH FIRST: Always prioritize research before proposing edits. DeepSeek and other models have knowledge cutoffs; do not assume you know the exact codebase structure or latest external libraries. Use 'grep', 'lsp', and 'read_file' to search the local codebase. Use MCP tools (like web search or documentation readers) to research external knowledge, APIs, or libraries. Use 'delegate' for deep background research. Read before you write.
 - CLARIFY GRAY AREAS: If the user's request is ambiguous or leaves critical design decisions unspecified, STOP and ask the user for clarification before writing code. Do not hallucinate requirements.
+- PRIORITIZE RECENT CONTEXT OVER HISTORY: When receiving short, ambiguous, or general continuation prompts from the user (such as "implement nhé", "tiếp tục", "go ahead", "tiếp tục nhé"), ALWAYS prioritize the most recently discussed design decisions, proposals, or topics from the immediate preceding turn(s). Do not regress or default back to earlier, older, or already completed tasks/topics that dominated the earlier parts of the session.
+- BATCH ALL TOOL CALLS — HARD RULE: You MUST combine every independent tool call (read_file, grep, bash, etc.) you know you need into ONE parallel batch in your FIRST tool turn. Do NOT spread them across sequential rounds. Each extra LLM round re-sends the full ~17K system prompt + accumulated context, costing $0.003-$0.006 and inflating input 3-5x for NO new signal. If your first batch cannot cover all the reads/exploration needed, use delegate (explore) instead — do NOT scatter reads across 3+ rounds.
+- MAX 2 LLM ROUND TRIPS per user message: round 1 = batch all reads/exploration; round 2 = follow-up only if a result from round 1 genuinely requires a NEW read you could not have anticipated. If you need round 3, you violated the batching rule — stop and use delegate (explore) instead.
+- COST AWARENESS: Every tool round after round 1 burns $0.004-$0.006 for ZERO new signal — the system prompt is unchanged, only tool outputs grew. If you have 8+ tool calls, they MUST all go in round 1, not spread across 3-8 rounds.
 
 SELF-LIMIT:
 - When you've read 5+ files and haven't concluded, summarize findings and propose next step instead of reading more.
-- BATCH TOOL CALLS: You MUST combine and invoke independent tool calls in parallel (e.g. read multiple files, or run grep and read a file concurrently) in a SINGLE turn. Do not wait for the result of one tool call before invoking another if you already know both are needed. This dramatically reduces conversation turns, roundtrip latency, and input token accumulation.
 - BATCH BASH COMMANDS: Combine independent commands into ONE bash call (a; b; c) rather than sequential single calls — each separate call adds ~500 tokens of overhead and prevents prompt-cache reuse across the session.
 - Read only specific file sections (start_line/end_line) instead of whole files.
 - When a clear direction emerges from the first 2-3 tool results, act on it — don't over-investigate.`,

package/dist/src/orchestrator/reactive-delegation.d.ts

@@ -0,0 +1,39 @@
+/**
+ * src/orchestrator/reactive-delegation.ts
+ *
+ * Reactive sub-session escalation — the deterministic complement to the upfront
+ * LLM router (`classifySubSessionAction`).
+ *
+ * Why this exists (measured, 2026-07-09): the upfront router mis-routes
+ * read-heavy work to DIRECT_ANSWER two ways —
+ *   1. Semantic blind spot: the live deepseek-v4-flash classifier answers the
+ *      exact prompt "đánh giá phân tích council feature" with DIRECT_ANSWER
+ *      ("no multi-step tool actions needed"), yet that turn ran 13 read_file
+ *      calls. Analysis/review phrasing reads as "no tools" to the router.
+ *   2. Silent degrade: on a dead key / EE-down the classifier returns null and
+ *      the caller falls back to DIRECT_ANSWER — so isolation never fires exactly
+ *      when infra is degraded (reproduced on session 50aa048a6303).
+ *
+ * Both failures are a PREDICTION problem (guessing tool cost from the prompt).
+ * This module instead reacts to OBSERVED load: the per-turn cumulative
+ * tool-output byte count from the top-level cap (`wrapToolSetWithCap` state).
+ * Once a turn demonstrably burns through heavy tool output, the NEXT turn on
+ * the same session is escalated to an isolated sub-session regardless of what
+ * the router predicted — the mechanism self-corrects after the first heavy turn
+ * instead of relying on a fragile upfront guess. No regex/keyword heuristic
+ * (respects the no-regex classification rule) — the signal is real execution.
+ */
+/**
+ * Cumulative tool-output chars a turn must exceed for the NEXT turn to escalate
+ * to a sub-session. Env-tunable via `MUONROI_REACTIVE_DELEGATE_CHARS`; set to 0
+ * to disable reactive escalation entirely.
+ */
+export declare function getReactiveDelegationThresholdChars(): number;
+/**
+ * True when the previous turn's observed tool-output load justifies escalating
+ * the current turn to an isolated sub-session. Threshold 0 disables it.
+ *
+ * Pure — the caller owns the "only override a DIRECT_ANSWER route" policy so
+ * ROTATE_SESSION (a deliberate topic switch) is never hijacked.
+ */
+export declare function shouldReactivelyEscalate(prevTurnToolChars: number, threshold?: number): boolean;

package/dist/src/orchestrator/reactive-delegation.js

@@ -0,0 +1,59 @@
+/**
+ * src/orchestrator/reactive-delegation.ts
+ *
+ * Reactive sub-session escalation — the deterministic complement to the upfront
+ * LLM router (`classifySubSessionAction`).
+ *
+ * Why this exists (measured, 2026-07-09): the upfront router mis-routes
+ * read-heavy work to DIRECT_ANSWER two ways —
+ *   1. Semantic blind spot: the live deepseek-v4-flash classifier answers the
+ *      exact prompt "đánh giá phân tích council feature" with DIRECT_ANSWER
+ *      ("no multi-step tool actions needed"), yet that turn ran 13 read_file
+ *      calls. Analysis/review phrasing reads as "no tools" to the router.
+ *   2. Silent degrade: on a dead key / EE-down the classifier returns null and
+ *      the caller falls back to DIRECT_ANSWER — so isolation never fires exactly
+ *      when infra is degraded (reproduced on session 50aa048a6303).
+ *
+ * Both failures are a PREDICTION problem (guessing tool cost from the prompt).
+ * This module instead reacts to OBSERVED load: the per-turn cumulative
+ * tool-output byte count from the top-level cap (`wrapToolSetWithCap` state).
+ * Once a turn demonstrably burns through heavy tool output, the NEXT turn on
+ * the same session is escalated to an isolated sub-session regardless of what
+ * the router predicted — the mechanism self-corrects after the first heavy turn
+ * instead of relying on a fragile upfront guess. No regex/keyword heuristic
+ * (respects the no-regex classification rule) — the signal is real execution.
+ */
+/** Default: ~120k chars of cumulative tool output ≈ ~30k tokens — clearly a
+ * multi-tool "heavy" turn, well above a 1–2 tool light turn. Matches the
+ * sub-agent cap's default budget so "heavy enough to cap" == "heavy enough to
+ * isolate next time". */
+const DEFAULT_REACTIVE_DELEGATE_CHARS = 120_000;
+/**
+ * Cumulative tool-output chars a turn must exceed for the NEXT turn to escalate
+ * to a sub-session. Env-tunable via `MUONROI_REACTIVE_DELEGATE_CHARS`; set to 0
+ * to disable reactive escalation entirely.
+ */
+export function getReactiveDelegationThresholdChars() {
+    const raw = process.env.MUONROI_REACTIVE_DELEGATE_CHARS;
+    if (raw !== undefined && raw.trim() !== "") {
+        const n = Number(raw);
+        if (Number.isFinite(n) && n >= 0)
+            return n;
+    }
+    return DEFAULT_REACTIVE_DELEGATE_CHARS;
+}
+/**
+ * True when the previous turn's observed tool-output load justifies escalating
+ * the current turn to an isolated sub-session. Threshold 0 disables it.
+ *
+ * Pure — the caller owns the "only override a DIRECT_ANSWER route" policy so
+ * ROTATE_SESSION (a deliberate topic switch) is never hijacked.
+ */
+export function shouldReactivelyEscalate(prevTurnToolChars, threshold = getReactiveDelegationThresholdChars()) {
+    if (!Number.isFinite(prevTurnToolChars) || prevTurnToolChars <= 0)
+        return false;
+    if (threshold <= 0)
+        return false;
+    return prevTurnToolChars >= threshold;
+}
+//# sourceMappingURL=reactive-delegation.js.map

package/dist/src/orchestrator/retry-classifier.d.ts

@@ -7,7 +7,8 @@ export interface TransientCheck {
  *
  * Transient:
  *  - Network-level errors: ECONNREFUSED, ETIMEDOUT, ECONNRESET, EAI_AGAIN,
- *    "fetch failed", "Unable to connect", "socket hang up", "network"
+ *    "fetch failed", "Unable to connect", "socket hang up", "network",
+ *    "socket connection was closed unexpectedly" (Bun stream drop)
  *  - HTTP 408 (request timeout), 425 (too early), 429 (rate limit), 5xx
  *  - TypeError with "fetch failed" message (browser/bun/node fetch layer)
  *  - AbortSignal.timeout firing (err.name === "TimeoutError")

package/dist/src/orchestrator/retry-classifier.js

@@ -1,11 +1,34 @@
 import { APICallError } from "@ai-sdk/provider";
+import { isProviderThinkingDegraded, markProviderThinkingDegrade } from "../providers/strategies/thinking-mode.js";
 import { STALL_ABORT_REASON } from "./stall-watchdog.js";
+/**
+ * Detect the generic, spec-undocumented param rejection from the z.ai GLM
+ * coding endpoint (HTTP 400 code 1210 "Invalid API parameter") and the
+ * opencode-go Console Go proxy (HTTP 400 invalid_request "Upstream request
+ * failed"). z.ai does NOT publish the exact constraint (verified 2026-07-02 vs
+ * docs.z.ai/api-reference/api-code — 1210 is an intentionally generic bucket),
+ * so no client transform can guarantee prevention. These are matched narrowly
+ * (400 + specific phrasing) so ordinary 400s stay non-transient.
+ */
+function isProviderParamReject(err) {
+    const status = APICallError.isInstance(err)
+        ? err.statusCode
+        : (err?.statusCode ??
+            err?.status);
+    if (status !== 400)
+        return false;
+    const message = err instanceof Error ? err.message : String(err);
+    const body = APICallError.isInstance(err) && typeof err.responseBody === "string" ? err.responseBody : "";
+    const hay = `${message}\n${body}`;
+    return /invalid api parameter|upstream request failed|unexpected end of JSON input|code"?\s*:?\s*1210/i.test(hay);
+}
 /**
  * Classifies a stream error as transient (safe to retry) or non-transient.
  *
  * Transient:
  *  - Network-level errors: ECONNREFUSED, ETIMEDOUT, ECONNRESET, EAI_AGAIN,
- *    "fetch failed", "Unable to connect", "socket hang up", "network"
+ *    "fetch failed", "Unable to connect", "socket hang up", "network",
+ *    "socket connection was closed unexpectedly" (Bun stream drop)
  *  - HTTP 408 (request timeout), 425 (too early), 429 (rate limit), 5xx
  *  - TypeError with "fetch failed" message (browser/bun/node fetch layer)
  *  - AbortSignal.timeout firing (err.name === "TimeoutError")
@@ -38,6 +61,19 @@ export function classifyStreamError(err, depth = 0) {
     if (e.name === "TimeoutError") {
         return { transient: true, reason: "timeout-error" };
     }
+    // z.ai / opencode-go generic param reject (1210 / "Upstream request failed"):
+    // give EXACTLY ONE retry with a degraded-but-valid body. The first sighting
+    // latches thinking OFF (markProviderThinkingDegrade) so the rebuilt request
+    // (factory re-invoked by withStreamRetry) sends the validator-safe shape;
+    // parallel tool_calls are already split by the transform. If it STILL rejects
+    // after we've degraded, stop retrying — the cause is beyond our client fix.
+    if (isProviderParamReject(err)) {
+        if (isProviderThinkingDegraded()) {
+            return { transient: false, reason: "provider-param-reject-after-degrade" };
+        }
+        markProviderThinkingDegrade();
+        return { transient: true, reason: "provider-param-reject-degrade-retry" };
+    }
     // AI SDK APICallError with statusCode
     if (APICallError.isInstance(err)) {
         const status = err.statusCode;
@@ -61,6 +97,10 @@ export function classifyStreamError(err, depth = 0) {
         }
     }
     const message = typeof e.message === "string" ? e.message : "";
+    // Rate limits (including wrapped messages from proxies like "Console Go")
+    if (/rate limit|rate-limited|429|too many requests/i.test(message)) {
+        return { transient: true, reason: "rate-limit-message" };
+    }
     // Malformed function/tool name errors — non-transient (own handler elsewhere)
     if (/invalid.*function.*name|function.*name.*invalid|malformed.*tool|NoSuchTool/i.test(message)) {
         return { transient: false, reason: "malformed-tool-name" };
@@ -86,7 +126,11 @@ function isTransientStatusCode(code) {
     return code === 408 || code === 425 || code === 429 || (code >= 500 && code <= 599);
 }
 function isTransientMessage(message) {
-    return /ECONNREFUSED|ETIMEDOUT|ECONNRESET|EAI_AGAIN|fetch failed|Unable to connect|network|socket hang up/i.test(message);
+    // "socket connection was closed unexpectedly" is Bun's fetch phrasing when a
+    // provider drops a streaming response mid-flight — a transient network drop,
+    // not a client error. Left unclassified it escapes as an unhandledRejection,
+    // which OpenTUI's handleError turns into an un-dismissable console overlay.
+    return /ECONNREFUSED|ETIMEDOUT|ECONNRESET|EAI_AGAIN|fetch failed|Unable to connect|network|socket hang up|socket connection was closed|socket.*closed unexpectedly/i.test(message);
 }
 /**
  * Parse Retry-After header value to milliseconds.

package/dist/src/orchestrator/safety-intercept.d.ts

@@ -0,0 +1,45 @@
+/**
+ * safety-intercept.ts — pure decision helpers for the tool-engine safety-block
+ * interceptor (tool-engine.ts). Extracted so the block-parse and the
+ * permission-mode policy are unit-testable in isolation from the giant
+ * executeToolEngine generator.
+ *
+ * Flow context: bash.execute / registry precheck emit a tool result whose text
+ * starts with `BLOCKED (<kind>): <reason>`. The tool-engine joins output+error,
+ * parses it here, and decides whether to auto-block, auto-allow (yolo), or show
+ * the safety-override askcard via deps.askSafetyOverride.
+ */
+import type { PermissionMode } from "../utils/permission-mode.js";
+import type { SafetyBlockKind } from "./safety-askcard.js";
+export interface ParsedSafetyBlock {
+    kind: SafetyBlockKind;
+    reason: string;
+}
+/**
+ * Parse a joined tool-result text into a safety block, or null when the text
+ * is not a BLOCKED marker.
+ *
+ * Tolerant of leading whitespace: when bash.execute returns `{error: "BLOCKED
+ * (...)"}` with no `output`, the joined text is the raw marker — but a result
+ * shape that carries an empty-string `output` produces a leading "\n" before
+ * the marker, which an anchored `/^BLOCKED/` would miss and silently drop the
+ * askcard (hard-stop with no prompt). Stripping leading whitespace first makes
+ * the parse robust to both shapes while still requiring the marker at the head
+ * of the (trimmed) text — so a command whose normal output merely mentions
+ * "BLOCKED (...)" mid-stream is not mistaken for a real block.
+ */
+export declare function parseSafetyBlock(outputText: string): ParsedSafetyBlock | null;
+/**
+ * Whether a parsed block should be auto-allowed (allow-once) without showing
+ * the askcard, given the active permission mode.
+ *
+ * Policy (confirmed with the user):
+ *   - `yolo` auto-allows lower-severity blocks (`git-safety`, `dangerous`) so
+ *     the "don't ask me" mode actually stops asking for routine guardrails.
+ *   - `catastrophic` ALWAYS shows the askcard, even in yolo — an irreversible
+ *     destroyer (rm -rf /dev, mkfs, sudo …) must never run unattended.
+ *   - `empty-bash` is handled separately (auto-block, no card) and never
+ *     reaches this policy.
+ *   - `safe` / `auto-edit` always show the card for any real block.
+ */
+export declare function shouldAutoAllowYolo(kind: SafetyBlockKind, mode: PermissionMode): boolean;

package/dist/src/orchestrator/safety-intercept.js

@@ -0,0 +1,55 @@
+/**
+ * safety-intercept.ts — pure decision helpers for the tool-engine safety-block
+ * interceptor (tool-engine.ts). Extracted so the block-parse and the
+ * permission-mode policy are unit-testable in isolation from the giant
+ * executeToolEngine generator.
+ *
+ * Flow context: bash.execute / registry precheck emit a tool result whose text
+ * starts with `BLOCKED (<kind>): <reason>`. The tool-engine joins output+error,
+ * parses it here, and decides whether to auto-block, auto-allow (yolo), or show
+ * the safety-override askcard via deps.askSafetyOverride.
+ */
+/**
+ * Parse a joined tool-result text into a safety block, or null when the text
+ * is not a BLOCKED marker.
+ *
+ * Tolerant of leading whitespace: when bash.execute returns `{error: "BLOCKED
+ * (...)"}` with no `output`, the joined text is the raw marker — but a result
+ * shape that carries an empty-string `output` produces a leading "\n" before
+ * the marker, which an anchored `/^BLOCKED/` would miss and silently drop the
+ * askcard (hard-stop with no prompt). Stripping leading whitespace first makes
+ * the parse robust to both shapes while still requiring the marker at the head
+ * of the (trimmed) text — so a command whose normal output merely mentions
+ * "BLOCKED (...)" mid-stream is not mistaken for a real block.
+ */
+export function parseSafetyBlock(outputText) {
+    if (typeof outputText !== "string")
+        return null;
+    const match = outputText.replace(/^\s+/, "").match(/^BLOCKED \(([^)]+)\):\s*(.*)/);
+    if (!match)
+        return null;
+    return { kind: match[1], reason: match[2] ?? "" };
+}
+/**
+ * Whether a parsed block should be auto-allowed (allow-once) without showing
+ * the askcard, given the active permission mode.
+ *
+ * Policy (confirmed with the user):
+ *   - `yolo` auto-allows lower-severity blocks (`git-safety`, `dangerous`) so
+ *     the "don't ask me" mode actually stops asking for routine guardrails.
+ *   - `catastrophic` ALWAYS shows the askcard, even in yolo — an irreversible
+ *     destroyer (rm -rf /dev, mkfs, sudo …) must never run unattended.
+ *   - `empty-bash` is handled separately (auto-block, no card) and never
+ *     reaches this policy.
+ *   - `safe` / `auto-edit` always show the card for any real block.
+ */
+export function shouldAutoAllowYolo(kind, mode) {
+    if (mode !== "yolo")
+        return false;
+    if (kind === "catastrophic")
+        return false;
+    if (kind === "empty-bash")
+        return false;
+    return true;
+}
+//# sourceMappingURL=safety-intercept.js.map

package/dist/src/orchestrator/scope-reminder.js

@@ -229,7 +229,7 @@ export function buildCheckpointReminder(iteration, hasEECheckpoint) {
  * compared `stripped.length` (a message count, ~tens) against a char-scaled
  * threshold (~156000), so the warning could never fire — session 2b7a10219499.
  */
-export function shouldPreWarnCompaction(promptChars, thresholdChars, ratio = 0.78) {
+export function shouldPreWarnCompaction(promptChars, thresholdChars, ratio = 0.6) {
     if (thresholdChars <= 0 || promptChars <= 0)
         return false;
     return promptChars >= Math.floor(thresholdChars * ratio);

package/dist/src/orchestrator/session-experience.d.ts

@@ -27,6 +27,7 @@ export interface ElisionRecord {
     chars: number;
     /** prepareStep step number at which it was elided. */
     step: number;
+    summary?: string;
 }
 export interface SessionExperience {
     compactions: number;
@@ -40,7 +41,7 @@ export interface SessionExperience {
 /** Record that B3/B4 compaction actually elided something at `step`. */
 export declare function recordCompaction(step: number): void;
 /** Record a single tool output the compactor rewrote into a stub. */
-export declare function recordElision(toolCallId: string, toolName: string, chars: number, step: number): void;
+export declare function recordElision(toolCallId: string, toolName: string, chars: number, step: number, summary?: string): void;
 /**
  * Record an ee_query rehydrate of an elided artifact, tagged by where it came
  * from. `unavailable` means the agent asked for an artifact that was neither in

package/dist/src/orchestrator/session-experience.js

@@ -38,7 +38,7 @@ export function recordCompaction(step) {
     state.lastCompactionStep = Number.isFinite(step) ? step : state.lastCompactionStep;
 }
 /** Record a single tool output the compactor rewrote into a stub. */
-export function recordElision(toolCallId, toolName, chars, step) {
+export function recordElision(toolCallId, toolName, chars, step, summary) {
     if (!toolCallId)
         return;
     state.elisions.push({
@@ -46,6 +46,7 @@ export function recordElision(toolCallId, toolName, chars, step) {
         toolName: toolName || "",
         chars: Number.isFinite(chars) && chars > 0 ? Math.floor(chars) : 0,
         step: Number.isFinite(step) ? step : 0,
+        summary,
     });
     // FIFO trim — keep the most recent MAX_ELISIONS.
     if (state.elisions.length > MAX_ELISIONS) {

package/dist/src/orchestrator/should-run-gate.d.ts

@@ -0,0 +1,5 @@
+export declare function shouldRunGate(pilCtx: {
+    intentKind?: string | null;
+    resumeDigest?: string | null;
+    activeRunId?: string | null;
+}, readPhase: () => string | null): boolean;

package/dist/src/orchestrator/should-run-gate.js

@@ -0,0 +1,18 @@
+// Keep the gate off pure chitchat, but ON for a resumed heavy task the classifier
+// mislabels as chitchat (continuation phrases — preprocessor.ts:118-134). Reading
+// STATE.md phase is the resume signal (execute phase = an active run).
+export function shouldRunGate(pilCtx, readPhase) {
+    if (pilCtx.intentKind !== "chitchat")
+        return true;
+    if (pilCtx.resumeDigest || pilCtx.activeRunId)
+        return true;
+    try {
+        return readPhase() === "execute";
+    }
+    catch (err) {
+        // Missing/corrupt .planning is the normal "no active run" case, not an error — treat as no run.
+        console.error(`[pil-gate] shouldRunGate readPhase failed (treating as no active run): ${err.message}`);
+        return false;
+    }
+}
+//# sourceMappingURL=should-run-gate.js.map

package/dist/src/orchestrator/stall-watchdog.d.ts

@@ -21,13 +21,34 @@
 export interface StallWatchdog {
     /** Combine this into the streamText abortSignal. */
     readonly signal: AbortSignal;
-    /** Call on every received stream chunk to reset the stall timer. */
+    /** Call on every received stream chunk to reset the any-activity stall timer. */
     pet(): void;
-    /** Stop the timer (call when the stream completes or errors). Idempotent. */
+    /**
+     * Call ONLY on real forward-progress chunks (a text-delta or a tool-call) to
+     * reset the no-forward-progress timer. No-op when the watchdog was created
+     * without a progressTimeoutMs. This is what makes the guard catch a reasoning
+     * model stuck in an endless chain-of-thought: `pet()` (called on EVERY chunk,
+     * including reasoning-delta) keeps the any-activity timer alive, but the
+     * progress timer only survives if actual output flows.
+     */
+    petProgress(): void;
+    /** Stop the timers (call when the stream completes or errors). Idempotent. */
     dispose(): void;
     /** True iff the watchdog aborted the stream because of a stall. */
     fired(): boolean;
 }
+/** Options for the second (no-forward-progress) timer of a stall watchdog. */
+export interface StallWatchdogProgressOpts {
+    /**
+     * If > 0, arm a SECOND timer that is reset only by petProgress() (real
+     * output), not by pet() (any chunk). Aborts the same signal when no forward
+     * progress happens for this long — catching runaway reasoning that keeps the
+     * any-activity timer alive with reasoning-delta chunks. <= 0 disables it.
+     */
+    progressTimeoutMs: number;
+    /** Called when the no-forward-progress timer fires (before abort). */
+    onProgressFire?: () => void;
+}
 export declare const STALL_ABORT_REASON = "provider-stall";
 /** User-facing message surfaced when the stall watchdog fires. */
 export declare const STALL_ERROR_MESSAGE: string;
@@ -109,4 +130,4 @@ export declare function shouldContinueAfterMidLoopStall(s: MidLoopStallState): b
  * (1-based): 500 → 1000 → 2000 → 4000 → 4000.
  */
 export declare function stallRepromptBackoffMs(attempt: number): number;
-export declare function createStallWatchdog(timeoutMs: number, onFire?: () => void): StallWatchdog;
+export declare function createStallWatchdog(timeoutMs: number, onFire?: () => void, progressOpts?: StallWatchdogProgressOpts): StallWatchdog;