docs: add release notes for v3.19.1-3 and update MCP documentation

- Add release notes for patch releases v3.19.1, v3.19.2, and v3.19.3
- Update combined v3.19 release notes with all patch release content
- Add MCP server configuration for GitHub integration
- Document environment variable support in MCP server args
- Add VPC endpoint configuration for AWS Bedrock provider
- Update release notes writer mode with automated PR analysis workflow
- Update index and sidebars with new release entries

Author: hannesrudolph

.roo/mcp.json

@@ -0,0 +1,20 @@
+{
+  "mcpServers": {
+    "github": {
+      "command": "docker",
+      "args": [
+        "run",
+        "-i",
+        "--rm",
+        "-e",
+        "GITHUB_PERSONAL_ACCESS_TOKEN=${env:GITHUB_PERSONAL_ACCESS_TOKEN}",
+        "ghcr.io/github/github-mcp-server"
+      ],
+      "alwaysAllow": [
+        "get_pull_request",
+        "get_pull_request_files",
+        "get_pull_request_diff"
+      ]
+    }
+  }
+}

.roomodes

@@ -197,26 +197,88 @@ customModes:
       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.
+    whenToUse: >-
+      Use this mode when creating release notes for new versions of Roo Code.
+      This mode automates the process of gathering PR information from GitHub,
+      analyzing changes, and generating user-friendly release notes. Simply
+      provide a list of PR numbers and the CHANGELOG.md entry for the release.
     customInstructions: >-
+      **Release Notes Creation Workflow:**
+
+
+      When the user provides a list of PR numbers and CHANGELOG.md entry, follow this automated workflow:
+
+
+      ## Step 1: Gather Technical PR Information
+
+      Use the GitHub MCP server (owner: RooCodeInc, repo: Roo-Code) to collect detailed information about each PR:
+
+      1. For each PR number provided, use `get_pull_request` to get:
+         - PR title and description
+         - Author information
+         - Merge date
+         - PR URL (https://github.com/RooCodeInc/Roo-Code/pull/[PR_NUMBER])
+      
+      2. Use `get_pull_request_files` to identify modified files
+      
+      3. Use `get_pull_request_diff` to understand the technical changes
+      
+      4. Use `get_pull_request_comments` if needed for additional context
+      
+      5. Create a temp.md file with all gathered information organized by PR
+
+
+      ## Step 2: Transform Technical Details into User Benefits
+
+      For each PR, analyze:
+      1. What changed? (Identify the core functionality/feature)
+      2. Why did it change? (Understand the problem being solved)
+      3. How does this impact users? (Determine user benefits)
+
+      Use this template for each PR:
+
+      ## [User-Friendly Feature Name]
+
+      We've [high-level description of improvement] (thanks [Author]!) ([#PR_NUMBER](https://github.com/RooCodeInc/Roo-Code/pull/PR_NUMBER)):
+
+      - **[Benefit Category 1]**: [How this helps users in plain language]
+      - **[Benefit Category 2]**: [Another user benefit explained simply]
+      - **[Benefit Category 3]**: [Another user benefit explained simply]
+
+      [Concluding sentence about overall impact on user experience]
+
+
+      ## Step 3: Generate Final Release Notes
+
+      After analyzing all PRs and the CHANGELOG.md entry:
+      
+      1. Create the release notes file (e.g., `docs/update-notes/vX.Y.Z.mdx`)
+      2. Follow the standard format with proper title and date
+      3. Organize features into appropriate sections
+      4. Ensure all formatting follows the guidelines below
+      5. Update the index.md file to include the new release
+      6. Update sidebars.ts with the new release entry
+
+
       **Release Notes (`docs/update-notes`) Standards:**
 
 
-      When creating or updating release notes (`.md` files within the
+      When creating or updating release notes (`.md` or `.mdx` files within the
       `docs/update-notes` directory), adhere to the following standards:
 
 
       1.  **File Naming:**
-          *   **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.
-          *   **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.).
-      2.  **File Structure (`vX.Y.Z.md` or `vX.Y.md`):**
+          *   **Patch Releases:** Use the full version number (e.g., `v3.3.1.mdx`). These files should detail specific bug fixes or minor changes since the last patch or minor release.
+          *   **Minor/Major Releases:** Use the major.minor version number (e.g., `v3.11.mdx`). 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.).
+      2.  **File Structure (`vX.Y.Z.mdx` or `vX.Y.mdx`):**
           *   **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.
           *   **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.
           *   **Content Organization:**
               *   **Expanded Sections:** Major features or significant changes should have their own `##` heading with detailed explanations in paragraph form. These sections should include:
                   - A brief description of the feature/change
                   - Bullet points with specific details
                   - A concluding sentence about the benefit to users
