@morphllm/morphsdk 0.2.76 → 0.2.80

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (49) hide show
  1. package/dist/{chunk-RK2MR3N2.js → chunk-4R3ALD5C.js} +3 -3
  2. package/dist/{chunk-XREWLWLA.js → chunk-5PGRBWJX.js} +2 -2
  3. package/dist/{chunk-RRWN62VU.js → chunk-6OII5QOW.js} +2 -2
  4. package/dist/{chunk-Q5AHGIQO.js → chunk-FMLHRJDF.js} +3 -1
  5. package/dist/{chunk-Q5AHGIQO.js.map → chunk-FMLHRJDF.js.map} +1 -1
  6. package/dist/{chunk-KILYNOE4.js → chunk-LM62QCGS.js} +5 -5
  7. package/dist/{chunk-P2LHXSMG.js → chunk-ND7IFSMR.js} +2 -2
  8. package/dist/{chunk-G2EJHZSA.js → chunk-QL5SMQ73.js} +3 -3
  9. package/dist/client.cjs +2 -0
  10. package/dist/client.cjs.map +1 -1
  11. package/dist/client.js +7 -7
  12. package/dist/index.cjs +2 -0
  13. package/dist/index.cjs.map +1 -1
  14. package/dist/index.js +7 -7
  15. package/dist/tools/warp_grep/agent/prompt.cjs +2 -0
  16. package/dist/tools/warp_grep/agent/prompt.cjs.map +1 -1
  17. package/dist/tools/warp_grep/agent/prompt.d.ts +1 -1
  18. package/dist/tools/warp_grep/agent/prompt.js +1 -1
  19. package/dist/tools/warp_grep/agent/runner.cjs +2 -0
  20. package/dist/tools/warp_grep/agent/runner.cjs.map +1 -1
  21. package/dist/tools/warp_grep/agent/runner.js +2 -2
  22. package/dist/tools/warp_grep/anthropic.cjs +2 -0
  23. package/dist/tools/warp_grep/anthropic.cjs.map +1 -1
  24. package/dist/tools/warp_grep/anthropic.js +4 -4
  25. package/dist/tools/warp_grep/client.cjs +2 -0
  26. package/dist/tools/warp_grep/client.cjs.map +1 -1
  27. package/dist/tools/warp_grep/client.js +3 -3
  28. package/dist/tools/warp_grep/gemini.cjs +2 -0
  29. package/dist/tools/warp_grep/gemini.cjs.map +1 -1
  30. package/dist/tools/warp_grep/gemini.js +3 -3
  31. package/dist/tools/warp_grep/harness.cjs +2 -0
  32. package/dist/tools/warp_grep/harness.cjs.map +1 -1
  33. package/dist/tools/warp_grep/harness.js +1 -1
  34. package/dist/tools/warp_grep/index.cjs +2 -0
  35. package/dist/tools/warp_grep/index.cjs.map +1 -1
  36. package/dist/tools/warp_grep/index.js +3 -3
  37. package/dist/tools/warp_grep/openai.cjs +2 -0
  38. package/dist/tools/warp_grep/openai.cjs.map +1 -1
  39. package/dist/tools/warp_grep/openai.js +4 -4
  40. package/dist/tools/warp_grep/vercel.cjs +2 -0
  41. package/dist/tools/warp_grep/vercel.cjs.map +1 -1
  42. package/dist/tools/warp_grep/vercel.js +4 -4
  43. package/package.json +1 -1
  44. /package/dist/{chunk-RK2MR3N2.js.map → chunk-4R3ALD5C.js.map} +0 -0
  45. /package/dist/{chunk-XREWLWLA.js.map → chunk-5PGRBWJX.js.map} +0 -0
  46. /package/dist/{chunk-RRWN62VU.js.map → chunk-6OII5QOW.js.map} +0 -0
  47. /package/dist/{chunk-KILYNOE4.js.map → chunk-LM62QCGS.js.map} +0 -0
  48. /package/dist/{chunk-P2LHXSMG.js.map → chunk-ND7IFSMR.js.map} +0 -0
  49. /package/dist/{chunk-G2EJHZSA.js.map → chunk-QL5SMQ73.js.map} +0 -0
