Update tools test

Author: jahooma

backend/src/__tests__/__snapshots__/tools.test.ts.snap

@@ -228,6 +228,56 @@ Example:
 4. Add tests for new module</thought>
 </think_deeply>
 
+### create_plan
+
+Generate a detailed markdown plan for complex tasks.
+
+Params:
+- \`path\`: (required) The path including the filename of a markdown file that will be overwritten with the plan.
+- \`plan\`: (required) A detailed plan to solve the user's request.
+
+Use when:  
+- User explicitly requests a detailed plan.  
+- Task involves significant architectural or multi-file changes.
+- Use this tool to overwrite a previous plan by using the exact same file name.
+
+Don't include:
+- Goals, timelines, benefits, next steps.  
+- Background context or extensive explanations.
+
+For a technical plan, act as an expert architect engineer and provide direction to your editor engineer.
+- Study the change request and the current code.
+- Describe how to modify the code to complete the request. The editor engineer will rely solely on your instructions, so make them unambiguous and complete.
+- Explain all needed code changes clearly and completely, but concisely.
+- Just show the changes needed.
+
+What to include in the plan:
+- Include key snippets of code -- not full files of it. Use psuedo code. For example, include interfaces between modules, function signatures, and other code that is not immediately obvious should be written out explicitly. Function and method bodies could be written out in psuedo code.
+- Do not waste time on much background information, focus on the exact steps of the implementation.
+- Do not wrap the path content in markdown code blocks, e.g. \`\`\`.
+
+Do not include any of the following sections in the plan:
+- goals
+- a timeline or schedule
+- benefits/key improvements
+- next steps
+
+After creating than plan, you should end turn to let the user review the plan.
+
+Important: Use this tool sparingly. Do not use this tool more than once in a conversation, unless in ask mode.
+
+Examples:
+<create_plan>
+<path>feature-x-plan.md</path>
+<plan>1. Create module \`auth.ts\` in \`/src/auth/\`.
+\`\`\`ts
+export function authenticate(user: User): boolean { /* pseudo-code logic */ }
+\`\`\`
+2. Refactor existing auth logic into this module.
+3. Update imports across codebase.
+4. Write integration tests covering new module logic.</plan>
+</create_plan>
+
 ### browser_logs
 
 In a headless browser, navigate to a web page and get the console logs after page load.
@@ -737,7 +787,7 @@ Params:
 Use when:  
 - User explicitly requests a detailed plan.  
 - Task involves significant architectural or multi-file changes.
-- Only use this tool to create new plans. Do not modify existing plans using this tool—use the \`write_file\` tool instead for modifications.
+- Use this tool to overwrite a previous plan by using the exact same file name.
 
 Don't include:
 - Goals, timelines, benefits, next steps.  
@@ -750,7 +800,7 @@ For a technical plan, act as an expert architect engineer and provide direction
 - Just show the changes needed.
 
 What to include in the plan:
-- Include code, but not full files of it. Write out key snippets of code and use lots of psuedo code. For example, interfaces between modules, function signatures, and other code that is not immediately obvious should be written out explicitly. Function and method bodies could be written out in psuedo code.
+- Include key snippets of code -- not full files of it. Use psuedo code. For example, include interfaces between modules, function signatures, and other code that is not immediately obvious should be written out explicitly. Function and method bodies could be written out in psuedo code.
 - Do not waste time on much background information, focus on the exact steps of the implementation.
 - Do not wrap the path content in markdown code blocks, e.g. \`\`\`.
 
@@ -762,7 +812,7 @@ Do not include any of the following sections in the plan:
 
 After creating than plan, you should end turn to let the user review the plan.
 
-Important: Use this tool sparingly. Do not use this tool more than once in a conversation, if a plan was already created, or for similar user requests.
+Important: Use this tool sparingly. Do not use this tool more than once in a conversation, unless in ask mode.
 
 Examples:
 <create_plan>
@@ -1285,7 +1335,7 @@ Params:
 Use when:  
 - User explicitly requests a detailed plan.  
 - Task involves significant architectural or multi-file changes.
-- Only use this tool to create new plans. Do not modify existing plans using this tool—use the \`write_file\` tool instead for modifications.
+- Use this tool to overwrite a previous plan by using the exact same file name.
 
 Don't include:
 - Goals, timelines, benefits, next steps.  
@@ -1298,7 +1348,7 @@ For a technical plan, act as an expert architect engineer and provide direction
 - Just show the changes needed.
 
 What to include in the plan:
-- Include code, but not full files of it. Write out key snippets of code and use lots of psuedo code. For example, interfaces between modules, function signatures, and other code that is not immediately obvious should be written out explicitly. Function and method bodies could be written out in psuedo code.
+- Include key snippets of code -- not full files of it. Use psuedo code. For example, include interfaces between modules, function signatures, and other code that is not immediately obvious should be written out explicitly. Function and method bodies could be written out in psuedo code.
 - Do not waste time on much background information, focus on the exact steps of the implementation.
 - Do not wrap the path content in markdown code blocks, e.g. \`\`\`.
 
@@ -1310,7 +1360,7 @@ Do not include any of the following sections in the plan:
 
 After creating than plan, you should end turn to let the user review the plan.
 
-Important: Use this tool sparingly. Do not use this tool more than once in a conversation, if a plan was already created, or for similar user requests.
+Important: Use this tool sparingly. Do not use this tool more than once in a conversation, unless in ask mode.
 
 Examples:
 <create_plan>
@@ -1833,7 +1883,7 @@ Params:
 Use when:  
 - User explicitly requests a detailed plan.  
 - Task involves significant architectural or multi-file changes.
-- Only use this tool to create new plans. Do not modify existing plans using this tool—use the \`write_file\` tool instead for modifications.
+- Use this tool to overwrite a previous plan by using the exact same file name.
 
 Don't include:
 - Goals, timelines, benefits, next steps.  
@@ -1846,7 +1896,7 @@ For a technical plan, act as an expert architect engineer and provide direction
 - Just show the changes needed.
 
 What to include in the plan:
-- Include code, but not full files of it. Write out key snippets of code and use lots of psuedo code. For example, interfaces between modules, function signatures, and other code that is not immediately obvious should be written out explicitly. Function and method bodies could be written out in psuedo code.
+- Include key snippets of code -- not full files of it. Use psuedo code. For example, include interfaces between modules, function signatures, and other code that is not immediately obvious should be written out explicitly. Function and method bodies could be written out in psuedo code.
 - Do not waste time on much background information, focus on the exact steps of the implementation.
 - Do not wrap the path content in markdown code blocks, e.g. \`\`\`.
 
@@ -1858,7 +1908,7 @@ Do not include any of the following sections in the plan:
 
 After creating than plan, you should end turn to let the user review the plan.
 
-Important: Use this tool sparingly. Do not use this tool more than once in a conversation, if a plan was already created, or for similar user requests.
+Important: Use this tool sparingly. Do not use this tool more than once in a conversation, unless in ask mode.
 
 Examples:
 <create_plan>
@@ -2381,7 +2431,7 @@ Params:
 Use when:  
 - User explicitly requests a detailed plan.  
 - Task involves significant architectural or multi-file changes.
-- Only use this tool to create new plans. Do not modify existing plans using this tool—use the \`write_file\` tool instead for modifications.
+- Use this tool to overwrite a previous plan by using the exact same file name.
 
 Don't include:
 - Goals, timelines, benefits, next steps.  
@@ -2394,7 +2444,7 @@ For a technical plan, act as an expert architect engineer and provide direction
 - Just show the changes needed.
 
 What to include in the plan:
-- Include code, but not full files of it. Write out key snippets of code and use lots of psuedo code. For example, interfaces between modules, function signatures, and other code that is not immediately obvious should be written out explicitly. Function and method bodies could be written out in psuedo code.
+- Include key snippets of code -- not full files of it. Use psuedo code. For example, include interfaces between modules, function signatures, and other code that is not immediately obvious should be written out explicitly. Function and method bodies could be written out in psuedo code.
 - Do not waste time on much background information, focus on the exact steps of the implementation.
 - Do not wrap the path content in markdown code blocks, e.g. \`\`\`.
 
@@ -2406,7 +2456,7 @@ Do not include any of the following sections in the plan:
 
 After creating than plan, you should end turn to let the user review the plan.
 
-Important: Use this tool sparingly. Do not use this tool more than once in a conversation, if a plan was already created, or for similar user requests.
+Important: Use this tool sparingly. Do not use this tool more than once in a conversation, unless in ask mode.
 
 Examples:
 <create_plan>