muonroi-cli 1.4.1 → 1.6.0

package/dist/src/orchestrator/orchestrator.js

@@ -244,6 +244,27 @@ export class Agent {
         this.pendingCalls = options.pendingCalls ?? null;
         this.permissionMode = options.permissionMode ?? "safe";
         ensureDefaultMcpServers();
+        // Pre-warm the always-on MCP servers in the BACKGROUND so they're pooled
+        // before the first user turn. npx stdio servers (filesystem/memory)
+        // cold-start >2.5s and would otherwise miss the first turn's build deadline
+        // (shown as "MCP unavailable: ... still connecting — available next turn").
+        // Empty-message smart-filter keeps only the baseline (drops browser/web
+        // categories) so we don't speculatively spawn playwright/tavily. Fire-and-
+        // forget; the pool handles errors and the per-turn acquire still connects on
+        // demand if this is skipped.
+        void (async () => {
+            try {
+                const [{ warmMcpClients }, { loadMcpServers }, { filterMcpServersByMessage }] = await Promise.all([
+                    import("../mcp/client-pool.js"),
+                    import("../utils/settings.js"),
+                    import("../mcp/smart-filter.js"),
+                ]);
+                warmMcpClients(filterMcpServersByMessage(loadMcpServers(), ""));
+            }
+            catch (err) {
+                console.error(`[orchestrator] MCP pre-warm skipped: ${err?.message}`);
+            }
+        })();
         if (options.persistSession !== false) {
             this.sessionStore = new SessionStore(this.bash.getCwd());
             this.workspace = this.sessionStore.getWorkspace();
@@ -469,6 +490,11 @@ export class Agent {
             this.bash.cleanup(),
             shutdownWorkspaceLspManager(this.bash.getCwd()),
             extractSession(this.messages, this.bash.getCwd(), "cli-exit", this.getSessionId()),
+            // Tear down pooled MCP clients (client-pool.ts). They persist across turns
+            // by design (no per-turn cold-spawn), so the only real teardown is here at
+            // session end. Stdio children would die with the process anyway, but close
+            // them gracefully on a clean exit.
+            import("../mcp/client-pool.js").then((m) => m.closeAllMcpClients()),
         ]);
     }
     // Tool-loop cap handler — set by the UI (app.tsx) at startup. Invoked from

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

@@ -3,6 +3,38 @@ import { type CustomSubagentConfig, type SandboxMode, type SandboxSettings } fro
 export declare const MAX_TOOL_ROUNDS: number;
 export declare const VISION_MODEL = "grok-4-1-fast-reasoning";
 export declare const COMPUTER_MODEL = "grok-4.20-0309-reasoning";
