reasonix 0.4.17 → 0.4.19

package/dist/cli/{prompt-HK5XLH55.js → prompt-JNNNJLYF.js}

@@ -2,9 +2,9 @@
 import {
   CODE_SYSTEM_PROMPT,
   codeSystemPrompt
-} from "./chunk-3YQRWFES.js";
+} from "./chunk-HNEWBEWZ.js";
 export {
   CODE_SYSTEM_PROMPT,
   codeSystemPrompt
 };
-//# sourceMappingURL=prompt-HK5XLH55.js.map
+//# sourceMappingURL=prompt-JNNNJLYF.js.map

package/dist/index.d.ts

@@ -1,3 +1,4 @@
+import { SpawnOptions } from 'node:child_process';
 import { WriteStream } from 'node:fs';
 
 /**
@@ -392,6 +393,14 @@ declare class ToolCallRepair {
     private readonly storm;
     private readonly opts;
     constructor(opts: ToolCallRepairOptions);
+    /**
+     * Drop the StormBreaker's sliding window of recent (name, args)
+     * signatures. Called at the start of every user turn — a fresh user
+     * message is a new intent, so carrying old repetition state into it
+     * would turn a valid "try again with different input" flow into a
+     * false-positive block.
+     */
+    resetStorm(): void;
     process(declaredCalls: ToolCall[], reasoningContent: string | null, content?: string | null): {
         calls: ToolCall[];
         report: RepairReport;
@@ -462,6 +471,25 @@ interface ToolDefinition<A = any, R = any> {
     name: string;
     description?: string;
     parameters?: JSONSchema;
+    /**
+     * Marks a tool as read-only: safe to invoke during plan mode. `true`
+     * for tools that only observe (read_file, list_directory, search, web
+     * fetch/search). Leave undefined / `false` for anything that can write,
+     * execute, or mutate state.
+     *
+     * The registry enforces this at dispatch: non-readonly tools called
+     * while `planMode` is on return a refusal string the model can
+     * learn from, instead of actually running.
+     */
+    readOnly?: boolean;
+    /**
+     * Dynamic read-only check for tools whose safety depends on arguments
+     * — `run_command` with an allowlisted argv is safe, `run_command
+     * rm -rf` isn't. Called with the parsed arguments; `true` means "treat
+     * as read-only for plan mode". Takes precedence over `readOnly` when
+     * both are set.
+     */
+    readOnlyCheck?: (args: A) => boolean;
     fn: (args: A, ctx?: ToolCallContext) => R | Promise<R>;
 }
 interface ToolRegistryOptions {
@@ -475,7 +503,19 @@ interface ToolRegistryOptions {
 declare class ToolRegistry {
     private readonly _tools;
     private readonly _autoFlatten;
+    /**
+     * When true, `dispatch` refuses any tool whose `readOnly` flag isn't
+     * set (and whose `readOnlyCheck` doesn't pass on the specific args).
+     * Drives `reasonix code`'s Plan Mode — the model can still explore
+     * via read tools but its writes and non-allowlisted shell calls are
+     * bounced until the user approves a submitted plan.
+     */
+    private _planMode;
     constructor(opts?: ToolRegistryOptions);
+    /** Enable / disable plan-mode enforcement at dispatch. */
+    setPlanMode(on: boolean): void;
+    /** True when the registry is currently refusing non-readonly calls. */
+    get planMode(): boolean;
     register<A, R>(def: ToolDefinition<A, R>): this;
     has(name: string): boolean;
     get(name: string): ToolDefinition | undefined;
@@ -817,6 +857,65 @@ interface FilesystemToolsOptions {
 }
 declare function registerFilesystemTools(registry: ToolRegistry, opts: FilesystemToolsOptions): ToolRegistry;
 
+/**
+ * Plan Mode — read-only exploration phase for `reasonix code`.
+ *
+ * Shape (mirrors claude-code's plan/act split, adapted for Reasonix):
+ *
+ *   1. User types `/plan` → registry switches to plan-mode enforcement
+ *      (write tools refused at dispatch; reads + allowlisted shell
+ *      still work).
+ *   2. Model explores, then calls `submit_plan` with a markdown plan.
+ *   3. `submit_plan` throws `PlanProposedError`, which the TUI renders
+ *      as a picker: Approve / Refine / Cancel.
+ *   4. Approve → registry leaves plan mode, a synthetic user message
+ *      "The plan has been approved. Implement it now." is pushed into
+ *      the loop so the next turn executes.
+ *
+ * The read-only enforcement lives in `ToolRegistry.dispatch` via
+ * `readOnly` / `readOnlyCheck`; this file only ships the `submit_plan`
+ * escape hatch and the error type that carries the plan out of the
+ * registry without stuffing it into the message.
+ *
+ * We do not change `ImmutablePrefix.toolSpecs` when plan mode toggles —
+ * that would break Pillar 1's prefix cache. Instead the same full spec
+ * list stays pinned, and the registry enforces mode at dispatch time.
+ * The refusal string teaches the model the rule; cache hits stay
+ * intact.
+ */
+
+/**
+ * Thrown by `submit_plan` when plan mode is active, carrying the plan
+ * text the TUI will render for the user's approval.
+ *
+ * Implements the `toToolResult` protocol so `ToolRegistry.dispatch`
+ * serializes the full plan into the tool-result JSON (not just the
+ * error message). The TUI parses `{ error, plan }` from the tool event
+ * and mounts the `PlanConfirm` picker.
+ */
+declare class PlanProposedError extends Error {
+    readonly plan: string;
+    constructor(plan: string);
+    /**
+     * Structured tool-result shape. Consumed by the TUI to extract the
+     * plan without regex-scraping the error message.
+     */
+    toToolResult(): {
+        error: string;
+        plan: string;
+    };
+}
+interface PlanToolOptions {
+    /**
+     * Optional side-channel callback fired when the model submits a plan.
+     * The TUI uses this to preview the plan in real time (the tool-result
+     * event is also emitted; this is just earlier and friendlier to
+     * test harnesses that don't want to parse JSON).
+     */
+    onPlanSubmitted?: (plan: string) => void;
+}
+declare function registerPlanTool(registry: ToolRegistry, opts?: PlanToolOptions): ToolRegistry;
+
 /**
  * Native shell tool — lets the model run commands inside the sandbox
  * root so it can actually verify its own work (run tests, check git
@@ -894,6 +993,64 @@ declare function runCommand(cmd: string, opts: {
     maxOutputChars?: number;
     signal?: AbortSignal;
 }): Promise<RunCommandResult>;
+/**
+ * Test/override hooks for {@link resolveExecutable}. Omitting any field
+ * falls through to the real process globals — the runtime call path
+ * uses defaults; tests inject `platform` + `env` + `isFile` to exercise
+ * Windows-specific lookup from a Linux CI runner without touching
+ * actual fs.
+ */
+interface ResolveExecutableOptions {
+    platform?: NodeJS.Platform;
+    env?: {
+        PATH?: string;
+        PATHEXT?: string;
+    };
+    /** Predicate swapped in by tests to avoid creating real files. */
+    isFile?: (path: string) => boolean;
+    /** Path.join used for the lookup. Defaults to Windows semantics on Windows. */
+    pathDelimiter?: string;
+}
+/**
+ * Resolve a bare command name (e.g. `npm`) to its on-disk path via
+ * PATH × PATHEXT on Windows. Returns the input unchanged on non-Windows
+ * platforms, when the input is already a path (contains `/`, `\`, or is
+ * absolute), or when no match is found in PATH × PATHEXT (caller gets a
+ * natural ENOENT from spawn, which surfaces cleanly).
+ *
+ * Why this exists: `child_process.spawn` with `shell: false` invokes
+ * Windows `CreateProcess`, which does not honor `PATHEXT` and does not
+ * search for `.cmd` / `.bat` wrappers. Node-ecosystem tools ship as
+ * `npm.cmd`, `npx.cmd`, `yarn.cmd`, etc., so a bare `npm` fails with
+ * ENOENT under `shell: false`. Flipping to `shell: true` would work
+ * but reintroduces shell-expansion (pipes, redirects, chained cmds)
+ * that the tool was explicitly designed to forbid. This resolver
+ * threads the needle.
+ */
+declare function resolveExecutable(cmd: string, opts?: ResolveExecutableOptions): string;
+/**
+ * Prepare `(bin, args, spawnOpts)` for the runCommand spawn call,
+ * applying Windows-specific workarounds for (a) PATHEXT lookup and
+ * (b) the CVE-2024-27980 prohibition on direct `.cmd`/`.bat` spawns.
+ *
+ * Exported so tests can assert the transformation without booting an
+ * actual child process.
+ */
+declare function prepareSpawn(argv: readonly string[], opts?: ResolveExecutableOptions): {
+    bin: string;
+    args: string[];
+    spawnOverrides: SpawnOptions;
+};
+/**
+ * Quote an argument so cmd.exe parses it back as a single token. We
+ * always wrap in double quotes when the arg contains whitespace or
+ * any cmd.exe metacharacter, doubling embedded quotes per cmd.exe's
+ * `""` escape rule. Bare alphanumeric args pass through unquoted for
+ * readability in logs.
+ *
+ * Exported for test coverage of the quoting semantics.
+ */
+declare function quoteForCmdExe(arg: string): string;
 /** Error thrown by `run_command` when the command isn't allowlisted. */
 declare class NeedsConfirmationError extends Error {
     readonly command: string;
@@ -1927,7 +2084,7 @@ declare function restoreSnapshots(snapshots: EditSnapshot[], rootDir: string): A
  * the Cache-First Loop is trying to conserve. The SEARCH/REPLACE spec
  * is the one unavoidable bloat; we trim everything else.
  */
-declare const CODE_SYSTEM_PROMPT = "You are Reasonix Code, a coding assistant. You have filesystem tools (read_file, write_file, list_directory, search_files, etc.) rooted at the user's working directory.\n\n# When to edit vs. when to explore\n\nOnly propose edits when the user explicitly asks you to change, fix, add, remove, refactor, or write something. Do NOT propose edits when the user asks you to:\n- analyze, read, explore, describe, or summarize a project\n- explain how something works\n- answer a question about the code\n\nIn those cases, use tools to gather what you need, then reply in prose. No SEARCH/REPLACE blocks, no file changes. If you're unsure what the user wants, ask.\n\nWhen you do propose edits, the user will review them and decide whether to `/apply` or `/discard`. Don't assume they'll accept \u2014 write as if each edit will be audited, because it will.\n\n# Editing files\n\nWhen you've been asked to change a file, output one or more SEARCH/REPLACE blocks in this exact format:\n\npath/to/file.ext\n<<<<<<< SEARCH\nexact existing lines from the file, including whitespace\n=======\nthe new lines\n>>>>>>> REPLACE\n\nRules:\n- Always read_file first so your SEARCH matches byte-for-byte. If it doesn't match, the edit is rejected and you'll have to retry with the exact current content.\n- One edit per block. Multiple blocks in one response are fine.\n- To create a new file, leave SEARCH empty:\n    path/to/new.ts\n    <<<<<<< SEARCH\n    =======\n    (whole file content here)\n    >>>>>>> REPLACE\n- Do NOT use write_file to change existing files \u2014 the user reviews your edits as SEARCH/REPLACE. write_file is only for files you explicitly want to overwrite wholesale (rare).\n- Paths are relative to the working directory. Don't use absolute paths.\n\n# Exploration\n\n- Avoid listing or reading inside these common dependency / build directories unless the user explicitly asks about them: node_modules, dist, build, out, .next, .nuxt, .svelte-kit, .git, .venv, venv, __pycache__, target, coverage, .turbo, .cache. They're expensive and usually irrelevant.\n- Prefer search_files / grep over list_directory when you know roughly what you're looking for \u2014 it saves context and avoids enumerating huge trees.\n\n# Style\n\n- Show edits; don't narrate them in prose. \"Here's the fix:\" is enough.\n- One short paragraph explaining *why*, then the blocks.\n- If you need to explore first (list / grep / read), do it with tool calls before writing any prose \u2014 silence while exploring is fine.\n";
+declare const CODE_SYSTEM_PROMPT = "You are Reasonix Code, a coding assistant. You have filesystem tools (read_file, write_file, list_directory, search_files, etc.) rooted at the user's working directory.\n\n# When to propose a plan (submit_plan)\n\nYou have a `submit_plan` tool that shows the user a markdown plan and lets them Approve / Refine / Cancel before you execute. Use it proactively when the task is large enough to deserve a review gate:\n\n- Multi-file refactors or renames.\n- Architecture changes (moving modules, splitting / merging files, new abstractions).\n- Anything where \"undo\" after the fact would be expensive \u2014 migrations, destructive cleanups, API shape changes.\n- When the user's request is ambiguous and multiple reasonable interpretations exist \u2014 propose your reading as a plan and let them confirm.\n\nSkip submit_plan for small, obvious changes: one-line typo, clear bug with a clear fix, adding a missing import, renaming a local variable. Just do those.\n\nPlan body: one-sentence summary, then a file-by-file breakdown of what you'll change and why, and any risks or open questions. If some decisions are genuinely up to the user (naming, tradeoffs, out-of-scope possibilities), list them in an \"Open questions\" or \"\u5F85\u786E\u8BA4\" section \u2014 the user sees the plan in a picker and has a text input to answer your questions before approving. Don't pretend certainty you don't have; flagged questions are how the user tells you what they care about. After calling submit_plan, STOP \u2014 don't call any more tools, wait for the user's verdict.\n\n# Plan mode (/plan)\n\nThe user can ALSO enter \"plan mode\" via /plan, which is a stronger, explicit constraint:\n- Write tools (edit_file, write_file, create_directory, move_file) and non-allowlisted run_command calls are BOUNCED at dispatch \u2014 you'll get a tool result like \"unavailable in plan mode\". Don't retry them.\n- Read tools (read_file, list_directory, search_files, directory_tree, get_file_info) and allowlisted shell (git status/log/diff, ls, cat, grep, cargo check, npm test) still work \u2014 use them to investigate.\n- You MUST call submit_plan before anything will execute. Approve exits plan mode; Refine stays in; Cancel exits without implementing.\n\n\n# When to edit vs. when to explore\n\nOnly propose edits when the user explicitly asks you to change, fix, add, remove, refactor, or write something. Do NOT propose edits when the user asks you to:\n- analyze, read, explore, describe, or summarize a project\n- explain how something works\n- answer a question about the code\n\nIn those cases, use tools to gather what you need, then reply in prose. No SEARCH/REPLACE blocks, no file changes. If you're unsure what the user wants, ask.\n\nWhen you do propose edits, the user will review them and decide whether to `/apply` or `/discard`. Don't assume they'll accept \u2014 write as if each edit will be audited, because it will.\n\n# Editing files\n\nWhen you've been asked to change a file, output one or more SEARCH/REPLACE blocks in this exact format:\n\npath/to/file.ext\n<<<<<<< SEARCH\nexact existing lines from the file, including whitespace\n=======\nthe new lines\n>>>>>>> REPLACE\n\nRules:\n- Always read_file first so your SEARCH matches byte-for-byte. If it doesn't match, the edit is rejected and you'll have to retry with the exact current content.\n- One edit per block. Multiple blocks in one response are fine.\n- To create a new file, leave SEARCH empty:\n    path/to/new.ts\n    <<<<<<< SEARCH\n    =======\n    (whole file content here)\n    >>>>>>> REPLACE\n- Do NOT use write_file to change existing files \u2014 the user reviews your edits as SEARCH/REPLACE. write_file is only for files you explicitly want to overwrite wholesale (rare).\n- Paths are relative to the working directory. Don't use absolute paths.\n\n# Exploration\n\n- Avoid listing or reading inside these common dependency / build directories unless the user explicitly asks about them: node_modules, dist, build, out, .next, .nuxt, .svelte-kit, .git, .venv, venv, __pycache__, target, coverage, .turbo, .cache. They're expensive and usually irrelevant.\n- Prefer search_files / grep over list_directory when you know roughly what you're looking for \u2014 it saves context and avoids enumerating huge trees.\n\n# Style\n\n- Show edits; don't narrate them in prose. \"Here's the fix:\" is enough.\n- One short paragraph explaining *why*, then the blocks.\n- If you need to explore first (list / grep / read), do it with tool calls before writing any prose \u2014 silence while exploring is fine.\n";
 /**
  * Inject the project's `.gitignore` content into the system prompt as a
  * "respect this on top of the built-in denylist" hint. We don't parse
@@ -2009,6 +2166,6 @@ declare function redactKey(key: string): string;
 
 /** Reasonix — DeepSeek-native agent framework. Library entry point. */
 
-declare const VERSION = "0.4.17";
+declare const VERSION = "0.4.19";
 
-export { AppendOnlyLog, type ApplyResult, type ApplyStatus, type BranchOptions, type BranchProgress, type BranchResult, type BranchSample, type BranchSelector, type BranchSummary, type BridgeOptions, type BridgeResult, CODE_SYSTEM_PROMPT, CacheFirstLoop, type CacheFirstLoopOptions, type CallToolResult, type ChatMessage, type ChatResponse, DEFAULT_MAX_RESULT_CHARS, DeepSeekClient, type DeepSeekClientOptions, type RenderOptions as DiffRenderOptions, type DiffReport, type DiffSide, type EditBlock, type EditSnapshot, type EventRole, type FilesystemToolsOptions, type FlattenDecision, type FlattenOptions, type GetPromptResult, type HarvestOptions, ImmutablePrefix, type ImmutablePrefixOptions, type InitializeResult, type InspectionReport, type JSONSchema, type JsonRpcMessage, type JsonRpcRequest, type JsonRpcResponse, type ListPromptsResult, type ListResourcesResult, type ListToolsResult, type LoopEvent, MCP_PROTOCOL_VERSION, McpClient, type McpClientOptions, type McpContentBlock, type McpProgressHandler, type McpProgressInfo, type McpPrompt, type McpPromptArgument, type McpPromptMessage, type McpPromptResourceBlock, type McpResource, type McpResourceContents, type McpResourceContentsBlob, type McpResourceContentsText, type McpSpec, type McpTool, type McpToolSchema, type McpTransport, NeedsConfirmationError, PROJECT_MEMORY_FILE, PROJECT_MEMORY_MAX_CHARS, type PageContent, type ProgressNotificationParams, type ProjectMemory, type ReadResourceResult, type ReadTranscriptResult, type ReasonixConfig, type ReconfigurableOptions, type RepairReport, type ReplayStats, type RetryInfo, type RetryOptions, type Role, type RunCommandResult, type ScavengeOptions, type ScavengeResult, type SearchResult, type SectionResult, type SessionInfo, SessionStats, type SessionSummary, type ShellToolsOptions, type SseMcpSpec, SseTransport, type SseTransportOptions, type StdioMcpSpec, StdioTransport, type StdioTransportOptions, StormBreaker, type StreamChunk, type ToolCall, type ToolCallContext, ToolCallRepair, type ToolCallRepairOptions, type ToolDefinition, type ToolFunctionSpec, ToolRegistry, type ToolSpec, type TranscriptMeta, type TranscriptRecord, type TruncationRepairResult, type TurnPair, type TurnStats, type TypedPlanState, Usage, VERSION, VolatileScratch, type WebFetchOptions, type WebSearchOptions, type WebToolsOptions, aggregateBranchUsage, analyzeSchema, appendSessionMessage, applyEditBlock, applyEditBlocks, applyProjectMemory, bridgeMcpTools, claudeEquivalentCost, codeSystemPrompt, computeReplayStats, costUsd, defaultConfigPath, defaultSelector, deleteSession, diffTranscripts, emptyPlanState, fetchWithRetry, flattenMcpResult, flattenSchema, formatCommandResult, formatLoopError, formatSearchResults, harvest, healLoadedMessages, htmlToText, inputCostUsd, inspectMcpServer, isAllowed, isJsonRpcError, isPlanStateEmpty, isPlausibleKey, listSessions, loadApiKey, loadDotenv, loadSessionMessages, memoryEnabled, nestArguments, openTranscriptFile, outputCostUsd, parseEditBlocks, parseMcpSpec, parseMojeekResults, parseTranscript, readConfig, readProjectMemory, readTranscript, recordFromLoopEvent, redactKey, registerFilesystemTools, registerShellTools, registerWebTools, renderMarkdown as renderDiffMarkdown, renderSummaryTable as renderDiffSummary, repairTruncatedJson, replayFromFile, restoreSnapshots, runBranches, runCommand, sanitizeName as sanitizeSessionName, saveApiKey, scavengeToolCalls, sessionPath, sessionsDir, similarity, snapshotBeforeEdits, stripHallucinatedToolMarkup, tokenizeCommand, truncateForModel, webFetch, webSearch, writeConfig, writeMeta, writeRecord };
+export { AppendOnlyLog, type ApplyResult, type ApplyStatus, type BranchOptions, type BranchProgress, type BranchResult, type BranchSample, type BranchSelector, type BranchSummary, type BridgeOptions, type BridgeResult, CODE_SYSTEM_PROMPT, CacheFirstLoop, type CacheFirstLoopOptions, type CallToolResult, type ChatMessage, type ChatResponse, DEFAULT_MAX_RESULT_CHARS, DeepSeekClient, type DeepSeekClientOptions, type RenderOptions as DiffRenderOptions, type DiffReport, type DiffSide, type EditBlock, type EditSnapshot, type EventRole, type FilesystemToolsOptions, type FlattenDecision, type FlattenOptions, type GetPromptResult, type HarvestOptions, ImmutablePrefix, type ImmutablePrefixOptions, type InitializeResult, type InspectionReport, type JSONSchema, type JsonRpcMessage, type JsonRpcRequest, type JsonRpcResponse, type ListPromptsResult, type ListResourcesResult, type ListToolsResult, type LoopEvent, MCP_PROTOCOL_VERSION, McpClient, type McpClientOptions, type McpContentBlock, type McpProgressHandler, type McpProgressInfo, type McpPrompt, type McpPromptArgument, type McpPromptMessage, type McpPromptResourceBlock, type McpResource, type McpResourceContents, type McpResourceContentsBlob, type McpResourceContentsText, type McpSpec, type McpTool, type McpToolSchema, type McpTransport, NeedsConfirmationError, PROJECT_MEMORY_FILE, PROJECT_MEMORY_MAX_CHARS, type PageContent, PlanProposedError, type PlanToolOptions, type ProgressNotificationParams, type ProjectMemory, type ReadResourceResult, type ReadTranscriptResult, type ReasonixConfig, type ReconfigurableOptions, type RepairReport, type ReplayStats, type RetryInfo, type RetryOptions, type Role, type RunCommandResult, type ScavengeOptions, type ScavengeResult, type SearchResult, type SectionResult, type SessionInfo, SessionStats, type SessionSummary, type ShellToolsOptions, type SseMcpSpec, SseTransport, type SseTransportOptions, type StdioMcpSpec, StdioTransport, type StdioTransportOptions, StormBreaker, type StreamChunk, type ToolCall, type ToolCallContext, ToolCallRepair, type ToolCallRepairOptions, type ToolDefinition, type ToolFunctionSpec, ToolRegistry, type ToolSpec, type TranscriptMeta, type TranscriptRecord, type TruncationRepairResult, type TurnPair, type TurnStats, type TypedPlanState, Usage, VERSION, VolatileScratch, type WebFetchOptions, type WebSearchOptions, type WebToolsOptions, aggregateBranchUsage, analyzeSchema, appendSessionMessage, applyEditBlock, applyEditBlocks, applyProjectMemory, bridgeMcpTools, claudeEquivalentCost, codeSystemPrompt, computeReplayStats, costUsd, defaultConfigPath, defaultSelector, deleteSession, diffTranscripts, emptyPlanState, fetchWithRetry, flattenMcpResult, flattenSchema, formatCommandResult, formatLoopError, formatSearchResults, harvest, healLoadedMessages, htmlToText, inputCostUsd, inspectMcpServer, isAllowed, isJsonRpcError, isPlanStateEmpty, isPlausibleKey, listSessions, loadApiKey, loadDotenv, loadSessionMessages, memoryEnabled, nestArguments, openTranscriptFile, outputCostUsd, parseEditBlocks, parseMcpSpec, parseMojeekResults, parseTranscript, prepareSpawn, quoteForCmdExe, readConfig, readProjectMemory, readTranscript, recordFromLoopEvent, redactKey, registerFilesystemTools, registerPlanTool, registerShellTools, registerWebTools, renderMarkdown as renderDiffMarkdown, renderSummaryTable as renderDiffSummary, repairTruncatedJson, replayFromFile, resolveExecutable, restoreSnapshots, runBranches, runCommand, sanitizeName as sanitizeSessionName, saveApiKey, scavengeToolCalls, sessionPath, sessionsDir, similarity, snapshotBeforeEdits, stripHallucinatedToolMarkup, tokenizeCommand, truncateForModel, webFetch, webSearch, writeConfig, writeMeta, writeRecord };