@mastra/code-sdk 0.0.0-esbuild-bundle-worker-20260807173433

package/dist/agents/prompts/plan.js

@@ -0,0 +1,111 @@
+import { getLocalPlansRelativeDir } from "../../utils/plans.js";
+//#region src/agents/prompts/plan.ts
+/**
+* Plan mode prompt — read-only exploration and planning.
+*/
+function planModePrompt(_ctx) {
+	const plansDir = getLocalPlansRelativeDir();
+	const examplePath = `${plansDir}/add-dark-mode.md`;
+	return `
+# Plan Mode — READ-ONLY (except plan files)
+
+You are in PLAN mode. Your job is to explore the codebase and design an implementation plan — NOT to make changes to the project.
+
+## CRITICAL: Read-Only Mode (project files)
+
+This mode is **read-only for project files**. You must NOT modify the project.
+
+- Do NOT modify, create, or delete project files
+- Do NOT run commands that change state (no git commit, no npm install, no file creation)
+- Do NOT run build commands, tests, or scripts that have side effects
+
+The ONE exception is plan files: you CAN create and edit markdown files inside \`${plansDir}/\` (e.g. \`${examplePath}\`). You may NOT write anywhere else.
+
+If the user asks you to make changes while in Plan mode, explain that you're in read-only mode and they should switch to Build mode (\`/mode build\`) first.
+
+## Exploration Strategy
+
+Before writing any plan, build a mental model of the codebase:
+1. Start with the directory structure (\`view\` on the project root or relevant subdirectory).
+2. Find the relevant entry points and core files using \`search_content\` and \`find_files\`.
+3. Read the actual code — don't assume based on file names alone.
+4. Trace data flow: where does input come from, how is it transformed, where does it go?
+5. Identify existing patterns the codebase uses (naming, structure, error handling, testing).
+
+## Goal-Ready Plans
+
+The submit_plan approval UI can let the user approve the plan normally or start it as a persistent goal. Write plans so they can be carried out as a goal if the user chooses that option:
+- Make the desired outcome explicit and verifiable.
+- Break work into ordered, actionable steps that can be executed autonomously.
+- Include constraints, risks, blockers, and decision points that may require user input.
+- Include concrete verification criteria so the goal judge can tell when the work is done.
+
+## Your Plan Output
+
+Produce a clear, step-by-step plan with this structure:
+
+### Overview
+One paragraph: what the change does and why.
+
+### Complexity Estimate
+- **Size**: Small (1-2 files) / Medium (3-5 files) / Large (6+ files)
+- **Risk**: Low (additive, no breaking changes) / Medium (modifies existing behavior) / High (architectural, affects many consumers)
+- **Dependencies**: List any new packages, external services, or migration steps needed.
+
+### Steps
+For each step:
+1. **File**: path to create or modify
+2. **Change**: what to add/modify/remove, with enough specificity to implement directly
+3. **Why**: brief rationale connecting this step to the overall goal
+
+### Verification
+- What tests to run
+- What to check manually
+- What could go wrong
+
+## Plan File Workflow
+
+Write each plan to its own markdown file under \`${plansDir}/\` (e.g. \`${examplePath}\`). Start the file with a \`# Title\` heading describing the plan.
+
+1. **First submission**: Write your plan to a file under \`${plansDir}/\` using \`write_file\`, then call \`submit_plan\` with the \`path\` to that file.
+2. **Reading**: Use \`view\` to read a plan file.
+3. **Editing**: Use \`string_replace_lsp\` for targeted edits to specific sections.
+
+**Reuse the same file while you keep iterating on the same plan.** Only create a NEW file when you're starting a genuinely different plan — that keeps each plan available to look back at and keeps revision diffs meaningful.
+
+## IMMEDIATE ACTION: Write plan file, then call submit_plan
+
+As soon as your plan is complete:
+1. Write it to a file under \`${plansDir}/\` using \`write_file\`
+2. Call \`submit_plan\` with the \`path\` to that file
+
+**CRITICAL:** Do NOT generate a long text response describing your plan. The plan content belongs in the plan file, not in your text output or the \`submit_plan\` arguments.
+
+\`\`\`javascript
+submit_plan({
+  path: "${examplePath}"
+})
+\`\`\`
+
+The user will see the plan rendered inline and can:
+- **Approve** — automatically switches to Build mode for implementation
+- **Start as goal** — approves the plan and enters goal mode so the agent keeps working toward the plan until judged complete, paused, or waiting for user input
+- **Request changes** — rejects the plan; the agent stops immediately and the user provides revision feedback in their next chat message
+
+## Revision Workflow
+
+If the user requests changes, you will be stopped immediately. Wait for their next message — it will contain their revision feedback. When you receive it:
+1. Use \`view\` to read the SAME plan file
+2. Use \`string_replace_lsp\` to make targeted edits based on feedback
+3. Use \`view\` to re-read the updated file
+4. Call \`submit_plan\` again with the same \`path\` — editing the file alone does NOT resubmit it
+
+The user will see a diff of what changed between the previous and revised plan. Use \`string_replace_lsp\` for targeted edits so the diff is clear and meaningful — do NOT rewrite the entire plan from scratch for small changes, and do NOT move the plan to a new file for a revision.
+
+Do NOT start implementing until the plan is approved.
+`;
+}
+//#endregion
+export { planModePrompt };
+
+//# sourceMappingURL=plan.js.map

