Merge branch 'RooVetGit:main' into main

Author: SannidhyaSah

.roomodes

@@ -23,7 +23,7 @@
       "slug": "release-notes-writer",
       "name": "Release Notes Writer",
       "roleDefinition": "You are a technical writer specializing in creating and maintaining release notes for the Roo Code VS Code extension, specifically within the `docs/update-notes` directory. Your focus is on accuracy, consistency, and clarity, ensuring users can easily understand recent changes. You adhere strictly to the project's release note standards.",
-      "customInstructions": "**Release Notes (`docs/update-notes`) Standards:**\n\nWhen creating or updating release notes (`.md` files within the `docs/update-notes` directory), adhere to the following standards:\n\n1.  **File Naming:**\n    *   **Patch Releases:** Use the full version number (e.g., `v3.3.1.md`). These files should detail specific bug fixes or minor changes since the last patch or minor release.\n    *   **Minor/Major Releases:** Use the major.minor version number (e.g., `v3.11.md`). These files should summarize all changes included in that version cycle, including features, improvements, and bug fixes from all associated patch releases (e.g., `v3.11.0`, `v3.11.1`, `v3.11.2`, etc.).\n2.  **File Structure (`vX.Y.Z.md` or `vX.Y.md`):**\n    *   **Title:** The H1 title must follow the format: `# Roo Code X.Y.Z Release Notes (YYYY-MM-DD)` or `# Roo Code X.Y Release Notes (YYYY-MM-DD)`. Ensure the date reflects the release date and is always included.\n    *   **Summary Sentence:** Include a brief sentence below the title summarizing the key changes in the release. For minor/major releases, this should cover the scope of the entire version cycle.\n    *   **Section Headings:** Use consistent `##` headings. Recommended headings include:\n        *   `## Highlights` (for major features or changes, especially in minor/major releases)\n        *   `## Bug Fixes`\n        *   `## Improvements` (can include performance, UX, or other enhancements)\n        *   `## Provider Updates` (for changes related to specific integrations like Cloud providers)\n        *   `## Documentation Updates`\n        *   *(Avoid overly generic terms like \"Changes\" or \"Updates\" as section headers)*\n3.  **`index.md` File (Main Index):**\n    *   The main `index.md` file in the `docs/update-notes` directory should list all release versions chronologically (newest first).\n    *   Each entry should link to the corresponding release note file (e.g., `v3.11.md` for the summary page, `v3.3.1.md` for a specific patch). Use absolute paths from `/docs/` and omit the `.md` extension (e.g., `[3.11.8](/update-notes/v3.11.8)`).\n    *   Ensure the date `(YYYY-MM-DD)` is included next to each version link.\n4.  **Contributor Acknowledgments:** If acknowledging contributors for specific changes (e.g., bug fixes), do so consistently. Add `(thanks username!)` at the end of the relevant bullet point, omitting the `@` symbol.\n5.  **Content Style:** Maintain a clear, concise, and informative writing style. Use Markdown formatting correctly (e.g., use backticks `` for code or version numbers). Ensure consistent terminology (e.g., \"release notes\" vs. \"changelog\").\n6.  **Sidebar Update (`sidebars.ts`):**\n    *   When a new **release note page** (e.g., `vX.Y.md` or `vX.Y.Z.md`) is created, you **must** update the `sidebars.ts` file.\n    *   Add the Docusaurus ID for the new page (e.g., `'update-notes/vX.Y'` or `'update-notes/vX.Y.Z'`) to the `items` array within the appropriate 'Update Notes' category.",
+      "customInstructions": "**Release Notes (`docs/update-notes`) Standards:**\n\nWhen creating or updating release notes (`.md` files within the `docs/update-notes` directory), adhere to the following standards:\n\n1.  **File Naming:**\n    *   **Patch Releases:** Use the full version number (e.g., `v3.3.1.md`). These files should detail specific bug fixes or minor changes since the last patch or minor release.\n    *   **Minor/Major Releases:** Use the major.minor version number (e.g., `v3.11.md`). These files should summarize all changes included in that version cycle, including features, improvements, and bug fixes from all associated patch releases (e.g., `v3.11.0`, `v3.11.1`, `v3.11.2`, etc.).\n2.  **File Structure (`vX.Y.Z.md` or `vX.Y.md`):**\n    *   **Title:** The H1 title must follow the format: `# Roo Code X.Y.Z Release Notes (YYYY-MM-DD)` or `# Roo Code X.Y Release Notes (YYYY-MM-DD)`. Ensure the date reflects the release date and is always included.\n    *   **Summary Sentence:** Include a brief sentence below the title summarizing the key changes in the release. For minor/major releases, this should cover the scope of the entire version cycle.\n    *   **Section Headings:** Use consistent `##` headings. Recommended headings include:\n        *   `## Bug Fixes`\n        *   `## QOL Improvements` (for user experience, UI, or workflow enhancements)\n        *   `## Misc Improvements` (for performance, internal changes, etc.)\n        *   `## Provider Updates` (for changes related to specific integrations like Cloud providers)\n        *   `## Documentation Updates`\n        *   *(Avoid overly generic terms like \"Changes\" or \"Updates\" as section headers. Do NOT use `## Highlights`)*\n3.  **`index.md` File (Main Index):**\n    *   The main `index.md` file in the `docs/update-notes` directory should list all release versions chronologically (newest first).\n    *   Each entry should link to the corresponding release note file (e.g., `v3.11.md` for the summary page, `v3.3.1.md` for a specific patch). Use absolute paths from `/docs/` and omit the `.md` extension (e.g., `[3.11.8](/update-notes/v3.11.8)`).\n    *   Ensure the date `(YYYY-MM-DD)` is included next to each version link.\n*   **Updating Combined Notes:** When creating a patch release note (`vX.Y.Z.md`), you must also update the corresponding minor/major release note (`vX.Y.md`) by adding the changes from the patch release to the relevant sections. Do *not* include the patch version number (e.g., `(vX.Y.Z)`) in the combined notes.\n4.  **Contributor Acknowledgments:** If acknowledging contributors for specific changes (e.g., bug fixes), do so consistently. Add `(thanks username!)` at the end of the relevant bullet point, omitting the `@` symbol.\n5.  **Content Style:** Maintain a clear, concise, and informative writing style. Use Markdown formatting correctly (e.g., use backticks `` for code or version numbers). Ensure consistent terminology (e.g., \"release notes\" vs. \"changelog\").\n6.  **Sidebar Update (`sidebars.ts`):**\n    *   When a new **release note page** (e.g., `vX.Y.md` or `vX.Y.Z.md`) is created, you **must** update the `sidebars.ts` file.\n    *   Add the Docusaurus ID for the new page (e.g., `'update-notes/vX.Y'` or `'update-notes/vX.Y.Z'`) to the `items` array within the appropriate 'Update Notes' category.",
       "groups": [
         "read",
         "command",

…cs/features/tools/access-mcp-resource.md …e/available-tools/access-mcp-resource.mddocs/features/tools/access-mcp-resource.md renamed to docs/advanced-usage/available-tools/access-mcp-resource.md docs/features/tools/access-mcp-resource.md renamed to docs/advanced-usage/available-tools/access-mcp-resource.md

@@ -1,19 +1,19 @@
 # apply_diff
 
-The `apply_diff` tool makes precise, surgical changes to files by specifying exactly what content to replace. It uses multiple sophisticated strategies for finding and applying changes while maintaining proper code formatting and structure.
+The `apply_diff` tool makes precise, surgical changes to files by specifying exactly what content to replace. It uses a sophisticated strategy for finding and applying changes while maintaining proper code formatting and structure.
 
 ## Parameters
 
 The tool accepts these parameters:
 
 - `path` (required): The path of the file to modify relative to the current working directory.
 - `diff` (required): The search/replace block defining the changes using a format specific to the active diff strategy.
-- `start_line` (optional): A hint for where the search content begins, used by some strategies.
-- `end_line` (optional): A hint for where the search content ends, used by some strategies.
+- `start_line` (optional): A hint for where the search content begins. _Note: This top-level parameter appears unused by the current main strategy, which relies on `:start_line:` within the diff content._
+- `end_line` (optional): A hint for where the search content ends. _Note: This top-level parameter appears unused by the current main strategy._
 
 ## What It Does
 
-This tool applies targeted changes to existing files using sophisticated strategies to locate and replace content precisely. Unlike simple search and replace, it uses intelligent matching algorithms (including fuzzy matching) that adapt to different content types and file sizes, with fallback mechanisms for complex edits.
+This tool applies targeted changes to existing files using fuzzy matching guided by line number hints to locate and replace content precisely. Unlike simple search and replace, it identifies the exact block for replacement based on the provided content and location hints.
 
 ## When is it used?
 
@@ -24,11 +24,10 @@ This tool applies targeted changes to existing files using sophisticated strateg
 
 ## Key Features
 
-- Uses intelligent fuzzy matching with configurable confidence thresholds (typically 0.8-1.0).
+- Uses fuzzy matching (Levenshtein distance on normalized strings) guided by a `:start_line:` hint, with configurable confidence thresholds (typically 0.8-1.0).
 - Provides context around matches using `BUFFER_LINES` (default 40).
-- Employs an overlapping window approach for searching large files.
-- Preserves code formatting and indentation automatically.
-- Combines overlapping matches for improved confidence scoring.
+- Performs a middle-out search within a configurable context window (`bufferLines`) around the hinted start line.
+- Preserves code formatting and indentation passively by replacing exact blocks.
 - Shows changes in a diff view for user review and editing before applying.
 - Tracks consecutive errors per file (`consecutiveMistakeCountForApplyDiff`) to prevent repeated failures.
 - Validates file access against `.rooignore` rules.
@@ -49,8 +48,8 @@ When the `apply_diff` tool is invoked, it follows this process:
 1.  **Parameter Validation**: Validates required `path` and `diff` parameters.
 2.  **RooIgnore Check**: Validates if the target file path is allowed by `.rooignore` rules.
 3.  **File Analysis**: Loads the target file content.
-4.  **Match Finding**: Uses the selected strategy's algorithms (exact, fuzzy, overlapping windows) to locate the target content, considering confidence thresholds and context (`BUFFER_LINES`).
-5.  **Change Preparation**: Generates the proposed changes, preserving indentation.
+4.  **Match Finding**: Uses a fuzzy matching algorithm (Levenshtein on normalized strings) guided by the `:start_line:` hint within a context window (`BUFFER_LINES`), searching middle-out to locate the target content based on the confidence threshold.
+5.  **Change Preparation**: Generates the proposed changes by replacing the identified block.
 6.  **User Interaction**:
     *   Displays the changes in a diff view.
     *   Allows the user to review and potentially edit the proposed changes.
@@ -59,16 +58,11 @@ When the `apply_diff` tool is invoked, it follows this process:
 8.  **Error Handling**: If errors occur (e.g., match failure, partial application), increments the `consecutiveMistakeCountForApplyDiff` for the file and reports the failure type.
 9. **Feedback**: Returns the result, including any user feedback or error details.
 
-## Diff Strategy
+## Diff Format Requirements
 
-Roo Code uses this strategy for applying diffs:
+The `<diff>` parameter requires a specific format supporting one or more changes in a single request. Each change block requires a line number hint for the original content.
 
-### MultiSearchReplaceDiffStrategy
-
-An enhanced search/replace format supporting multiple changes in one request. Requires line numbers for each search block.
-
-*   **Best for**: Multiple, distinct changes where line numbers are known or can be estimated.
-*   **Requires**: Exact match for the `SEARCH` block content, including whitespace and indentation. Line numbers (`:start_line:`, `:end_line:`) are mandatory. Markers within content must be escaped (`\`).
+*   **Requires**: Exact match for the `SEARCH` block content (within the fuzzy threshold), including whitespace and indentation. The `:start_line:` number hint is mandatory within each block. The `:end_line:` hint is optional (but supported by the parser). Markers like `<<<<<<<` within the file's content must be escaped (`\\`) in the SEARCH block.
 
 Example format for the `<diff>` block:
 
@@ -94,5 +88,4 @@ Example format for the `<diff>` block:
     const defaultTimeout = 5000;
 =======
     const defaultTimeout = 10000; // Increased timeout
->>>>>>> REPLACE
-```
+>>>>>>> REPLACE

docs/features/tools/apply-diff.md …nced-usage/available-tools/apply-diff.mddocs/features/tools/apply-diff.md renamed to docs/advanced-usage/available-tools/apply-diff.md docs/features/tools/apply-diff.md renamed to docs/advanced-usage/available-tools/apply-diff.md

@@ -0,0 +1,104 @@
+# insert_content
+
+The `insert_content` tool adds new lines of content into an existing file without modifying the original content. It's ideal for inserting code blocks, configuration entries, or log lines at specific locations.
+
+## Parameters
+
+The tool accepts these parameters:
+
+- `path` (required): The relative path (from the workspace root) of the file to insert content into.
+- `line` (required): The 1-based line number *before* which the content should be inserted. Use `0` to append the content to the end of the file.
+- `content` (required): The text content to insert.
+
+## What It Does
+
+This tool reads the target file, identifies the specified insertion point based on the `line` parameter, and inserts the provided `content` at that location. If `line` is `0`, the content is added to the end. Changes are presented in a diff view for user approval before being saved.
+
+## When is it used?
+
+- When adding new import statements at the beginning of a file.
+- When inserting new functions or methods into existing code.
+- When adding configuration blocks to settings files.
+- When appending log entries or data records.
+- When adding any multi-line text block without altering existing lines.
+
+## Key Features
+
+- **Targeted Insertion**: Adds content precisely at the specified line number or appends to the end.
+- **Preserves Existing Content**: Does not modify or delete original file lines.
+- **Interactive Approval**: Shows proposed insertions in a diff view, requiring explicit user approval.
+- **User Edit Support**: Allows editing the proposed content directly within the diff view before final approval.
+- **Handles Line Numbers**: Correctly interprets the `line` parameter (1-based or 0 for append).
+- **Context Tracking**: Records the file edit operation for context management.
+- **Error Handling**: Checks for missing parameters, invalid line numbers, and file access issues.
+
+## Limitations
+
+- **Insert Only**: Cannot replace or delete existing content. Use `apply_diff` or `search_and_replace` for modifications.
+- **Requires Existing File**: The target file specified by `path` must exist.
+- **Review Overhead**: The mandatory diff view approval adds an interactive step.
+
+## How It Works
+
+When the `insert_content` tool is invoked, it follows this process:
+
+1.  **Parameter Validation**: Checks for required `path`, `line`, and `content`. Validates `line` is a non-negative integer.
+2.  **File Reading**: Reads the content of the target file specified by `path`.
+3.  **Insertion Point Calculation**: Converts the 1-based `line` parameter to a 0-based index for internal processing (`-1` for appending).
+4.  **Content Insertion**: Uses an internal utility (`insertGroups`) to merge the original file lines with the new `content` at the calculated index.
+5.  **Diff View Interaction**:
+    *   Opens the file in the diff view (`cline.diffViewProvider.open`).
+    *   Updates the diff view with the proposed content (`cline.diffViewProvider.update`).
+6.  **User Approval**: Presents the change via `askApproval`. Reverts if rejected.
+7.  **Saving Changes**: If approved, saves the changes using `cline.diffViewProvider.saveChanges`.
+8.  **File Context Tracking**: Tracks the edit using `cline.getFileContextTracker().trackFileContext`.
+9.  **Handling User Edits**: If the user edited the content in the diff view, reports the final merged content back.
+10. **Result Reporting**: Reports success (including user edits) or failure back to the AI model.
+
+## Usage Examples
+
+Inserting import statements at the beginning of a file (`line: 1`):
+
+```xml
+<insert_content>
+<path>src/utils.ts</path>
+<line>1</line>
+<content>
+// Add imports at start of file
+import { sum } from './math';
+import { parse } from 'date-fns';
+</content>
+</insert_content>
+```
+
+Appending content to the end of a file (`line: 0`):
+
+```xml
+<insert_content>
+<path>config/routes.yaml</path>
+<line>0</line>
+<content>
+- path: /new-feature
+  component: NewFeatureComponent
+  auth_required: true
+</content>
+</insert_content>
+```
+
+Inserting a function before line 50:
+
+```xml
+<insert_content>
+<path>src/services/api.js</path>
+<line>50</line>
+<content>
+async function fetchUserData(userId) {
+  const response = await fetch(`/api/users/${userId}`);
+  if (!response.ok) {
+    throw new Error('Failed to fetch user data');
+  }
+  return response.json();
+}
+</content>
+</insert_content>
+```

…/features/tools/ask-followup-question.md …available-tools/ask-followup-question.mddocs/features/tools/ask-followup-question.md renamed to docs/advanced-usage/available-tools/ask-followup-question.md docs/features/tools/ask-followup-question.md renamed to docs/advanced-usage/available-tools/ask-followup-question.md

@@ -28,15 +28,15 @@ This tool lists all files and directories in a specified location, providing a c
 - Intelligently ignores common large directories like `node_modules` and `.git` in recursive mode
 - Respects `.gitignore` rules when in recursive mode
 - Marks files ignored by `.rooignore` with a lock symbol (🔒) when `showRooIgnoredFiles` is enabled
-- Optimizes performance with level-by-level directory traversal
+- Optimizes file listing performance by leveraging the `ripgrep` tool.
 - Sorts results to show directories before their contents, maintaining a logical hierarchy
 - Presents results in a clean, organized format
 - Automatically creates a mental map of your project structure
 
 ## Limitations
 
 - File listing is capped at about 200 files by default to prevent performance issues
-- Has a 10-second timeout for directory traversal to prevent hanging on complex directory structures
+- The underlying `ripgrep` file listing process has a 10-second timeout; if exceeded, partial results may be returned.
 - When the file limit is hit, it adds a note suggesting to use `list_files` on specific subdirectories
 - Not designed for confirming the existence of files you've just created
 - May have reduced performance in very large directory structures
@@ -49,10 +49,10 @@ When the `list_files` tool is invoked, it follows this process:
 1. **Parameter Validation**: Validates the required `path` parameter and optional `recursive` parameter
 2. **Path Resolution**: Resolves the relative path to an absolute path
 3. **Security Checks**: Prevents listing files in sensitive locations like root or home directories
-4. **Directory Scanning**:
-   - For non-recursive mode: Lists only the top-level contents
-   - For recursive mode: Traverses the directory structure level by level with a 10-second timeout
-   - If timeout occurs, returns partial results collected up to that point
+4. **Directory/File Scanning**:
+   - Uses the `ripgrep` tool to efficiently list files, applying a 10-second timeout.
+   - Uses Node.js `fs` module to list directories.
+   - Applies different filtering logic for recursive vs. non-recursive modes.
 5. **Result Filtering**:
    - In recursive mode, skips common large directories like `node_modules`, `.git`, etc.
    - Respects `.gitignore` rules when in recursive mode