reasonix 0.3.2 → 0.4.1

package/README.md

@@ -173,6 +173,38 @@ every message appended atomically, so killing the CLI never loses
 context. Oversized tool results auto-heal on load, so poisoning a
 session with one giant `read_file` doesn't brick your history.
 
+### Code mode — `npx reasonix code`
+
+A thin opinionated layer on top of chat: filesystem MCP bridged at
+`cwd`, coding system prompt, reasoner preset, per-directory session.
+The model proposes edits as **SEARCH/REPLACE blocks**:
+
+```
+src/foo.ts
+<<<<<<< SEARCH
+const x = 1;
+=======
+const x = 2;
+>>>>>>> REPLACE
+```
+
+Reasonix parses them out of each turn, applies them to disk, reports
+`✓ applied src/foo.ts` in the TUI. SEARCH must match byte-for-byte;
+we never fuzzy-match (silent wrong edits are worse than loud
+rejections). Run `git diff` to review, `git checkout .` to undo.
+
+```bash
+cd my-project
+npx reasonix code           # default: cwd, reasoner, per-dir session
+npx reasonix code src/      # scope the filesystem sandbox tighter
+npx reasonix code --no-session   # ephemeral
+```
+
+First-run sandbox: because code mode uses the filesystem MCP from
+`@modelcontextprotocol/server-filesystem`, the model can only read
+and write inside the directory you pointed at. It literally can't
+touch files above that root.
+
 ### Advanced — CLI subcommands and flags
 
 ```bash

package/dist/cli/chunk-2P2MZLCE.js

@@ -0,0 +1,81 @@
+#!/usr/bin/env node
+
+// src/code/prompt.ts
+import { existsSync, readFileSync } from "fs";
+import { join } from "path";
+var 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.
+
+# When to edit vs. when to explore
+
+Only 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:
+- analyze, read, explore, describe, or summarize a project
+- explain how something works
+- answer a question about the code
+
+In 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.
+
+When 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.
+
+# Editing files
+
+When you've been asked to change a file, output one or more SEARCH/REPLACE blocks in this exact format:
+
+path/to/file.ext
+<<<<<<< SEARCH
+exact existing lines from the file, including whitespace
+=======
+the new lines
+>>>>>>> REPLACE
+
+Rules:
+- 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.
+- One edit per block. Multiple blocks in one response are fine.
+- To create a new file, leave SEARCH empty:
+    path/to/new.ts
+    <<<<<<< SEARCH
+    =======
+    (whole file content here)
+    >>>>>>> REPLACE
+- 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).
+- Paths are relative to the working directory. Don't use absolute paths.
+
+# Exploration
+
+- 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.
+- 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.
+
+# Style
+
+- Show edits; don't narrate them in prose. "Here's the fix:" is enough.
+- One short paragraph explaining *why*, then the blocks.
+- If you need to explore first (list / grep / read), do it with tool calls before writing any prose \u2014 silence while exploring is fine.
+`;
+function codeSystemPrompt(rootDir) {
+  const gitignorePath = join(rootDir, ".gitignore");
+  if (!existsSync(gitignorePath)) return CODE_SYSTEM_PROMPT;
+  let content;
+  try {
+    content = readFileSync(gitignorePath, "utf8");
+  } catch {
+    return CODE_SYSTEM_PROMPT;
+  }
+  const MAX = 2e3;
+  const truncated = content.length > MAX ? `${content.slice(0, MAX)}
+\u2026 (truncated ${content.length - MAX} chars)` : content;
+  return `${CODE_SYSTEM_PROMPT}
+
+# Project .gitignore
+
+The user's repo ships this .gitignore \u2014 treat every pattern as "don't traverse or edit inside these paths unless explicitly asked":
+
+\`\`\`
+${truncated}
+\`\`\`
+`;
+}
+
+export {
+  CODE_SYSTEM_PROMPT,
+  codeSystemPrompt
+};
+//# sourceMappingURL=chunk-2P2MZLCE.js.map

package/dist/cli/chunk-2P2MZLCE.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../../src/code/prompt.ts"],"sourcesContent":["/**\n * System prompt used by `reasonix code`. Teaches the model:\n *\n *   1. It has a filesystem MCP bridge rooted at the user's CWD.\n *   2. To modify files it emits SEARCH/REPLACE blocks (not\n *      `write_file` — that would whole-file rewrite and kill diff\n *      reviewability).\n *   3. Read first, edit second — SEARCH must match byte-for-byte.\n *   4. Be concise. The user can read a diff faster than prose.\n *\n * Kept short on purpose. Long system prompts eat context budget that\n * the Cache-First Loop is trying to conserve. The SEARCH/REPLACE spec\n * is the one unavoidable bloat; we trim everything else.\n */\n\nimport { existsSync, readFileSync } from \"node:fs\";\nimport { join } from \"node:path\";\n\nexport 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 — 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 — 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 — 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 — silence while exploring is fine.\n`;\n\n/**\n * Inject the project's `.gitignore` content into the system prompt as a\n * \"respect this on top of the built-in denylist\" hint. We don't parse\n * the file — we hand it to the model as-is. Truncate long ones so we\n * don't eat context budget on huge generated ignore lists.\n *\n * Missing or unreadable .gitignore → returns the base prompt unchanged.\n */\nexport function codeSystemPrompt(rootDir: string): string {\n  const gitignorePath = join(rootDir, \".gitignore\");\n  if (!existsSync(gitignorePath)) return CODE_SYSTEM_PROMPT;\n  let content: string;\n  try {\n    content = readFileSync(gitignorePath, \"utf8\");\n  } catch {\n    return CODE_SYSTEM_PROMPT;\n  }\n  const MAX = 2000;\n  const truncated =\n    content.length > MAX\n      ? `${content.slice(0, MAX)}\\n… (truncated ${content.length - MAX} chars)`\n      : content;\n  return `${CODE_SYSTEM_PROMPT}\n\n# Project .gitignore\n\nThe user's repo ships this .gitignore — treat every pattern as \"don't traverse or edit inside these paths unless explicitly asked\":\n\n\\`\\`\\`\n${truncated}\n\\`\\`\\`\n`;\n}\n"],"mappings":";;;AAeA,SAAS,YAAY,oBAAoB;AACzC,SAAS,YAAY;AAEd,IAAM,qBAAqB;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAwD3B,SAAS,iBAAiB,SAAyB;AACxD,QAAM,gBAAgB,KAAK,SAAS,YAAY;AAChD,MAAI,CAAC,WAAW,aAAa,EAAG,QAAO;AACvC,MAAI;AACJ,MAAI;AACF,cAAU,aAAa,eAAe,MAAM;AAAA,EAC9C,QAAQ;AACN,WAAO;AAAA,EACT;AACA,QAAM,MAAM;AACZ,QAAM,YACJ,QAAQ,SAAS,MACb,GAAG,QAAQ,MAAM,GAAG,GAAG,CAAC;AAAA,oBAAkB,QAAQ,SAAS,GAAG,YAC9D;AACN,SAAO,GAAG,kBAAkB;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,EAO5B,SAAS;AAAA;AAAA;AAGX;","names":[]}