pybao-cli 1.5.46 → 1.5.49

package/dist/{chunk-LSDHJWLA.js → chunk-UEF22EAA.js}

@@ -3,13 +3,13 @@ const require = __pybCreateRequire(import.meta.url);
 import {
   getSettingsFileCandidates,
   loadSettingsWithLegacyFallback
-} from "./chunk-J2NQVO6G.js";
+} from "./chunk-JJNZ7WEP.js";
 import {
   getSessionPlugins
 } from "./chunk-BJSWTHRM.js";
 import {
   getTheme
-} from "./chunk-4K3MGWZ7.js";
+} from "./chunk-AKDLTQJZ.js";
 import {
   addMcprcServerForTesting,
   getCurrentProjectConfig,
@@ -19,13 +19,13 @@ import {
   safeParseJSON,
   saveCurrentProjectConfig,
   saveGlobalConfig
-} from "./chunk-C2NMYFPN.js";
+} from "./chunk-NYRCQC7E.js";
 import {
   PRODUCT_COMMAND,
   PRODUCT_NAME,
   getCwd,
   logMCPError
-} from "./chunk-J2UQWSDT.js";
+} from "./chunk-ZBUV2OFZ.js";
 
 // src/services/mcp/client.ts
 import { existsSync as existsSync2, readFileSync as readFileSync2 } from "fs";
@@ -695,6 +695,7 @@ function FallbackToolUseRejectedMessage() {
 }
 
 // src/tools/mcp/MCPTool/prompt.ts
+var TOOL_NAME = "mcp";
 var PROMPT = "";
 var DESCRIPTION = "";
 
@@ -906,6 +907,545 @@ function normalizeSandboxRuntimeConfigFromSettings(settings, options) {
   };
 }
 