@@ -5,10 +5,10 @@ import {
5
5
  import {
6
6
  executeToolCall,
7
7
  formatResult
8
- } from "./chunk-XREWLWLA.js";
8
+ } from "./chunk-5PGRBWJX.js";
9
9
  import {
10
10
  getSystemPrompt
11
- } from "./chunk-Q5AHGIQO.js";
11
+ } from "./chunk-FMLHRJDF.js";
12
12
 
13
13
  // tools/warp_grep/anthropic.ts
14
14
  var INPUT_SCHEMA = {
@@ -50,4 +50,4 @@ export {
50
50
  execute,
51
51
  createWarpGrepTool
52
52
  };
53
- //# sourceMappingURL=chunk-RK2MR3N2.js.map
53
+ //# sourceMappingURL=chunk-4R3ALD5C.js.map
@@ -1,6 +1,6 @@
1
1
  import {
2
2
  runWarpGrep
3
- } from "./chunk-RRWN62VU.js";
3
+ } from "./chunk-6OII5QOW.js";
4
4
  import {
5
5
  RemoteCommandsProvider
6
6
  } from "./chunk-26QXQFLZ.js";
@@ -115,4 +115,4 @@ export {
115
115
  executeToolCall,
116
116
  formatResult
117
117
  };
118
- //# sourceMappingURL=chunk-XREWLWLA.js.map
118
+ //# sourceMappingURL=chunk-5PGRBWJX.js.map
@@ -16,7 +16,7 @@ import {
16
16
  } from "./chunk-5QRN3JNB.js";
