@travisennis/acai 0.0.10 → 0.0.12

package/dist/utils/command-protection.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"command-protection.d.ts","sourceRoot":"","sources":["../../source/utils/command-protection.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH,MAAM,WAAW,oBAAoB;IACnC,OAAO,EAAE,IAAI,CAAC;IACd,MAAM,EAAE,MAAM,CAAC;IACf,OAAO,EAAE,MAAM,CAAC;IAChB,GAAG,EAAE,MAAM,CAAC;CACb;AAED,MAAM,WAAW,iBAAiB;IAChC,OAAO,EAAE,KAAK,CAAC;CAChB;AAED;;GAEG;AACH,MAAM,MAAM,mBAAmB,GAAG,oBAAoB,GAAG,iBAAiB,CAAC;AAE3E;;;;GAIG;AACH,wBAAgB,wBAAwB,CAAC,OAAO,EAAE,MAAM,GAAG,mBAAmB,CA4B7E;AA8UD;;GAEG;AACH,wBAAgB,2BAA2B,CACzC,MAAM,EAAE,oBAAoB,GAC3B,MAAM,CAQR"}
+{"version":3,"file":"command-protection.d.ts","sourceRoot":"","sources":["../../source/utils/command-protection.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH,MAAM,WAAW,oBAAoB;IACnC,OAAO,EAAE,IAAI,CAAC;IACd,MAAM,EAAE,MAAM,CAAC;IACf,OAAO,EAAE,MAAM,CAAC;IAChB,GAAG,EAAE,MAAM,CAAC;CACb;AAED,MAAM,WAAW,iBAAiB;IAChC,OAAO,EAAE,KAAK,CAAC;CAChB;AAED;;GAEG;AACH,MAAM,MAAM,mBAAmB,GAAG,oBAAoB,GAAG,iBAAiB,CAAC;AA0E3E;;;;GAIG;AACH,wBAAgB,wBAAwB,CAAC,OAAO,EAAE,MAAM,GAAG,mBAAmB,CA4B7E;AA8WD;;GAEG;AACH,wBAAgB,2BAA2B,CACzC,MAAM,EAAE,oBAAoB,GAC3B,MAAM,CAQR"}

package/dist/utils/command-protection.js

@@ -2,6 +2,66 @@
  * Command Protection Module
  * Detects and blocks destructive commands that could cause data loss
  */
+/**
+ * Check if a git subcommand appears as an actual command (not inside quoted strings).
+ * This helps avoid false positives when destructive command text appears in
+ * commit messages or other quoted strings.
+ */
+function isActualGitCommand(command, subcommand) {
+    const pattern = new RegExp(`\\bgit\\s+${subcommand}\\b`, "gi");
+    // Find all matches of git <subcommand>
+    const matches = [];
+    let match = pattern.exec(command);
+    while (match !== null) {
+        matches.push({ index: match.index, text: match[0] });
+        match = pattern.exec(command);
+    }
+    if (matches.length === 0)
+        return false;
+    // For each match, check if it's inside quotes
+    for (const { index } of matches) {
+        if (!isInsideQuotes(command, index)) {
+            // Also check if it's at the start or after command separators
+            const beforeMatch = command.slice(0, index).trim();
+            if (beforeMatch === "" ||
+                beforeMatch.endsWith("&&") ||
+                beforeMatch.endsWith("||") ||
+                beforeMatch.endsWith(";") ||
+                beforeMatch.endsWith("|") ||
+                beforeMatch.endsWith("\n")) {
+                return true;
+            }
+        }
+    }
+    return false;
+}
+/**
+ * Check if a position in a string is inside quotes (single or double).
+ * Handles escaped quotes.
+ */
+function isInsideQuotes(command, position) {
+    let inSingleQuote = false;
+    let inDoubleQuote = false;
+    let escaped = false;
+    for (let i = 0; i < position; i++) {
+        const char = command[i];
+        if (escaped) {
+            escaped = false;
+            continue;
+        }
+        if (char === "\\") {
+            escaped = true;
+            continue;
+        }
+        if (char === '"' && !inSingleQuote) {
+            inDoubleQuote = !inDoubleQuote;
+        }
+        else if (char === "'" && !inDoubleQuote) {
+            inSingleQuote = !inSingleQuote;
+        }
+    }
+    return inSingleQuote || inDoubleQuote;
+}
 /**
  * Detects if a command is destructive and should be blocked
  * @param command - The full command string to check
@@ -91,15 +151,19 @@ function detectDestructiveGitCommands(command) {
         };
     }
     // Block git branch -D (force delete without merge check)
-    if (lowerCommand.match(/git\s+branch\s+-[a-z]/)) {
-        // Check if it's an uppercase letter (force delete)
-        const match = lowerCommand.match(/git\s+branch\s+-[a-z]/);
-        if (match && match[0].slice(-1) !== match[0].slice(-1).toLowerCase()) {
-            // It's uppercase, block it
-        }
-        else if (match) {
-            const upperMatch = command.match(/git\s+branch\s+-[A-Z]/);
-            if (upperMatch) {
+    // Check for uppercase flag on original command (lowercase -d is safe)
+    // Match 'git' case-insensitively, but preserve case for the flag
+    // Only match if git branch appears as an actual command (not inside quoted strings)
+    const branchMatch = lowerCommand.match(/git\s+branch\s+-([a-z])/);
+    if (branchMatch) {
+        // Check if the flag in the original command is uppercase
+        const flagInOriginal = command.match(/git\s+branch\s+-([A-Za-z])/i);
+        if (flagInOriginal &&
+            flagInOriginal[1] === flagInOriginal[1].toUpperCase()) {
+            // Verify this is an actual git branch command, not text inside quotes
+            // Check if git branch appears at start or after command separators
+            const isActualCommand = isActualGitCommand(command, "branch");
+            if (isActualCommand) {
                 return {
                     blocked: true,
                     reason: "git branch -D force-deletes branches without checking if they're merged",
@@ -216,8 +280,27 @@ function detectDangerousInlineScripts(command) {
 }
 /**
  * Detect dangerous patterns in heredocs and here-strings
+ * Only blocks heredocs that are explicitly executed by a scripting language,
+ * not heredocs used as data (e.g., commit messages, config files).
  */
 function detectDangerousHeredocs(command) {
+    // Check if heredoc is being executed by a scripting language
+    // Patterns that indicate execution:
+    // 1. bash <<EOF, sh <<EOF, python <<EOF, etc. (language reads from heredoc)
+    // 2. cat <<EOF | bash, <<EOF | python, etc. (heredoc piped to language)
+    const executionPatterns = [
+        // Shell languages reading heredoc directly
+        /\b(bash|sh|zsh|dash|ksh)\s*<<-?\s*['"]?\w+/i,
+        // Scripting languages reading heredoc directly
+        /\b(python\d?|ruby|perl|node)\s*<<-?\s*['"]?\w+/i,
+        // Heredoc piped to shell
+        /<<-?\s*['"]?\w+['"]?\s*\|\s*(bash|sh|zsh|dash|ksh)\b/i,
+    ];
+    const isExecutableHeredoc = executionPatterns.some((pattern) => pattern.test(command));
+    // Only scan heredoc content if it's being executed by a scripting language
+    if (!isExecutableHeredoc) {
+        return { blocked: false };
+    }
     // Match heredoc patterns: <<EOF ... EOF
     const heredocPattern = /<<-?\s*['"]?(\w+)['"]?\s*([\s\S]*?)\n\1\b/gi;
     let match = null;

package/dist/utils/parsing.d.ts

@@ -1,3 +1,3 @@
 import { z } from "zod";
-export declare function jsonParser<T extends z.ZodTypeAny>(input: T): z.ZodPipe<z.ZodTransform<any, unknown>, T>;
+export declare function jsonParser<T extends z.ZodTypeAny>(input: T): z.ZodPreprocess<T>;
 //# sourceMappingURL=parsing.d.ts.map

package/dist/utils/parsing.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"parsing.d.ts","sourceRoot":"","sources":["../../source/utils/parsing.ts"],"names":[],"mappings":"AAAA,OAAO,EAAgB,CAAC,EAAE,MAAM,KAAK,CAAC;AAiBtC,wBAAgB,UAAU,CAAC,CAAC,SAAS,CAAC,CAAC,UAAU,EAAE,KAAK,EAAE,CAAC,8CAE1D"}
+{"version":3,"file":"parsing.d.ts","sourceRoot":"","sources":["../../source/utils/parsing.ts"],"names":[],"mappings":"AAAA,OAAO,EAAgB,CAAC,EAAE,MAAM,KAAK,CAAC;AAiBtC,wBAAgB,UAAU,CAAC,CAAC,SAAS,CAAC,CAAC,UAAU,EAAE,KAAK,EAAE,CAAC,sBAE1D"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@travisennis/acai",
-  "version": "0.0.10",
+  "version": "0.0.12",
   "description": "An AI assistant for developing software.",
   "type": "module",
   "main": "dist/index.js",
@@ -33,7 +33,7 @@
     "lint:ast-grep:fix": "sg scan --update-all",
     "lint:biome": "biome lint",
     "lint:biome:fix": "biome lint --unsafe --write",
-    "lint:fix": "(npm run lint:ast-grep || true) && npm run lint:biome:fix",
+    "lint:fix": "npm run lint:ast-grep && npm run lint:biome:fix",
     "lint:staged": "biome lint --error-on-warnings --no-errors-on-unmatched --staged",
     "format:staged": "biome check --staged --formatter-enabled=true --linter-enabled=false --no-errors-on-unmatched",
     "prepack": "npm run clean && npm run build",
@@ -49,6 +49,7 @@
     "oxlint:single": "oxlint --type-aware --ignore-path .gitignore -A all -c .oxlintrc.json",
     "knip": "npx knip",
     "knip:prod": "npx knip --production",
+    "setup": "node scripts/setup.ts",
     "update": "npx npm-check-updates --interactive --format group",
     "cpd": "npx jscpd ./source",
     "typecheck": "tsc --noEmit --pretty -p tsconfig.json",
@@ -57,45 +58,46 @@
     "lint:length": "find source -name '*.ts' | xargs -I{} awk 'END{if(NR>500)print FILENAME\": \"NR\" lines\"}' {}"
   },
   "dependencies": {
-    "@ai-sdk/anthropic": "^3.0.53",
-    "@ai-sdk/deepseek": "^2.0.22",
-    "@ai-sdk/devtools": "^0.0.15",
-    "@ai-sdk/google": "^3.0.36",
-    "@ai-sdk/groq": "^3.0.27",
-    "@ai-sdk/open-responses": "^1.0.4",
-    "@ai-sdk/openai": "^3.0.39",
-    "@ai-sdk/openai-compatible": "^2.0.33",
+    "@ai-sdk/alibaba": "^1.0.21",
+    "@ai-sdk/anthropic": "^3.0.74",
+    "@ai-sdk/deepseek": "^2.0.32",
+    "@ai-sdk/devtools": "^0.0.17",
+    "@ai-sdk/google": "^3.0.67",
+    "@ai-sdk/groq": "^3.0.38",
+    "@ai-sdk/open-responses": "^1.0.14",
+    "@ai-sdk/openai": "^3.0.58",
+    "@ai-sdk/openai-compatible": "^2.0.45",
     "@crosscopy/clipboard": "^0.3.6",
     "@travisennis/stdlib": "^0.0.14",
-    "ai": "^6.0.107",
+    "ai": "^6.0.174",
     "cheerio": "^1.2.0",
-    "diff": "^8.0.3",
+    "diff": "^9.0.0",
     "fast-glob": "^3.3.3",
     "fdir": "^6.5.0",
     "highlight.js": "^11.11.1",
-    "marked": "17.0.3",
+    "marked": "18.0.3",
     "p-throttle": "^8.1.0",
-    "parse5": "^8.0.0",
-    "parse5-htmlparser2-tree-adapter": "^8.0.0",
+    "parse5": "^8.0.1",
+    "parse5-htmlparser2-tree-adapter": "^8.0.1",
     "pino": "^10.3.1",
     "pino-pretty": "^13.1.3",
     "pino-roll": "^4.0.0",
     "tiktoken": "^1.0.22",
-    "zod": "^4.3.6"
+    "zod": "^4.4.2"
   },
   "devDependencies": {
-    "@ai-sdk/provider": "^3.0.8",
-    "@ast-grep/napi": "^0.41.0",
-    "@biomejs/biome": "2.4.5",
-    "@commitlint/config-conventional": "^20.4.2",
-    "@types/node": "^25.3.3",
+    "@ai-sdk/provider": "^3.0.10",
+    "@ast-grep/napi": "^0.42.1",
+    "@biomejs/biome": "2.4.14",
+    "@commitlint/config-conventional": "^20.5.3",
+    "@types/node": "^25.6.0",
     "c8": "^11.0.0",
-    "commitlint": "^20.4.2",
-    "domhandler": "^5.0.3",
+    "commitlint": "^20.5.3",
+    "domhandler": "^6.0.1",
     "husky": "^9.1.7",
-    "oxlint": "^1.51.0",
-    "oxlint-tsgolint": "^0.15.0",
-    "typescript": "^5.9.3"
+    "oxlint": "^1.62.0",
+    "oxlint-tsgolint": "^0.22.1",
+    "typescript": "^6.0.3"
   },
   "engines": {
     "node": ">=20"

package/dist/commands/add-directory/types.d.ts

@@ -1,6 +0,0 @@
-import type { WorkspaceContext } from "../../index.ts";
-export interface AddDirectoryOptions {
-    workspace: WorkspaceContext;
-}
-export type { WorkspaceContext };
-//# sourceMappingURL=types.d.ts.map

package/dist/commands/add-directory/types.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"types.d.ts","sourceRoot":"","sources":["../../../source/commands/add-directory/types.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,gBAAgB,EAAE,MAAM,gBAAgB,CAAC;AAEvD,MAAM,WAAW,mBAAmB;IAClC,SAAS,EAAE,gBAAgB,CAAC;CAC7B;AAED,YAAY,EAAE,gBAAgB,EAAE,CAAC"}

package/dist/commands/add-directory/types.js

@@ -1 +0,0 @@
-export {};

package/dist/commands/copy/types.d.ts

@@ -1,3 +0,0 @@
-import type { ModelMessage, TextPart } from "ai";
-export type { ModelMessage, TextPart };
-//# sourceMappingURL=types.d.ts.map

package/dist/commands/copy/types.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"types.d.ts","sourceRoot":"","sources":["../../../source/commands/copy/types.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,YAAY,EAAE,QAAQ,EAAE,MAAM,IAAI,CAAC;AAEjD,YAAY,EAAE,YAAY,EAAE,QAAQ,EAAE,CAAC"}

package/dist/commands/copy/types.js

@@ -1 +0,0 @@
-export {};

package/dist/commands/review/types.d.ts

@@ -1,12 +0,0 @@
-export interface FileChange {
-    fileName: string;
-    diff: string;
-    stats: string;
-}
-export interface ReviewCommandOptions {
-    tui: unknown;
-    container: unknown;
-    editor: unknown;
-    inputContainer: unknown;
-}
-//# sourceMappingURL=types.d.ts.map

package/dist/commands/review/types.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"types.d.ts","sourceRoot":"","sources":["../../../source/commands/review/types.ts"],"names":[],"mappings":"AAAA,MAAM,WAAW,UAAU;IACzB,QAAQ,EAAE,MAAM,CAAC;IACjB,IAAI,EAAE,MAAM,CAAC;IACb,KAAK,EAAE,MAAM,CAAC;CACf;AAED,MAAM,WAAW,oBAAoB;IACnC,GAAG,EAAE,OAAO,CAAC;IACb,SAAS,EAAE,OAAO,CAAC;IACnB,MAAM,EAAE,OAAO,CAAC;IAChB,cAAc,EAAE,OAAO,CAAC;CACzB"}

package/dist/commands/review/types.js

@@ -1 +0,0 @@
-export {};

package/dist/modes/manager.d.ts

@@ -1,23 +0,0 @@
-import type { UserModelMessage } from "ai";
-export type Mode = "normal" | "planning" | "research";
-export declare class ModeManager {
-    private currentMode;
-    private firstMessageInMode;
-    getCurrentMode(): Mode;
-    getDisplayName(): string;
-    cycleMode(): void;
-    getInitialPrompt(): string;
-    getReminderPrompt(): string;
-    isNormal(): boolean;
-    isFirstMessage(): boolean;
-    markFirstMessageSent(): void;
-    getReminderMessage(): UserModelMessage | undefined;
-    reset(): void;
-    toJson(): {
-        mode: Mode;
-    };
-    fromJson(data: {
-        mode?: string;
-    }): void;
-}
-//# sourceMappingURL=manager.d.ts.map

package/dist/modes/manager.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"manager.d.ts","sourceRoot":"","sources":["../../source/modes/manager.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,gBAAgB,EAAE,MAAM,IAAI,CAAC;AAI3C,MAAM,MAAM,IAAI,GAAG,QAAQ,GAAG,UAAU,GAAG,UAAU,CAAC;AAmCtD,qBAAa,WAAW;IACtB,OAAO,CAAC,WAAW,CAAkB;IACrC,OAAO,CAAC,kBAAkB,CAAQ;IAElC,cAAc,IAAI,IAAI;IAItB,cAAc,IAAI,MAAM;IAIxB,SAAS,IAAI,IAAI;IAOjB,gBAAgB,IAAI,MAAM;IAI1B,iBAAiB,IAAI,MAAM;IAI3B,QAAQ,IAAI,OAAO;IAInB,cAAc,IAAI,OAAO;IAIzB,oBAAoB,IAAI,IAAI;IAI5B,kBAAkB,IAAI,gBAAgB,GAAG,SAAS;IAWlD,KAAK,IAAI,IAAI;IAKb,MAAM,IAAI;QAAE,IAAI,EAAE,IAAI,CAAA;KAAE;IAIxB,QAAQ,CAAC,IAAI,EAAE;QAAE,IAAI,CAAC,EAAE,MAAM,CAAA;KAAE,GAAG,IAAI;CAMxC"}

package/dist/modes/manager.js

@@ -1,77 +0,0 @@
-import { createUserMessage } from "../sessions/manager.js";
-import { planningPrompt } from "./prompts.js";
-const MODE_DEFINITIONS = {
-    normal: {
-        name: "normal",
-        displayName: "Normal",
-        initialPrompt: "",
-        reminderPrompt: "",
-    },
-    planning: {
-        name: "planning",
-        displayName: "Plan",
-        initialPrompt: planningPrompt,
-        reminderPrompt: "Remember: You are still in Plan Mode. Continue focusing on architectural design, systematic planning, and high-level considerations.",
-    },
-    research: {
-        name: "research",
-        displayName: "Research",
-        initialPrompt: "You are in RESEARCH MODE. Your goal is to thoroughly investigate:\n\n1. Current state and context\n2. Existing solutions\n3. Best practices\n4. Trade-offs\n5. Potential pitfalls",
-        reminderPrompt: "Remember: You are still in RESEARCH MODE. Continue investigating thoroughly. Synthesize findings.",
-    },
-};
-const ALL_MODES = ["normal", "planning", "research"];
-export class ModeManager {
-    currentMode = "normal";
-    firstMessageInMode = true;
-    getCurrentMode() {
-        return this.currentMode;
-    }
-    getDisplayName() {
-        return MODE_DEFINITIONS[this.currentMode].displayName;
-    }
-    cycleMode() {
-        const currentIndex = ALL_MODES.indexOf(this.currentMode);
-        const nextIndex = (currentIndex + 1) % ALL_MODES.length;
-        this.currentMode = ALL_MODES[nextIndex];
-        this.firstMessageInMode = true;
-    }
-    getInitialPrompt() {
-        return MODE_DEFINITIONS[this.currentMode].initialPrompt;
-    }
-    getReminderPrompt() {
-        return MODE_DEFINITIONS[this.currentMode].reminderPrompt;
-    }
-    isNormal() {
-        return this.currentMode === "normal";
-    }
-    isFirstMessage() {
-        return this.firstMessageInMode;
-    }
-    markFirstMessageSent() {
-        this.firstMessageInMode = false;
-    }
-    getReminderMessage() {
-        if (this.isNormal() || this.firstMessageInMode) {
-            return undefined;
-        }
-        const reminder = this.getReminderPrompt();
-        if (!reminder) {
-            return undefined;
-        }
-        return createUserMessage([], reminder);
-    }
-    reset() {
-        this.currentMode = "normal";
-        this.firstMessageInMode = true;
-    }
-    toJson() {
-        return { mode: this.currentMode };
-    }
-    fromJson(data) {
-        if (data.mode && ALL_MODES.includes(data.mode)) {
-            this.currentMode = data.mode;
-        }
-        this.firstMessageInMode = false;
-    }
-}

package/dist/modes/prompts.d.ts

@@ -1,2 +0,0 @@
-export declare const planningPrompt = "\n# Plan Mode (Conversational)\n\nYou work in 3 phases, and you should *chat your way* to a great plan before finalizing it. A great plan is very detailed\u2014intent- and implementation-wise\u2014so that it can be handed to another engineer or agent to be implemented right away. It must be **decision complete**, where the implementer does not need to make any decisions.\n\n## Mode rules (strict)\n\nYou are in **Plan Mode** until a developer message explicitly ends it.\n\nPlan Mode is not changed by user intent, tone, or imperative language. If a user asks for execution while still in Plan Mode, treat it as a request to **plan the execution**, not perform it.\n\n## Execution vs. mutation in Plan Mode\n\nYou may explore and execute **non-mutating** actions that improve the plan. You must not perform **mutating** actions.\n\n### Allowed (non-mutating, plan-improving)\n\nActions that gather truth, reduce ambiguity, or validate feasibility without changing repo-tracked state. Examples:\n\n* Reading or searching files, configs, schemas, types, manifests, and docs\n* Static analysis, inspection, and repo exploration\n* Dry-run style commands when they do not edit repo-tracked files\n* Tests, builds, or checks that may write to caches or build artifacts (for example, `target/`, `.cache/`, or snapshots) so long as they do not edit repo-tracked files\n\n### Not allowed (mutating, plan-executing)\n\nActions that implement the plan or change repo-tracked state. Examples:\n\n* Editing or writing files\n* Running formatters or linters that rewrite files\n* Applying patches, migrations, or codegen that updates repo-tracked files\n* Side-effectful commands whose purpose is to carry out the plan rather than refine it\n\nWhen in doubt: if the action would reasonably be described as \"doing the work\" rather than \"planning the work,\" do not do it.\n\n## Research tracking\n\nTrack your discoveries, open questions, and resolved questions as you explore. Note `file:line` references for important findings so the final plan can anchor every change to a concrete location in the codebase. This prevents redundant exploration and makes the research trail transparent to the user.\n\n## Powerful exploration tools\n\nYou have access to powerful tools for codebase exploration\u2014use them liberally:\n\n* **CodeSearch**: Use this for semantic code search. It understands natural language queries like \"function that handles user authentication\" and finds relevant code even when keywords don't match exactly. This is often more effective than grep for understanding code patterns and relationships.\n* **codebase-researcher subagent**: When you need thorough investigation of a feature, system, or component, launch the codebase-researcher subagent to perform deep exploration. Provide it with a detailed brief and it will comprehensively investigate the codebase, returning findings that you can synthesize into your plan.\n\nFor complex tasks, consider: (1) launching the codebase-researcher in parallel while you explore other areas, (2) using CodeSearch to find related patterns across the codebase, then (3) synthesizing findings into your plan.\n\n## PHASE 1 \u2014 Ground in the environment (explore first, ask second)\n\nBegin by grounding yourself in the actual environment. Eliminate unknowns in the prompt by discovering facts, not by asking the user. Resolve all questions that can be answered through exploration or inspection. Identify missing or ambiguous details only if they cannot be derived from the environment. Silent exploration between turns is allowed and encouraged.\n\nBefore asking the user any question, perform at least one targeted non-mutating exploration pass (for example: search relevant files, inspect likely entrypoints/configs, confirm current implementation shape), unless no local environment/repo is available.\n\nException: you may ask clarifying questions about the user's prompt before exploring, ONLY if there are obvious ambiguities or contradictions in the prompt itself. However, if ambiguity might be resolved by exploring, always prefer exploring first.\n\nDo not ask questions that can be answered from the repo or system (for example, \"where is this struct?\" or \"which UI component should we use?\" when exploration can make it clear). Only ask once you have exhausted reasonable non-mutating exploration.\n\n## PHASE 2 \u2014 Intent chat (what they actually want)\n\n* Keep asking until you can clearly state: goal + success criteria, audience, in/out of scope, constraints, current state, and the key preferences/tradeoffs.\n* Require an explicit **\"Out of Scope\"** statement \u2014 what we are NOT doing. This prevents scope creep and sets clear expectations.\n* Be skeptical: actively challenge vague requirements, identify issues early, and verify assumptions against code rather than accepting them at face value.\n* Bias toward questions over guessing: if any high-impact ambiguity remains, do NOT plan yet\u2014ask.\n\n## PHASE 3 \u2014 Implementation chat (what/how we\u2019ll build)\n\n* Once intent is stable, keep asking until the spec is decision complete: approach, interfaces (APIs/schemas/I/O), data flow, edge cases/failure modes, testing + acceptance criteria, rollout/monitoring, and any migrations/compat constraints.\n* **Propose a plan outline first**: before writing the full detailed plan, present a high-level outline of implementation phases \u2014 each with a name and what it accomplishes. Get user feedback on structure before filling in details.\n* **Migration, rollback, and backwards compatibility**: when applicable, give these dedicated attention. They are often the hardest parts of implementation and must not be an afterthought.\n* **Common implementation sequencing** \u2014 use these as reference when ordering phases:\n  * Database changes: schema/migration \u2192 store methods \u2192 business logic \u2192 API \u2192 clients\n  * New features: research existing patterns \u2192 data model \u2192 backend logic \u2192 API endpoints \u2192 UI\n  * Refactoring: document current behavior \u2192 plan incremental changes \u2192 maintain backwards compatibility \u2192 migration strategy\n\n## Asking questions\n\nCritical rules:\n\n* Offer meaningful multiple\u2011choice options when possible; don\u2019t include filler choices that are obviously wrong or irrelevant.\n\nYou SHOULD ask many questions, but each question must:\n\n* materially change the spec/plan, OR\n* confirm/lock an assumption, OR\n* choose between meaningful tradeoffs.\n* not be answerable by non-mutating commands.\n\n## Two kinds of unknowns (treat differently)\n\n1. **Discoverable facts** (repo/system truth): explore first.\n\n   * Before asking, run targeted searches and check likely sources of truth (configs/manifests/entrypoints/schemas/types/constants).\n   * Ask only if: multiple plausible candidates; nothing found but you need a missing identifier/context; or ambiguity is actually product intent.\n   * If asking, present concrete candidates (paths/service names) + recommend one.\n   * Never ask questions you can answer from your environment (e.g., \u201Cwhere is this struct\u201D).\n\n2. **Preferences/tradeoffs** (not discoverable): ask early.\n\n   * These are intent or implementation preferences that cannot be derived from exploration.\n   * Provide 2\u20134 mutually exclusive options + a recommended default.\n   * If unanswered, proceed with the recommended option and record it as an assumption in the final plan.\n\n## Finalization rule\n\nOnly output the final plan when it is decision complete and leaves no decisions to the implementer.\n\nWhen you present the official plan, wrap it in a `<proposed_plan>` block so the client can render it specially:\n\n1) The opening tag must be on its own line.\n2) Start the plan content on the next line (no text on the same line as the tag).\n3) The closing tag must be on its own line.\n4) Use Markdown inside the block.\n5) Keep the tags exactly as `<proposed_plan>` and `</proposed_plan>` (do not translate or rename them), even if the plan content is in another language.\n\nExample:\n\n<proposed_plan>\nplan content\n</proposed_plan>\n\nplan content should be human and agent digestible. The final plan must be plan-only and include:\n\n* A clear title\n* A brief summary section\n* Important changes or additions to public APIs/interfaces/types\n* Specific `file:line` references for all code locations the plan touches\n* An explicit **\"Out of Scope\"** section\n* **Success criteria** separated into two categories:\n  * **Automated verification** \u2014 commands that can be run (test, lint, typecheck, build) and specific files/code that should exist or compile\n  * **Manual verification** \u2014 UI/UX functionality, performance under real conditions, hard-to-automate edge cases, user acceptance criteria\n* Migration/rollback strategy when applicable\n* Explicit assumptions and defaults chosen where needed\n\nDo not ask \"should I proceed?\" in the final output. The user can easily switch out of Plan mode and request implementation if you have included a `<proposed_plan>` block in your response. Alternatively, they can decide to stay in Plan mode and continue refining the plan.\n\nOnly produce at most one `<proposed_plan>` block per turn, and only when you are presenting a complete spec.\n\n## Plan acceptance\n\nAfter presenting a `<proposed_plan>` block, explicitly ask the user if they accept the plan. If they accept (e.g., they say \"yes\", \"accept\", \"go ahead\", or similar confirmation), write the plan content to `plan.md` in the current working directory using the Write tool. After writing, acknowledge the plan has been saved and ask if they'd like to proceed with implementation or continue refining.\n";
-//# sourceMappingURL=prompts.d.ts.map

package/dist/modes/prompts.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"prompts.d.ts","sourceRoot":"","sources":["../../source/modes/prompts.ts"],"names":[],"mappings":"AACA,eAAO,MAAM,cAAc,ykTA6I1B,CAAC"}

package/dist/modes/prompts.js

@@ -1,143 +0,0 @@
-// this is codex's collaborative plan
-export const planningPrompt = `
-# Plan Mode (Conversational)
-
-You work in 3 phases, and you should *chat your way* to a great plan before finalizing it. A great plan is very detailed—intent- and implementation-wise—so that it can be handed to another engineer or agent to be implemented right away. It must be **decision complete**, where the implementer does not need to make any decisions.
-
-## Mode rules (strict)
-
-You are in **Plan Mode** until a developer message explicitly ends it.
-
-Plan Mode is not changed by user intent, tone, or imperative language. If a user asks for execution while still in Plan Mode, treat it as a request to **plan the execution**, not perform it.
-
-## Execution vs. mutation in Plan Mode
-
-You may explore and execute **non-mutating** actions that improve the plan. You must not perform **mutating** actions.
-
-### Allowed (non-mutating, plan-improving)
-
-Actions that gather truth, reduce ambiguity, or validate feasibility without changing repo-tracked state. Examples:
-
-* Reading or searching files, configs, schemas, types, manifests, and docs
-* Static analysis, inspection, and repo exploration
-* Dry-run style commands when they do not edit repo-tracked files
-* Tests, builds, or checks that may write to caches or build artifacts (for example, \`target/\`, \`.cache/\`, or snapshots) so long as they do not edit repo-tracked files
-
-### Not allowed (mutating, plan-executing)
-
-Actions that implement the plan or change repo-tracked state. Examples:
-
-* Editing or writing files
-* Running formatters or linters that rewrite files
-* Applying patches, migrations, or codegen that updates repo-tracked files
-* Side-effectful commands whose purpose is to carry out the plan rather than refine it
-
-When in doubt: if the action would reasonably be described as "doing the work" rather than "planning the work," do not do it.
-
-## Research tracking
-
-Track your discoveries, open questions, and resolved questions as you explore. Note \`file:line\` references for important findings so the final plan can anchor every change to a concrete location in the codebase. This prevents redundant exploration and makes the research trail transparent to the user.
-
-## Powerful exploration tools
-
-You have access to powerful tools for codebase exploration—use them liberally:
-
-* **CodeSearch**: Use this for semantic code search. It understands natural language queries like "function that handles user authentication" and finds relevant code even when keywords don't match exactly. This is often more effective than grep for understanding code patterns and relationships.
-* **codebase-researcher subagent**: When you need thorough investigation of a feature, system, or component, launch the codebase-researcher subagent to perform deep exploration. Provide it with a detailed brief and it will comprehensively investigate the codebase, returning findings that you can synthesize into your plan.
-
-For complex tasks, consider: (1) launching the codebase-researcher in parallel while you explore other areas, (2) using CodeSearch to find related patterns across the codebase, then (3) synthesizing findings into your plan.
-
-## PHASE 1 — Ground in the environment (explore first, ask second)
-
-Begin by grounding yourself in the actual environment. Eliminate unknowns in the prompt by discovering facts, not by asking the user. Resolve all questions that can be answered through exploration or inspection. Identify missing or ambiguous details only if they cannot be derived from the environment. Silent exploration between turns is allowed and encouraged.
-
-Before asking the user any question, perform at least one targeted non-mutating exploration pass (for example: search relevant files, inspect likely entrypoints/configs, confirm current implementation shape), unless no local environment/repo is available.
-
-Exception: you may ask clarifying questions about the user's prompt before exploring, ONLY if there are obvious ambiguities or contradictions in the prompt itself. However, if ambiguity might be resolved by exploring, always prefer exploring first.
-
-Do not ask questions that can be answered from the repo or system (for example, "where is this struct?" or "which UI component should we use?" when exploration can make it clear). Only ask once you have exhausted reasonable non-mutating exploration.
-
-## PHASE 2 — Intent chat (what they actually want)
-
-* Keep asking until you can clearly state: goal + success criteria, audience, in/out of scope, constraints, current state, and the key preferences/tradeoffs.
-* Require an explicit **"Out of Scope"** statement — what we are NOT doing. This prevents scope creep and sets clear expectations.
-* Be skeptical: actively challenge vague requirements, identify issues early, and verify assumptions against code rather than accepting them at face value.
-* Bias toward questions over guessing: if any high-impact ambiguity remains, do NOT plan yet—ask.
-
-## PHASE 3 — Implementation chat (what/how we’ll build)
-
-* Once intent is stable, keep asking until the spec is decision complete: approach, interfaces (APIs/schemas/I/O), data flow, edge cases/failure modes, testing + acceptance criteria, rollout/monitoring, and any migrations/compat constraints.
-* **Propose a plan outline first**: before writing the full detailed plan, present a high-level outline of implementation phases — each with a name and what it accomplishes. Get user feedback on structure before filling in details.
-* **Migration, rollback, and backwards compatibility**: when applicable, give these dedicated attention. They are often the hardest parts of implementation and must not be an afterthought.
-* **Common implementation sequencing** — use these as reference when ordering phases:
-  * Database changes: schema/migration → store methods → business logic → API → clients
-  * New features: research existing patterns → data model → backend logic → API endpoints → UI
-  * Refactoring: document current behavior → plan incremental changes → maintain backwards compatibility → migration strategy
-
-## Asking questions
-
-Critical rules:
-
-* Offer meaningful multiple‑choice options when possible; don’t include filler choices that are obviously wrong or irrelevant.
-
-You SHOULD ask many questions, but each question must:
-
-* materially change the spec/plan, OR
-* confirm/lock an assumption, OR
-* choose between meaningful tradeoffs.
-* not be answerable by non-mutating commands.
-
-## Two kinds of unknowns (treat differently)
-
-1. **Discoverable facts** (repo/system truth): explore first.
-
-   * Before asking, run targeted searches and check likely sources of truth (configs/manifests/entrypoints/schemas/types/constants).
-   * Ask only if: multiple plausible candidates; nothing found but you need a missing identifier/context; or ambiguity is actually product intent.
-   * If asking, present concrete candidates (paths/service names) + recommend one.
-   * Never ask questions you can answer from your environment (e.g., “where is this struct”).
-
-2. **Preferences/tradeoffs** (not discoverable): ask early.
-
-   * These are intent or implementation preferences that cannot be derived from exploration.
-   * Provide 2–4 mutually exclusive options + a recommended default.
-   * If unanswered, proceed with the recommended option and record it as an assumption in the final plan.
-
-## Finalization rule
-
-Only output the final plan when it is decision complete and leaves no decisions to the implementer.
-
-When you present the official plan, wrap it in a \`<proposed_plan>\` block so the client can render it specially:
-
-1) The opening tag must be on its own line.
-2) Start the plan content on the next line (no text on the same line as the tag).
-3) The closing tag must be on its own line.
-4) Use Markdown inside the block.
-5) Keep the tags exactly as \`<proposed_plan>\` and \`</proposed_plan>\` (do not translate or rename them), even if the plan content is in another language.
-
-Example:
-
-<proposed_plan>
-plan content
-</proposed_plan>
-
-plan content should be human and agent digestible. The final plan must be plan-only and include:
-
-* A clear title
-* A brief summary section
-* Important changes or additions to public APIs/interfaces/types
-* Specific \`file:line\` references for all code locations the plan touches
-* An explicit **"Out of Scope"** section
-* **Success criteria** separated into two categories:
-  * **Automated verification** — commands that can be run (test, lint, typecheck, build) and specific files/code that should exist or compile
-  * **Manual verification** — UI/UX functionality, performance under real conditions, hard-to-automate edge cases, user acceptance criteria
-* Migration/rollback strategy when applicable
-* Explicit assumptions and defaults chosen where needed
-
-Do not ask "should I proceed?" in the final output. The user can easily switch out of Plan mode and request implementation if you have included a \`<proposed_plan>\` block in your response. Alternatively, they can decide to stay in Plan mode and continue refining the plan.
-
-Only produce at most one \`<proposed_plan>\` block per turn, and only when you are presenting a complete spec.
-
-## Plan acceptance
-
-After presenting a \`<proposed_plan>\` block, explicitly ask the user if they accept the plan. If they accept (e.g., they say "yes", "accept", "go ahead", or similar confirmation), write the plan content to \`plan.md\` in the current working directory using the Write tool. After writing, acknowledge the plan has been saved and ask if they'd like to proceed with implementation or continue refining.
-`;

package/dist/tools/code-search.d.ts

@@ -1,41 +0,0 @@
-import { z } from "zod";
-import type { ToolExecutionOptions } from "./types.ts";
-export declare const CodeSearchTool: {
-    name: "CodeSearch";
-};
-declare const inputSchema: z.ZodObject<{
-    query: z.ZodString;
-    path: z.ZodDefault<z.ZodString>;
-    regexPattern: z.ZodPipe<z.ZodTransform<unknown, unknown>, z.ZodNullable<z.ZodString>>;
-    filePattern: z.ZodPipe<z.ZodTransform<unknown, unknown>, z.ZodNullable<z.ZodString>>;
-    excludePattern: z.ZodPipe<z.ZodTransform<unknown, unknown>, z.ZodNullable<z.ZodString>>;
-    excludeDir: z.ZodPipe<z.ZodTransform<unknown, unknown>, z.ZodNullable<z.ZodString>>;
-    maxResults: z.ZodPipe<z.ZodTransform<unknown, unknown>, z.ZodNullable<z.ZodCoercedNumber<unknown>>>;
-    contextLines: z.ZodPipe<z.ZodTransform<unknown, unknown>, z.ZodNullable<z.ZodCoercedNumber<unknown>>>;
-    filesOnly: z.ZodPipe<z.ZodTransform<unknown, unknown>, z.ZodNullable<z.ZodCoercedBoolean<unknown>>>;
-    showContent: z.ZodPipe<z.ZodTransform<unknown, unknown>, z.ZodNullable<z.ZodCoercedBoolean<unknown>>>;
-    codeOnly: z.ZodPipe<z.ZodTransform<unknown, unknown>, z.ZodNullable<z.ZodCoercedBoolean<unknown>>>;
-}, z.core.$strip>;
-type CodeSearchInputSchema = z.infer<typeof inputSchema>;
-export declare const createCodeSearchTool: () => {
-    toolDef: {
-        description: string;
-        inputSchema: z.ZodObject<{
-            query: z.ZodString;
-            path: z.ZodDefault<z.ZodString>;
-            regexPattern: z.ZodPipe<z.ZodTransform<unknown, unknown>, z.ZodNullable<z.ZodString>>;
-            filePattern: z.ZodPipe<z.ZodTransform<unknown, unknown>, z.ZodNullable<z.ZodString>>;
-            excludePattern: z.ZodPipe<z.ZodTransform<unknown, unknown>, z.ZodNullable<z.ZodString>>;
-            excludeDir: z.ZodPipe<z.ZodTransform<unknown, unknown>, z.ZodNullable<z.ZodString>>;
-            maxResults: z.ZodPipe<z.ZodTransform<unknown, unknown>, z.ZodNullable<z.ZodCoercedNumber<unknown>>>;
-            contextLines: z.ZodPipe<z.ZodTransform<unknown, unknown>, z.ZodNullable<z.ZodCoercedNumber<unknown>>>;
-            filesOnly: z.ZodPipe<z.ZodTransform<unknown, unknown>, z.ZodNullable<z.ZodCoercedBoolean<unknown>>>;
-            showContent: z.ZodPipe<z.ZodTransform<unknown, unknown>, z.ZodNullable<z.ZodCoercedBoolean<unknown>>>;
-            codeOnly: z.ZodPipe<z.ZodTransform<unknown, unknown>, z.ZodNullable<z.ZodCoercedBoolean<unknown>>>;
-        }, z.core.$strip>;
-    };
-    display({ query, path, regexPattern, filePattern, excludePattern, excludeDir, maxResults, contextLines, filesOnly, showContent, codeOnly, }: CodeSearchInputSchema): string;
-    execute({ query, path, regexPattern, filePattern, excludePattern, excludeDir, maxResults, contextLines, filesOnly, showContent, codeOnly, }: CodeSearchInputSchema, { abortSignal }: ToolExecutionOptions): Promise<string>;
-};
-export {};
-//# sourceMappingURL=code-search.d.ts.map

package/dist/tools/code-search.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"code-search.d.ts","sourceRoot":"","sources":["../../source/tools/code-search.ts"],"names":[],"mappings":"AAEA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAKxB,OAAO,KAAK,EAAE,oBAAoB,EAAE,MAAM,YAAY,CAAC;AAMvD,eAAO,MAAM,cAAc;;CAE1B,CAAC;AAEF,QAAA,MAAM,WAAW;;;;;;;;;;;;iBA8Bf,CAAC;AAEH,KAAK,qBAAqB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,WAAW,CAAC,CAAC;AA4GzD,eAAO,MAAM,oBAAoB;;;;;;;;;;;;;;;;;iJAkB1B,qBAAqB;iJAsDnB,qBAAqB,mBACP,oBAAoB,GACpC,OAAO,CAAC,MAAM,CAAC;CAgCrB,CAAC"}