+/**
+ * Phase 5 Fix — Env-aware ENVIRONMENT block.
+ *
+ * Replaces the static rendering-only block with a dynamic block that
+ * tells the model exactly which OS + shell + cwd it's operating in.
+ * Without this the model historically emitted PowerShell cmdlets
+ * (Get-ChildItem, Select-Object, $null), cmd.exe syntax (del, if exist),
+ * or POSIX tools that aren't installed (hyperfine) — all of which fail
+ * silently in the bash tool and waste tokens on retry-cascades.
+ *
+ * Evidence: sessions f9a4cea1bf44, 9c63a38197f3, d0dc4a1f542a,
+ * 77cd2e11c6a5, 1bc27b79223c all logged shell-mismatch errors.
+ *
+ * The block is recomputed on each system-prompt assembly so settings
+ * changes (MUONROI_SHELL override, shell.kind config) are reflected
+ * without a CLI restart.
+ */
+/**
+ * Deterministically detect the project's stack from manifest/lockfile presence
+ * at the workspace root. Pure (no LLM), cheap (one readdir), zero-hardcode (no
+ * model/provider IDs — only ecosystem markers). Returns a compact one-line
+ * summary like "TypeScript · pkg: bun · tests: vitest · vcs: git", or "" when
+ * nothing recognizable is present (greenfield / unreadable dir).
+ *
+ * Motivation (2026-06-14 dogfood): the ENVIRONMENT block told the model its OS,
+ * shell, and cwd but never WHICH project it was in — so the model acted
+ * context-blind, assumed Python, and asked the user to describe the repo it was
+ * already running inside. This gives every model, on every turn, in every mode
+ * (agent/plan/ask) and for every provider (it is NOT in the strippable TOOLS
+ * section), a concrete self-model of the codebase it can act on.
+ */
+export declare function detectProjectStack(cwd: string): string;
 export declare function findCustomSubagent(agent: string, subagents?: CustomSubagentConfig[]): CustomSubagentConfig | undefined;
 export declare function formatCustomSubagentsPromptSection(subagents: CustomSubagentConfig[]): string;
 export interface SystemPromptParts {
@@ -24,6 +56,25 @@ export interface SystemPromptOptions {
      */
     chitchat?: boolean;
 }
+/**
+ * Render the LIVE per-turn MCP tool roster as a system-prompt block.
+ *
+ * The static prompt only states the mcp_<server>__<tool> naming convention; it
+ * never names the tools actually connected this turn, and the per-message smart
+ * filter can drop whole servers. The model therefore receives connected MCP
+ * tools ONLY as raw tool JSON, which it can overlook — live failure
+ * (session f6f7881a5fae): asked to call `setup_guide`, the agent said "I don't
+ * have a direct call_mcp tool" and drove the muonroi-docs server by hand over
+ * bash JSON-RPC, fabricating output. Surfacing the exact callable names in prose
+ * closes that gap.
+ *
+ * `toolNames` should be the keys of the FINAL assembled tool set for the turn
+ * (post smart-filter, post fs-dedup). Returns "" when no MCP tool is connected,
+ * so non-agent / chitchat / no-client-tools turns add nothing. The block is
+ * DYNAMIC (varies per turn) so callers must append it OUTSIDE the cached static
+ * prefix.
+ */
+export declare function buildMcpCapabilityBlock(toolNames: readonly string[]): string;
 export declare function buildSystemPromptParts(cwd: string, mode: AgentMode, sandboxMode: SandboxMode, planContext?: string | null, subagents?: CustomSubagentConfig[], sandboxSettings?: SandboxSettings, providerId?: string, resumeDigest?: string | null, options?: SystemPromptOptions): SystemPromptParts;
 export declare function buildSystemPrompt(cwd: string, mode: AgentMode, sandboxMode: SandboxMode, planContext?: string | null, subagents?: CustomSubagentConfig[], sandboxSettings?: SandboxSettings, providerId?: string, resumeDigest?: string | null, options?: SystemPromptOptions): string;
 export declare function buildSubagentPrompt(request: TaskRequest, cwd: string, custom: CustomSubagentConfig | null, sandboxMode: SandboxMode, subagents?: CustomSubagentConfig[], sandboxSettings?: SandboxSettings, providerId?: string): string;

package/dist/src/orchestrator/prompts.js

@@ -1,3 +1,4 @@
+import * as fs from "node:fs";
 import { getModelInfo } from "../models/registry.js";
 import { buildContractSection } from "../pil/agent-operating-contract.js";
 import { buildNativeCapabilitiesSection } from "../pil/native-capabilities-workbook.js";
@@ -38,6 +39,81 @@ export const COMPUTER_MODEL = "grok-4.20-0309-reasoning";
  * changes (MUONROI_SHELL override, shell.kind config) are reflected
  * without a CLI restart.
  */
+/**
+ * Deterministically detect the project's stack from manifest/lockfile presence
+ * at the workspace root. Pure (no LLM), cheap (one readdir), zero-hardcode (no
+ * model/provider IDs — only ecosystem markers). Returns a compact one-line
+ * summary like "TypeScript · pkg: bun · tests: vitest · vcs: git", or "" when
+ * nothing recognizable is present (greenfield / unreadable dir).
+ *
+ * Motivation (2026-06-14 dogfood): the ENVIRONMENT block told the model its OS,
+ * shell, and cwd but never WHICH project it was in — so the model acted
+ * context-blind, assumed Python, and asked the user to describe the repo it was
+ * already running inside. This gives every model, on every turn, in every mode
+ * (agent/plan/ask) and for every provider (it is NOT in the strippable TOOLS
+ * section), a concrete self-model of the codebase it can act on.
+ */
+export function detectProjectStack(cwd) {
+    let entries;
+    try {
+        entries = fs.readdirSync(cwd);
+    }
+    catch (err) {
+        // Best-effort enrichment: a missing/unreadable cwd simply omits the stack
+        // line (the ENVIRONMENT cwd line already surfaces "<unknown>"). Debug-gated
+        // so prompt assembly never corrupts the TUI at startup.
+        if (process.env.MUONROI_DEBUG === "1") {
+            console.error(`[orchestrator/prompts] detectProjectStack failed for ${cwd}: ${err?.message}`);
+        }
+        return "";
+    }
+    const has = (name) => entries.includes(name);
+    const hasExt = (ext) => entries.some((e) => e.toLowerCase().endsWith(ext));
+    let lang = "";
+    if (has("tsconfig.json"))
+        lang = "TypeScript";
+    else if (has("package.json"))
+        lang = "JavaScript/Node";
+    else if (has("Cargo.toml"))
+        lang = "Rust";
+    else if (has("go.mod"))
+        lang = "Go";
+    else if (has("pyproject.toml") || has("requirements.txt") || has("setup.py"))
+        lang = "Python";
+    else if (hasExt(".csproj") || hasExt(".sln") || has("Directory.Build.props"))
+        lang = ".NET/C#";
+    else if (has("pom.xml"))
+        lang = "Java (Maven)";
+    else if (has("build.gradle") || has("build.gradle.kts"))
+        lang = "Java/Kotlin (Gradle)";
+    let pkg = "";
+    if (has("bun.lockb") || has("bun.lock"))
+        pkg = "bun";
+    else if (has("pnpm-lock.yaml"))
+        pkg = "pnpm";
+    else if (has("yarn.lock"))
+        pkg = "yarn";
+    else if (has("package-lock.json"))
+        pkg = "npm";
+    let tests = "";
+    if (entries.some((e) => /^vitest\.([\w.-]+\.)?config\.(ts|js|mjs|cjs|cts|mts)$/i.test(e)))
+        tests = "vitest";
+    else if (entries.some((e) => /^jest\.config\./i.test(e)))
+        tests = "jest";
+    else if (has("pytest.ini") || has("tox.ini"))
+        tests = "pytest";
+    const vcs = has(".git") ? "git" : "";
+    const segs = [];
+    if (lang)
+        segs.push(lang);
+    if (pkg)
+        segs.push(`pkg: ${pkg}`);
+    if (tests)
+        segs.push(`tests: ${tests}`);
+    if (vcs)
+        segs.push(`vcs: ${vcs}`);
+    return segs.join(" · ");
+}
 function buildEnvironmentBlock() {
     const platform = process.platform;
     const osName = platform === "win32" ? "Windows" : platform === "darwin" ? "macOS" : platform === "linux" ? "Linux" : platform;
@@ -74,11 +150,14 @@ function buildEnvironmentBlock() {
     else if (shell.kind === "cmd") {
         shellRules.push("- The bash tool runs cmd.exe. Use cmd.exe syntax: dir, type, copy, del, if exist, for %%.", "- DO NOT use POSIX commands (grep, sed, awk, ls) or PowerShell cmdlets — they will fail.", "- For complex shell work, ask the user to enable Git Bash or PowerShell via `--shell` / MUONROI_SHELL env.");
     }
+    const projectStack = cwd === "<unknown>" ? "" : detectProjectStack(cwd);
     return [
         "ENVIRONMENT:",
         `- OS: ${osName} (${platform})`,
         `- Shell available via bash tool: ${shellKindLabel} (kind=${shell.kind})`,
         `- Working directory: ${cwd}`,
+        ...(projectStack ? [`- Project stack: ${projectStack}`] : []),
+        "- You are running INSIDE this repository: read and search it with your own tools instead of asking the user to describe its files, structure, or stack. You can act on what you find here directly.",
         "",
         "Terminal rendering:",
         "- Your text output is rendered in a plain terminal — not a browser, not a rich text editor.",
@@ -95,138 +174,138 @@ function buildEnvironmentBlock() {
 }
 const ENVIRONMENT = buildEnvironmentBlock();
 const MODE_PROMPTS = {
-    agent: `You are muonroi-cli in Agent mode — a powerful AI coding agent. You execute tasks directly using tools.
-
-${ENVIRONMENT}
-
-TOOLS:
-- read_file: Read file contents with start_line/end_line for iterative reading. Use for examining code.
-- grep: Fast regex content search across the codebase. Prefer this over bash for finding patterns in files. Supports full regex syntax and file filtering with the include parameter.
-- lsp: Experimental semantic code intelligence for definitions, references, hover, symbols, implementations, and call hierarchy when a matching language server is available.
-- write_file: Create new files or overwrite existing ones with full content.
-- edit_file: Replace a unique string in a file with new content. The old_string must be unique — include enough context lines.
-- bash: Execute shell commands. Set background=true for long-running processes (dev servers, watchers, builds). Returns a process ID immediately.
-- process_logs: View recent output from a background process by ID.
-- process_stop: Stop a background process by ID.
-- process_list: List all background processes with status and uptime.
-- wallet_info: Check the local wallet address, chain, and current ETH/USDC balances.
-- wallet_history: Show recent x402 payment history from the audit log.
-- fetch_payment_info: Inspect a URL for x402 payment requirements without paying. Returns payment options and a brin security score. Use only when the user wants to inspect — for actual access, use paid_request directly.
-- paid_request: Access an x402-protected URL using the local wallet. Includes a brin security scan — URLs scoring below 25 are automatically blocked. The user will be prompted to approve the payment before it executes. Prefer this over fetch_payment_info when the user wants to access the resource.
-- task: Delegate a focused foreground task to a sub-agent. Use general for multi-step execution, explore for fast read-only research, verify for sandbox-aware validation, computer for host desktop screenshot/input workflows, or a configured custom sub-agent name when listed under CUSTOM SUB-AGENTS.
-- delegate: Launch a read-only background agent for longer research while you continue working.
-- delegation_read: Retrieve a completed background delegation result by ID.
-- delegation_list: List running and completed background delegations. Do not poll it repeatedly.
-- schedule_create: Create a recurring or one-time scheduled headless run.
-- schedule_list: List saved schedules and their status.
-- schedule_remove: Remove a saved schedule.
-- schedule_read_log: Read recent log output from a schedule.
-- schedule_daemon_status: Check whether the schedule daemon is running.
-- schedule_daemon_start: Start the schedule daemon in the background.
-- schedule_daemon_stop: Stop the schedule daemon.
-- search_web: Search the web for current information, documentation, APIs, tutorials, etc.
-- search_x: Search X/Twitter for real-time posts, discussions, opinions, and trends.
-- generate_image: Generate a new image or edit an existing image. It saves image files locally and returns their paths.
-- generate_video: Generate a new video or animate an existing image. It saves video files locally and returns their paths.
-- computer_snapshot: Capture an accessibility-tree snapshot with stable refs like @e1 for desktop interaction.
-- computer_screenshot: Capture a host desktop screenshot for visual confirmation or fallback inspection.
-- computer_click: Click a desktop element by ref, or coordinates as a fallback.
-- computer_mouse_move: Hover a desktop element by ref, or coordinates as a fallback.
-- computer_type: Type text into a specific desktop element ref.
-- computer_press: Press a key or key chord in the focused host application.
-- computer_scroll: Scroll a desktop element by ref.
-- computer_launch: Launch an application and wait for its window to appear.
-- computer_list_windows: List visible windows and their ids.
-- computer_focus_window: Bring a target window to the front.
-- computer_wait: Wait for time, elements, windows, or text during desktop workflows.
-- computer_get: Read a property from a desktop element ref.
-- MCP tools: Enabled servers appear as tools named like mcp_<server>__<tool>.
-
-WORKFLOW:
-1. Understand the request
-2. Decide whether a sub-agent should handle the first investigation pass
-3. Use read_file, grep, lsp, and bash to explore the codebase directly when the task is small or tightly scoped
-4. Use bash with background=true for dev servers, watchers, or any long-running process — then continue working
-5. Use delegate for read-only work that can run in parallel, then continue productive work
-6. Use edit_file for targeted changes, write_file for new files or full rewrites
-7. Verify changes by reading modified files
-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.
-
-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
-- "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
-- "generate a logo" -> use generate_image
-- "animate this still image" -> use generate_video
-- Recurring specialized workflows -> use the matching custom sub-agent via task
-- "every weekday at 9am run this check" -> use schedule_create with a cron expression
-- "run this once automatically" -> use schedule_create with the right timing
-- "make sure scheduled jobs keep running" -> use schedule_daemon_status and schedule_daemon_start
-
-IMPORTANT:
-- Prefer edit_file for surgical changes to existing files — it shows a clean diff.
-- Prefer grep over bash for searching file contents. Use bash only for find, ls, git, and other shell commands.
-- Prefer lsp over text search when you need exact definitions, references, implementations, or call hierarchy and a server is available.
-- 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.
-- After creating a recurring schedule, check the daemon status and start it with \`schedule_daemon_start\` if needed.
-
+    agent: `You are muonroi-cli in Agent mode — a powerful AI coding agent. You execute tasks directly using tools.
+
+${ENVIRONMENT}
+
+TOOLS:
+- read_file: Read file contents with start_line/end_line for iterative reading. Use for examining code.
+- grep: Fast regex content search across the codebase. Prefer this over bash for finding patterns in files. Supports full regex syntax and file filtering with the include parameter.
+- lsp: Experimental semantic code intelligence for definitions, references, hover, symbols, implementations, and call hierarchy when a matching language server is available.
+- write_file: Create new files or overwrite existing ones with full content.
+- edit_file: Replace a unique string in a file with new content. The old_string must be unique — include enough context lines.
+- bash: Execute shell commands. Set background=true for long-running processes (dev servers, watchers, builds). Returns a process ID immediately.
+- process_logs: View recent output from a background process by ID.
+- process_stop: Stop a background process by ID.
+- process_list: List all background processes with status and uptime.
+- wallet_info: Check the local wallet address, chain, and current ETH/USDC balances.
+- wallet_history: Show recent x402 payment history from the audit log.
+- fetch_payment_info: Inspect a URL for x402 payment requirements without paying. Returns payment options and a brin security score. Use only when the user wants to inspect — for actual access, use paid_request directly.
+- paid_request: Access an x402-protected URL using the local wallet. Includes a brin security scan — URLs scoring below 25 are automatically blocked. The user will be prompted to approve the payment before it executes. Prefer this over fetch_payment_info when the user wants to access the resource.
+- task: Delegate a focused foreground task to a sub-agent. Use general for multi-step execution, explore for fast read-only research, verify for sandbox-aware validation, computer for host desktop screenshot/input workflows, or a configured custom sub-agent name when listed under CUSTOM SUB-AGENTS.
+- delegate: Launch a read-only background agent for longer research while you continue working.
+- delegation_read: Retrieve a completed background delegation result by ID.
+- delegation_list: List running and completed background delegations. Do not poll it repeatedly.
+- schedule_create: Create a recurring or one-time scheduled headless run.
+- schedule_list: List saved schedules and their status.
+- schedule_remove: Remove a saved schedule.
+- schedule_read_log: Read recent log output from a schedule.
+- schedule_daemon_status: Check whether the schedule daemon is running.
+- schedule_daemon_start: Start the schedule daemon in the background.
+- schedule_daemon_stop: Stop the schedule daemon.
+- search_web: Search the web for current information, documentation, APIs, tutorials, etc.
+- search_x: Search X/Twitter for real-time posts, discussions, opinions, and trends.
+- generate_image: Generate a new image or edit an existing image. It saves image files locally and returns their paths.
+- generate_video: Generate a new video or animate an existing image. It saves video files locally and returns their paths.
+- computer_snapshot: Capture an accessibility-tree snapshot with stable refs like @e1 for desktop interaction.
+- computer_screenshot: Capture a host desktop screenshot for visual confirmation or fallback inspection.
+- computer_click: Click a desktop element by ref, or coordinates as a fallback.
+- computer_mouse_move: Hover a desktop element by ref, or coordinates as a fallback.
+- computer_type: Type text into a specific desktop element ref.
+- computer_press: Press a key or key chord in the focused host application.
+- computer_scroll: Scroll a desktop element by ref.
+- computer_launch: Launch an application and wait for its window to appear.
+- computer_list_windows: List visible windows and their ids.
+- computer_focus_window: Bring a target window to the front.
+- computer_wait: Wait for time, elements, windows, or text during desktop workflows.
+- computer_get: Read a property from a desktop element ref.
+- MCP tools: connected servers appear as first-class tools named mcp_<server>__<tool>. The exact tools available THIS turn are listed under "CONNECTED MCP TOOLS" near the end of this prompt — call them directly by that name; never shell out to bash/JSON-RPC to reach an MCP server.
+
+WORKFLOW:
+1. Understand the request
+2. Decide whether a sub-agent should handle the first investigation pass
+3. Use read_file, grep, lsp, and bash to explore the codebase directly when the task is small or tightly scoped
+4. Use bash with background=true for dev servers, watchers, or any long-running process — then continue working
+5. Use delegate for read-only work that can run in parallel, then continue productive work
+6. Use edit_file for targeted changes, write_file for new files or full rewrites
+7. Verify changes by reading modified files
+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.
+
+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
+- "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
+- "generate a logo" -> use generate_image
+- "animate this still image" -> use generate_video
+- Recurring specialized workflows -> use the matching custom sub-agent via task
+- "every weekday at 9am run this check" -> use schedule_create with a cron expression
+- "run this once automatically" -> use schedule_create with the right timing
+- "make sure scheduled jobs keep running" -> use schedule_daemon_status and schedule_daemon_start
+
+IMPORTANT:
+- Prefer edit_file for surgical changes to existing files — it shows a clean diff.
+- Prefer grep over bash for searching file contents. Use bash only for find, ls, git, and other shell commands.
+- Prefer lsp over text search when you need exact definitions, references, implementations, or call hierarchy and a server is available.
+- 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.
+- After creating a recurring schedule, check the daemon status and start it with \`schedule_daemon_start\` if needed.
+
 Be direct. Execute, don't just describe. Show results, not plans.`,
-    plan: `You are muonroi-cli in Plan mode — you analyze and plan but DO NOT execute changes.
-
-${ENVIRONMENT}
-
-TOOLS:
-- read_file: Read file contents for analysis.
-- grep: Fast regex content search across the codebase. Prefer this over bash for finding patterns in files.
-- lsp: Experimental semantic code intelligence for read-only planning and research.
-- bash: ONLY for searching (find, ls), git inspection — NEVER modify files.
-- task: Delegate a focused task to a sub-agent when deeper research or specialized analysis would help.
-- generate_plan: ALWAYS use this to present your plan. Creates an interactive UI with steps and questions.
-
-BEHAVIOR:
-- Explore the codebase first using read_file, grep, and bash to understand the current state
-- Prefer lsp for exact symbol navigation when a matching server is available
-- ALWAYS call generate_plan to present your plan — never just describe it in text
-- Include clear, ordered steps with affected file paths
-- Include questions when you need user input on approach, trade-offs, or preferences
-- Use "select" questions for single-choice decisions, "multiselect" for picking multiple options, and "text" for free-form input
-- Highlight potential risks, edge cases, and dependencies in the plan summary
+    plan: `You are muonroi-cli in Plan mode — you analyze and plan but DO NOT execute changes.
+
+${ENVIRONMENT}
+
+TOOLS:
+- read_file: Read file contents for analysis.
+- grep: Fast regex content search across the codebase. Prefer this over bash for finding patterns in files.
+- lsp: Experimental semantic code intelligence for read-only planning and research.
+- bash: ONLY for searching (find, ls), git inspection — NEVER modify files.
+- task: Delegate a focused task to a sub-agent when deeper research or specialized analysis would help.
+- generate_plan: ALWAYS use this to present your plan. Creates an interactive UI with steps and questions.
+
+BEHAVIOR:
+- Explore the codebase first using read_file, grep, and bash to understand the current state
+- Prefer lsp for exact symbol navigation when a matching server is available
+- ALWAYS call generate_plan to present your plan — never just describe it in text
+- Include clear, ordered steps with affected file paths
+- Include questions when you need user input on approach, trade-offs, or preferences
+- Use "select" questions for single-choice decisions, "multiselect" for picking multiple options, and "text" for free-form input
+- Highlight potential risks, edge cases, and dependencies in the plan summary
 - NEVER create, modify, or delete files — only read and analyze`,
-    ask: `You are muonroi-cli in Ask mode — you answer questions clearly and thoroughly.
-
-${ENVIRONMENT}
-
-TOOLS:
-- read_file: Read file contents for context.
-- grep: Fast regex content search across the codebase. Prefer this over bash for finding patterns in files.
-- lsp: Experimental semantic code intelligence for definitions, references, hover, and symbols.
-- bash: ONLY for searching (find, ls), git inspection — NEVER modify.
-- task: Delegate a focused task to a sub-agent when specialized analysis or deeper investigation would help.
-
-BEHAVIOR:
-- Answer the user's question directly and thoroughly
-- Use tools to gather context when needed, preferring lsp for exact symbol questions when available
-- Provide code examples when helpful
-- NEVER create, modify, or delete files
+    ask: `You are muonroi-cli in Ask mode — you answer questions clearly and thoroughly.
+
+${ENVIRONMENT}
+
+TOOLS:
+- read_file: Read file contents for context.
+- grep: Fast regex content search across the codebase. Prefer this over bash for finding patterns in files.
+- lsp: Experimental semantic code intelligence for definitions, references, hover, and symbols.
+- bash: ONLY for searching (find, ls), git inspection — NEVER modify.
+- task: Delegate a focused task to a sub-agent when specialized analysis or deeper investigation would help.
+
+BEHAVIOR:
+- Answer the user's question directly and thoroughly
+- Use tools to gather context when needed, preferring lsp for exact symbol questions when available
+- Provide code examples when helpful
+- NEVER create, modify, or delete files
 - Focus on explanation, not execution`,
 };
 export function findCustomSubagent(agent, subagents = loadValidSubAgents()) {
@@ -242,10 +321,10 @@ export function formatCustomSubagentsPromptSection(subagents) {
     });
     return `\n\nCUSTOM SUB-AGENTS:\nUser-defined foreground sub-agents from ~/.muonroi-cli/user-settings.json. When one matches the task, call the task tool with agent set to the exact name.\n\n${lines.join("\n\n")}\n`;
 }
-const NON_ANTHROPIC_TOOL_PREAMBLE = `\n\nIMPORTANT — TOOL CALLING:
-You MUST invoke tools ONLY via the structured function calling API provided to you.
-NEVER output XML tags like <tool_name>, <bash>, <read_file>, or <delegate> as text.
-If you want to call a tool, use the function calling mechanism — do NOT write tool invocations as text in your response.
+const NON_ANTHROPIC_TOOL_PREAMBLE = `\n\nIMPORTANT — TOOL CALLING:
+You MUST invoke tools ONLY via the structured function calling API provided to you.
+NEVER output XML tags like <tool_name>, <bash>, <read_file>, or <delegate> as text.
+If you want to call a tool, use the function calling mechanism — do NOT write tool invocations as text in your response.
 Any XML-like tool invocation in your text output will be ignored by the system.\n`;
 /**
  * Strip the TOOLS: listing section from system prompt.
@@ -255,6 +334,50 @@ Any XML-like tool invocation in your text output will be ignored by the system.\
 export function stripToolsSection(text) {
     return text.replace(/\nTOOLS:\n[\s\S]*?\n(?=WORKFLOW:|BEHAVIOR:|IMPORTANT:|DEFAULT DELEGATION|EXAMPLES:|$)/g, "\n");
 }
+/**
+ * Render the LIVE per-turn MCP tool roster as a system-prompt block.
+ *
+ * The static prompt only states the mcp_<server>__<tool> naming convention; it
+ * never names the tools actually connected this turn, and the per-message smart
+ * filter can drop whole servers. The model therefore receives connected MCP
+ * tools ONLY as raw tool JSON, which it can overlook — live failure
+ * (session f6f7881a5fae): asked to call `setup_guide`, the agent said "I don't
+ * have a direct call_mcp tool" and drove the muonroi-docs server by hand over
+ * bash JSON-RPC, fabricating output. Surfacing the exact callable names in prose
+ * closes that gap.
+ *
+ * `toolNames` should be the keys of the FINAL assembled tool set for the turn
+ * (post smart-filter, post fs-dedup). Returns "" when no MCP tool is connected,
+ * so non-agent / chitchat / no-client-tools turns add nothing. The block is
+ * DYNAMIC (varies per turn) so callers must append it OUTSIDE the cached static
+ * prefix.
+ */
+export function buildMcpCapabilityBlock(toolNames) {
+    const byServer = new Map();
+    for (const name of toolNames) {
+        if (!name.startsWith("mcp_"))
+            continue;
+        // mcp_<sanitized-server-id>__<tool>; split on the FIRST "__" (server ids
+        // rarely contain "__" — they are sanitized from real ids like "muonroi-docs").
+        const m = name.match(/^mcp_(.+?)__(.+)$/);
+        if (!m)
+            continue;
+        const server = m[1];
+        const list = byServer.get(server) ?? [];
+        list.push(name);
+        byServer.set(server, list);
+    }
+    if (byServer.size === 0)
+        return "";
+    const lines = [];
+    for (const [server, tools] of byServer) {
+        lines.push(`  • ${server}: ${tools.sort().join(", ")}`);
+    }
+    return ("\n\nCONNECTED MCP TOOLS (this turn) — these are available to you RIGHT NOW as " +
+        "first-class tools. Call them directly by their exact name; do NOT shell out " +
+        "to bash or hand-write JSON-RPC to reach an MCP server:\n" +
+        lines.join("\n"));
+}
 export function buildSystemPromptParts(cwd, mode, sandboxMode, planContext, subagents, sandboxSettings, providerId, resumeDigest, options) {
     const chitchat = options?.chitchat === true;
     const custom = loadCustomInstructions(cwd);

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

@@ -46,7 +46,12 @@ const KNOWN_TASK_TYPES = new Set(Object.keys(CEILING_MATRIX));
  * graceful when PIL emits an out-of-band label or null.
  */
 export function resolveCeiling(taskType, size) {
-    const row = taskType && KNOWN_TASK_TYPES.has(taskType) ? taskType : "general";
+    // `build` (greenfield creation, PIL Pass-0) is not a row in the LOCKED matrix.
+    // It is the highest-effort task — scaffolding many files — so it borrows the
+    // `generate` ceiling (10/18/30) rather than falling back to the tight `general`
+    // row (5/10/20), which would force-finalize a greenfield build far too early.
+    const normalized = taskType === "build" ? "generate" : taskType;
+    const row = normalized && KNOWN_TASK_TYPES.has(normalized) ? normalized : "general";
     return CEILING_MATRIX[row][size];
 }
 /**

package/dist/src/orchestrator/scope-reminder.d.ts

@@ -100,3 +100,15 @@ export declare function attachReminderToMessages<T>(messages: ReadonlyArray<T>,
  * Used by prepareStep / sub-agent paths after compaction.
  */
 export declare function buildCheckpointReminder(iteration: number, hasEECheckpoint: boolean): string;
+/**
+ * Pre-compaction "advance warning" gate. Fires when the prompt is approaching
+ * (default ≥78% of) the compaction threshold but compaction has NOT yet run this
+ * step — giving the agent one step to PRESERVE / finish before B3/B4 rewrites
+ * older tool results into stubs.
+ *
+ * `promptChars` MUST be the same quantity the compactor thresholds on (cumulative
+ * message chars + envelope chars), NOT the message COUNT. The original B4 wiring
+ * compared `stripped.length` (a message count, ~tens) against a char-scaled
+ * threshold (~156000), so the warning could never fire — session 2b7a10219499.
+ */
+export declare function shouldPreWarnCompaction(promptChars: number, thresholdChars: number, ratio?: number): boolean;

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

@@ -218,4 +218,20 @@ export function buildCheckpointReminder(iteration, hasEECheckpoint) {
         return base;
     return base.slice(0, 220);
 }
+/**
+ * Pre-compaction "advance warning" gate. Fires when the prompt is approaching
+ * (default ≥78% of) the compaction threshold but compaction has NOT yet run this
+ * step — giving the agent one step to PRESERVE / finish before B3/B4 rewrites
+ * older tool results into stubs.
+ *
+ * `promptChars` MUST be the same quantity the compactor thresholds on (cumulative
+ * message chars + envelope chars), NOT the message COUNT. The original B4 wiring
+ * 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) {
+    if (thresholdChars <= 0 || promptChars <= 0)
+        return false;
+    return promptChars >= Math.floor(thresholdChars * ratio);
+}
 //# sourceMappingURL=scope-reminder.js.map

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

@@ -13,7 +13,7 @@
  *   - Reminder lives in tool_result/system message — never in system prompt
  */
 import { afterEach, beforeEach, describe, expect, it } from "vitest";
-import { attachReminderToMessages, buildScopeReminder, cadenceForSize, shouldInjectCeilingCrossing, shouldInjectReminder, shouldInjectSoftWarn, } from "./scope-reminder.js";
+import { attachReminderToMessages, buildScopeReminder, cadenceForSize, shouldInjectCeilingCrossing, shouldInjectReminder, shouldInjectSoftWarn, shouldPreWarnCompaction, } from "./scope-reminder.js";
 describe("cadenceForSize", () => {
     it("locks 3/5/8 for small/medium/large with hard floor >= 3", () => {
         expect(cadenceForSize("small")).toBe(3);
@@ -201,4 +201,25 @@ describe("attachReminderToMessages", () => {
         expect(out).toEqual(messages);
     });
 });
+describe("shouldPreWarnCompaction (regression: session 2b7a10219499 dead pre-warning)", () => {
+    const THRESHOLD = 200_000; // MUONROI_TOP_LEVEL_COMPACT_THRESHOLD_CHARS default
+    it("fires when prompt chars reach >=78% of the threshold (approaching compaction)", () => {
+        expect(shouldPreWarnCompaction(Math.floor(THRESHOLD * 0.78), THRESHOLD)).toBe(true);
+        expect(shouldPreWarnCompaction(190_000, THRESHOLD)).toBe(true);
+    });
+    it("does NOT fire while comfortably below the threshold", () => {
+        expect(shouldPreWarnCompaction(100_000, THRESHOLD)).toBe(false);
+        expect(shouldPreWarnCompaction(0, THRESHOLD)).toBe(false);
+    });
+    it("guards against the original bug: a message COUNT can never trip a char threshold", () => {
+        // The dead wiring compared stripped.length (a message count, ~tens) to the
+        // char-scaled threshold. With chars it crosses; with a count it never does.
+        const messageCount = 60; // plausible long-session message count
+        expect(shouldPreWarnCompaction(messageCount, THRESHOLD)).toBe(false);
+        expect(shouldPreWarnCompaction(170_000, THRESHOLD)).toBe(true);
+    });
+    it("is inert for a zero/negative threshold (no compaction configured)", () => {
+        expect(shouldPreWarnCompaction(999_999, 0)).toBe(false);
+    });
+});
 //# sourceMappingURL=scope-reminder.test.js.map