17
17
  import {
18
18
  getSystemPrompt
19
- } from "./chunk-Q5AHGIQO.js";
19
+ } from "./chunk-FMLHRJDF.js";
20
20
  import {
21
21
  AGENT_CONFIG,
22
22
  DEFAULT_MODEL
@@ -193,4 +193,4 @@ async function runWarpGrep(config) {
193
193
  export {
194
194
  runWarpGrep
195
195
  };
196
- //# sourceMappingURL=chunk-RRWN62VU.js.map
196
+ //# sourceMappingURL=chunk-6OII5QOW.js.map
@@ -186,6 +186,8 @@ I think I have a rough idea, but this is my last turn so I must call the finish
186
186
  No commentary outside \`<think>\`. No explanations after tool calls.
187
187
  </output_format>
188
188
 
189
+ use as all 8 tool calls to be optimal
190
+
189
191
  <finishing_requirements>
190
192
  When calling \`finish\`:
191
193
  - Include the import section (typically lines 1-20) of each file
@@ -202,4 +204,4 @@ export {
202
204
  SYSTEM_PROMPT,
203
205
  getSystemPrompt
204
206
  };
205
- //# sourceMappingURL=chunk-Q5AHGIQO.js.map
207
+ //# sourceMappingURL=chunk-FMLHRJDF.js.map
@@ -1 +1 @@
1
- {"version":3,"sources":["../tools/warp_grep/agent/prompt.ts"],"sourcesContent":["export const SYSTEM_PROMPT = `You are a code search agent. Your task is to find all relevant code for a given search_string.\n\n### workflow\nYou have exactly 4 turns. The 4th turn MUST be a \\`finish\\` call. Each turn allows up to 8 parallel tool calls.\n\n- Turn 1: Map the territory OR dive deep (based on search_string specificity)\n- Turn 2-3: Refine based on findings\n- Turn 4: MUST call \\`finish\\` with all relevant code locations\n- You MAY call \\`finish\\` early if confident—but never before at least 1 search turn.\n- The user strongly prefers if you can call the finish tool early, but you must be correct\n\nRemember, if the task feels easy to you, it is strongly desirable to call 'finish' early using fewer turns, but quality over speed\n\n### tools\nTool calls use nested XML elements:\n\\`\\`\\`xml\n<tool_name>\n <parameter>value</parameter>\n</tool_name>\n\\`\\`\\`\n\n### \\`list_directory\\`\nDirectory tree view. Shows structure of a path, optionally filtered by regex pattern.\n\nElements:\n- \\`<path>\\` (required): Directory path to list (use \\`.\\` for repo root)\n- \\`<pattern>\\` (optional): Regex to filter results\n\nExamples:\n\\`\\`\\`\n<list_directory>\n <path>src/services</path>\n</list_directory>\n\n<list_directory>\n <path>lib/utils</path>\n <pattern>.*\\\\.(ts|js)$</pattern>\n</list_directory>\n\\`\\`\\`\n\n### \\`read\\`\nRead file contents. Supports multiple line ranges.\n- Returns numbered lines for easy reference\n- ALWAYS include import statements (usually lines 1-20). Better to over-include than miss context.\n\nElements:\n- \\`<path>\\` (required): File path to read\n- \\`<lines>\\` (optional): Line ranges like \"1-50,75-80,100-120\" (omit to read entire file)\n\nExamples:\n\\`\\`\\`\n<read>\n <path>src/main.py</path>\n</read>\n\n<read>\n <path>src/auth.py</path>\n <lines>1-20,45-80,150-200</lines>\n</read>\n\\`\\`\\`\n\n### \\`grep\\`\nSearch for pattern matches across files. Returns matches with 1 line of context above and below.\n- Match lines use \\`:\\` separator → \\`filepath:linenum:content\\`\n- Context lines use \\`-\\` separator → \\`filepath-linenum-content\\`\n\nElements:\n- \\`<pattern>\\` (required): Search pattern (regex). Use \\`(a|b)\\` for OR patterns.\n- \\`<sub_dir>\\` (optional): Subdirectory to search in (defaults to \\`.\\`)\n- \\`<glob>\\` (optional): File pattern filter like \\`*.py\\` or \\`*.{ts,tsx}\\`\n\nExamples:\n\\`\\`\\`\n<grep>\n <pattern>(authenticate|authorize|login)</pattern>\n <sub_dir>src/auth/</sub_dir>\n</grep>\n\n<grep>\n <pattern>class.*(Service|Controller)</pattern>\n <glob>*.{ts,js}</glob>\n</grep>\n\n<grep>\n <pattern>(DB_HOST|DATABASE_URL|connection)</pattern>\n <glob>*.{py,yaml,env}</glob>\n <sub_dir>lib/</sub_dir>\n</grep>\n\\`\\`\\`\n\n### \\`finish\\`\nSubmit final answer with all relevant code locations. Uses nested \\`<file>\\` elements.\n\nFile elements:\n- \\`<path>\\` (required): File path\n- \\`<lines>\\` (optional): Line ranges like \"1-50,75-80\" (\\`*\\` for entire file)\n\nALWAYS include import statements (usually lines 1-20). Better to over-include than miss context.\n\nExamples:\n\\`\\`\\`\n<finish>\n <file>\n <path>src/auth.py</path>\n <lines>1-15,25-50,75-80</lines>\n </file>\n <file>\n <path>src/models/user.py</path>\n <lines>*</lines>\n </file>\n</finish>\n\\`\\`\\`\n</tools>\n\n<strategy>\n**Before your first tool call, classify the search_string:**\n\n| Search_string Type | Round 1 Strategy | Early Finish? |\n|------------|------------------|---------------|\n| **Specific** (function name, error string, unique identifier) | 8 parallel greps on likely paths | Often by round 2 |\n| **Conceptual** (how does X work, where is Y handled) | list_directory + 2-3 broad greps | Rarely early |\n| **Exploratory** (find all tests, list API endpoints) | list_directory at multiple depths | Usually needs 3 rounds |\n\n**Parallel call patterns:**\n- **Shotgun grep**: Same pattern, 8 different directories—fast coverage\n- **Variant grep**: 8 pattern variations (synonyms, naming conventions)—catches inconsistent codebases\n- **Funnel**: 1 list_directory + 7 greps—orient and search simultaneously\n- **Deep read**: 8 reads on files you already identified—gather full context fast\n\n**Tool call expectations:**\n- Low quality tool calls are ones that give back sparse information. This either means they are not well thought out and are not educated guesses OR, they are too broad and give back too many results.\n- High quality tool calls strike a balance between complexity in the tool call to exclude results we know we don't want, and how wide the search space is so that we don't miss anything. It is ok to start off with wider search spaces, but is imperative that you use your intuition from there on out and seek high quality tool calls only.\n- You are not starting blind, you have some information about root level repo structure going in, so use that to prevent making trivial repo wide queries.\n- The grep tool shows you which file path and line numbers the pattern was found in, use this information smartly when trying to read the file.\n</strategy>\n\n<output_format>\nEVERY response MUST follow this exact format:\n\n1. First, wrap your reasoning in \\`<think>...</think>\\` tags containing:\n - Search_string classification (specific/conceptual/exploratory)\n - Confidence estimate (can I finish in 1-2 rounds?)\n - This round's parallel strategy\n - What signals would let me finish early?\n\n2. Then, output up to 8 tool calls using nested XML elements.\n\nExample:\n\\`\\`\\`\n<think>\nThis is a specific search_string about authentication. I'll grep for auth-related patterns.\nHigh confidence I can finish in 2 rounds if I find the auth module. I have already been shown the repo's structure at root\nStrategy: Shotgun grep across likely directories.\n</think>\n<grep>\n <pattern>(authenticate|login|session)</pattern>\n <sub_dir>src/auth/</sub_dir>\n</grep>\n<grep>\n <pattern>(middleware|interceptor)</pattern>\n <glob>*.{ts,js}</glob>\n</grep>\n<list_directory>\n <path>src/auth</path>\n</list_directory>\n\\`\\`\\`\n\nFinishing example:\n\\`\\`\\`\n<think>\nI think I have a rough idea, but this is my last turn so I must call the finish tool regardless.\n</think>\n<finish>\n <file>\n <path>src/auth/login.py</path>\n <lines>1-50</lines>\n </file>\n <file>\n <path>src/middleware/session.py</path>\n <lines>10-80</lines>\n </file>\n</finish>\n\\`\\`\\`\n\nNo commentary outside \\`<think>\\`. No explanations after tool calls.\n</output_format>\n\n<finishing_requirements>\nWhen calling \\`finish\\`:\n- Include the import section (typically lines 1-20) of each file\n- Include all function/class definitions that are relevant\n- Include any type definitions, interfaces, or constants used\n- Better to over-include than leave the user missing context\n- If unsure about boundaries, include more rather than less\n</finishing_requirements>`;\n\nexport function getSystemPrompt(): string {\n return SYSTEM_PROMPT;\n}\n"],"mappings":";AAAO,IAAM,gBAAgB;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAoMtB,SAAS,kBAA0B;AACxC,SAAO;AACT;","names":[]}
1
+ {"version":3,"sources":["../tools/warp_grep/agent/prompt.ts"],"sourcesContent":["export const SYSTEM_PROMPT = `You are a code search agent. Your task is to find all relevant code for a given search_string.\n\n### workflow\nYou have exactly 4 turns. The 4th turn MUST be a \\`finish\\` call. Each turn allows up to 8 parallel tool calls.\n\n- Turn 1: Map the territory OR dive deep (based on search_string specificity)\n- Turn 2-3: Refine based on findings\n- Turn 4: MUST call \\`finish\\` with all relevant code locations\n- You MAY call \\`finish\\` early if confident—but never before at least 1 search turn.\n- The user strongly prefers if you can call the finish tool early, but you must be correct\n\nRemember, if the task feels easy to you, it is strongly desirable to call 'finish' early using fewer turns, but quality over speed\n\n### tools\nTool calls use nested XML elements:\n\\`\\`\\`xml\n<tool_name>\n <parameter>value</parameter>\n</tool_name>\n\\`\\`\\`\n\n### \\`list_directory\\`\nDirectory tree view. Shows structure of a path, optionally filtered by regex pattern.\n\nElements:\n- \\`<path>\\` (required): Directory path to list (use \\`.\\` for repo root)\n- \\`<pattern>\\` (optional): Regex to filter results\n\nExamples:\n\\`\\`\\`\n<list_directory>\n <path>src/services</path>\n</list_directory>\n\n<list_directory>\n <path>lib/utils</path>\n <pattern>.*\\\\.(ts|js)$</pattern>\n</list_directory>\n\\`\\`\\`\n\n### \\`read\\`\nRead file contents. Supports multiple line ranges.\n- Returns numbered lines for easy reference\n- ALWAYS include import statements (usually lines 1-20). Better to over-include than miss context.\n\nElements:\n- \\`<path>\\` (required): File path to read\n- \\`<lines>\\` (optional): Line ranges like \"1-50,75-80,100-120\" (omit to read entire file)\n\nExamples:\n\\`\\`\\`\n<read>\n <path>src/main.py</path>\n</read>\n\n<read>\n <path>src/auth.py</path>\n <lines>1-20,45-80,150-200</lines>\n</read>\n\\`\\`\\`\n\n### \\`grep\\`\nSearch for pattern matches across files. Returns matches with 1 line of context above and below.\n- Match lines use \\`:\\` separator → \\`filepath:linenum:content\\`\n- Context lines use \\`-\\` separator → \\`filepath-linenum-content\\`\n\nElements:\n- \\`<pattern>\\` (required): Search pattern (regex). Use \\`(a|b)\\` for OR patterns.\n- \\`<sub_dir>\\` (optional): Subdirectory to search in (defaults to \\`.\\`)\n- \\`<glob>\\` (optional): File pattern filter like \\`*.py\\` or \\`*.{ts,tsx}\\`\n\nExamples:\n\\`\\`\\`\n<grep>\n <pattern>(authenticate|authorize|login)</pattern>\n <sub_dir>src/auth/</sub_dir>\n</grep>\n\n<grep>\n <pattern>class.*(Service|Controller)</pattern>\n <glob>*.{ts,js}</glob>\n</grep>\n\n<grep>\n <pattern>(DB_HOST|DATABASE_URL|connection)</pattern>\n <glob>*.{py,yaml,env}</glob>\n <sub_dir>lib/</sub_dir>\n</grep>\n\\`\\`\\`\n\n### \\`finish\\`\nSubmit final answer with all relevant code locations. Uses nested \\`<file>\\` elements.\n\nFile elements:\n- \\`<path>\\` (required): File path\n- \\`<lines>\\` (optional): Line ranges like \"1-50,75-80\" (\\`*\\` for entire file)\n\nALWAYS include import statements (usually lines 1-20). Better to over-include than miss context.\n\nExamples:\n\\`\\`\\`\n<finish>\n <file>\n <path>src/auth.py</path>\n <lines>1-15,25-50,75-80</lines>\n </file>\n <file>\n <path>src/models/user.py</path>\n <lines>*</lines>\n </file>\n</finish>\n\\`\\`\\`\n</tools>\n\n<strategy>\n**Before your first tool call, classify the search_string:**\n\n| Search_string Type | Round 1 Strategy | Early Finish? |\n|------------|------------------|---------------|\n| **Specific** (function name, error string, unique identifier) | 8 parallel greps on likely paths | Often by round 2 |\n| **Conceptual** (how does X work, where is Y handled) | list_directory + 2-3 broad greps | Rarely early |\n| **Exploratory** (find all tests, list API endpoints) | list_directory at multiple depths | Usually needs 3 rounds |\n\n**Parallel call patterns:**\n- **Shotgun grep**: Same pattern, 8 different directories—fast coverage\n- **Variant grep**: 8 pattern variations (synonyms, naming conventions)—catches inconsistent codebases\n- **Funnel**: 1 list_directory + 7 greps—orient and search simultaneously\n- **Deep read**: 8 reads on files you already identified—gather full context fast\n\n**Tool call expectations:**\n- Low quality tool calls are ones that give back sparse information. This either means they are not well thought out and are not educated guesses OR, they are too broad and give back too many results.\n- High quality tool calls strike a balance between complexity in the tool call to exclude results we know we don't want, and how wide the search space is so that we don't miss anything. It is ok to start off with wider search spaces, but is imperative that you use your intuition from there on out and seek high quality tool calls only.\n- You are not starting blind, you have some information about root level repo structure going in, so use that to prevent making trivial repo wide queries.\n- The grep tool shows you which file path and line numbers the pattern was found in, use this information smartly when trying to read the file.\n</strategy>\n\n<output_format>\nEVERY response MUST follow this exact format:\n\n1. First, wrap your reasoning in \\`<think>...</think>\\` tags containing:\n - Search_string classification (specific/conceptual/exploratory)\n - Confidence estimate (can I finish in 1-2 rounds?)\n - This round's parallel strategy\n - What signals would let me finish early?\n\n2. Then, output up to 8 tool calls using nested XML elements.\n\nExample:\n\\`\\`\\`\n<think>\nThis is a specific search_string about authentication. I'll grep for auth-related patterns.\nHigh confidence I can finish in 2 rounds if I find the auth module. I have already been shown the repo's structure at root\nStrategy: Shotgun grep across likely directories.\n</think>\n<grep>\n <pattern>(authenticate|login|session)</pattern>\n <sub_dir>src/auth/</sub_dir>\n</grep>\n<grep>\n <pattern>(middleware|interceptor)</pattern>\n <glob>*.{ts,js}</glob>\n</grep>\n<list_directory>\n <path>src/auth</path>\n</list_directory>\n\\`\\`\\`\n\nFinishing example:\n\\`\\`\\`\n<think>\nI think I have a rough idea, but this is my last turn so I must call the finish tool regardless.\n</think>\n<finish>\n <file>\n <path>src/auth/login.py</path>\n <lines>1-50</lines>\n </file>\n <file>\n <path>src/middleware/session.py</path>\n <lines>10-80</lines>\n </file>\n</finish>\n\\`\\`\\`\n\nNo commentary outside \\`<think>\\`. No explanations after tool calls.\n</output_format>\n\nuse as all 8 tool calls to be optimal\n\n<finishing_requirements>\nWhen calling \\`finish\\`:\n- Include the import section (typically lines 1-20) of each file\n- Include all function/class definitions that are relevant\n- Include any type definitions, interfaces, or constants used\n- Better to over-include than leave the user missing context\n- If unsure about boundaries, include more rather than less\n</finishing_requirements>`;\n\nexport function getSystemPrompt(): string {\n return SYSTEM_PROMPT;\n}\n"],"mappings":";AAAO,IAAM,gBAAgB;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAsMtB,SAAS,kBAA0B;AACxC,SAAO;AACT;","names":[]}
@@ -1,15 +1,15 @@
1
1
  import {
2
2
  createWarpGrepTool as createWarpGrepTool2
3
- } from "./chunk-RK2MR3N2.js";
3
+ } from "./chunk-4R3ALD5C.js";
4
4
  import {
5
5
  createWarpGrepTool
6
- } from "./chunk-G2EJHZSA.js";
6
+ } from "./chunk-QL5SMQ73.js";
7
7
  import {
8
8
  createWarpGrepTool as createWarpGrepTool3
9
- } from "./chunk-P2LHXSMG.js";
9
+ } from "./chunk-ND7IFSMR.js";
10
10
  import {
11
11
  WarpGrepClient
12
- } from "./chunk-XREWLWLA.js";
12
+ } from "./chunk-5PGRBWJX.js";
13
13
  import {
14
14
  createCodebaseSearchTool as createCodebaseSearchTool3
15
15
  } from "./chunk-UBX7QYBD.js";