-              *   **Grouped Sections:** Smaller fixes and improvements should be grouped under appropriate `##` headings with single-line bullet points. Each bullet should be concise and complete on one line.
+              *   **Grouped Sections:** Smaller fixes and improvements should be grouped under appropriate `##` headings with single-line bullet points. Each bullet should be concise and complete on one line. Include PR links where appropriate.
           *   **Section Headings:** Use consistent `##` headings. Recommended headings include:
               *   Major feature sections (e.g., `## Intelligent Context Condensing Now Default`)
               *   `## Bug Fixes`
@@ -230,8 +292,8 @@ customModes:
           *   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)`).
           *   Ensure the date `(YYYY-MM-DD)` is included next to each version link.
       *   **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
+      (`vX.Y.Z.mdx`), you must also update the corresponding minor/major release
+      note (`vX.Y.mdx`) 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.
 
@@ -251,25 +313,40 @@ customModes:
               ```markdown
               ## Section Name
 
-              *   **Item Name**: Brief description on a single line (thanks contributor!)
-              *   **Another Item**: Another brief description on a single line
+              *   **Item Name**: Brief description on a single line (thanks contributor!) ([#1234](https://github.com/RooCodeInc/Roo-Code/pull/1234))
+              *   **Another Item**: Another brief description on a single line ([#1235](https://github.com/RooCodeInc/Roo-Code/pull/1235))
               ```
 
-      5.  **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.
+      5.  **Contributor Acknowledgments and PR Links:**
+          *   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.
+          *   Include PR links for all items using the format `([#PR_NUMBER](https://github.com/RooCodeInc/Roo-Code/pull/PR_NUMBER))` at the end of each bullet point or section.
+          *   For expanded sections, include the PR link(s) in the introductory paragraph or as part of the bullet points.
+          *   For grouped sections, add the PR link at the end of each bullet point after the contributor acknowledgment (if any).
 
       6.  **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"). DO NOT include summary sections in release notes.
 
       7.  **Sidebar Update (`sidebars.ts`):**
-          *   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.
+          *   When a new **release note page** (e.g., `vX.Y.mdx` or `vX.Y.Z.mdx`) is created, you **must** update the `sidebars.ts` file.
           *   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.
+
+      8.  **Formatting Guidelines Specific to User Benefits:**
+          *   Use clear, non-technical language
+          *   Focus on benefits, not implementation
+          *   Be concise (1-4 bullet points per feature)
+          *   Use present tense ("We've improved..." not "We improved...")
+          *   Add release dates for context
+          *   Group related changes when appropriate
+          *   Avoid technical jargon unless necessary
+          *   Use consistent formatting throughout
+          *   Conclude each section with the overall impact on user experience
+          *   Verify that the claims made in each point are accurate
+          *   Include PR links for easy reference to the source changes
     groups:
       - read
       - command
       - edit
+      - mcp
     source: project

docs/features/mcp/using-mcp-in-roo.mdx

@@ -93,7 +93,7 @@ Both files use a JSON format with a `mcpServers` object containing named server
   STDIO configuration parameters:
 
   *   `command` (required): The executable to run (e.g., `node`, `python`, `npx`, or an absolute path).
-  *   `args` (optional): An array of string arguments to pass to the command.
+  *   `args` (optional): An array of string arguments to pass to the command. You can reference system environment variables using `${env:VARIABLE_NAME}` syntax.
   *   `cwd` (optional): The working directory from which to launch the server process. If omitted, defaults to the first workspace folder path or the main process's working directory. Useful if the server script relies on relative paths.
   *   `env` (optional): An object containing environment variables to set for the server process.
   *   `alwaysAllow` (optional): An array of tool names from this server to automatically approve.
@@ -116,6 +116,38 @@ Both files use a JSON format with a `mcpServers` object containing named server
     }
   }
   ```
+
+  #### Using System Environment Variables in Arguments
+
+  You can reference system-level environment variables within the `args` array using the `${env:VARIABLE_NAME}` syntax. This allows you to pass sensitive information like API keys or tokens from your system environment without hardcoding them in your configuration:
+
+  ```json
+  {
+    "mcpServers": {
+      "github": {
+        "command": "docker",
+        "args": [
+          "run",
+          "-i",
+          "--rm",
+          "-e",
+          "GITHUB_PERSONAL_ACCESS_TOKEN=${env:GITHUB_PERSONAL_ACCESS_TOKEN}",
+          "ghcr.io/github/github-mcp-server"
+        ],
+        "alwaysAllow": [
+          "get_pull_request"
+        ]
+      }
+    }
+  }
+  ```
+
+  In this example, `${env:GITHUB_PERSONAL_ACCESS_TOKEN}` will be replaced with the value of the `GITHUB_PERSONAL_ACCESS_TOKEN` environment variable from your system. This is particularly useful when:
+  - Working with Docker containers that need environment variables passed through
+  - Keeping sensitive credentials out of your configuration files
+  - Using the same configuration across different environments with different credentials
+
+  **Note:** The environment variable must exist in your system environment for this to work. You can set system environment variables through your operating system's settings or shell configuration files (e.g., `.bashrc`, `.zshrc`, or Windows Environment Variables).
 #### Streamable HTTP Transport
 
 This is the **modern standard** for remote servers accessed over HTTP/HTTPS, offering more flexibility and replacing the legacy SSE transport for new implementations.

docs/providers/bedrock.md

@@ -84,10 +84,15 @@ Refer to the [Amazon Bedrock documentation](https://docs.aws.amazon.com/bedrock/
         *   Enter your "AWS Profile" name (e.g., "default").
 4.  **Select Region:** Choose the AWS region where your Bedrock service is available (e.g., "us-east-1").
 5.  **(Optional) Cross-Region Inference:** Check "Use cross-region inference" if you want to access models in a region different from your configured AWS region.
-6.  **Select Model:** Choose your desired model from the "Model" dropdown.
+6.  **(Optional) VPC Endpoint:** For enterprise environments:
+    *   Check "Use VPC Endpoint" to route all Bedrock API calls through your VPC endpoint
+    *   Enter your VPC endpoint URL in the text field that appears
+    *   This ensures all LLM transactions remain within your corporate network
+7.  **Select Model:** Choose your desired model from the "Model" dropdown.
 
 ## Tips and Notes
 
 *   **Permissions:**  Ensure your IAM user or role has the necessary permissions to invoke Bedrock models.  The `bedrock:InvokeModel` permission is required.
 *   **Pricing:**  Refer to the [Amazon Bedrock pricing](https://aws.amazon.com/bedrock/pricing/) page for details on model costs.
 *   **Cross-Region Inference:**  Using cross-region inference may result in higher latency.
+*   **VPC Endpoints:**  When using VPC endpoints, ensure your endpoint is properly configured to handle Bedrock API calls. This feature is particularly useful for organizations with strict security requirements that mandate keeping all API traffic within their private network.

docs/update-notes/index.md

@@ -4,8 +4,11 @@ This section contains notes about recent updates to Roo Code, listed by version
 
 ## Version 3.19
 
+*   [3.19.3](/update-notes/v3.19.3) (2025-06-02)
+*   [3.19.2](/update-notes/v3.19.2) (2025-06-01)
+*   [3.19.1](/update-notes/v3.19.1) (2025-05-31)
 *   [3.19.0](/update-notes/v3.19.0) (2025-05-30)
-*   [3.19](/update-notes/v3.19) (2025-05-30)
+*   [3.19](/update-notes/v3.19) (2025-05-31)
 
 ## Version 3.18
 

docs/update-notes/v3.19.1.mdx

@@ -0,0 +1,36 @@
+# Roo Code 3.19.1 Release Notes (2025-05-31)
+
+This patch release delivers critical fixes and experimental features to enhance your development experience, including multi-file reading capabilities, improved MCP server integration, and enterprise security enhancements.
+
+## Multi-File Reading (Experimental)
+We've introduced an experimental feature for handling large codebases more efficiently:
+
+- **Batch File Processing**: Read up to 100 files in a single operation for comprehensive code analysis
+- **Performance Control**: Adjustable concurrent file read limits to optimize for your system
+- **Smart Permission Management**: Streamlined approval process for multi-file operations
+- **Efficiency Boost**: Dramatically reduces the time needed to analyze multiple related files
+
+This experimental feature transforms how Roo Code understands and works with your entire codebase at once (thanks samhvw8!).
+
+## Enterprise-Ready VPC Endpoint Support
+We've added crucial enterprise security features for [AWS Bedrock](/providers/bedrock) users:
+
+- **Secure Corporate Access**: Configure custom VPC endpoints to keep all LLM transactions within your firewall
+- **Easy Configuration**: Simple checkbox and text field to enable VPC endpoint usage
+- **Compliance Ready**: Meet your organization's security policies while using powerful AI models
+- **Flexible Control**: Toggle VPC endpoints on/off as needed with settings persistence
+
+Enterprise customers can now use Roo Code with AWS Bedrock while maintaining complete network security (thanks kcwhite!). See the [AWS Bedrock configuration guide](/providers/bedrock#configuration-in-roo-code) for setup instructions.
+
+## Bug Fixes
+
+*   **MCP Server Authentication**: Fixed SSE header passing to correctly authenticate with remote MCP servers
+*   **AWS Bedrock Conversations**: Resolved context condensing error that required conversations to start with user messages
+*   **Terminal UTF-8 Encoding**: Fixed encoding errors when running Ruby/CocoaPods commands (thanks mr-ryan-james!)
+*   **Sidebar Context Menus**: Resolved empty menu items by properly setting sidebar name (thanks chrarnoldus!)
+*   **Documentation Links**: Fixed broken CONTRIBUTING.md link in feature request template (thanks cannuri!)
+
+## Misc Improvements
+
+*   **Backend Task Tracking**: Added metadata to Unbound API requests for improved service reliability (thanks pugazhendhi-m!)
+*   **Model-Specific Caching**: Optimized cache strategies for Gemini and Anthropic models for better performance