reasonix 0.7.12 → 0.10.0

package/dist/cli/{prompt-2OABSPAW.js → prompt-LJ44NWSU.js}

@@ -2,9 +2,9 @@
 import {
   CODE_SYSTEM_PROMPT,
   codeSystemPrompt
-} from "./chunk-5DZMZCCW.js";
+} from "./chunk-WRG56OKI.js";
 export {
   CODE_SYSTEM_PROMPT,
   codeSystemPrompt
 };
-//# sourceMappingURL=prompt-2OABSPAW.js.map
+//# sourceMappingURL=prompt-LJ44NWSU.js.map

package/dist/index.d.ts

@@ -1622,12 +1622,12 @@ declare function applyUserMemory(basePrompt: string, opts?: {
     projectRoot?: string;
 }): string;
 /**
- * Compose every lazy-loaded prefix block in one call: REASONIX.md,
- * user memory (global + project), and the skills index. Drop-in
- * replacement for `applyProjectMemory` at CLI entry points. Stacking
- * order is stable — the prefix hash only changes when block *content*
- * changes, not when this helper is called a second time with the same
- * filesystem state.
+ * Compose every lazy-loaded prefix block in one call: project REASONIX.md,
+ * global REASONIX.md (`#g` destination), user memory indexes (global +
+ * per-project), and the skills index. Drop-in replacement for
+ * `applyProjectMemory` at CLI entry points. Stacking order is stable —
+ * the prefix hash only changes when block *content* changes, not when
+ * this helper is called a second time with the same filesystem state.
  */
 declare function applyMemoryStack(basePrompt: string, rootDir: string): string;
 