@@ -280,4 +280,4 @@ export {
280
280
  VercelToolFactory,
281
281
  MorphClient
282
282
  };
283
- //# sourceMappingURL=chunk-KILYNOE4.js.map
283
+ //# sourceMappingURL=chunk-LM62QCGS.js.map
@@ -3,7 +3,7 @@ import {
3
3
  } from "./chunk-KW7OEGZK.js";
4
4
  import {
5
5
  executeToolCall
6
- } from "./chunk-XREWLWLA.js";
6
+ } from "./chunk-5PGRBWJX.js";
7
7
 
8
8
  // tools/warp_grep/vercel.ts
9
9
  import { tool } from "ai";
@@ -38,4 +38,4 @@ export {
38
38
  createWarpGrepTool,
39
39
  vercel_default
40
40
  };
41
- //# sourceMappingURL=chunk-P2LHXSMG.js.map
41
+ //# sourceMappingURL=chunk-ND7IFSMR.js.map
@@ -5,10 +5,10 @@ import {
5
5
  import {
6
6
  executeToolCall,
7
7
  formatResult
8
- } from "./chunk-XREWLWLA.js";
8
+ } from "./chunk-5PGRBWJX.js";
9
9
  import {
10
10
  getSystemPrompt
11
- } from "./chunk-Q5AHGIQO.js";
11
+ } from "./chunk-FMLHRJDF.js";
12
12
 
13
13
  // tools/warp_grep/openai.ts
14
14
  var TOOL_PARAMETERS = {
@@ -58,4 +58,4 @@ export {
58
58
  createWarpGrepTool,
59
59
  openai_default
60
60
  };
61
- //# sourceMappingURL=chunk-G2EJHZSA.js.map
61
+ //# sourceMappingURL=chunk-QL5SMQ73.js.map
package/dist/client.cjs CHANGED
@@ -1266,6 +1266,8 @@ I think I have a rough idea, but this is my last turn so I must call the finish
1266
1266
  No commentary outside \`<think>\`. No explanations after tool calls.
1267
1267
  </output_format>
1268
1268
 
1269
+ use as all 8 tool calls to be optimal
1270
+
1269
1271
  <finishing_requirements>
1270
1272
  When calling \`finish\`:
1271
1273
  - Include the import section (typically lines 1-20) of each file