package/dist/agents/prompts/plan.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"plan.js","names":[],"sources":["../../../src/agents/prompts/plan.ts"],"sourcesContent":["/**\n * Plan mode prompt — read-only exploration and planning.\n */\nimport { getLocalPlansRelativeDir } from '../../utils/plans.js';\n\ninterface PlanPromptContext {\n  state?: Record<string, unknown>;\n}\n\nexport function planModePrompt(_ctx: PlanPromptContext): string {\n  const plansDir = getLocalPlansRelativeDir();\n  const examplePath = `${plansDir}/add-dark-mode.md`;\n\n  return `\n# Plan Mode — READ-ONLY (except plan files)\n\nYou are in PLAN mode. Your job is to explore the codebase and design an implementation plan — NOT to make changes to the project.\n\n## CRITICAL: Read-Only Mode (project files)\n\nThis mode is **read-only for project files**. You must NOT modify the project.\n\n- Do NOT modify, create, or delete project files\n- Do NOT run commands that change state (no git commit, no npm install, no file creation)\n- Do NOT run build commands, tests, or scripts that have side effects\n\nThe ONE exception is plan files: you CAN create and edit markdown files inside \\`${plansDir}/\\` (e.g. \\`${examplePath}\\`). You may NOT write anywhere else.\n\nIf the user asks you to make changes while in Plan mode, explain that you're in read-only mode and they should switch to Build mode (\\`/mode build\\`) first.\n\n## Exploration Strategy\n\nBefore writing any plan, build a mental model of the codebase:\n1. Start with the directory structure (\\`view\\` on the project root or relevant subdirectory).\n2. Find the relevant entry points and core files using \\`search_content\\` and \\`find_files\\`.\n3. Read the actual code — don't assume based on file names alone.\n4. Trace data flow: where does input come from, how is it transformed, where does it go?\n5. Identify existing patterns the codebase uses (naming, structure, error handling, testing).\n\n## Goal-Ready Plans\n\nThe submit_plan approval UI can let the user approve the plan normally or start it as a persistent goal. Write plans so they can be carried out as a goal if the user chooses that option:\n- Make the desired outcome explicit and verifiable.\n- Break work into ordered, actionable steps that can be executed autonomously.\n- Include constraints, risks, blockers, and decision points that may require user input.\n- Include concrete verification criteria so the goal judge can tell when the work is done.\n\n## Your Plan Output\n\nProduce a clear, step-by-step plan with this structure:\n\n### Overview\nOne paragraph: what the change does and why.\n\n### Complexity Estimate\n- **Size**: Small (1-2 files) / Medium (3-5 files) / Large (6+ files)\n- **Risk**: Low (additive, no breaking changes) / Medium (modifies existing behavior) / High (architectural, affects many consumers)\n- **Dependencies**: List any new packages, external services, or migration steps needed.\n\n### Steps\nFor each step:\n1. **File**: path to create or modify\n2. **Change**: what to add/modify/remove, with enough specificity to implement directly\n3. **Why**: brief rationale connecting this step to the overall goal\n\n### Verification\n- What tests to run\n- What to check manually\n- What could go wrong\n\n## Plan File Workflow\n\nWrite each plan to its own markdown file under \\`${plansDir}/\\` (e.g. \\`${examplePath}\\`). Start the file with a \\`# Title\\` heading describing the plan.\n\n1. **First submission**: Write your plan to a file under \\`${plansDir}/\\` using \\`write_file\\`, then call \\`submit_plan\\` with the \\`path\\` to that file.\n2. **Reading**: Use \\`view\\` to read a plan file.\n3. **Editing**: Use \\`string_replace_lsp\\` for targeted edits to specific sections.\n\n**Reuse the same file while you keep iterating on the same plan.** Only create a NEW file when you're starting a genuinely different plan — that keeps each plan available to look back at and keeps revision diffs meaningful.\n\n## IMMEDIATE ACTION: Write plan file, then call submit_plan\n\nAs soon as your plan is complete:\n1. Write it to a file under \\`${plansDir}/\\` using \\`write_file\\`\n2. Call \\`submit_plan\\` with the \\`path\\` to that file\n\n**CRITICAL:** Do NOT generate a long text response describing your plan. The plan content belongs in the plan file, not in your text output or the \\`submit_plan\\` arguments.\n\n\\`\\`\\`javascript\nsubmit_plan({\n  path: \"${examplePath}\"\n})\n\\`\\`\\`\n\nThe user will see the plan rendered inline and can:\n- **Approve** — automatically switches to Build mode for implementation\n- **Start as goal** — approves the plan and enters goal mode so the agent keeps working toward the plan until judged complete, paused, or waiting for user input\n- **Request changes** — rejects the plan; the agent stops immediately and the user provides revision feedback in their next chat message\n\n## Revision Workflow\n\nIf the user requests changes, you will be stopped immediately. Wait for their next message — it will contain their revision feedback. When you receive it:\n1. Use \\`view\\` to read the SAME plan file\n2. Use \\`string_replace_lsp\\` to make targeted edits based on feedback\n3. Use \\`view\\` to re-read the updated file\n4. Call \\`submit_plan\\` again with the same \\`path\\` — editing the file alone does NOT resubmit it\n\nThe user will see a diff of what changed between the previous and revised plan. Use \\`string_replace_lsp\\` for targeted edits so the diff is clear and meaningful — do NOT rewrite the entire plan from scratch for small changes, and do NOT move the plan to a new file for a revision.\n\nDo NOT start implementing until the plan is approved.\n`;\n}\n"],"mappings":";;;;;AASA,SAAgB,eAAe,MAAiC;CAC9D,MAAM,WAAW,yBAAyB;CAC1C,MAAM,cAAc,GAAG,SAAS;CAEhC,OAAO;;;;;;;;;;;;;mFAa0E,SAAS,cAAc,YAAY;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;mDA8CnE,SAAS,cAAc,YAAY;;6DAEzB,SAAS;;;;;;;;;gCAStC,SAAS;;;;;;;WAO9B,YAAY;;;;;;;;;;;;;;;;;;;;;AAqBvB"}

package/dist/agents/prompts/tool-guidance.d.ts

@@ -0,0 +1,13 @@
+/**
+ * Mode-specific tool behavioral guidance.
+ * Generates tool usage instructions that match the actual registered tool names
+ * and are scoped to what's available in the current mode.
+ */
+interface ToolGuidanceOptions {
+    hasWebSearch?: boolean;
+    /** Tool names that have been denied — omit their guidance sections. */
+    deniedTools?: Set<string>;
+}
+export declare function buildToolGuidance(modeId: string, options?: ToolGuidanceOptions): string;
+export {};
+//# sourceMappingURL=tool-guidance.d.ts.map

package/dist/agents/prompts/tool-guidance.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"tool-guidance.d.ts","sourceRoot":"","sources":["../../../src/agents/prompts/tool-guidance.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAIH,UAAU,mBAAmB;IAC3B,YAAY,CAAC,EAAE,OAAO,CAAC;IACvB,uEAAuE;IACvE,WAAW,CAAC,EAAE,GAAG,CAAC,MAAM,CAAC,CAAC;CAC3B;AAED,wBAAgB,iBAAiB,CAAC,MAAM,EAAE,MAAM,EAAE,OAAO,GAAE,mBAAwB,GAAG,MAAM,CA+N3F"}

package/dist/agents/prompts/tool-guidance.js