+// src/tools/filesystem/FileReadTool/prompt.ts
+var MAX_LINES_TO_READ = 2e3;
+var MAX_LINE_LENGTH = 2e3;
+var TOOL_NAME2 = "Read";
+var DESCRIPTION2 = "Read a file or directory from the local filesystem.";
+var PROMPT2 = `Reads a file or directory from the local filesystem. You can access any file or directory directly by using this tool.Assume this tool is able to read all files on the machine. If the User provides a path to a file assume that path is valid; otherwise, Ensure the path is confirmed by Glob/Grep before reading.
+
+## Best Practice
+- **Read vs Analyze**: Use this tool when you need to inspect full implementation details.
+- **Workflow**: Locate file (Glob/Grep) -> Read file (FileRead) -> Edit file.
+- **Avoid**: Do not use this to 'search' for code strings; use 'Grep' or 'Glob' for that.
+
+## When NOT to Use Read Tool
+- **Unverified Paths**: Do NOT read a file if the path was inferred or guessed from context. Always verify the path exists using Glob/Grep first.
+- **Exploration Phase**: When exploring unfamiliar code, do NOT assume file locations. Use Glob/Grep to discover actual paths before reading.
+- It is okay to read a file that does not exist; an error will be returned. 
+
+## Usage Details
+- The file_path parameter must be an absolute path, not a relative path
+- This tool supports both file mode and directory mode
+- In directory mode, offset/limit are 1-based entry pagination and offset>=1 is required
+- In file mode, offset/limit are 1-based line pagination; offset=1 starts from the first line shown in cat -n output
+- By default, file mode reads up to ${MAX_LINES_TO_READ} lines starting from the beginning of the file
+- You can optionally specify a line offset and limit (especially handy for long files). **Smart Truncation is active** only in file mode when \`limit\` is provided and \`symbol_name\` is not provided: if your limit cuts a function or class in the middle, the tool will automatically extend the read range to include the full semantic block (up to 500 extra lines).
+- Smart Truncation is a best-effort semantic boundary repair (Tree-sitter). If semantic parsing fails, Read falls back to the original offset/limit window.
+- symbol_name enables LSP-assisted symbol read: provide an exact symbol name to resolve the symbol range and read that block directly
+- When \`symbol_name\` is provided, Read resolves symbol range via LSP and reads that block directly (offset/limit are ignored for range selection).
+- Use symbol_name only after file path is confirmed and when you need a specific class/function definition; if symbol is missing, unresolved, or LSP is unavailable, fallback to offset/limit or use LspTool for semantic discovery first.
+- Directory mode returns a one-level tree structure using \u251C\u2500\u2500/\u2514\u2500\u2500 and supports pagination continuation hints
+- For large files, iterate in chunks: offset=1 limit=200, then offset=201 limit=200, and so on until the needed region is covered
+- File text truncation is capped at 50KB per result and 2000 lines; 50KB is file text truncation and not a directory access gate
+- Any lines longer than ${MAX_LINE_LENGTH} characters will be truncated
+- Results are returned using cat -n format, with line numbers starting at 1
+- This tool allows reading images (eg PNG, JPG, etc). When reading an image file the contents are presented visually.
+- This tool can read PDF files and return them as document blocks for analysis.
+- This tool can read Jupyter notebooks (.ipynb files) and returns all cells with their outputs, combining code, text, and visualizations.
+- For wide repository exploration, still prefer Glob first, then use Read for focused file/directory inspection.
+- You can call multiple tools in a single response. It is always better to speculatively read multiple potentially useful files in parallel.
+- You will regularly be asked to read screenshots. If the user provides a path to a screenshot, ALWAYS use this tool to view the file at the path. This tool will work with all temporary file paths.
+- If you read a file that exists but has empty contents you will receive a system reminder warning in place of file contents.
+
+## Typical Usage Examples
+### Example 1: Exploring Unfamiliar Codebase
+ <example>
+  user: How does authentication work in this project?
+  assistant: [uses Grep tool with pattern="auth|login" to find relevant files]
+  [uses Glob tool with pattern="**/auth*.{ts,js}" to locate auth modules]
+  [reads the matched files after confirming their paths]
+ </example>
+
+### Example 2: User Mentions a Concept Without Path
+ <example>
+  user: Check the database configuration
+  assistant: [uses Glob tool with pattern="**/config*.{ts,js,json}"]
+  [uses Grep tool with pattern="database|db_" to find config files with db settings]
+  [reads the confirmed config file]
+ </example>
+
+### Example 3: Read Directory Structure Then Read File
+ <example>
+  user: Check the API module layout and read router implementation
+  assistant: [uses Glob tool with pattern="**/api*"]
+  [reads the confirmed api directory path to get one-level tree structure with Read]
+  [reads the router file path found in that directory tree]
+ </example>
+
+### Example 4: LSP-Assisted Symbol Read
+ <example>
+  user: I only need the function that actually executes file reading, not the whole file
+  assistant: [uses Glob/Grep to confirm FileReadTool file path]
+  [uses Read with file_path="<absolute path>/FileReadTool.tsx" symbol_name="call"]
+  [if symbol is missing or unresolved, uses LspTool documentSymbol to discover exact symbol names, then retries]
+  [if LSP is unavailable, falls back to offset/limit chunked reads around likely implementation area]
+  <reasoning>
+  The assistant used symbol_name-based Read because:
+  1. User intent is a specific implementation block, not whole-file browsing
+  2. symbol_name gives precise semantic range selection and avoids noisy context
+  3. LspTool is used only for symbol discovery fallback, while Read remains the code retrieval tool
+  </reasoning>
+ </example>
+
+### Example 5: Smart Truncation on Partial Window
+ <example>
+  user: Please read this file section for me; I do not know where the function ends
+  assistant: [uses Read with file_path="<absolute path>/service.ts" offset=120 limit=30]
+  [relies on Smart Truncation to auto-extend when the requested window cuts a function/class boundary]
+  [checks returned startLine/numLines and continues with adjacent chunks if more context is needed]
+  [if semantic parsing fails, falls back to original offset/limit and continues chunked reading]
+  <reasoning>
+  The assistant used offset/limit Read with Smart Truncation because:
+  1. User asked for a local section without symbol-level knowledge
+  2. Pagination windows can split semantic containers, causing misleading partial code
+  3. Smart Truncation repairs semantic boundaries while preserving pagination workflow
+  </reasoning>
+ </example>
+`.trim();
+
+// src/tools/filesystem/FileEditTool/prompt.ts
+var TOOL_NAME3 = "Edit";
+var DESCRIPTION3 = `Performs smart string replacements in files using SEARCH/REPLACE blocks.
+
+Usage:
+1. **Read First**: You must use your \`Read\` tool at least once before editing.
+2. **Block Format**: Provide changes as one or more SEARCH/REPLACE blocks.
+   \`\`\`
+   <<<<<<< SEARCH
+   [original code to replace]
+   =======
+   [new code to insert]
+   >>>>>>> REPLACE
+   \`\`\`
+3. **Multiple Edits**: You can provide multiple blocks in a single turn to perform batch edits.
+4. **Context**: Include enough surrounding lines in the SEARCH block to ensure uniqueness.
+5. **Indentation**: Preserve the exact indentation (tabs/spaces) of the original file in your SEARCH block.
+6. **Smart Matching**: The tool uses a fuzzy matching engine. It can locate code even if there are minor differences in whitespace or indentation.
+7. **Conditional Edit**: Use \`if_not_contains\` to skip the edit if the file already contains a specific string.
+8. **Thinking**: You can include "thinking" text between blocks; the tool will ignore it.
+
+## LSP-Integrated Behavior
+- **Semantic Anchor Assist**: Before fuzzy replacement, Edit tries LSP anchor matching to narrow replacement to the most relevant symbol range.
+- **When It Helps**: Especially useful when the same snippet appears multiple times and plain text matching may hit the wrong block.
+- **Fallback**: If LSP anchor is unavailable, Edit falls back to normal SEARCH/REPLACE matching.
+- **Post-Edit Verification**: Set \`verify: true\` to run LSP diagnostics after applying edits.
+- **Verification Guardrail**: If syntax/type diagnostics contain errors after edit, Edit reverts changes and returns a verification failure.
+- **When LSP Is Unavailable**: You may receive verification unavailable; retry with \`verify: false\` only when you have high confidence in edit safety.
+
+Notes:
+- The edit will FAIL if the SEARCH block matches multiple locations(ambiguous). Provide more context.
+- To delete code, leave the REPLACE section empty.
+- To create a new file, use an empty SEARCH block with the desired content in REPLACE.
+- ALWAYS prefer editing existing files. NEVER write new files unless explicitly required.
+- For Jupyter Notebooks (.ipynb), use the NotebookEditTool instead.
+
+## Typical Usage Examples
+### Example 1: Ambiguous Duplicate Snippet with LSP Anchor
+<example>
+user: Update the constructor guard in UserService, not the test helper copy
+assistant: [uses Read on UserService file to confirm target block]
+[uses Edit with SEARCH/REPLACE block and verify=true]
+[relies on LSP anchor assist to prefer semantic symbol region when duplicate text exists]
+<reasoning>
+The assistant enabled semantic-safe editing because:
+1. Duplicate snippets can cause ambiguous fuzzy matches
+2. LSP anchor narrows replacement to the intended symbol scope
+3. verify=true adds post-edit diagnostics guardrail and auto-revert on syntax errors
+</reasoning>
+</example>
+
+### Example 2: Verification-Unavailable Recovery
+<example>
+user: Apply this quick rename in a generated file
+assistant: [uses Read to confirm exact path and block]
+[uses Edit with verify=true]
+[if response says verification unavailable, retries with verify=false and tighter SEARCH context]
+<reasoning>
+The assistant keeps verification first, then degrades safely because:
+1. LSP verification is preferred for correctness
+2. Generated or unsupported files may not have active LSP diagnostics
+3. Retrying with verify=false is acceptable only after narrowing context
+</reasoning>
+</example>
+`.trim();
+
+// src/tools/filesystem/FileWriteTool/prompt.ts
+var TOOL_NAME4 = "Write";
+var DESCRIPTION4 = "Write a file to the local filesystem.";
+var PROMPT3 = `Writes a file to the local filesystem.
+
+Usage:
+- This tool will overwrite the existing file if there is one at the provided path.
+- If this is an existing file, you MUST use the ${TOOL_NAME2} tool first to read the file's contents. This tool will fail if you did not read the file first.
+- ALWAYS prefer editing existing files in the codebase. NEVER write new files unless explicitly required.
+- NEVER proactively create documentation files (*.md) or README files. Only create documentation files if explicitly requested by the User.
+- Only use emojis if the user explicitly requests it. Avoid writing emojis to files unless asked.
+`.trim();
+
+// src/tools/filesystem/GlobTool/prompt.ts
+var TOOL_NAME5 = "Glob";
+var DESCRIPTION5 = `Fast file pattern matching tool that works with any codebase size
+
+  ## WhenToUse & Best Practice
+  - If you have keywords or fuzzy paths, use Glob first to narrow candidates.
+  - When you are doing an open ended search that may require multiple rounds of globbing and grepping, use the Agent tool instead
+  - You can call multiple tools in a single response. It is always better to speculatively perform multiple searches in parallel if they are potentially useful.
+  - This tool is for FINDING files.
+
+  ## Directory Structure Guidance
+  - For one-level directory structure, use Read directly on the directory path (offset>=1, optional limit)
+  - Use Glob for file-path discovery and candidate narrowing, not as the primary one-level directory listing workflow
+
+  ## Search Strategy
+  - **Broad-to-Narrow Pattern**: Start with a broad pattern, then narrow based on results.
+    - Step 1: Use broad patterns like \`**/*.ts\` or \`src/**/*\` to get an overview
+    - Step 2: Analyze results and refine with more specific patterns
+    - Example: "\`**/*.test.ts\`" \u2192 too many results \u2192 "src/**/auth*.test.ts"
+  - **Pattern Selection Guide**:
+    - Unknown structure? Start with \`**/*.{ext}\` to discover layout, then use Read on specific directory paths for one-level structure
+    - Looking for specific type? Use descriptive names: \`**/test*\`, \`**/config*\`
+    - In a specific area? Combine path + pattern: \`src/auth/**/*.ts\`
+  - **Discovery Workflow**: For unfamiliar codebases, run these in parallel:
+    - \`**/package.json\`, \`**/*.{ts,js,tsx,jsx}\`, \`**/README*\`, \`**/*config*.{ts,js,json}\`
+    - Analyze structure \u2192 refine search \u2192 read key files
+  - **Tool Collaboration**:
+    - Read \`directory_path\` \u2192 Get one-level directory tree structure
+    - Grep \u2192 After Glob finds files, use Grep to search content
+    - Read \u2192 Read the found file contents
+
+  ## Usage Details
+  - Supports glob patterns like "**/*.js" or "src/**/*.ts"
+  - Returns absolute file paths sorted by modification time (most recent first)
+  - Use this tool when you need to find files by name patterns
+  - Powered by ripgrep with \`--files\` mode for fast pattern matching
+  - \`path\` parameter: Specify the directory to search in. If omitted, uses the current working directory. IMPORTANT: Omit this field to use the default directory. DO NOT enter "undefined" or "null" - simply omit it for the default behavior. Supports both relative and absolute paths.
+  - Results are limited to 100 files by default. If truncated, use a more specific path or pattern to narrow results.
+  - Search ignores .gitignore rules and includes hidden files by default.
+  - **Empty Results**: When no files are found, try broader patterns (e.g., src/**/*) or verify path exists.
+  - **Error Handling**: Returns error if \`path\` does not exist or is not a valid directory.
+  - **LSP Semantic Mode**: \`semantic: true\` enables workspace symbol fallback when file globbing returns empty.
+  - **Semantic search is opt-in**: Only set \`semantic: true\` when you intentionally want LSP-assisted fallback.
+  - Semantic output may include:
+    - \`semanticNotice\`: human-readable semantic fallback note
+    - \`semanticReason\`: structured reason code (e.g., \`SYMBOLS_ADDED\`, \`NO_SYMBOL_MATCH\`, \`LSP_UNAVAILABLE\`)
+    - \`semanticSuggestion\`: suggested next action aligned to reason code
+  - **Truncated Results**: When results are truncated (limited to 100 files), narrow down using:
+    1. Add a more specific path: \`src/core/**/*.ts\` instead of \`**/*.ts\`
+    2. Use file extension filter: \`src/**/*.test.ts\` instead of \`src/**/*.ts\`
+    3. Use Read on a specific directory path to confirm one-level structure, then target specific directories with Glob
+
+  ## Typical Usage Examples
+
+  ### Example 1: Project Structure Discovery (Unknown Codebase)
+  <example>
+  user: I'm new to this project, what's the structure?       
+  assistant: [uses Glob tool with pattern="**/package.json" to find project roots]
+  [reads the confirmed source directory path to inspect one-level tree structure]
+  [uses Glob tool with pattern="**/*.{ts,tsx,js,jsx}" to locate major source areas]
+  </example>
+
+  ### Example 2: Find Files by Type in Specific Area
+  <example>
+  user: Find all test files in the auth module
+  assistant: [uses Glob tool with pattern="src/auth/**/*.test.ts"]
+  [uses Read tool to examine specific test files]
+  </example>
+
+  ### Example 3: Config File Location (Deterministic)        
+  <example>
+  user: Where is the webpack configuration?
+  assistant: [uses Glob tool with pattern="**/webpack*.{js,ts,json}"]
+  [uses Read tool on the matched config file]
+  </example>
+
+  ### Example 4: Parallel Discovery for Entry Points
+  <example>
+  user: What are the main entry points of this application?
+  assistant: [uses Glob tool with pattern="**/index.{ts,js}"]
+  [uses Glob tool with pattern="**/main.{ts,js}"]
+  [uses Glob tool with pattern="**/app.{ts,js}"]
+  [uses Read tool to examine the entry point files]
+  </example>
+
+  ### Example 5: Narrow Down After Broad Results
+  <example>
+  user: Find all TypeScript files in the project
+  assistant: [uses Glob tool with pattern="**/*.ts" - returns 500+ files, truncated]
+  [uses Glob tool with pattern="src/**/*.ts" to focus on source code]
+  [uses Glob tool with pattern="src/core/**/*.ts" to narrow further if needed]
+  </example>
+
+  ### Example 6: Semantic Fallback for Unknown File Path
+  <example>
+  user: Find where AuthService is implemented, I do not know the file name
+  assistant: [uses Glob tool with pattern="**/*AuthService*" semantic=false first]
+  [if no files found, retries with semantic=true]
+  [reads semanticReason and semanticSuggestion to decide next step]
+  <reasoning>
+  The assistant switches to semantic mode because:
+  1. Filename-based glob failed and user intent is symbol-oriented
+  2. semantic=true allows LSP workspace symbols to recover likely file paths
+  3. semanticReason + semanticSuggestion provide explicit fallback diagnostics
+  </reasoning>
+  </example>
+`.trim();
+
+// src/tools/search/GrepTool/prompt.ts
+var TOOL_NAME6 = "Grep";
+var DESCRIPTION6 = `A powerful fast content search tool that works with any codebase size
+
+  ## Best Practice
+  - Use Grep as a "Scout" to *find* entry points based on text patterns.
+    - STEP 1: Search for a unique string (e.g., error message, URL route, specific variable name).
+    - STEP 2: Once you get a match (File + Line Number), STOP grepping.
+    - STEP 3: Use Read to get the exact line + character, then call LspTool for definition or references.
+    - AVOID: Do not use Grep to trace execution flow (e.g., searching for "functionName" manually). Use LSP for that.
+  - Hotspot strategy: narrow the path scope first, then paginate or refine the search; after truncation, focus on high-signal directories to avoid full-repo scans.
+
+  ## Search Strategy
+  - **Pattern Refinement Workflow**:
+    - Start broad: simple keyword first, observe results
+    - Narrow down: add constraints (type, glob, path) if too many matches
+    - Switch mode: \`files_with_matches\` for discovery, \`content\` for details
+  - **From Vague Intent to Precise Pattern**:
+    - "How does auth work?" \u2192 Start with Grep("auth", type="ts") \u2192 Analyze results \u2192 Refine pattern
+    - "Find the API endpoints" \u2192 Grep("router|route|endpoint", type="ts") \u2192 Read key files
+    - "Where is this error from?" \u2192 Grep(exact error message) \u2192 Trace back to source
+  - **Iterative Narrowing**:
+    - Too many results? Add \`glob\`, \`type\`, or narrower \`path\`
+    - No results? Broaden pattern, try case-insensitive (\`-i\`), or try alternative keywords
+    - Wrong results? Adjust pattern, check regex syntax, try alternative keywords
+  - **Tool Collaboration**:
+    - Read "directory_path" \u2192 Confirm one-level directory structure for search scope
+    - Glob "file_path" \u2192 Confirm file path existence
+    - Read \u2192 Read specific content of matched files
+    - LspTool \u2192 Trace definitions and references (replace manual Grep tracing)
+
+  ## Usage Details
+  - ALWAYS use Grep for search tasks. NEVER invoke \`grep\` or \`rg\` as a Bash command. The Grep tool has been optimized for correct permissions and access.
+  - Powered by ripgrep for fast text search with full regex support (e.g., "log.*Error", "function\\s+\\w+")
+  - Pattern syntax: Uses ripgrep - literal braces need escaping (use \`interface\\{\\}\` to find \`interface{}\` in Go code)
+  - Excludes version control directories (.git, .svn, .hg, .bzr) automatically
+  - Includes hidden files by default
+
+  **Path & Scope**:
+  - \`path\` parameter: File or directory to search in. Defaults to current working directory.
+  - \`glob\` parameter: Filter files by glob pattern (e.g., "*.js", "*.{ts,tsx}") - maps to rg --glob
+  - \`type\` parameter: Filter by file type (e.g., "js", "py", "rust", "go", "java") - more efficient than glob for standard types
+  - Path guidance: If user provides a path, use it directly. If uncertain, confirm with Glob first.
+
+  **Output Modes**:
+  - \`files_with_matches\` (default): Returns file paths sorted by modification time
+  - \`content\`: Shows matching lines with line numbers (supports -A/-B/-C context)
+  - \`count\`: Shows match counts per file
+
+  **Context & Pagination**:
+  - \`-B\`, \`-A\`, \`-C\`: Context lines before/after/around matches (requires output_mode: "content")
+  - \`-n\`: Show line numbers (default: true, requires output_mode: "content")
+  - \`head_limit\`: Limit output to first N entries (works across all modes)
+  - \`offset\`: Skip first N entries before applying head_limit
+  - \`multiline\`: Enable multiline mode where . matches newlines (default: false)
+
+  **Case Sensitivity**:
+  - \`-i\`: Enable case-insensitive search
+
+  **Result Handling**:
+  - Results are truncated at 20,000 characters if too large
+  - Use Task tool for open-ended searches requiring multiple rounds
+  - **Semantic Fallback** (\`semantic: true\`): when text grep has no hit (or \`symbol_type\` is provided), Grep can query LSP workspace symbols.
+  - Semantic-enhanced outputs may include:
+    - \`semanticNotice\`: fallback summary
+    - \`semanticReason\`: structured reason code (e.g., \`SYMBOLS_ADDED\`, \`NO_SYMBOL_MATCH\`, \`LSP_UNAVAILABLE\`)
+    - \`semanticSuggestion\`: suggested next action by reason code
+  - Keep deterministic workflow: text search first, semantic fallback second.
+
+  **Typical Usage Examples**:
+
+  Example 1: Exact Error Message Tracing (Deterministic)
+  <example>
+  user: Where does the error "Connection timeout after 30s" come from?
+  assistant: [uses Grep tool with pattern="Connection timeout after 30s"output_mode="content"]
+  [uses Read tool to examine the error source and surrounding context]
+  </example>
+
+  Example 2: Precise Function Definition Lookup (Deterministic)
+  <example>
+  user: Find the implementation of \`calculateCompoundInterest\` function
+  assistant: [uses Grep tool with pattern="calculateCompoundInterest" type="ts"output_mode="content"]
+  [uses Read tool on the matched file to read the full implementation]
+  </example>
+  
+  Example 3: Iterative Narrowing for Broad Patterns
+  <example>
+  user: Find all API route definitions
+  assistant: [uses Grep tool with pattern="router\\.(get|post|put|delete)" type="ts"]       
+  [if too many results: adds path="src/routes" to narrow scope]
+  [uses Read tool to inspect specific route handlers]
+  </example>
+
+  Example 4: Handoff to LSP After Entry Point Found
+  <example>
+  user: Find all usages of the \`PaymentService\` class
+  assistant: [uses Grep tool with pattern="class PaymentService" type="ts"output_mode="content"]
+  [uses LSP findReferences at the class definition location to get all references]
+  </example>
+
+  Example 5: Case-Insensitive Search for Config Values
+  <example>
+  user: Where is the database host configured?
+  assistant: [uses Grep tool with pattern="database.*host|db_host|DB_HOST" -i: true]        
+  [uses Read tool to examine configuration files]
+  </example>
+
+  Example 6: Semantic Fallback with Structured Reason
+  <example>
+  user: Find usages of PaymentSrvce (name might be misspelled)
+  assistant: [uses Grep tool with pattern="PaymentSrvce" output_mode="files_with_matches"]
+  [if no hit, retries with semantic=true]
+  [uses semanticReason and semanticSuggestion to decide whether to broaden query or switch to LspTool]
+  <reasoning>
+  The assistant uses semantic fallback because:
+  1. Text grep may miss typo-tolerant symbol matches
+  2. LSP workspace symbols can recover intended semantic targets
+  3. Structured reason fields make fallback outcomes explicit and actionable
+  </reasoning>
+  </example>
+  `.trim();
+
+// src/tools/search/LspTool/prompt.ts
+var TOOL_NAME7 = "LSP";
+var PROMPT4 = `Interact with Language Server Protocol (LSP) servers to get code intelligence features.Supports all languages.
+
+## Capabilities & Scenarios
+This tool acts as your "Code Analyst". Use it to understand the codebase semantically, rather than just matching text.
+
+### 1. Tracing Logic (Where does this go?)
+- **Scenario**: You see a function call \`calculateTax(amount)\` and need to know its formula.
+- **Action**: Use \`goToDefinition\` on the function name.
+- **Why**: It jumps directly to the implementation, even if it's imported from another file.
+
+### 2. Impact Analysis (What uses this?)
+- **Scenario**: You are planning to rename or modify the \`User\` class.
+- **Action**: Use \`findReferences\` at the symbol position (line + character) in the file where \`User\` is declared or used.
+- **Why**: It lists every file and line where \`User\` is referenced, ensuring you don't break dependents.
+
+### 3. Exploring New Files (What's in here?)
+- **Scenario**: You just opened a large file \`utils.ts\` and want a quick overview.
+- **Action**: Use \`documentSymbol\`.
+- **Why**: It returns a structured outline (Classes, Functions, Variables) using LspFacade policy: LSP-first for accuracy, Tree-Sitter fallback for speed when needed.
+
+### 4. Interface Implementation (Who implements this?)
+- **Scenario**: You see an interface \`IStorage\` and want to find the concrete class (e.g., \`S3Storage\`).
+- **Action**: Use \`goToImplementation\`.
+- **Why**: Grep might just find the import; LSP finds the actual code that implements the interface.
+
+### 5. Scope Analysis (What is visible here?)
+- **Scenario**: You are debugging a closure or nested function and want to know which variables are captured or locally defined.
+- **Action**: Use \`getScope\`.
+- **Why**: It returns the local variables and closure captures at the current position. Essential for debugging Python closures or JavaScript lexical scopes.
+
+### 6. Real-time Diagnostics (Is this correct?)
+- **Scenario**: You just edited a file and want to verify if you introduced any syntax errors.
+- **Action**: Use \`diagnostics\` with \`waitForDiagnostics: true\`.
+- **Why**: It waits for the language server to re-analyze the file and returns fresh errors/warnings. This is your "Self-Correction" mechanism.
+
+### 7. Workspace Symbol Search (Where is this symbol?)
+- **Scenario**: You need to find a class or function across the entire project.
+- **Action**: Use \`workspaceSymbol\` with a query string and a scoped filePath (module or directory).
+- **Why**: It searches across all files in the scope. **Important**: Must provide a scoped path to avoid unbounded full-repo queries.
+
+## Supported Operations
+
+### Location-Based Operations (require line + character)
+These 8 operations require precise symbol position:
+- \`goToDefinition\`: Find where a symbol is defined
+- \`findReferences\`: Find all references to a symbol
+- \`hover\`: Get hover information (documentation, type info) for a symbol
+- \`goToImplementation\`: Find implementations of an interface or abstract method
+- \`prepareCallHierarchy\`: Get call hierarchy item at a position (functions/methods)
+- \`incomingCalls\`: Find all functions/methods that call the function at a position
+- \`outgoingCalls\`: Find all functions/methods called by the function at a position
+- \`getScope\`: Get local variables and closure captures at a position
+
+### Document-Level Operations (no position required)
+- \`documentSymbol\`: Get all symbols (functions, classes, variables) in a document
+- \`diagnostics\`: Get validation errors and warnings for a file (supports waiting for fresh results)
+
+### Workspace-Level Operations
+- \`workspaceSymbol\`: Search for symbols across the entire workspace (requires query + scoped filePath)
+
+## Parameters
+
+All operations require:
+- \`filePath\`: The file or directory to operate on
+
+Location-based operations require:
+- \`line\`: The line number (1-based, as shown in editors)
+- \`character\`: The character offset (1-based, as shown in editors)
+
+\`workspaceSymbol\` requires:
+- \`query\`: The symbol name or keyword to search for
+
+Optional:
+- \`waitForDiagnostics\`: If true, wait for fresh diagnostics (used with "diagnostics" operation)
+- \`timeout\`: Timeout in milliseconds for waiting operations (default: 5000)
+
+## Intelligent Position Handling
+
+**Do not pass a symbol name.** LSPTool works on positions, not names. Use Read to locate the symbol and derive line + character first.
+
+### Auto-Adjustment Mechanism
+If the specified position is not on a valid symbol, the tool automatically searches for the nearest valid token:
+- **Search scope**: Current line, then previous line, then next line
+- **Priority**: Current line tokens are preferred (lower score)
+- **Skipped tokens**: Keywords (function, class, if, for, return, etc.) and operators (=, =>, +, -, &&, ||, etc.) are automatically skipped
+- **If no valid token found**: Returns an error message
+
+### Best Practice for Position
+1. Use Read to open the file and locate the symbol
+2. Provide accurate 1-based line and character offset
+3. Position should be on the symbol name itself, not on keywords/operators
+4. If unsure, position at the start of the symbol name
+
+## Workflow & Scope Guidelines
+- **Priority order**: documentSymbol \u2192 hotspot detection \u2192 Read \u2192 LSP (ensure line + character)
+- **workspaceSymbol**: Must provide scoped filePath (module or directory), avoid unbounded full-repo queries
+- **documentSymbol**: Uses LspFacade policy (LSP-first for accuracy, Tree-Sitter fallback for speed)
+
+## Typical Usage Examples
+### Example 1: Find Symbol Then Read Precise Block
+<example>
+user: Locate JWT validation implementation quickly
+assistant: [uses LSP workspaceSymbol with query="jwt validate" and scoped filePath]
+[uses Read on the discovered file and then LSP documentSymbol/definition as needed]
+<reasoning>
+The assistant starts semantically because:
+1. User asks for implementation location, not broad text grep
+2. workspaceSymbol narrows candidate files efficiently
+3. Read is then used for exact code extraction once target is known
+</reasoning>
+</example>
+
+### Example 2: Diagnostics-First Debugging
+<example>
+user: Build failed in api package, tell me real code errors
+assistant: [uses LSP diagnostics with waitForDiagnostics=true on scoped filePath]
+[uses goToDefinition/findReferences for follow-up impact tracing]
+<reasoning>
+The assistant prioritizes diagnostics because:
+1. Diagnostics provide direct semantic errors from language tooling
+2. Scoped path avoids unbounded workspace queries
+3. Follow-up LSP ops can trace root-cause dependencies
+</reasoning>
+</example>
+
+Note: LSP servers are automatically managed and installed for most languages. For system-level languages (like C++, Java), ensure the corresponding tools (clangd, jdtls) are in your PATH.`;
+var DESCRIPTION7 = PROMPT4;
+
+// src/tools/agent/TaskTool/constants.ts
+var TOOL_NAME8 = "Task";
+
 // src/tools/system/BashTool/prompt.ts
 var DEFAULT_TIMEOUT_MS = 12e4;
 var MAX_TIMEOUT_MS = 6e5;