@@ -2214,8 +2214,14 @@ interface ShellToolsOptions {
      * When true, skip the allowlist entirely and auto-run every command.
      * Off by default — this is an escape hatch for non-interactive use
      * (CI, benchmarks) where a human can't be in the loop to confirm.
+     *
+     * Accepts either a static boolean (captured once) or a getter called
+     * on every dispatch. The getter form is what `reasonix code` uses to
+     * wire `editMode === "yolo"` into the registry: flipping the mode
+     * mid-session must take effect on the next tool call without forcing
+     * a re-registration. Static `true` is fine for CI / benchmark code.
      */
-    allowAll?: boolean;
+    allowAll?: boolean | (() => boolean);
     /**
      * Background-process registry shared between `run_background`,
      * `job_output`, `stop_job`, `list_jobs`, and the /jobs /kill slashes.
@@ -3452,13 +3458,27 @@ declare function codeSystemPrompt(rootDir: string): string;
 /** One of the preset bundles (model + harvest + branch combo). */
 type PresetName = "fast" | "smart" | "max";
 /**
- * How `reasonix code` handles model-issued edits:
- *   - "review" — queue the edit into pendingEdits; user /apply or `y` commits.
- *   - "auto"   — apply immediately, snapshot for /undo, show a short undo
- *                banner so the user can roll back with one keystroke.
- * Persisted so `/mode auto` survives a relaunch. Missing → "review".
+ * How `reasonix code` handles model-issued tool calls. Two axes folded
+ * into one enum because users think about "how trusting am I right now?"
+ * as a single dial, not as "writes vs shell" pairs.
+ *
+ *   - "review" — queue edits into pendingEdits (user /apply or `y` to
+ *                commit); shell commands NOT on the read-only allowlist
+ *                hit ShellConfirm. Default.
+ *   - "auto"   — apply edits immediately, snapshot for /undo, show a
+ *                short undo banner. Shell still goes through ShellConfirm
+ *                for non-allowlisted commands.
+ *   - "yolo"   — apply edits immediately AND auto-approve every shell
+ *                command. No prompts at all. Use when you trust the
+ *                current direction and just want to iterate fast; /undo
+ *                still rolls back individual edit batches.
+ *
+ * Persisted so `/mode <x>` survives a relaunch. Missing → "review".
+ *
+ * Codex-equivalence note: review ≈ untrusted, auto ≈ on-request,
+ * yolo ≈ never.
  */
-type EditMode = "review" | "auto";
+type EditMode = "review" | "auto" | "yolo";
 /**
  * reasoning_effort cap for the model. "max" is the agent-class default;
  * "high" is cheaper / faster. Persisted so `/effort high` survives a

package/dist/index.js

@@ -3525,6 +3525,111 @@ ${NEGATIVE_CLAIM_RULE}
 ${TUI_FORMATTING_RULES}
 
 The 'task' the parent gave you is the research question. Stay on it.`;
+var BUILTIN_REVIEW_BODY = `You are running as a code-review subagent. Your job is to inspect the changes the user is about to ship \u2014 usually the current git branch vs its upstream \u2014 and produce a focused review the parent can hand back to the user.
+
+How to operate:
+- Default scope: the current branch's diff vs the default branch. If the user's task names a specific commit range or files, honor that instead.
+- Discover scope first: \`run_command git status\`, \`git diff --stat\`, \`git log --oneline\` to see what changed. Then \`git diff\` (or \`git diff <base>...HEAD\`) for the actual hunks.
+- Read the touched files (\`read_file\`) when the diff alone doesn't carry enough context \u2014 function signatures, surrounding invariants, callers.
+- For "any callers depending on this?" questions: \`search_content\` against the symbol BEFORE asserting impact.
+- Stay read-only. Never \`run_command git commit\`, never write files, never propose SEARCH/REPLACE blocks. The parent decides whether to act on your findings.
+- Cap yourself at ~12 tool calls. If the diff is too big to review in one pass, pick the riskiest 2-3 files and say so explicitly.
+
+What to look for, in priority order:
+1. **Correctness bugs** \u2014 off-by-one, null/undefined handling, race conditions, wrong sign / wrong operator, edge cases the code doesn't handle.
+2. **Security** \u2014 injection (SQL, shell, path traversal), secrets in code, missing authz checks, unsafe deserialization.
+3. **Behavior changes the diff hides** \u2014 renames that miss callers, removed branches that were load-bearing, error-handling that now swallows what used to surface.
+4. **Tests** \u2014 does the change have tests for the new behavior? Are existing tests still meaningful, or did the change make them tautological?
+5. **Style + consistency** \u2014 only flag deviations that matter (unsafe \`any\`, missing types in TypeScript, inconsistent error shape). Don't pile on cosmetic nits if the substance is clean.
+
+Your final answer:
+- Lead with a one-sentence verdict: "ship as-is" / "minor nits, OK to ship after" / "blocking issues, do not ship".
+- Then a short bulleted list of issues, each with: file:line citation + the problem in one sentence + what to change.
+- Group by severity if you have more than 4 items: **Blocking**, **Should-fix**, **Nits**.
+- If everything looks clean, say so plainly. Don't manufacture concerns.
+
+${NEGATIVE_CLAIM_RULE}
+
+${TUI_FORMATTING_RULES}
+
+The 'task' the parent gave you describes WHAT to review (a branch, a file set, or "the pending changes"). Stay on it; don't redesign the feature.`;
+var BUILTIN_SECURITY_REVIEW_BODY = `You are running as a security-review subagent. Your job is to inspect the changes the user is about to ship \u2014 usually the current git branch vs its upstream \u2014 through a security lens specifically, and report exploitable issues.
+
+How to operate:
+- Default scope: the current branch's diff vs the default branch. If the user names a different range or a directory, honor that.
+- Discover scope first: \`git status\`, \`git diff --stat\`, \`git diff <base>...HEAD\`. Read touched files (\`read_file\`) when the diff alone doesn't carry security context \u2014 auth checks, input validation, the actual handler that calls into the changed function.
+- Use \`search_content\` to verify "is this user-controlled input ever sanitized later?" / "are there other call sites that depend on this validation?" before asserting impact.
+- Stay read-only. Never write, never run destructive commands, never propose SEARCH/REPLACE blocks. The parent decides what to act on.
+- Cap yourself at ~12 tool calls. If the diff is too big, focus on the riskiest 2-3 files and say so explicitly.
+
+Threat model \u2014 flag with severity:
+
+**CRITICAL** (do-not-ship):
+- SQL / NoSQL / shell / template injection \u2014 user input concatenated into a query, command, or template without parameterization.
+- Path traversal \u2014 user-controlled filenames touching the filesystem without canonicalization + sandbox check.
+- Authentication / authorization missing \u2014 endpoints / actions that should require a session check but don't.
+- Hardcoded secrets \u2014 API keys, passwords, signing tokens visible in the diff.
+- Deserialization of untrusted input \u2014 \`pickle.loads\`, \`yaml.load\` (non-safe), \`eval\`, \`Function()\`, \`unserialize()\`.
+- Cryptographic mistakes \u2014 homemade crypto, weak hashes (MD5/SHA-1) for passwords, missing IVs, ECB mode, predictable nonces.
+
+**HIGH**:
+- XSS \u2014 user input rendered into HTML without escaping (or wrong escaping context).
+- SSRF \u2014 fetching URLs from user input without an allowlist.
+- Race conditions in security-relevant code \u2014 TOCTOU on auth/file checks.
+- Open redirects \u2014 user-controlled URL passed to a redirect helper.
+- Insufficient logging on security events (login failure, permission denial) \u2014 only flag if the codebase clearly DOES log elsewhere.
+
+**MEDIUM**:
+- Verbose error messages leaking internal paths / stack traces / SQL.
+- Missing rate limiting on a credential / token endpoint.
+- Cross-origin / cookie-flag issues (missing \`Secure\` / \`HttpOnly\` / \`SameSite\`).
+
+Things to NOT pile on (out of scope here \u2014 the regular /review covers them):
+- Style, formatting, naming.
+- Performance, refactor opportunities, test coverage gaps that aren't security-relevant.
+- "Should be a constant" / "extract this helper" \u2014 irrelevant to ship-blocking.
+
+Your final answer:
+- Lead with a one-sentence verdict: "no security issues found", "minor concerns", or "blocking issues".
+- Then a list grouped by severity. Each item: file:line + 1-sentence threat + 1-sentence fix direction (no full SEARCH/REPLACE \u2014 the user / parent agent will write that).
+- If clean, say so plainly. Don't manufacture findings.
+
+${NEGATIVE_CLAIM_RULE}
+
+${TUI_FORMATTING_RULES}
+
+The 'task' the parent gave you names what to review. Stay on it; don't redesign the feature.`;
+var BUILTIN_TEST_BODY = `You are running as the parent agent \u2014 this skill is INLINED, not a subagent. The user invoked /test (or asked you to "run the tests and fix failures"). Your job: run the project's test suite, diagnose any failure, propose fixes as SEARCH/REPLACE edit blocks, then re-run. Repeat until green or you hit a wall you should escalate.
+
+How to operate:
+
+1. **Detect the test command**.
+   - Look for \`package.json\` \u2192 \`scripts.test\` first (most common: \`npm test\`, \`pnpm test\`, \`yarn test\`).
+   - If no package.json or no test script: try \`pytest\`, \`go test ./...\`, \`cargo test\` based on what files exist (pyproject.toml/requirements.txt \u2192 pytest; go.mod \u2192 go test; Cargo.toml \u2192 cargo test).
+   - If you can't tell, ASK the user for the command \u2014 don't guess. One question, one tool call to confirm.
+
+2. **Run it via run_command** (typical timeout 120s, bigger if the suite is large). Capture stdout + stderr.
+
+3. **Read the failures**. Pull out: which test names failed, the actual error/traceback, the file + line that threw. Don't just paraphrase \u2014 locate the exact assertion or stack frame.
+
+4. **Propose fixes**. For each distinct failure:
+   - If the failure is in PRODUCTION code (test catches a real bug) \u2192 propose a SEARCH/REPLACE that fixes the production code.
+   - If the failure is in TEST code (test is wrong, codebase is right) \u2192 propose a SEARCH/REPLACE that updates the test, AND say so explicitly: "This is a test bug, not a production bug \u2014 updating the assertion."
+   - If the failure is environmental (missing dep, wrong node version, missing fixture file) \u2192 say so and stop. Don't try to install packages or change config without checking with the user.
+
+5. **Apply + re-run**. After the user accepts the edit blocks, run the test command again. Iterate.
+
+6. **Stop conditions**:
+   - All tests pass \u2192 report green, summarize what changed.
+   - Same test still failing after 2 fix attempts on the same line \u2192 STOP. Tell the user "I've tried twice, it's still failing \u2014 here's what I think is happening, want me to try a different angle?". Don't loop indefinitely.
+   - 3+ unrelated failures \u2192 fix one at a time, smallest first, so each pass narrows the surface.
+
+Don't:
+- Run \`npm install\` / \`pip install\` / \`cargo update\` without asking \u2014 those mutate lockfiles and have global effects.
+- Disable, skip, or delete failing tests to "make it green". If a test seems wrong, update its assertion with a one-sentence explanation, but never add \`.skip\` / \`it.skip\` / \`@pytest.mark.skip\`.
+- Modify the test runner config (vitest.config, jest.config, etc.) to silence failures.
+
+Lead each turn with a one-line status: "\u25B8 running \`npm test\` ..." \u2192 "\u25B8 2 failures in tests/foo.test.ts \u2014 first is \u2026" \u2192 so the user always knows where you are without scrolling tool output.`;
 var BUILTIN_SKILLS = Object.freeze([
   Object.freeze({
     name: "explore",
@@ -3541,6 +3646,30 @@ var BUILTIN_SKILLS = Object.freeze([
     scope: "builtin",
     path: "(builtin)",
     runAs: "subagent"
+  }),
+  Object.freeze({
+    name: "review",
+    description: "Review the pending changes (current branch diff by default) in an isolated subagent \u2014 flags correctness, security, missing tests, hidden behavior changes; reports verdict + per-issue file:line. Read-only; the parent decides what to act on.",
+    body: BUILTIN_REVIEW_BODY,
+    scope: "builtin",
+    path: "(builtin)",
+    runAs: "subagent"
+  }),
+  Object.freeze({
+    name: "security-review",
+    description: "Security-focused review of the current branch diff in an isolated subagent \u2014 flags injection/authz/secrets/deserialization/path-traversal/crypto issues, severity-tagged. Read-only. Use when shipping changes that touch auth, input parsing, file IO, or external requests.",
+    body: BUILTIN_SECURITY_REVIEW_BODY,
+    scope: "builtin",
+    path: "(builtin)",
+    runAs: "subagent"
+  }),
+  Object.freeze({
+    name: "test",
+    description: "Run the project's test suite, diagnose failures, propose SEARCH/REPLACE fixes, re-run until green (or stop after 2 fix attempts on the same failure). Inlined \u2014 runs in the parent loop so you see the edit blocks and can /apply them. Detects npm/pnpm/yarn/pytest/go/cargo.",
+    body: BUILTIN_TEST_BODY,
+    scope: "builtin",
+    path: "(builtin)",
+    runAs: "inline"
   })
 ]);
 
@@ -3780,6 +3909,40 @@ var MemoryStore = class {
 `, "utf8");
   }
 };
+function readGlobalReasonixMemory(homeDir = join7(homedir4(), ".reasonix")) {
+  const path = join7(homeDir, "REASONIX.md");
+  if (!existsSync7(path)) return null;
+  let raw;
+  try {
+    raw = readFileSync7(path, "utf8");
+  } catch {
+    return null;
+  }
+  const trimmed = raw.trim();
+  if (!trimmed) return null;
+  const originalChars = trimmed.length;
+  const truncated = originalChars > 8e3;
+  const content = truncated ? `${trimmed.slice(0, 8e3)}
+\u2026 (truncated ${originalChars - 8e3} chars)` : trimmed;
+  return { path, content, originalChars, truncated };
+}
+function applyGlobalReasonixMemory(basePrompt, homeDir) {
+  if (!memoryEnabled()) return basePrompt;
+  const dir = homeDir ?? join7(homedir4(), ".reasonix");
+  const mem = readGlobalReasonixMemory(dir);
+  if (!mem) return basePrompt;
+  return [
+    basePrompt,
+    "",
+    "# Global memory (~/.reasonix/REASONIX.md)",
+    "",
+    "Cross-project notes the user pinned via the `#g` prompt prefix. Treat as authoritative \u2014 same level of trust as project memory.",
+    "",
+    "```",
+    mem.content,
+    "```"
+  ].join("\n");
+}
 function applyUserMemory(basePrompt, opts = {}) {
   if (!memoryEnabled()) return basePrompt;
   const store = new MemoryStore(opts);
@@ -3815,7 +3978,8 @@ function applyUserMemory(basePrompt, opts = {}) {
 }
 function applyMemoryStack(basePrompt, rootDir) {
   const withProject = applyProjectMemory(basePrompt, rootDir);
-  const withMemory = applyUserMemory(withProject, { projectRoot: rootDir });
+  const withGlobal = applyGlobalReasonixMemory(withProject);
+  const withMemory = applyUserMemory(withGlobal, { projectRoot: rootDir });
   return applySkillsIndex(withMemory, { projectRoot: rootDir });
 }
 
@@ -5738,7 +5902,7 @@ function registerShellTools(registry, opts) {
     const snapshot2 = opts.extraAllowed ?? [];
     return () => snapshot2;
   })();
-  const allowAll = opts.allowAll ?? false;
+  const isAllowAll = typeof opts.allowAll === "function" ? opts.allowAll : () => opts.allowAll === true;
   registry.register({
     name: "run_command",
     description: "Run a shell command in the project root and return its combined stdout+stderr.\n\nConstraints (read these before the first call):\n\u2022 ONE process per call, NO shell expansion. `&&`, `||`, `|`, `;`, `>`, `<`, `2>&1` are all rejected up-front \u2014 split into separate calls and combine results in reasoning. Example: instead of `grep foo *.ts | wc -l`, use `grep -c foo *.ts`; instead of `cd sub && npm test`, use `npm test --prefix sub` (or whatever --cwd flag the binary accepts).\n\u2022 `cd` DOES NOT PERSIST between calls \u2014 each call spawns a fresh process rooted at the project. If a tool needs a subdirectory, pass it via the tool's own flag (`npm --prefix`, `cargo -C`, `git -C`, `pytest tests/\u2026`), NOT via a preceding `cd`.\n\u2022 Avoid commands with unbounded output (`netstat -ano`, `find /`, etc.) \u2014 they waste tokens. Filter at source: `netstat -ano -p TCP`, `find src -name '*.ts'`, `grep -c`, `wc -l`.\n\nCommon read-only inspection and test/lint/typecheck commands run immediately; anything that could mutate state, install dependencies, or touch the network is refused until the user confirms it in the TUI. Prefer this over asking the user to run a command manually \u2014 after edits, run the project's tests to verify.",
@@ -5747,7 +5911,7 @@ function registerShellTools(registry, opts) {
     // during planning. Anything that would otherwise trigger a
     // confirmation prompt is treated as "not read-only" and bounced.
     readOnlyCheck: (args) => {
-      if (allowAll) return true;
+      if (isAllowAll()) return true;
       const cmd = typeof args?.command === "string" ? args.command.trim() : "";
       if (!cmd) return false;
       return isAllowed(cmd, getExtraAllowed());
@@ -5769,7 +5933,7 @@ function registerShellTools(registry, opts) {
     fn: async (args, ctx) => {
       const cmd = args.command.trim();
       if (!cmd) throw new Error("run_command: empty command");
-      if (!allowAll && !isAllowed(cmd, getExtraAllowed())) {
+      if (!isAllowAll() && !isAllowed(cmd, getExtraAllowed())) {
         throw new NeedsConfirmationError(cmd);
       }
       const effectiveTimeout = Math.max(1, Math.min(600, args.timeoutSec ?? timeoutSec));
@@ -5802,7 +5966,7 @@ function registerShellTools(registry, opts) {
     fn: async (args, ctx) => {
       const cmd = args.command.trim();
       if (!cmd) throw new Error("run_background: empty command");
-      if (!allowAll && !isAllowed(cmd, getExtraAllowed())) {
+      if (!isAllowAll() && !isAllowed(cmd, getExtraAllowed())) {
         throw new NeedsConfirmationError(cmd);
       }
       const result = await jobs.start(cmd, {