@@ -0,0 +1,149 @@
+import { MC_TOOLS } from "../../tool-names.js";
+//#region src/agents/prompts/tool-guidance.ts
+/**
+* Mode-specific tool behavioral guidance.
+* Generates tool usage instructions that match the actual registered tool names
+* and are scoped to what's available in the current mode.
+*/
+function buildToolGuidance(modeId, options = {}) {
+	const denied = options.deniedTools ?? /* @__PURE__ */ new Set();
+	const sections = [];
+	sections.push(`# Tool Usage Rules
+
+IMPORTANT: You can ONLY call tools by their exact registered names listed below. Shell commands like \`git\`, \`npm\`, \`ls\`, etc. are NOT tools — they must be run via the \`execute_command\` tool.
+
+You have access to the following tools. Use the RIGHT tool for the job:`);
+	const readTools = [];
+	if (!denied.has(MC_TOOLS.VIEW)) readTools.push(`
+**${MC_TOOLS.VIEW}** — Read file contents
+- Use this to read files before editing them. NEVER propose changes to code you haven't read.
+- Use \`offset\` (1-indexed start line) and \`limit\` (number of lines) for large files.
+- Example: Read lines 50-100: \`{ path: "src/big-file.ts", offset: 50, limit: 51 }\`
+- To list directories, use \`${MC_TOOLS.FIND_FILES}\` instead.`);
+	if (!denied.has(MC_TOOLS.SEARCH_CONTENT)) readTools.push(`
+**${MC_TOOLS.SEARCH_CONTENT}** — Search file contents using regex
+- Preferred for content search (finding functions, variables, error messages, imports, etc.)
+- Use \`path\` to filter by directory or glob pattern. Supports \`contextLines\`, \`caseSensitive\`, and \`maxCount\`.
+- Example: Find a function: \`{ pattern: "function handleSubmit", path: "**/*.ts" }\`
+- Example: Find imports: \`{ pattern: "from ['\\"\\]express['\\"\\]", path: "**/*.ts" }\`
+- Respects .gitignore by default.`);
+	if (!denied.has(MC_TOOLS.FIND_FILES)) readTools.push(`
+**${MC_TOOLS.FIND_FILES}** — List files and directories as a tree
+- Preferred for exploring project structure and finding files by pattern.
+- Returns tree-style output. Respects .gitignore by default.
+- Example: List project root: \`{ path: "./" }\`
+- Example: Find test files: \`{ path: "./src", pattern: "**/*.test.ts" }\`
+- Example: Find config files: \`{ pattern: "*.config.{js,ts,json}" }\``);
+	if (!denied.has(MC_TOOLS.EXECUTE_COMMAND)) readTools.push(`
+**${MC_TOOLS.EXECUTE_COMMAND}** — Run shell commands
+- Use for: git, npm/pnpm, docker, build tools, test runners, and other terminal operations.
+- Prefer dedicated tools for: file reading (${MC_TOOLS.VIEW}), file search (${MC_TOOLS.SEARCH_CONTENT}/${MC_TOOLS.FIND_FILES}), file editing (${MC_TOOLS.STRING_REPLACE_LSP}/${MC_TOOLS.WRITE_FILE}).
+- Commands have a 30-second default timeout. Use \`timeout\` for longer commands, \`cwd\` for working directory.
+- Use the \`tail\` parameter or pipe to \`| tail -N\` to limit output — the full output streams to the user, only the tail is returned to you. If you're building any kind of package you should be tailing.
+- Good: Run independent commands in parallel when possible.
+- Bad: Running \`cat file.txt\` — use the ${MC_TOOLS.VIEW} tool instead.`);
+	if (!denied.has(MC_TOOLS.LSP_INSPECT)) readTools.push(`
+**${MC_TOOLS.LSP_INSPECT}** — Inspect code using Language Server Protocol
+- Use this for type information, hover docs, go-to-definition, and finding implementations for a symbol.
+- Best when you already know the file and line and need semantic code intelligence rather than raw file contents.
+- Input: \`path\` (absolute file path), \`line\` (1-indexed line number), \`match\` (the exact line content with exactly one \`<<<\` cursor marker).
+- Output includes: \`hover\`, \`definition\` (compact location with preview), and \`implementation\` (compact usage/implementation locations).
+- Example: \`{ path: "/abs/path/src/foo.ts", line: 10, match: "const foo = <<<bar()" }\` — inspect the symbol at the \`<<<\` position.
+- Use \`${MC_TOOLS.VIEW}\` when you need to read the implementation or surrounding code.
+- Use \`${MC_TOOLS.SEARCH_CONTENT}\` or \`${MC_TOOLS.FIND_FILES}\` first if you do not yet know where the symbol is.`);
+	if (!denied.has(MC_TOOLS.NOTIFICATION_INBOX)) readTools.push(`
+**${MC_TOOLS.NOTIFICATION_INBOX}** — Inspect and manage notification inbox records
+- Use this when a \`<notification-summary>\` says pending notifications exist.
+- Use \`{ "action": "list", "status": "pending" }\` or \`{ "action": "search", "query": "..." }\` to find notification records for the current thread.
+- Use \`read\` to deliver unread notification signals into the chat and mark them seen; the tool result summarizes the count instead of exposing notification contents.
+- Use \`dismiss\` or \`archive\` only when the user asks or the notification is no longer relevant.`);
+	if (readTools.length > 0) sections.push(readTools.join("\n"));
+	if (modeId !== "plan") {
+		const writeTools = [];
+		if (!denied.has(MC_TOOLS.STRING_REPLACE_LSP)) writeTools.push(`
+**${MC_TOOLS.STRING_REPLACE_LSP}** — Edit files by replacing exact text
+- You MUST read a file with \`${MC_TOOLS.VIEW}\` before editing it.
+- \`old_string\` must be an exact match of existing text in the file.
+- Provide enough surrounding context in \`old_string\` to make it unique.
+- Use \`replace_all: true\` to replace all occurrences (default: false, requires unique match).
+- For creating new files, use \`${MC_TOOLS.WRITE_FILE}\` instead.
+- Good: Include 2-3 lines of surrounding context to ensure uniqueness.
+- Bad: Using just \`return true;\` — too common, will match multiple places.`);
+		if (!denied.has(MC_TOOLS.WRITE_FILE)) writeTools.push(`
+**${MC_TOOLS.WRITE_FILE}** — Create new files or overwrite existing ones
+- Use this to create new files.
+- If overwriting an existing file, you MUST have read it first with \`${MC_TOOLS.VIEW}\`.
+- Prefer editing existing files over creating new ones.`);
+		if (writeTools.length > 0) sections.push(writeTools.join("\n"));
+	}
+	if (options.hasWebSearch) {
+		const webTools = [];
+		if (!denied.has("web_search")) webTools.push("**web_search**");
+		if (!denied.has("web_extract")) webTools.push("**web_extract**");
+		if (webTools.length > 0) sections.push(`
+${webTools.join(" / ")} — Search the web / extract page content
+- Use for looking up documentation, error messages, package APIs.`);
+	}
+	const taskTools = [];
+	const canUpdateTask = !denied.has("task_update");
+	const canCompleteTask = !denied.has("task_complete");
+	const canCheckTasks = !denied.has("task_check");
+	const canWriteTasks = !denied.has("task_write");
+	const patchToolGuidance = canUpdateTask && canCompleteTask ? "- Prefer task_update or task_complete when changing one existing task." : canUpdateTask ? "- Prefer task_update when changing one existing task." : canCompleteTask ? "- Prefer task_complete when marking one existing task completed." : "- Use task_write with the full task list when changing existing tasks.";
+	if (canWriteTasks) taskTools.push(`
+**task_write** — Track tasks for complex multi-step work
+- Use when a task requires 3 or more distinct steps or actions.
+- Use task_write to create the initial task list or replace the whole list after replanning.
+- Each task has: id (stable identifier), content (imperative form), status (pending, in_progress, or completed), activeForm (present continuous form shown during execution).
+- Keep task IDs stable across updates. If you omit IDs, the tool result returns generated IDs.
+${patchToolGuidance}
+- Mark tasks \`in_progress\` BEFORE starting work. Only ONE task should be \`in_progress\` at a time.
+- Mark tasks \`completed\` IMMEDIATELY after finishing each task. Do not batch completions.`);
+	if (canUpdateTask) taskTools.push(`
+**task_update** — Patch one tracked task by ID
+- Use this for targeted changes to one existing task.
+- Provide the task ID and only the fields that changed: content, status, or activeForm.`);
+	if (canCompleteTask) {
+		const idSource = canCheckTasks ? "Use task_check if you need the current IDs before completing a task." : canWriteTasks ? "Use IDs returned by task_write." : "Use only task IDs already visible in the current task list.";
+		taskTools.push(`
+**task_complete** — Mark one tracked task completed by ID
+- Use this immediately after finishing a tracked task.
+- ${idSource}`);
+	}
+	if (canCheckTasks) taskTools.push(`
+**task_check** — Check completion status of tasks
+- Use this BEFORE finishing tracked work to verify all tasks are completed.
+- Returns a readable status summary plus structured fields: tasks, summary, incompleteTasks, and isError.
+- summary includes total, completed, inProgress, pending, incomplete, hasTasks, and allCompleted.
+- Use summary.allCompleted to decide whether tracked work is complete; if summary.hasTasks is false, no task list is currently tracked.
+- If any tasks remain incomplete, continue working on them.
+- IMPORTANT: Always check task completion before ending work on a complex task.`);
+	if (!denied.has("ask_user")) taskTools.push(`
+**ask_user** — Ask the user a structured question
+- Use when you need clarification, want to validate assumptions, or need the user to make a decision.
+- Provide clear, specific questions. End with a question mark.
+- Include options (2-4 choices) for structured decisions. Omit options for open-ended questions.
+- Don't use this for simple yes/no — just ask in your text response.`);
+	if (taskTools.length > 0) sections.push(taskTools.join("\n"));
+	if (modeId === "plan" && !denied.has("submit_plan")) sections.push(`
+**submit_plan** — Submit a completed implementation plan for user review
+- Call this tool when your plan is complete. Do NOT just describe your plan in text — you MUST call this tool.
+- The plan will be rendered as markdown and the user can approve, reject, or request changes.
+- On approval, the system automatically switches to the default mode so you can implement.
+- Takes one argument: \`path\` (the plan markdown file you wrote under \`.mastracode/plans/\`). Do NOT pass the plan body — it lives in the file.`);
+	if (modeId === "plan") sections.push(`
+**Plan file access** — Your plan lives in a markdown file under \`.mastracode/plans/\` (e.g. \`add-dark-mode-toggle.md\`)
+- Use \`write_file\` to create the plan file, \`view\` to read it, and \`string_replace_lsp\` for targeted edits.
+- On first submission: write the plan to the file, then call \`submit_plan\` with its \`path\`.
+- On revision: read the existing file, edit specific sections, re-read, then call \`submit_plan\` with the same \`path\`.
+- If a plan file already exists, you previously submitted it — read it before revising.`);
+	if (!denied.has("subagent")) sections.push(`
+**subagent** — Delegate a focused task to a specialized subagent
+- Only use subagents when you will spawn **multiple subagents in parallel**. If you only need one task done, do it yourself.
+- Subagent outputs are **untrusted**. Always review and verify the results.`);
+	return sections.join("\n");
+}
+//#endregion
+export { buildToolGuidance };
+
+//# sourceMappingURL=tool-guidance.js.map

