mastracode 0.19.1-alpha.2 → 0.19.1-alpha.3

package/CHANGELOG.md

@@ -1,5 +1,19 @@
 # mastracode
 
+## 0.19.1-alpha.3
+
+### Patch Changes
+
+- Improve goal mode UX: ([#16654](https://github.com/mastra-ai/mastra/pull/16654))
+  - Add `/goal` actions and built-in subcommand autocomplete.
+  - Add goal-aware planning guidance so submitted plans can be used as executable goals.
+  - Let the judge evaluate full assistant responses and verify work with readonly workspace tools.
+  - Stream muted judge activity into the goal box and support Ctrl+C judge aborts.
+  - Show duration-based goal status and clearer plan approval rendering with streamed plan previews.
+
+- Updated dependencies [[`271c044`](https://github.com/mastra-ai/mastra/commit/271c044f6b79ff38cfa3409f4385fbd26a0f3185), [`75c7c38`](https://github.com/mastra-ai/mastra/commit/75c7c38a4e9af9821931539dd339f57fcc6414e3)]:
+  - @mastra/core@1.35.0-alpha.3
+
 ## 0.19.1-alpha.2
 
 ### Patch Changes

package/dist/agents/prompts/base.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"base.d.ts","sourceRoot":"","sources":["../../../src/agents/prompts/base.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH,MAAM,WAAW,aAAa;IAC5B,WAAW,EAAE,MAAM,CAAC;IACpB,WAAW,EAAE,MAAM,CAAC;IACpB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,QAAQ,EAAE,MAAM,CAAC;IACjB,cAAc,CAAC,EAAE;QAAE,IAAI,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,GAAG,IAAI,CAAA;KAAE,EAAE,CAAC;IACzD,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,EAAE,MAAM,CAAC;IACb,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,UAAU,CAAC,EAAE;QAAE,KAAK,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAC;QAAC,UAAU,EAAE,MAAM,CAAA;KAAE,GAAG,IAAI,CAAC;IACxE,YAAY,EAAE,MAAM,CAAC;CACtB;AAED,wBAAgB,eAAe,CAAC,GAAG,EAAE,aAAa,GAAG,MAAM,CA4H1D"}
+{"version":3,"file":"base.d.ts","sourceRoot":"","sources":["../../../src/agents/prompts/base.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH,MAAM,WAAW,aAAa;IAC5B,WAAW,EAAE,MAAM,CAAC;IACpB,WAAW,EAAE,MAAM,CAAC;IACpB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,QAAQ,EAAE,MAAM,CAAC;IACjB,cAAc,CAAC,EAAE;QAAE,IAAI,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,GAAG,IAAI,CAAA;KAAE,EAAE,CAAC;IACzD,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,EAAE,MAAM,CAAC;IACb,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,UAAU,CAAC,EAAE;QAAE,KAAK,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAC;QAAC,UAAU,EAAE,MAAM,CAAA;KAAE,GAAG,IAAI,CAAC;IACxE,YAAY,EAAE,MAAM,CAAC;CACtB;AAED,wBAAgB,eAAe,CAAC,GAAG,EAAE,aAAa,GAAG,MAAM,CAmI1D"}

package/dist/agents/prompts/plan.d.ts

@@ -1,5 +1,5 @@
 /**
  * Plan mode prompt — read-only exploration and planning.
  */
-export declare const planModePrompt = "\n# Plan Mode \u2014 READ-ONLY\n\nYou are in PLAN mode. Your job is to explore the codebase and design an implementation plan \u2014 NOT to make changes.\n\n## CRITICAL: Read-Only Mode\n\nThis mode is **strictly read-only**. You must NOT modify anything.\n\n- Do NOT modify, create, or delete any 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\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 \u2014 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## 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## IMMEDIATE ACTION: Call submit_plan Tool\n\nAs soon as your plan is complete, **STOP** and call the `submit_plan` tool immediately.\n\n**CRITICAL:** Do NOT generate a long text response describing your plan. The plan content belongs in the `submit_plan` tool call, not in your text output.\n\nWhen done, call:\n```javascript\nsubmit_plan({\n  title: \"short descriptive title\",\n  plan: \"your full plan in markdown\"\n})\n```\n\nThe user will see the plan rendered inline and can:\n- **Approve** \u2014 automatically switches to Build mode for implementation\n- **Reject** \u2014 stays in Plan mode\n- **Request changes** \u2014 provides feedback for you to revise and resubmit\n\nDo NOT start implementing until the plan is approved. If rejected with feedback, revise the plan and call `submit_plan` again.\n";
+export declare const planModePrompt = "\n# Plan Mode \u2014 READ-ONLY\n\nYou are in PLAN mode. Your job is to explore the codebase and design an implementation plan \u2014 NOT to make changes.\n\n## CRITICAL: Read-Only Mode\n\nThis mode is **strictly read-only**. You must NOT modify anything.\n\n- Do NOT modify, create, or delete any 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\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 \u2014 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## IMMEDIATE ACTION: Call submit_plan Tool\n\nAs soon as your plan is complete, **STOP** and call the `submit_plan` tool immediately.\n\n**CRITICAL:** Do NOT generate a long text response describing your plan. The plan content belongs in the `submit_plan` tool call, not in your text output.\n\nWhen done, call:\n```javascript\nsubmit_plan({\n  title: \"short descriptive title\",\n  plan: \"your full plan in markdown\"\n})\n```\n\nThe user will see the plan rendered inline and can:\n- **Approve** \u2014 automatically switches to Build mode for implementation\n- **Start as goal** \u2014 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- **Reject** \u2014 stays in Plan mode\n- **Request changes** \u2014 provides feedback for you to revise and resubmit\n\nDo NOT start implementing until the plan is approved. If rejected with feedback, revise the plan and call `submit_plan` again.\n";
 //# sourceMappingURL=plan.d.ts.map

package/dist/agents/prompts/plan.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"plan.d.ts","sourceRoot":"","sources":["../../../src/agents/prompts/plan.ts"],"names":[],"mappings":"AAAA;;GAEG;AAEH,eAAO,MAAM,cAAc,0sFAmE1B,CAAC"}
+{"version":3,"file":"plan.d.ts","sourceRoot":"","sources":["../../../src/agents/prompts/plan.ts"],"names":[],"mappings":"AAAA;;GAEG;AAEH,eAAO,MAAM,cAAc,i4GA4E1B,CAAC"}