@@ -913,14 +1453,7 @@ var MAX_OUTPUT_LENGTH = 3e4;
 var MAX_RENDERED_LINES = 5;
 var PROJECT_URL = "https://github.com/pyb-xc/pyb-ts";
 var DEFAULT_CO_AUTHOR = "PYB-XC";
-var TOOL_NAME_BASH = "Bash";
-var TOOL_NAME_GLOB = "Glob";
-var TOOL_NAME_GREP = "Grep";
-var TOOL_NAME_LSP = "Lsp";
-var TOOL_NAME_READ = "Read";
-var TOOL_NAME_EDIT = "Edit";
-var TOOL_NAME_WRITE = "Write";
-var TOOL_NAME_TASK = "Task";
+var TOOL_NAME9 = "Bash";
 function isExperimentalMcpCliEnabled() {
   const value = process.env.ENABLE_EXPERIMENTAL_MCP_CLI;
   if (!value) return false;
@@ -1012,7 +1545,7 @@ Git Safety Protocol:
 - Before amending: ALWAYS check authorship (git log -1 --format='%an %ae')
 - NEVER commit changes unless the user explicitly asks you to. It is VERY IMPORTANT to only commit when explicitly asked, otherwise the user will feel that you are being too proactive.
 
-1. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following bash commands in parallel, each using the ${TOOL_NAME_BASH} tool:
+1. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following bash commands in parallel, each using the ${TOOL_NAME9} tool:
   - Run a git status command to see all untracked files.
   - Run a git diff command to see both staged and unstaged changes that will be committed.
   - Run a git log command to see recent commit messages, so that you can follow this repository's commit message style.
@@ -1034,7 +1567,7 @@ Git Safety Protocol:
 
 Important notes:
 - NEVER run additional commands to read or explore code, besides git bash commands
-- NEVER use the ${TOOL_NAME_WRITE} or ${TOOL_NAME_TASK} tools
+- NEVER use the ${TOOL_NAME4} or ${TOOL_NAME8} tools
 - DO NOT push to the remote repository unless the user explicitly asks you to do so
 - IMPORTANT: Never use git commands with the -i flag (like git rebase -i or git add -i) since they require interactive input which is not supported.
 - If there are no changes to commit (i.e., no untracked files and no modifications), do not create an empty commit
@@ -1053,7 +1586,7 @@ Use the gh command via the Bash tool for ALL GitHub-related tasks including work
 
 IMPORTANT: When the user asks you to create a pull request, follow these steps carefully:
 
-1. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following bash commands in parallel using the ${TOOL_NAME_BASH} tool, in order to understand the current state of the branch since it diverged from the main branch:
+1. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel using the ${TOOL_NAME9} tool, in order to understand the current state of the branch since it diverged from the main branch:
    - Run a git status command to see all untracked files
    - Run a git diff command to see both staged and unstaged changes that will be committed
    - Check if the current branch tracks a remote branch and is up to date with the remote, so you know if you need to push to the remote
@@ -1077,7 +1610,7 @@ EOF
 </example>
 
 Important:
-- DO NOT use the ${TOOL_NAME_WRITE} or ${TOOL_NAME_TASK} tools
+- DO NOT use the ${TOOL_NAME4} or ${TOOL_NAME8} tools
 - Return the PR URL when you're done, so the user can see it
 
 # Other common operations
@@ -1092,7 +1625,7 @@ IMPORTANT: This tool is for terminal operations like git, npm, docker, etc. DO N
 Before executing the command, please follow these steps:
 
 1. Directory Verification:
-   - If the command will create new directories or files, first use the ${TOOL_NAME_GLOB} tool to verify the parent directory exists and is the correct location
+   - If the command will create new directories or files, first use the ${TOOL_NAME5} tool to verify the parent directory exists and is the correct location
    - For example, before running "mkdir foo/bar", first check if "foo" exists
 
 2. Command Execution:
@@ -1110,21 +1643,21 @@ Usage notes:
   - You can specify an optional timeout in milliseconds (up to ${MAX_TIMEOUT_MS}ms / ${MAX_TIMEOUT_MS / 6e4} minutes). If not specified, commands will timeout after ${DEFAULT_TIMEOUT_MS}ms (${DEFAULT_TIMEOUT_MS / 6e4} minutes).
   - It is very helpful if you write a clear, concise description of what this command does in 5-10 words.
   - If the output exceeds ${MAX_OUTPUT_LENGTH} characters, output will be truncated before being returned to you.
-  - You can use the \`run_in_background\` parameter to run the command in the background, which allows you to continue working while the command runs. You can monitor the output using the ${TOOL_NAME_BASH} tool as it becomes available. You do not need to use '&' at the end of the command when using this parameter.
+  - You can use the \`run_in_background\` parameter to run the command in the background, which allows you to continue working while the command runs. You can monitor the output using the ${TOOL_NAME9} tool as it becomes available. You do not need to use '&' at the end of the command when using this parameter.
   ${sandboxPrompt}
   - Avoid using Bash with the \`find\`, \`grep\`, \`cat\`, \`head\`, \`tail\`, \`sed\`, \`awk\`, \`echo\`, \`ls\`, \`dir\`, or \`tree\` commands, unless explicitly instructed or when these commands are truly necessary for the task. Instead, always prefer using the dedicated tools for these commands:
-    - File search: Use ${TOOL_NAME_GLOB} (NOT find or ls)
-    - Directory structure and information: use ${TOOL_NAME_READ} (NOT ls/dir/tree)
-    - Content search: Use ${TOOL_NAME_GREP} (NOT grep or rg)
-    - Symbol navigation: Use ${TOOL_NAME_LSP} (NOT ctags/gtags)
-    - Read files: Use ${TOOL_NAME_READ} (NOT cat/head/tail)
-    - Edit files: Use ${TOOL_NAME_EDIT} (NOT sed/awk)
-    - Write files: Use ${TOOL_NAME_WRITE} (NOT echo >/cat <<EOF)
+    - File search: Use ${TOOL_NAME5} (NOT find or ls)
+    - Directory structure and information: use ${TOOL_NAME2} (NOT ls/dir/tree)
+    - Content search: Use ${TOOL_NAME6} (NOT grep or rg)
+    - Symbol navigation: Use ${TOOL_NAME7} (NOT ctags/gtags)
+    - Read files: Use ${TOOL_NAME2} (NOT cat/head/tail)
+    - Edit files: Use ${TOOL_NAME3} (NOT sed/awk)
+    - Write files: Use ${TOOL_NAME4} (NOT echo >/cat <<EOF)
     - Delete files: Use Delete (NOT rm/rmdir/del). Example: Delete({ file_paths: ["/path/to/file"] })
     - Communication: Output text directly (NOT echo/printf)
   - When issuing multiple commands:
-    - If the commands are independent and can run in parallel, make multiple ${TOOL_NAME_BASH} tool calls in a single message. For example, if you need to run "git status" and "git diff", send a single message with two ${TOOL_NAME_BASH} tool calls in parallel.
-    - If the commands depend on each other and must run sequentially, use a single ${TOOL_NAME_BASH} call with '&&' to chain them together (e.g., \`git add . && git commit -m "message" && git push\`). For instance, if one operation must complete before another starts (like mkdir before cp, Write before Bash for git operations, or git add before git commit), run these operations sequentially instead.
+    - If the commands are independent and can run in parallel, make multiple ${TOOL_NAME9} tool calls in a single message. For example, if you need to run "git status" and "git diff", send a single message with two ${TOOL_NAME9} tool calls in parallel.
+    - If the commands depend on each other and must run sequentially, use a single ${TOOL_NAME9} call with '&&' to chain them together (e.g., \`git add . && git commit -m "message" && git push\`). For instance, if one operation must complete before another starts (like mkdir before cp, Write before Bash for git operations, or git add before git commit), run these operations sequentially instead.
     - Use ';' only when you need to run commands sequentially but don't care if earlier commands fail
     - DO NOT use newlines to separate commands (newlines are ok in quoted strings)
   - Try to maintain your current working directory throughout the session by using absolute paths and avoiding usage of \`cd\`. You may use \`cd\` if the User explicitly requests it.
@@ -1174,7 +1707,7 @@ var MCPTool = {
   isConcurrencySafe() {
     return false;
   },
-  name: "mcp",
+  name: TOOL_NAME,
   async description() {
     return DESCRIPTION;
   },
@@ -1588,8 +2121,25 @@ export {
   FallbackToolUseRejectedMessage,
   loadMergedSettings,
   normalizeSandboxRuntimeConfigFromSettings,
+  TOOL_NAME2 as TOOL_NAME,
+  DESCRIPTION2 as DESCRIPTION,
+  PROMPT2 as PROMPT,
+  TOOL_NAME3 as TOOL_NAME2,
+  DESCRIPTION3 as DESCRIPTION2,
+  TOOL_NAME4 as TOOL_NAME3,
+  DESCRIPTION4 as DESCRIPTION3,
+  PROMPT3 as PROMPT2,
+  TOOL_NAME5 as TOOL_NAME4,
+  DESCRIPTION5 as DESCRIPTION4,
+  TOOL_NAME6 as TOOL_NAME5,
+  DESCRIPTION6 as DESCRIPTION5,
+  TOOL_NAME7 as TOOL_NAME6,
+  PROMPT4 as PROMPT3,
+  DESCRIPTION7 as DESCRIPTION6,
+  TOOL_NAME8 as TOOL_NAME7,
   DEFAULT_TIMEOUT_MS,
   MAX_OUTPUT_LENGTH,
+  TOOL_NAME9 as TOOL_NAME8,
   getBashToolPrompt,
   OutputLine,
   listPluginMCPServers,