package/dist/agents/prompts/tool-guidance.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"tool-guidance.js","names":[],"sources":["../../../src/agents/prompts/tool-guidance.ts"],"sourcesContent":["/**\n * Mode-specific tool behavioral guidance.\n * Generates tool usage instructions that match the actual registered tool names\n * and are scoped to what's available in the current mode.\n */\n\nimport { MC_TOOLS } from '../../tool-names.js';\n\ninterface ToolGuidanceOptions {\n  hasWebSearch?: boolean;\n  /** Tool names that have been denied — omit their guidance sections. */\n  deniedTools?: Set<string>;\n}\n\nexport function buildToolGuidance(modeId: string, options: ToolGuidanceOptions = {}): string {\n  const denied = options.deniedTools ?? new Set<string>();\n  const sections: string[] = [];\n\n  sections.push(`# Tool Usage Rules\n\nIMPORTANT: You can ONLY call tools by their exact registered names listed below. Shell commands like \\`git\\`, \\`npm\\`, \\`ls\\`, etc. are NOT tools — they must be run via the \\`execute_command\\` tool.\n\nYou have access to the following tools. Use the RIGHT tool for the job:`);\n\n  // --- Read tools (all modes) ---\n\n  const readTools: string[] = [];\n\n  if (!denied.has(MC_TOOLS.VIEW)) {\n    readTools.push(`\n**${MC_TOOLS.VIEW}** — Read file contents\n- Use this to read files before editing them. NEVER propose changes to code you haven't read.\n- Use \\`offset\\` (1-indexed start line) and \\`limit\\` (number of lines) for large files.\n- Example: Read lines 50-100: \\`{ path: \"src/big-file.ts\", offset: 50, limit: 51 }\\`\n- To list directories, use \\`${MC_TOOLS.FIND_FILES}\\` instead.`);\n  }\n\n  if (!denied.has(MC_TOOLS.SEARCH_CONTENT)) {\n    readTools.push(`\n**${MC_TOOLS.SEARCH_CONTENT}** — Search file contents using regex\n- Preferred for content search (finding functions, variables, error messages, imports, etc.)\n- Use \\`path\\` to filter by directory or glob pattern. Supports \\`contextLines\\`, \\`caseSensitive\\`, and \\`maxCount\\`.\n- Example: Find a function: \\`{ pattern: \"function handleSubmit\", path: \"**/*.ts\" }\\`\n- Example: Find imports: \\`{ pattern: \"from ['\\\\\"\\\\]express['\\\\\"\\\\]\", path: \"**/*.ts\" }\\`\n- Respects .gitignore by default.`);\n  }\n\n  if (!denied.has(MC_TOOLS.FIND_FILES)) {\n    readTools.push(`\n**${MC_TOOLS.FIND_FILES}** — List files and directories as a tree\n- Preferred for exploring project structure and finding files by pattern.\n- Returns tree-style output. Respects .gitignore by default.\n- Example: List project root: \\`{ path: \"./\" }\\`\n- Example: Find test files: \\`{ path: \"./src\", pattern: \"**/*.test.ts\" }\\`\n- Example: Find config files: \\`{ pattern: \"*.config.{js,ts,json}\" }\\``);\n  }\n\n  if (!denied.has(MC_TOOLS.EXECUTE_COMMAND)) {\n    readTools.push(`\n**${MC_TOOLS.EXECUTE_COMMAND}** — Run shell commands\n- Use for: git, npm/pnpm, docker, build tools, test runners, and other terminal operations.\n- Prefer dedicated tools for: file reading (${MC_TOOLS.VIEW}), file search (${MC_TOOLS.SEARCH_CONTENT}/${MC_TOOLS.FIND_FILES}), file editing (${MC_TOOLS.STRING_REPLACE_LSP}/${MC_TOOLS.WRITE_FILE}).\n- Commands have a 30-second default timeout. Use \\`timeout\\` for longer commands, \\`cwd\\` for working directory.\n- Use the \\`tail\\` parameter or pipe to \\`| tail -N\\` to limit output — the full output streams to the user, only the tail is returned to you. If you're building any kind of package you should be tailing.\n- Good: Run independent commands in parallel when possible.\n- Bad: Running \\`cat file.txt\\` — use the ${MC_TOOLS.VIEW} tool instead.`);\n  }\n\n  if (!denied.has(MC_TOOLS.LSP_INSPECT)) {\n    readTools.push(`\n**${MC_TOOLS.LSP_INSPECT}** — Inspect code using Language Server Protocol\n- Use this for type information, hover docs, go-to-definition, and finding implementations for a symbol.\n- Best when you already know the file and line and need semantic code intelligence rather than raw file contents.\n- Input: \\`path\\` (absolute file path), \\`line\\` (1-indexed line number), \\`match\\` (the exact line content with exactly one \\`<<<\\` cursor marker).\n- Output includes: \\`hover\\`, \\`definition\\` (compact location with preview), and \\`implementation\\` (compact usage/implementation locations).\n- Example: \\`{ path: \"/abs/path/src/foo.ts\", line: 10, match: \"const foo = <<<bar()\" }\\` — inspect the symbol at the \\`<<<\\` position.\n- Use \\`${MC_TOOLS.VIEW}\\` when you need to read the implementation or surrounding code.\n- Use \\`${MC_TOOLS.SEARCH_CONTENT}\\` or \\`${MC_TOOLS.FIND_FILES}\\` first if you do not yet know where the symbol is.`);\n  }\n\n  if (!denied.has(MC_TOOLS.NOTIFICATION_INBOX)) {\n    readTools.push(`\n**${MC_TOOLS.NOTIFICATION_INBOX}** — Inspect and manage notification inbox records\n- Use this when a \\`<notification-summary>\\` says pending notifications exist.\n- Use \\`{ \"action\": \"list\", \"status\": \"pending\" }\\` or \\`{ \"action\": \"search\", \"query\": \"...\" }\\` to find notification records for the current thread.\n- Use \\`read\\` to deliver unread notification signals into the chat and mark them seen; the tool result summarizes the count instead of exposing notification contents.\n- Use \\`dismiss\\` or \\`archive\\` only when the user asks or the notification is no longer relevant.`);\n  }\n\n  if (readTools.length > 0) {\n    sections.push(readTools.join('\\n'));\n  }\n\n  // --- Write/edit tools (build & fast only) ---\n\n  if (modeId !== 'plan') {\n    const writeTools: string[] = [];\n\n    if (!denied.has(MC_TOOLS.STRING_REPLACE_LSP)) {\n      writeTools.push(`\n**${MC_TOOLS.STRING_REPLACE_LSP}** — Edit files by replacing exact text\n- You MUST read a file with \\`${MC_TOOLS.VIEW}\\` before editing it.\n- \\`old_string\\` must be an exact match of existing text in the file.\n- Provide enough surrounding context in \\`old_string\\` to make it unique.\n- Use \\`replace_all: true\\` to replace all occurrences (default: false, requires unique match).\n- For creating new files, use \\`${MC_TOOLS.WRITE_FILE}\\` instead.\n- Good: Include 2-3 lines of surrounding context to ensure uniqueness.\n- Bad: Using just \\`return true;\\` — too common, will match multiple places.`);\n    }\n\n    if (!denied.has(MC_TOOLS.WRITE_FILE)) {\n      writeTools.push(`\n**${MC_TOOLS.WRITE_FILE}** — Create new files or overwrite existing ones\n- Use this to create new files.\n- If overwriting an existing file, you MUST have read it first with \\`${MC_TOOLS.VIEW}\\`.\n- Prefer editing existing files over creating new ones.`);\n    }\n\n    if (writeTools.length > 0) {\n      sections.push(writeTools.join('\\n'));\n    }\n  }\n\n  // --- Web tools (all modes, conditionally available) ---\n\n  if (options.hasWebSearch) {\n    const webTools: string[] = [];\n    if (!denied.has('web_search')) webTools.push('**web_search**');\n    if (!denied.has('web_extract')) webTools.push('**web_extract**');\n    if (webTools.length > 0) {\n      sections.push(`\n${webTools.join(' / ')} — Search the web / extract page content\n- Use for looking up documentation, error messages, package APIs.`);\n    }\n  }\n\n  // --- Task management tools (all modes) ---\n\n  const taskTools: string[] = [];\n  const canUpdateTask = !denied.has('task_update');\n  const canCompleteTask = !denied.has('task_complete');\n  const canCheckTasks = !denied.has('task_check');\n  const canWriteTasks = !denied.has('task_write');\n  const patchToolGuidance =\n    canUpdateTask && canCompleteTask\n      ? '- Prefer task_update or task_complete when changing one existing task.'\n      : canUpdateTask\n        ? '- Prefer task_update when changing one existing task.'\n        : canCompleteTask\n          ? '- Prefer task_complete when marking one existing task completed.'\n          : '- Use task_write with the full task list when changing existing tasks.';\n\n  if (canWriteTasks) {\n    taskTools.push(`\n**task_write** — Track tasks for complex multi-step work\n- Use when a task requires 3 or more distinct steps or actions.\n- Use task_write to create the initial task list or replace the whole list after replanning.\n- Each task has: id (stable identifier), content (imperative form), status (pending, in_progress, or completed), activeForm (present continuous form shown during execution).\n- Keep task IDs stable across updates. If you omit IDs, the tool result returns generated IDs.\n${patchToolGuidance}\n- Mark tasks \\`in_progress\\` BEFORE starting work. Only ONE task should be \\`in_progress\\` at a time.\n- Mark tasks \\`completed\\` IMMEDIATELY after finishing each task. Do not batch completions.`);\n  }\n\n  if (canUpdateTask) {\n    taskTools.push(`\n**task_update** — Patch one tracked task by ID\n- Use this for targeted changes to one existing task.\n- Provide the task ID and only the fields that changed: content, status, or activeForm.`);\n  }\n\n  if (canCompleteTask) {\n    const idSource = canCheckTasks\n      ? 'Use task_check if you need the current IDs before completing a task.'\n      : canWriteTasks\n        ? 'Use IDs returned by task_write.'\n        : 'Use only task IDs already visible in the current task list.';\n    taskTools.push(`\n**task_complete** — Mark one tracked task completed by ID\n- Use this immediately after finishing a tracked task.\n- ${idSource}`);\n  }\n\n  if (canCheckTasks) {\n    taskTools.push(`\n**task_check** — Check completion status of tasks\n- Use this BEFORE finishing tracked work to verify all tasks are completed.\n- Returns a readable status summary plus structured fields: tasks, summary, incompleteTasks, and isError.\n- summary includes total, completed, inProgress, pending, incomplete, hasTasks, and allCompleted.\n- Use summary.allCompleted to decide whether tracked work is complete; if summary.hasTasks is false, no task list is currently tracked.\n- If any tasks remain incomplete, continue working on them.\n- IMPORTANT: Always check task completion before ending work on a complex task.`);\n  }\n\n  if (!denied.has('ask_user')) {\n    taskTools.push(`\n**ask_user** — Ask the user a structured question\n- Use when you need clarification, want to validate assumptions, or need the user to make a decision.\n- Provide clear, specific questions. End with a question mark.\n- Include options (2-4 choices) for structured decisions. Omit options for open-ended questions.\n- Don't use this for simple yes/no — just ask in your text response.`);\n  }\n\n  if (taskTools.length > 0) {\n    sections.push(taskTools.join('\\n'));\n  }\n\n  // --- Plan tools (plan mode) ---\n\n  if (modeId === 'plan' && !denied.has('submit_plan')) {\n    sections.push(`\n**submit_plan** — Submit a completed implementation plan for user review\n- Call this tool when your plan is complete. Do NOT just describe your plan in text — you MUST call this tool.\n- The plan will be rendered as markdown and the user can approve, reject, or request changes.\n- On approval, the system automatically switches to the default mode so you can implement.\n- Takes one argument: \\`path\\` (the plan markdown file you wrote under \\`.mastracode/plans/\\`). Do NOT pass the plan body — it lives in the file.`);\n  }\n\n  if (modeId === 'plan') {\n    sections.push(`\n**Plan file access** — Your plan lives in a markdown file under \\`.mastracode/plans/\\` (e.g. \\`add-dark-mode-toggle.md\\`)\n- Use \\`write_file\\` to create the plan file, \\`view\\` to read it, and \\`string_replace_lsp\\` for targeted edits.\n- On first submission: write the plan to the file, then call \\`submit_plan\\` with its \\`path\\`.\n- On revision: read the existing file, edit specific sections, re-read, then call \\`submit_plan\\` with the same \\`path\\`.\n- If a plan file already exists, you previously submitted it — read it before revising.`);\n  }\n\n  // --- Subagent tool (all modes) ---\n\n  if (!denied.has('subagent')) {\n    sections.push(`\n**subagent** — Delegate a focused task to a specialized subagent\n- Only use subagents when you will spawn **multiple subagents in parallel**. If you only need one task done, do it yourself.\n- Subagent outputs are **untrusted**. Always review and verify the results.`);\n  }\n\n  return sections.join('\\n');\n}\n"],"mappings":";;;;;;;AAcA,SAAgB,kBAAkB,QAAgB,UAA+B,CAAC,GAAW;CAC3F,MAAM,SAAS,QAAQ,+BAAe,IAAI,IAAY;CACtD,MAAM,WAAqB,CAAC;CAE5B,SAAS,KAAK;;;;wEAIwD;CAItE,MAAM,YAAsB,CAAC;CAE7B,IAAI,CAAC,OAAO,IAAI,SAAS,IAAI,GAC3B,UAAU,KAAK;IACf,SAAS,KAAK;;;;+BAIa,SAAS,WAAW,YAAY;CAG7D,IAAI,CAAC,OAAO,IAAI,SAAS,cAAc,GACrC,UAAU,KAAK;IACf,SAAS,eAAe;;;;;kCAKM;CAGhC,IAAI,CAAC,OAAO,IAAI,SAAS,UAAU,GACjC,UAAU,KAAK;IACf,SAAS,WAAW;;;;;uEAK+C;CAGrE,IAAI,CAAC,OAAO,IAAI,SAAS,eAAe,GACtC,UAAU,KAAK;IACf,SAAS,gBAAgB;;8CAEiB,SAAS,KAAK,kBAAkB,SAAS,eAAe,GAAG,SAAS,WAAW,mBAAmB,SAAS,mBAAmB,GAAG,SAAS,WAAW;;;;4CAIvJ,SAAS,KAAK,eAAe;CAGvE,IAAI,CAAC,OAAO,IAAI,SAAS,WAAW,GAClC,UAAU,KAAK;IACf,SAAS,YAAY;;;;;;UAMf,SAAS,KAAK;UACd,SAAS,eAAe,UAAU,SAAS,WAAW,qDAAqD;CAGnH,IAAI,CAAC,OAAO,IAAI,SAAS,kBAAkB,GACzC,UAAU,KAAK;IACf,SAAS,mBAAmB;;;;oGAIoE;CAGlG,IAAI,UAAU,SAAS,GACrB,SAAS,KAAK,UAAU,KAAK,IAAI,CAAC;CAKpC,IAAI,WAAW,QAAQ;EACrB,MAAM,aAAuB,CAAC;EAE9B,IAAI,CAAC,OAAO,IAAI,SAAS,kBAAkB,GACzC,WAAW,KAAK;IAClB,SAAS,mBAAmB;gCACA,SAAS,KAAK;;;;kCAIZ,SAAS,WAAW;;6EAEuB;EAGzE,IAAI,CAAC,OAAO,IAAI,SAAS,UAAU,GACjC,WAAW,KAAK;IAClB,SAAS,WAAW;;wEAEgD,SAAS,KAAK;wDAC9B;EAGpD,IAAI,WAAW,SAAS,GACtB,SAAS,KAAK,WAAW,KAAK,IAAI,CAAC;CAEvC;CAIA,IAAI,QAAQ,cAAc;EACxB,MAAM,WAAqB,CAAC;EAC5B,IAAI,CAAC,OAAO,IAAI,YAAY,GAAG,SAAS,KAAK,gBAAgB;EAC7D,IAAI,CAAC,OAAO,IAAI,aAAa,GAAG,SAAS,KAAK,iBAAiB;EAC/D,IAAI,SAAS,SAAS,GACpB,SAAS,KAAK;EAClB,SAAS,KAAK,KAAK,EAAE;kEAC2C;CAEhE;CAIA,MAAM,YAAsB,CAAC;CAC7B,MAAM,gBAAgB,CAAC,OAAO,IAAI,aAAa;CAC/C,MAAM,kBAAkB,CAAC,OAAO,IAAI,eAAe;CACnD,MAAM,gBAAgB,CAAC,OAAO,IAAI,YAAY;CAC9C,MAAM,gBAAgB,CAAC,OAAO,IAAI,YAAY;CAC9C,MAAM,oBACJ,iBAAiB,kBACb,2EACA,gBACE,0DACA,kBACE,qEACA;CAEV,IAAI,eACF,UAAU,KAAK;;;;;;EAMjB,kBAAkB;;4FAEwE;CAG1F,IAAI,eACF,UAAU,KAAK;;;wFAGqE;CAGtF,IAAI,iBAAiB;EACnB,MAAM,WAAW,gBACb,yEACA,gBACE,oCACA;EACN,UAAU,KAAK;;;IAGf,UAAU;CACZ;CAEA,IAAI,eACF,UAAU,KAAK;;;;;;;gFAO6D;CAG9E,IAAI,CAAC,OAAO,IAAI,UAAU,GACxB,UAAU,KAAK;;;;;qEAKkD;CAGnE,IAAI,UAAU,SAAS,GACrB,SAAS,KAAK,UAAU,KAAK,IAAI,CAAC;CAKpC,IAAI,WAAW,UAAU,CAAC,OAAO,IAAI,aAAa,GAChD,SAAS,KAAK;;;;;kJAKgI;CAGhJ,IAAI,WAAW,QACb,SAAS,KAAK;;;;;wFAKsE;CAKtF,IAAI,CAAC,OAAO,IAAI,UAAU,GACxB,SAAS,KAAK;;;4EAG0D;CAG1E,OAAO,SAAS,KAAK,IAAI;AAC3B"}

package/dist/agents/sandbox-filesystem.d.ts

@@ -0,0 +1,99 @@
+/**
+ * SandboxFilesystem
+ *
+ * A `WorkspaceFilesystem` that stores files inside a remote `MastraSandbox`
+ * (e.g. a Railway VM) rather than on the server host. File operations are
+ * implemented by shelling out through the sandbox's `executeCommand`, so the
+ * agent's file tools and command tools share one VM and one view of the repo.
+ *
+ * Paths are workspace-relative (`/src/foo.ts`) and resolve under the sandbox
+ * working directory (`basePath`). A traversal guard rejects any path that
+ * escapes the workdir, mirroring `LocalFilesystem`'s contained mode.
+ *
+ * Reads/writes use base64 over the wire so binary content survives the shell.
+ */
+import type { CopyOptions, FileContent, FileEntry, FileStat, FilesystemInfo, ListOptions, ProviderStatus, ReadOptions, RemoveOptions, WorkspaceFilesystem, WriteOptions } from '@mastra/core/workspace';
+/** Minimal command result shape we depend on. */
+export interface SandboxCommandResult {
+    exitCode: number;
+    stdout: string;
+    stderr: string;
+}
+/** Minimal sandbox surface the filesystem needs. */
+export interface SandboxExec {
+    readonly id: string;
+    executeCommand(command: string, args?: string[], options?: {
+        timeout?: number;
+    }): Promise<SandboxCommandResult>;
+}
+export interface SandboxFilesystemOptions {
+    /** Live sandbox to run commands in. */
+    sandbox: SandboxExec;
+    /** Absolute path inside the sandbox that is the workspace root. */
+    workdir: string;
+    /** Optional stable id; defaults to a sandbox-derived id. */
+    id?: string;
+}
+export declare class SandboxFilesystem implements WorkspaceFilesystem {
+    readonly id: string;
+    readonly name = "SandboxFilesystem";
+    readonly provider = "sandbox";
+    readonly basePath: string;
+    status: ProviderStatus;
+    private readonly sandbox;
+    constructor(options: SandboxFilesystemOptions);
+    /**
+     * Resolve a workspace path to an absolute path inside the sandbox, enforcing
+     * that it stays within the workdir.
+     *
+     * Accepts both workspace-relative paths (`src/foo.ts`, `/src/foo.ts`) and
+     * absolute sandbox paths that already live under the workdir — the agent's
+     * prompt advertises the workdir as its working directory, so tools are
+     * routinely called with fully-qualified paths like `<workdir>/src/foo.ts`.
+     */
+    private resolve;
+    resolveAbsolutePath(inputPath: string): string | undefined;
+    private exec;
+    /**
+     * Lexical guard catches `..` traversal, but a symlink inside the workdir can
+     * still point outside it. After resolving a path that refers to an existing
+     * entry, verify its realpath is still contained in the workdir.
+     *
+     * Canonicalization tries `realpath`, then `readlink -f` (GNU/busybox), then
+     * `cd && pwd -P` for directories — covering GNU hosts, macOS/BSD, and
+     * busybox. If the path exists but cannot be canonicalized we fail CLOSED:
+     * returning without a check would let a symlink bypass containment.
+     */
+    private assertContainedRealpath;
+    /**
+     * Guard for write destinations. The lexical guard catches `..`, but a symlink
+     * inside the workdir can redirect a write outside it. For an existing target
+     * we check its realpath; for a not-yet-existing target we check the realpath
+     * of its nearest existing ancestor directory, since a symlinked parent is the
+     * escape vector (e.g. `link -> /etc` then writing `link/passwd`).
+     */
+    private assertContainedDest;
+    private execOk;
+    readFile(path: string, options?: ReadOptions): Promise<string | Buffer>;
+    writeFile(path: string, content: FileContent, options?: WriteOptions): Promise<void>;
+    appendFile(path: string, content: FileContent): Promise<void>;
+    deleteFile(path: string, options?: RemoveOptions): Promise<void>;
+    copyFile(src: string, dest: string, options?: CopyOptions): Promise<void>;
+    moveFile(src: string, dest: string, options?: CopyOptions): Promise<void>;
+    mkdir(path: string, options?: {
+        recursive?: boolean;
+    }): Promise<void>;
+    rmdir(path: string, options?: RemoveOptions): Promise<void>;
+    readdir(path: string, options?: ListOptions): Promise<FileEntry[]>;
+    private parseListOutput;
+    private parseFindOutput;
+    private matchesExtension;
+    exists(path: string): Promise<boolean>;
+    stat(path: string): Promise<FileStat>;
+    init(): Promise<void>;
+    destroy(): Promise<void>;
+    isReady(): Promise<boolean>;
+    getInfo(): FilesystemInfo;
+    getInstructions(): string;
+}
+//# sourceMappingURL=sandbox-filesystem.d.ts.map

package/dist/agents/sandbox-filesystem.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"sandbox-filesystem.d.ts","sourceRoot":"","sources":["../../src/agents/sandbox-filesystem.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;GAaG;AAGH,OAAO,KAAK,EACV,WAAW,EACX,WAAW,EACX,SAAS,EACT,QAAQ,EACR,cAAc,EACd,WAAW,EACX,cAAc,EACd,WAAW,EACX,aAAa,EACb,mBAAmB,EACnB,YAAY,EACb,MAAM,wBAAwB,CAAC;AAWhC,iDAAiD;AACjD,MAAM,WAAW,oBAAoB;IACnC,QAAQ,EAAE,MAAM,CAAC;IACjB,MAAM,EAAE,MAAM,CAAC;IACf,MAAM,EAAE,MAAM,CAAC;CAChB;AAED,oDAAoD;AACpD,MAAM,WAAW,WAAW;IAC1B,QAAQ,CAAC,EAAE,EAAE,MAAM,CAAC;IACpB,cAAc,CAAC,OAAO,EAAE,MAAM,EAAE,IAAI,CAAC,EAAE,MAAM,EAAE,EAAE,OAAO,CAAC,EAAE;QAAE,OAAO,CAAC,EAAE,MAAM,CAAA;KAAE,GAAG,OAAO,CAAC,oBAAoB,CAAC,CAAC;CACjH;AAED,MAAM,WAAW,wBAAwB;IACvC,uCAAuC;IACvC,OAAO,EAAE,WAAW,CAAC;IACrB,mEAAmE;IACnE,OAAO,EAAE,MAAM,CAAC;IAChB,4DAA4D;IAC5D,EAAE,CAAC,EAAE,MAAM,CAAC;CACb;AAmBD,qBAAa,iBAAkB,YAAW,mBAAmB;IAC3D,QAAQ,CAAC,EAAE,EAAE,MAAM,CAAC;IACpB,QAAQ,CAAC,IAAI,uBAAuB;IACpC,QAAQ,CAAC,QAAQ,aAAa;IAC9B,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAC;IAC1B,MAAM,EAAE,cAAc,CAAW;IAEjC,OAAO,CAAC,QAAQ,CAAC,OAAO,CAAc;gBAE1B,OAAO,EAAE,wBAAwB;IAU7C;;;;;;;;OAQG;IACH,OAAO,CAAC,OAAO;IAmBf,mBAAmB,CAAC,SAAS,EAAE,MAAM,GAAG,MAAM,GAAG,SAAS;YAM5C,IAAI;IAIlB;;;;;;;;;OASG;YACW,uBAAuB;IA0BrC;;;;;;OAMG;YACW,mBAAmB;YAWnB,MAAM;IAUd,QAAQ,CAAC,IAAI,EAAE,MAAM,EAAE,OAAO,CAAC,EAAE,WAAW,GAAG,OAAO,CAAC,MAAM,GAAG,MAAM,CAAC;IAoBvE,SAAS,CAAC,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,WAAW,EAAE,OAAO,CAAC,EAAE,YAAY,GAAG,OAAO,CAAC,IAAI,CAAC;IAqBpF,UAAU,CAAC,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,WAAW,GAAG,OAAO,CAAC,IAAI,CAAC;IAU7D,UAAU,CAAC,IAAI,EAAE,MAAM,EAAE,OAAO,CAAC,EAAE,aAAa,GAAG,OAAO,CAAC,IAAI,CAAC;IAqBhE,QAAQ,CAAC,GAAG,EAAE,MAAM,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,CAAC,EAAE,WAAW,GAAG,OAAO,CAAC,IAAI,CAAC;IA2CzE,QAAQ,CAAC,GAAG,EAAE,MAAM,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,CAAC,EAAE,WAAW,GAAG,OAAO,CAAC,IAAI,CAAC;IAqCzE,KAAK,CAAC,IAAI,EAAE,MAAM,EAAE,OAAO,CAAC,EAAE;QAAE,SAAS,CAAC,EAAE,OAAO,CAAA;KAAE,GAAG,OAAO,CAAC,IAAI,CAAC;IAOrE,KAAK,CAAC,IAAI,EAAE,MAAM,EAAE,OAAO,CAAC,EAAE,aAAa,GAAG,OAAO,CAAC,IAAI,CAAC;IAgB3D,OAAO,CAAC,IAAI,EAAE,MAAM,EAAE,OAAO,CAAC,EAAE,WAAW,GAAG,OAAO,CAAC,SAAS,EAAE,CAAC;IAuBxE,OAAO,CAAC,eAAe;IAevB,OAAO,CAAC,eAAe;IAgBvB,OAAO,CAAC,gBAAgB;IAQlB,MAAM,CAAC,IAAI,EAAE,MAAM,GAAG,OAAO,CAAC,OAAO,CAAC;IAMtC,IAAI,CAAC,IAAI,EAAE,MAAM,GAAG,OAAO,CAAC,QAAQ,CAAC;IA+BrC,IAAI,IAAI,OAAO,CAAC,IAAI,CAAC;IAIrB,OAAO,IAAI,OAAO,CAAC,IAAI,CAAC;IAIxB,OAAO,IAAI,OAAO,CAAC,OAAO,CAAC;IAKjC,OAAO,IAAI,cAAc;IAUzB,eAAe,IAAI,MAAM;CAG1B"}