diff --git a/.changeset/changelog-config.js b/.changeset/changelog-config.js
index 1e64dbf093..0ab9a9e48e 100644
--- a/.changeset/changelog-config.js
+++ b/.changeset/changelog-config.js
@@ -1,5 +1,3 @@
-// Half-works to simplify the format but needs 'overwrite_changeset_changelog.py' in GHA to finish formatting
-
const getReleaseLine = async (changeset) => {
const [firstLine] = changeset.summary
.split("\n")
diff --git a/.changeset/config.json b/.changeset/config.json
index bcd6eefa00..e2acc37662 100644
--- a/.changeset/config.json
+++ b/.changeset/config.json
@@ -2,7 +2,7 @@
"$schema": "https://unpkg.com/@changesets/config@3.0.4/schema.json",
"changelog": "./changelog-config.js",
"commit": false,
- "fixed": [],
+ "fixed": [["roo-cline"]],
"linked": [],
"access": "restricted",
"baseBranch": "main",
diff --git a/.clinerules b/.clinerules
deleted file mode 100644
index 9bd9ff02ee..0000000000
--- a/.clinerules
+++ /dev/null
@@ -1,27 +0,0 @@
-# Code Quality Rules
-
-1. Test Coverage:
- - Before attempting completion, always make sure that any code changes have test coverage
- - Ensure all tests pass before submitting changes
-
-2. Lint Rules:
- - Never disable any lint rules without explicit user approval
- - If a lint rule needs to be disabled, ask the user first and explain why
- - Prefer fixing the underlying issue over disabling the lint rule
- - Document any approved lint rule disabling with a comment explaining the reason
-
-3. Logging Guidelines:
- - Always instrument code changes using the logger exported from `src\utils\logging\index.ts`.
- - This will facilitate efficient debugging without impacting production (as the logger no-ops outside of a test environment.)
- - Logs can be found in `logs\app.log`
- - Logfile is overwritten on each run to keep it to a manageable volume.
-
-4. Styling Guidelines:
- - Use Tailwind CSS classes instead of inline style objects for new markup
- - VSCode CSS variables must be added to webview-ui/src/index.css before using them in Tailwind classes
- - Example: `
` instead of style objects
-
-
-# Adding a New Setting
-
-To add a new setting that persists its state, follow the steps in cline_docs/settings.md
diff --git a/.dockerignore b/.dockerignore
new file mode 100644
index 0000000000..514136ac91
--- /dev/null
+++ b/.dockerignore
@@ -0,0 +1,90 @@
+# git
+.git
+
+# build artifacts
+bin/
+dist/
+**/dist/
+out/
+**/out/
+src/webview-ui/
+
+# dependencies
+node_modules/
+**/node_modules/
+
+# testing
+coverage/
+**/.vscode-test/
+**/mock/
+
+# devtools
+knip.json
+.husky/
+
+# monorepo
+.turbo/
+**/.turbo/
+
+# next.js
+**/.next/
+.vercel
+
+# Ignore common development files
+node_modules
+.git
+.gitignore
+.dockerignore
+.env*
+.vscode
+.idea
+
+# Ignore build artifacts
+dist
+build
+*.log
+*.tmp
+.cache
+coverage
+
+# Ignore OS files
+.DS_Store
+Thumbs.db
+
+# Ignore test files
+__tests__
+*.test.js
+*.spec.js
+*.test.ts
+*.spec.ts
+
+# Ignore development config files
+.eslintrc*
+.prettierrc*
+
+# Ignore most directories except what we need for the build
+apps/
+evals/
+webview-ui/node_modules
+src/node_modules
+
+# Keep essential files for the build
+!README.md
+!CHANGELOG.md
+!package.json
+!pnpm-lock.yaml
+!pnpm-workspace.yaml
+!scripts/bootstrap.mjs
+!apps/web-evals/
+!src/
+!webview-ui/
+!packages/evals/.docker/entrypoints/runner.sh
+!packages/build/
+!packages/cloud/
+!packages/config-eslint/
+!packages/config-typescript/
+!packages/evals/
+!packages/ipc/
+!packages/telemetry/
+!packages/types/
+!locales/
diff --git a/.env.sample b/.env.sample
new file mode 100644
index 0000000000..d89ef72792
--- /dev/null
+++ b/.env.sample
@@ -0,0 +1,5 @@
+POSTHOG_API_KEY=key-goes-here
+
+# Roo Code Cloud / Local Development
+CLERK_BASE_URL=https://epic-chamois-85.clerk.accounts.dev
+ROO_CODE_API_URL=http://localhost:3000
diff --git a/.eslintrc.json b/.eslintrc.json
deleted file mode 100644
index bae7854a6e..0000000000
--- a/.eslintrc.json
+++ /dev/null
@@ -1,23 +0,0 @@
-{
- "root": true,
- "parser": "@typescript-eslint/parser",
- "parserOptions": {
- "ecmaVersion": 6,
- "sourceType": "module"
- },
- "plugins": ["@typescript-eslint"],
- "rules": {
- "@typescript-eslint/naming-convention": [
- "warn",
- {
- "selector": "import",
- "format": ["camelCase", "PascalCase"]
- }
- ],
- "@typescript-eslint/semi": "off",
- "eqeqeq": "warn",
- "no-throw-literal": "warn",
- "semi": "off"
- },
- "ignorePatterns": ["out", "dist", "**/*.d.ts"]
-}
diff --git a/.git-blame-ignore-revs b/.git-blame-ignore-revs
index 93f9eeaa5b..2a350d20e8 100644
--- a/.git-blame-ignore-revs
+++ b/.git-blame-ignore-revs
@@ -1,3 +1,3 @@
-# Ran Prettier on all files - https://github.com/RooVetGit/Roo-Code/pull/404
+# Ran Prettier on all files - https://github.com/RooCodeInc/Roo-Code/pull/404
60a0a824b96a0b326af4d8871b6903f4ddcfe114
579bdd9dbf6d2d569e5e7adb5ff6292b1e42ea34
diff --git a/.gitattributes b/.gitattributes
index 92a294bfae..02ddd6b634 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -1,2 +1,6 @@
demo.gif filter=lfs diff=lfs merge=lfs -text
assets/docs/demo.gif filter=lfs diff=lfs merge=lfs -text
+src/assets/docs/demo.gif filter=lfs diff=lfs merge=lfs -text
+
+# Test snapshot files - mark as linguist-generated to exclude from GitHub language statistics
+*.snap linguist-generated=true
diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
index 7feb2005ae..a3daa0f144 100644
--- a/.github/CODEOWNERS
+++ b/.github/CODEOWNERS
@@ -1,2 +1,2 @@
# These owners will be the default owners for everything in the repo
-* @mrubens @cte
+* @mrubens @cte @jr
diff --git a/.github/ISSUE_TEMPLATE/bug_report.yml b/.github/ISSUE_TEMPLATE/bug_report.yml
index dc66b4f390..44626273b5 100644
--- a/.github/ISSUE_TEMPLATE/bug_report.yml
+++ b/.github/ISSUE_TEMPLATE/bug_report.yml
@@ -1,68 +1,98 @@
name: Bug Report
-description: File a bug report
+description: Clearly report a bug with detailed repro steps
labels: ["bug"]
body:
- - type: input
- id: version
- attributes:
- label: Which version of the app are you using?
- description: Please specify the app version you're using (e.g. v3.3.1)
- validations:
- required: true
- - type: dropdown
- id: provider
- attributes:
- label: Which API Provider are you using?
- multiple: false
- options:
- - OpenRouter
- - Anthropic
- - Google Gemini
- - DeepSeek
- - OpenAI
- - OpenAI Compatible
- - GCP Vertex AI
- - AWS Bedrock
- - Glama
- - VS Code LM API
- - LM Studio
- - Ollama
- validations:
- required: true
- - type: input
- id: model
- attributes:
- label: Which Model are you using?
- description: Please specify the model you're using (e.g. Claude 3.7 Sonnet)
- validations:
- required: true
- - type: textarea
- id: what-happened
- attributes:
- label: What happened?
- description: Also tell us, what did you expect to happen?
- placeholder: Tell us what you see!
- validations:
- required: true
- - type: textarea
- id: steps
- attributes:
- label: Steps to reproduce
- description: How do you trigger this bug? Please walk us through it step by step.
- value: |
- 1.
- 2.
- 3.
- validations:
- required: true
- - type: textarea
- id: logs
- attributes:
- label: Relevant API REQUEST output
- description: Please copy and paste any relevant output. This will be automatically formatted into code, so no need for backticks.
- render: shell
- - type: textarea
- id: additional-context
- attributes:
- label: Additional context
- description: Add any other context about the problem here, such as screenshots or related issues.
+ - type: markdown
+ attributes:
+ value: |
+ **Thanks for your report!** Please check existing issues first:
+ 👉 https://github.com/RooCodeInc/Roo-Code/issues
+
+ - type: input
+ id: version
+ attributes:
+ label: App Version
+ description: What version of Roo Code are you using? (e.g., v3.3.1)
+ validations:
+ required: true
+
+ - type: dropdown
+ id: provider
+ attributes:
+ label: API Provider
+ options:
+ - Anthropic
+ - AWS Bedrock
+ - Chutes AI
+ - DeepSeek
+ - Glama
+ - Google Gemini
+ - Google Vertex AI
+ - Groq
+ - Human Relay Provider
+ - LiteLLM
+ - LM Studio
+ - Mistral AI
+ - Ollama
+ - OpenAI
+ - OpenAI Compatible
+ - OpenRouter
+ - Requesty
+ - Unbound
+ - VS Code Language Model API
+ - xAI (Grok)
+ - Not Applicable / Other
+ validations:
+ required: true
+
+ - type: input
+ id: model
+ attributes:
+ label: Model Used
+ description: Exact model name (e.g., Claude 3.7 Sonnet). Use N/A if irrelevant.
+ validations:
+ required: true
+
+ - type: textarea
+ id: roo-code-tasks
+ attributes:
+ label: Roo Code Task Links (Optional)
+ description: |
+ If you have any publicly shared task links that demonstrate the issue, please paste them here.
+ This helps maintainers understand the context.
+ Example: https://app.roocode.com/share/task-id
+ placeholder: Paste your Roo Code share links here, one per line
+
+ - type: textarea
+ id: steps
+ attributes:
+ label: 🔁 Steps to Reproduce
+ description: |
+ Help us see what you saw. Give clear, numbered steps:
+
+ 1. Setup (OS, extension version, settings)
+ 2. Exact actions (clicks, input, files, commands)
+ 3. What happened after each step
+
+ Think like you're writing a recipe. Without this, we can't reproduce the issue.
+ validations:
+ required: true
+
+ - type: textarea
+ id: what-happened
+ attributes:
+ label: 💥 Outcome Summary
+ description: |
+ Recap what went wrong in one or two lines.
+
+ Example: "Expected code to run, but got an empty response and no error."
+ placeholder: Expected ___, but got ___.
+ validations:
+ required: true
+
+ - type: textarea
+ id: logs
+ attributes:
+ label: 📄 Relevant Logs or Errors (Optional)
+ description: Paste API logs, terminal output, or errors here. Use triple backticks (```) for code formatting.
+ render: shell
diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml
index 70472c2597..0351ad1930 100644
--- a/.github/ISSUE_TEMPLATE/config.yml
+++ b/.github/ISSUE_TEMPLATE/config.yml
@@ -1,7 +1,7 @@
blank_issues_enabled: false
contact_links:
- name: Feature Request
- url: https://github.com/RooVetGit/Roo-Code/discussions/categories/feature-requests
+ url: https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests
about: Share and vote on feature requests for Roo Code
- name: Leave a Review
url: https://marketplace.visualstudio.com/items?itemName=RooVeterinaryInc.roo-cline&ssr=false#review-details
diff --git a/.github/ISSUE_TEMPLATE/feature_request.yml b/.github/ISSUE_TEMPLATE/feature_request.yml
new file mode 100644
index 0000000000..4863f9ffa6
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/feature_request.yml
@@ -0,0 +1,201 @@
+name: Detailed Feature Proposal
+description: Report a specific problem that needs solving in Roo Code
+labels: ["proposal", "enhancement"]
+body:
+ - type: markdown
+ attributes:
+ value: |
+ **Thank you for submitting a feature request for Roo Code!**
+
+ This template helps you describe problems that need solving. Focus on the problem - the Roo team will work to design solutions unless you want to contribute the implementation yourself.
+
+ **Quality over speed:** We prefer detailed, clear problem descriptions over quick ones. Vague requests often get closed or require multiple rounds of clarification, which wastes everyone's time.
+
+ **Before submitting:**
+ - Search existing [Issues](https://github.com/RooCodeInc/Roo-Code/issues) and [Discussions](https://github.com/RooCodeInc/Roo-Code/discussions) to avoid duplicates
+ - For general ideas, use [GitHub Discussions](https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests) instead of this template.
+
+ - type: markdown
+ attributes:
+ value: |
+ ## ❌ Common mistakes that lead to request rejection:
+ - **Vague problem descriptions:** "UI is bad" -> Should be: "Submit button is invisible on dark theme"
+ - **Missing user impact:** "This would be cool" -> Should explain who benefits and how
+ - **No specific context:** Describe exactly when and how the problem occurs
+
+
+ - type: textarea
+ id: problem-description
+ attributes:
+ label: What specific problem does this solve?
+ description: |
+ **Be concrete and detailed.** Explain the problem from a user's perspective.
+
+ ✅ **Good examples (specific, clear impact):**
+ - "When running large tasks, users wait 5+ minutes because tasks execute sequentially instead of in parallel, blocking productivity"
+ - "AI can only read one file per request, forcing users to make multiple requests for multi-file projects, increasing wait time from 30s to 5+ minutes"
+ - "Dark theme users can't see the submit button because it uses white text on light grey background"
+
+ ❌ **Poor examples (vague, unclear impact):**
+ - "The UI looks weird" -> What specifically looks weird? On which screen? What's the impact?
+ - "System prompt is not good" -> What's wrong with it? What behaviour does it cause? What should it do instead?
+ - "Performance could be better" -> Where? How slow is it currently? What's the user impact?
+
+ **Your problem description should answer:**
+ - Who is affected? (all users, specific user types, etc.)
+ - When does this happen? (specific scenarios/steps)
+ - What's the current behaviour vs expected behaviour?
+ - What's the impact? (time wasted, errors caused, etc.)
+ placeholder: Be specific about the problem, who it affects, and the impact. Avoid generic statements like "it's slow" or "it's confusing."
+ validations:
+ required: true
+
+
+ - type: textarea
+ id: additional-context
+ attributes:
+ label: Additional context (optional)
+ description: Mockups, screenshots, links, user quotes, or other relevant information that supports your proposal.
+
+ - type: textarea
+ id: roo-code-tasks
+ attributes:
+ label: Roo Code Task Links (Optional)
+ description: |
+ If you used Roo Code to explore this feature request or develop solutions, share the public task links here.
+ This helps maintainers understand the context and any exploration you've done.
+ Example: https://app.roocode.com/share/task-id
+ placeholder: Paste your Roo Code share links here, one per line
+
+ - type: checkboxes
+ id: checklist
+ attributes:
+ label: Request checklist
+ options:
+ - label: I've searched existing Issues and Discussions for duplicates
+ required: true
+ - label: This describes a specific problem with clear impact and context
+ required: true
+
+ - type: markdown
+ attributes:
+ value: |
+ ---
+
+ ## 🛠️ **Optional: Contributing & Technical Analysis**
+
+ **🎯 Just reporting a problem?** You can click "Submit new issue" right now! The sections below are only needed if you want to contribute a solution via pull request.
+
+ **⚠️ Only continue if you want to:**
+ - Propose a specific solution design
+ - Implement the feature yourself via pull request
+ - Provide technical analysis to help with implementation
+
+ **For contributors who continue:**
+ - A maintainer (especially @hannesrudolph) will review this proposal. **Do not start implementation until approved and assigned.** We're a small team with limited resources, so every code addition needs careful consideration. We're always happy to receive clear, actionable proposals though!
+ - Join [Discord](https://discord.gg/roocode) and DM **Hannes Rudolph** (`hrudolph`) for guidance on implementation
+ - Check our [Roadmap](https://github.com/orgs/RooCodeInc/projects/1/views/1?query=sort%3Aupdated-desc+is%3Aopen&filterQuery=is%3Aissue%2Copen%2Cclosed+label%3A%22feature+request%22+status%3A%22Issue+%5BUnassigned%5D%22%2C%22Issue+%5BIn+Progress%5D%22) to see open feature requests ready to be implemented or currently being worked on
+
+ - type: checkboxes
+ id: willingness-to-contribute
+ attributes:
+ label: Interested in implementing this?
+ description: |
+ **Important:** If you check "Yes" below, the technical sections become REQUIRED.
+ We need detailed technical analysis from contributors to ensure quality implementation.
+ options:
+ - label: Yes, I'd like to help implement this feature
+ required: false
+
+ - type: checkboxes
+ id: implementation-approval
+ attributes:
+ label: Implementation requirements
+ options:
+ - label: I understand this needs approval before implementation begins
+ required: false
+
+ - type: textarea
+ id: proposed-solution
+ attributes:
+ label: How should this be solved? (REQUIRED if contributing, optional otherwise)
+ description: |
+ **If you want to implement this feature, this section is REQUIRED.**
+
+ **Describe your solution in detail.** Explain not just what to build, but how it should work.
+
+ ✅ **Good examples:**
+ - "Add parallel task execution: Allow up to 3 tasks to run simultaneously with a queue system for additional tasks. Show progress for each active task in the UI."
+ - "Enable multi-file AI processing: Modify the request handler to accept multiple files in a single request and process them together, reducing round trips."
+ - "Fix button contrast: Change submit button to use primary colour on dark theme (white text on blue background) instead of current grey."
+
+ ❌ **Poor examples:**
+ - "Make it faster" -> How? What specific changes?
+ - "Improve the UI" -> Which part? What specific improvements?
+ - "Fix the prompt" -> What should the new prompt do differently?
+
+ **Your solution should explain:**
+ - What exactly will change?
+ - How will users interact with it?
+ - What will the new behaviour look like?
+ placeholder: Describe the specific changes and how they will work. Include user interaction details if relevant.
+
+ - type: textarea
+ id: acceptance-criteria
+ attributes:
+ label: How will we know it works? (Acceptance Criteria - REQUIRED if contributing, optional otherwise)
+ description: |
+ **If you want to implement this feature, this section is REQUIRED.**
+
+ **This is crucial - don't skip it.** Define what "working" looks like with specific, testable criteria.
+
+ **Format suggestion:**
+ ```
+ Given [context/situation]
+ When [user action]
+ Then [expected result]
+ And [additional expectations]
+ But [what should NOT happen]
+ ```
+
+ **Example:**
+ ```
+ Given I have 5 large tasks to run
+ When I start all of them
+ Then they execute in parallel (max 3 at once, can be configured)
+ And I see progress for each active task
+ And queued tasks show "waiting" status
+ But the UI doesn't freeze or become unresponsive
+ ```
+ placeholder: |
+ Define specific, testable criteria. What should users be able to do? What should happen? What should NOT happen?
+ Use the Given/When/Then format above or your own clear structure.
+
+ - type: textarea
+ id: technical-considerations
+ attributes:
+ label: Technical considerations (REQUIRED if contributing, optional otherwise)
+ description: |
+ **If you want to implement this feature, this section is REQUIRED.**
+
+ Share technical insights that could help planning:
+ - Implementation approach or architecture changes
+ - Performance implications
+ - Compatibility concerns
+ - Systems that might be affected
+ - Potential blockers you can foresee
+ placeholder: e.g., "Will need to refactor task manager", "Could impact memory usage on large files", "Requires a large portion of code to be rewritten"
+
+ - type: textarea
+ id: trade-offs-and-risks
+ attributes:
+ label: Trade-offs and risks (REQUIRED if contributing, optional otherwise)
+ description: |
+ **If you want to implement this feature, this section is REQUIRED.**
+
+ What could go wrong or what alternatives did you consider?
+ - Alternative approaches and why you chose this one
+ - Potential negative impacts (performance, UX, etc.)
+ - Breaking changes or migration concerns
+ - Edge cases that need careful handling
+ placeholder: 'e.g., "Alternative: use library X but it is 500KB larger", "Risk: might slow older devices", "Breaking: changes API response format"'
diff --git a/.github/ISSUE_TEMPLATE/marketplace.yml b/.github/ISSUE_TEMPLATE/marketplace.yml
new file mode 100644
index 0000000000..f314ca520a
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/marketplace.yml
@@ -0,0 +1,62 @@
+name: Marketplace Feedback
+description: Report issues or suggest improvements for marketplace items (custom modes and MCP servers)
+labels: ["marketplace"]
+body:
+ - type: markdown
+ attributes:
+ value: |
+ **Thanks for your feedback!** Please check existing issues first: https://github.com/RooCodeInc/Roo-Code/issues
+
+ - type: dropdown
+ id: feedback-type
+ attributes:
+ label: What kind of feedback?
+ options:
+ - Problem with existing marketplace item
+ - Suggestion for new custom mode
+ - Suggestion for new MCP server
+ - General marketplace issue
+ validations:
+ required: true
+
+ - type: dropdown
+ id: item-type
+ attributes:
+ label: Item Type (if applicable)
+ options:
+ - Custom Mode
+ - MCP Server
+ - Marketplace UI/Functionality
+ - Not Applicable
+ validations:
+ required: false
+
+ - type: input
+ id: item-name
+ attributes:
+ label: Item Name (if applicable)
+ placeholder: e.g., "Debug Mode", "Weather API Server", "Code Formatter"
+
+ - type: textarea
+ id: description
+ attributes:
+ label: Description
+ description: What's the issue or what would you like to see?
+ placeholder: Clear description of the problem or suggestion
+ validations:
+ required: true
+
+ - type: textarea
+ id: additional-info
+ attributes:
+ label: Additional Details (optional)
+ description: Steps to reproduce, expected behavior, screenshots, etc.
+ placeholder: Any other helpful information
+
+ - type: checkboxes
+ id: checklist
+ attributes:
+ label: Checklist
+ options:
+ - label: I've searched existing issues for duplicates
+ required: true
\ No newline at end of file
diff --git a/.github/actions/ai-release-notes/action.yml b/.github/actions/ai-release-notes/action.yml
deleted file mode 100644
index 575e49c97c..0000000000
--- a/.github/actions/ai-release-notes/action.yml
+++ /dev/null
@@ -1,83 +0,0 @@
-name: AI Release Notes
-description: Generate AI release notes using git and openai, outputs 'RELEASE_NOTES' and 'OPENAI_PROMPT'
-
-inputs:
- OPENAI_API_KEY:
- required: true
- type: string
- GHA_PAT:
- required: true
- type: string
- model_name:
- required: false
- type: string
- default: gpt-4o-mini
- repo_path:
- required: false
- type: string
- custom_prompt:
- required: false
- default: ''
- type: string
- git_ref:
- required: true
- type: string
- head_ref:
- required: true
- type: string
- base_ref:
- required: true
- type: string
-
-outputs:
- RELEASE_NOTES:
- description: "AI generated release notes"
- value: ${{ steps.ai_release_notes.outputs.RELEASE_NOTES }}
- OPENAI_PROMPT:
- description: "Prompt used to generate release notes"
- value: ${{ steps.ai_prompt.outputs.OPENAI_PROMPT }}
-
-env:
- GITHUB_REF: ${{ inputs.git_ref }}
- BASE_REF: ${{ inputs.base_ref }}
- HEAD_REF: ${{ inputs.head_ref }}
-
-runs:
- using: "composite"
- steps:
- - uses: actions/checkout@v4
- with:
- repository: ${{ inputs.repo_path }}
- token: ${{ inputs.GHA_PAT }}
- ref: ${{ env.GITHUB_REF }}
- fetch-depth: 0
-
- - name: Set Workspace
- shell: bash
- run: |
- pip install tiktoken
- pip install pytz
-
- # Github outputs: 'OPENAI_PROMPT'
- - name: Add Git Info to base prompt
- id: ai_prompt
- shell: bash
- env:
- BASE_REF: ${{ env.BASE_REF }}
- HEAD_SHA: ${{ env.HEAD_SHA }}
- PR_TITLE: ${{ github.event.pull_request.title }}
- PR_BODY: ${{ github.event.pull_request.body }}
- MODEL_NAME: ${{ inputs.model_name }}
- CUSTOM_PROMPT: ${{ inputs.custom_prompt }} # Default: ''
- run: python .github/scripts/release-notes-prompt.py
-
- # Github outputs: 'RELEASE_NOTES'
- - name: Generate AI release notes
- id: ai_release_notes
- shell: bash
- env:
- OPENAI_API_KEY: ${{ inputs.OPENAI_API_KEY }}
- CUSTOM_PROMPT: ${{ steps.ai_prompt.outputs.OPENAI_PROMPT }}
- MODEL_NAME: ${{ inputs.model_name }}
- run: python .github/scripts/ai-release-notes.py
-
diff --git a/.github/actions/setup-node-pnpm/action.yml b/.github/actions/setup-node-pnpm/action.yml
new file mode 100644
index 0000000000..af9b45b5e9
--- /dev/null
+++ b/.github/actions/setup-node-pnpm/action.yml
@@ -0,0 +1,48 @@
+name: "Setup Node.js and pnpm"
+
+description: "Sets up Node.js and pnpm with caching and installs dependencies"
+
+inputs:
+ node-version:
+ description: "Node.js version to use"
+ required: false
+ default: "20.19.2"
+ pnpm-version:
+ description: "pnpm version to use"
+ required: false
+ default: "10.8.1"
+ skip-install:
+ description: "Skip dependency installation"
+ required: false
+ default: "false"
+ install-args:
+ description: "Additional arguments for pnpm install"
+ required: false
+ default: ""
+
+runs:
+ using: "composite"
+ steps:
+ - name: Install pnpm
+ uses: pnpm/action-setup@v4
+ with:
+ version: ${{ inputs.pnpm-version }}
+ - name: Get pnpm store directory
+ shell: bash
+ run: |
+ echo "STORE_PATH=$(pnpm store path --silent)" >> $GITHUB_ENV
+ - name: Setup pnpm cache
+ uses: actions/cache@v4
+ with:
+ path: ${{ env.STORE_PATH }}
+ key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
+ restore-keys: |
+ ${{ runner.os }}-pnpm-store-
+ - name: Setup Node.js
+ uses: actions/setup-node@v4
+ with:
+ node-version: ${{ inputs.node-version }}
+ - name: Install dependencies
+ if: ${{ inputs.skip-install != 'true' }}
+ shell: bash
+ run: pnpm install ${{ inputs.install-args }}
diff --git a/.github/actions/slack-notify/action.yml b/.github/actions/slack-notify/action.yml
new file mode 100644
index 0000000000..9e95ab959d
--- /dev/null
+++ b/.github/actions/slack-notify/action.yml
@@ -0,0 +1,58 @@
+name: 'Slack Notification'
+description: 'Send Slack notification for workflow failures'
+inputs:
+ webhook-url:
+ description: 'Slack webhook URL'
+ required: true
+ channel:
+ description: 'Slack channel to notify'
+ required: true
+ workflow-name:
+ description: 'Name of the workflow'
+ required: true
+ failed-jobs:
+ description: 'JSON object containing job results'
+ required: true
+
+runs:
+ using: 'composite'
+ steps:
+ - name: Parse failed jobs
+ id: parse-jobs
+ shell: bash
+ run: |
+ echo "Parsing job results..."
+ failed_list=""
+
+ echo '${{ inputs.failed-jobs }}' | jq -r 'to_entries[] | select(.value.result == "failure") | .key' | while read job; do
+ case $job in
+ "check-translations") failed_list="${failed_list}❌ Translation check\n" ;;
+ "knip") failed_list="${failed_list}❌ Knip analysis\n" ;;
+ "compile") failed_list="${failed_list}❌ Compile & lint\n" ;;
+ "unit-test") failed_list="${failed_list}❌ Unit tests\n" ;;
+ "integration-test") failed_list="${failed_list}❌ Integration tests\n" ;;
+ esac
+ done
+
+ echo "failed_jobs<> $GITHUB_OUTPUT
+ echo -e "$failed_list" | sed '/^$/d' >> $GITHUB_OUTPUT
+ echo "EOF" >> $GITHUB_OUTPUT
+
+ - name: Send Slack notification
+ uses: 8398a7/action-slack@v3
+ with:
+ status: failure
+ channel: ${{ inputs.channel }}
+ text: |
+ 🚨 ${{ inputs.workflow-name }} workflow failed on main branch!
+
+ Repository: ${{ github.repository }}
+ Commit: ${{ github.sha }}
+ Author: ${{ github.actor }}
+
+ Failed jobs:
+ ${{ steps.parse-jobs.outputs.failed_jobs }}
+
+ View details: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
+ env:
+ SLACK_WEBHOOK_URL: ${{ inputs.webhook-url }}
diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
index de7e461cb9..e83e44cd66 100644
--- a/.github/pull_request_template.md
+++ b/.github/pull_request_template.md
@@ -1,35 +1,75 @@
-## Context
-
-
-
-## Implementation
-
-## Screenshots
+### Related GitHub Issue
-| before | after |
-| ------ | ----- |
-| | |
+
-## How to Test
+Closes: #
+
+### Roo Code Task Context (Optional)
-## Get in Touch
+### Description
-
+
+
+### Test Procedure
+
+
+
+### Pre-Submission Checklist
+
+
+
+- [ ] **Issue Linked**: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
+- [ ] **Scope**: My changes are focused on the linked issue (one major feature/fix per PR).
+- [ ] **Self-Review**: I have performed a thorough self-review of my code.
+- [ ] **Testing**: New and/or updated tests have been added to cover my changes (if applicable).
+- [ ] **Documentation Impact**: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
+- [ ] **Contribution Guidelines**: I have read and agree to the [Contributor Guidelines](/CONTRIBUTING.md).
+
+### Screenshots / Videos
+
+
+
+### Documentation Updates
+
+
+
+### Additional Notes
+
+
+
+### Get in Touch
+
+
diff --git a/.github/scripts/ai-release-notes.py b/.github/scripts/ai-release-notes.py
deleted file mode 100644
index 5dc451810e..0000000000
--- a/.github/scripts/ai-release-notes.py
+++ /dev/null
@@ -1,123 +0,0 @@
-"""
-AI-powered release notes generator that creates concise and informative release notes from git changes.
-
-This script uses OpenAI's API to analyze git changes (summary, diff, and commit log) and generate
-well-formatted release notes in markdown. It focuses on important changes and their impact,
-particularly highlighting new types and schemas while avoiding repetitive information.
-
-Environment Variables Required:
- OPENAI_API_KEY: OpenAI API key for authentication
- CHANGE_SUMMARY: Summary of changes made (optional if CUSTOM_PROMPT provided)
- CHANGE_DIFF: Git diff of changes (optional if CUSTOM_PROMPT provided)
- CHANGE_LOG: Git commit log (optional if CUSTOM_PROMPT provided)
- GITHUB_OUTPUT: Path to GitHub output file
- CUSTOM_PROMPT: Custom prompt to override default (optional)
-"""
-
-import os
-import requests # type: ignore
-import json
-import tiktoken # type: ignore
-
-OPENAI_API_KEY = os.environ["OPENAI_API_KEY"]
-CHANGE_SUMMARY = os.environ.get('CHANGE_SUMMARY', '')
-CHANGE_DIFF = os.environ.get('CHANGE_DIFF', '')
-CHANGE_LOG = os.environ.get('CHANGE_LOG', '')
-GITHUB_OUTPUT = os.getenv("GITHUB_OUTPUT")
-OPEN_AI_BASE_URL = "https://api.openai.com/v1"
-OPEN_API_HEADERS = {"Authorization": f"Bearer {OPENAI_API_KEY}", "Content-Type": "application/json"}
-CUSTOM_PROMPT = os.environ.get('CUSTOM_PROMPT', '')
-MODEL_NAME = os.environ.get('MODEL_NAME', 'gpt-3.5-turbo-16k')
-
-def num_tokens_from_string(string: str, model_name: str) -> int:
- """
- Calculate the number of tokens in a text string for a specific model.
-
- Args:
- string: The input text to count tokens for
- model_name: Name of the OpenAI model to use for token counting
-
- Returns:
- int: Number of tokens in the input string
- """
- encoding = tiktoken.encoding_for_model(model_name)
- num_tokens = len(encoding.encode(string))
- return num_tokens
-
-def truncate_to_token_limit(text, max_tokens, model_name):
- """
- Truncate text to fit within a maximum token limit for a specific model.
-
- Args:
- text: The input text to truncate
- max_tokens: Maximum number of tokens allowed
- model_name: Name of the OpenAI model to use for tokenization
-
- Returns:
- str: Truncated text that fits within the token limit
- """
- encoding = tiktoken.encoding_for_model(model_name)
- encoded = encoding.encode(text)
- truncated = encoded[:max_tokens]
- return encoding.decode(truncated)
-
-def generate_release_notes(model_name):
- """
- Generate release notes using OpenAI's API based on git changes.
-
- Uses the GPT-3.5-turbo model to analyze change summary, commit log, and code diff
- to generate concise and informative release notes in markdown format. The notes
- focus on important changes and their impact, with sections for new types/schemas
- and other updates.
-
- Returns:
- str: Generated release notes in markdown format
-
- Raises:
- requests.exceptions.RequestException: If the OpenAI API request fails
- """
- max_tokens = 14000 # Reserve some tokens for the response
-
- # Truncate inputs if necessary to fit within token limits
- change_summary = '' if CUSTOM_PROMPT else truncate_to_token_limit(CHANGE_SUMMARY, 1000, model_name)
- change_log = '' if CUSTOM_PROMPT else truncate_to_token_limit(CHANGE_LOG, 2000, model_name)
- change_diff = '' if CUSTOM_PROMPT else truncate_to_token_limit(CHANGE_DIFF, max_tokens - num_tokens_from_string(change_summary, model_name) - num_tokens_from_string(change_log, model_name) - 1000, model_name)
-
- url = f"{OPEN_AI_BASE_URL}/chat/completions"
-
- # Construct prompt for OpenAI API
- openai_prompt = CUSTOM_PROMPT if CUSTOM_PROMPT else f"""Based on the following summary of changes, commit log and code diff, please generate concise and informative release notes:
- Summary of changes:
- {change_summary}
- Commit log:
- {change_log}
- Code Diff:
- {json.dumps(change_diff)}
- """
-
- data = {
- "model": model_name,
- "messages": [{"role": "user", "content": openai_prompt}],
- "temperature": 0.7,
- "max_tokens": 1000,
- }
-
- print("----------------------------------------------------------------------------------------------------------")
- print("POST request to OpenAI")
- print("----------------------------------------------------------------------------------------------------------")
- ai_response = requests.post(url, headers=OPEN_API_HEADERS, json=data)
- print(f"Status Code: {str(ai_response.status_code)}")
- print(f"Response: {ai_response.text}")
- ai_response.raise_for_status()
-
- return ai_response.json()["choices"][0]["message"]["content"]
-
-release_notes = generate_release_notes(MODEL_NAME)
-print("----------------------------------------------------------------------------------------------------------")
-print("OpenAI generated release notes")
-print("----------------------------------------------------------------------------------------------------------")
-print(release_notes)
-
-# Write the release notes to GITHUB_OUTPUT
-with open(GITHUB_OUTPUT, "a") as outputs_file:
- outputs_file.write(f"RELEASE_NOTES<= 3:
- # Parse HEAD~1 (PR to generate notes for)
- head_info = parse_merge_commit(commits[1])
- # Parse HEAD~2 (previous PR to compare against)
- base_info = parse_merge_commit(commits[2])
-
- if head_info and base_info:
- # Set output for GitHub Actions
- with open(os.environ['GITHUB_OUTPUT'], 'a') as gha_outputs:
- gha_outputs.write(f"head_ref={head_info['sha']}\n")
- gha_outputs.write(f"base_ref={base_info['sha']}")
-
- print(f"Head ref (PR #{head_info['pr_number']}): {head_info['sha']}")
- print(f"Base ref (PR #{base_info['pr_number']}): {base_info['sha']}")
- return head_info, base_info
-
- print("Could not find or parse sufficient merge history")
- return None, None
-
-if __name__ == "__main__":
- head_info, base_info = get_version_refs()
\ No newline at end of file
diff --git a/.github/scripts/overwrite_changeset_changelog.py b/.github/scripts/overwrite_changeset_changelog.py
deleted file mode 100755
index 42e693d4ac..0000000000
--- a/.github/scripts/overwrite_changeset_changelog.py
+++ /dev/null
@@ -1,62 +0,0 @@
-"""
-This script updates a specific version's release notes section in CHANGELOG.md with new content
-or reformats existing content.
-
-The script:
-1. Takes a version number, changelog path, and optionally new content as input from environment variables
-2. Finds the section in the changelog for the specified version
-3. Either:
- a) Replaces the content with new content if provided, or
- b) Reformats existing content by:
- - Removing the first two lines of the changeset format
- - Ensuring version numbers are wrapped in square brackets
-4. Writes the updated changelog back to the file
-
-Environment Variables:
- CHANGELOG_PATH: Path to the changelog file (defaults to 'CHANGELOG.md')
- VERSION: The version number to update/format
- PREV_VERSION: The previous version number (used to locate section boundaries)
- NEW_CONTENT: Optional new content to insert for this version
-"""
-
-#!/usr/bin/env python3
-
-import os
-
-CHANGELOG_PATH = os.environ.get("CHANGELOG_PATH", "CHANGELOG.md")
-VERSION = os.environ['VERSION']
-PREV_VERSION = os.environ.get("PREV_VERSION", "")
-NEW_CONTENT = os.environ.get("NEW_CONTENT", "")
-
-def overwrite_changelog_section(changelog_text: str, new_content: str):
- # Find the section for the specified version
- version_pattern = f"## {VERSION}\n"
- prev_version_pattern = f"## [{PREV_VERSION}]\n"
- print(f"latest version: {VERSION}")
- print(f"prev_version: {PREV_VERSION}")
-
- notes_start_index = changelog_text.find(version_pattern) + len(version_pattern)
- notes_end_index = changelog_text.find(prev_version_pattern, notes_start_index) if PREV_VERSION and prev_version_pattern in changelog_text else len(changelog_text)
-
- if new_content:
- return changelog_text[:notes_start_index] + f"{new_content}\n" + changelog_text[notes_end_index:]
- else:
- changeset_lines = changelog_text[notes_start_index:notes_end_index].split("\n")
- # Remove the first two lines from the regular changeset format, ex: \n### Patch Changes
- parsed_lines = "\n".join(changeset_lines[2:])
- updated_changelog = changelog_text[:notes_start_index] + parsed_lines + changelog_text[notes_end_index:]
- updated_changelog = updated_changelog.replace(f"## {VERSION}", f"## [{VERSION}]")
- return updated_changelog
-
-with open(CHANGELOG_PATH, 'r') as f:
- changelog_content = f.read()
-
-new_changelog = overwrite_changelog_section(changelog_content, NEW_CONTENT)
-print("----------------------------------------------------------------------------------")
-print(new_changelog)
-print("----------------------------------------------------------------------------------")
-# Write back to CHANGELOG.md
-with open(CHANGELOG_PATH, 'w') as f:
- f.write(new_changelog)
-
-print(f"{CHANGELOG_PATH} updated successfully!")
\ No newline at end of file
diff --git a/.github/scripts/parse_changeset_changelog.py b/.github/scripts/parse_changeset_changelog.py
deleted file mode 100755
index b21c444dd1..0000000000
--- a/.github/scripts/parse_changeset_changelog.py
+++ /dev/null
@@ -1,64 +0,0 @@
-"""
-This script extracts the release notes section for a specific version from CHANGELOG.md.
-
-The script:
-1. Takes a version number and changelog path as input from environment variables
-2. Finds the section in the changelog for the specified version
-3. Extracts the content between the current version header and the next version header
- (or end of file if it's the latest version)
-4. Outputs the extracted release notes to GITHUB_OUTPUT for use in creating GitHub releases
-
-Environment Variables:
- GITHUB_OUTPUT: Path to GitHub Actions output file
- CHANGELOG_PATH: Path to the changelog file (defaults to 'CHANGELOG.md')
- VERSION: The version number to extract notes for
-"""
-
-#!/usr/bin/env python3
-
-import sys
-import os
-import subprocess
-
-GITHUB_OUTPUT = os.getenv("GITHUB_OUTPUT")
-CHANGELOG_PATH = os.environ.get("CHANGELOG_PATH", "CHANGELOG.md")
-VERSION = os.environ['VERSION']
-
-def parse_changelog_section(content: str):
- """Parse a specific version section from the changelog content.
-
- Args:
- content: The full changelog content as a string
-
- Returns:
- The formatted content for this version, or None if version not found
-
- Example:
- >>> content = "## 1.2.0\\nChanges\\n## 1.1.0\\nOld changes"
- >>> parse_changelog_section(content)
- 'Changes\\n'
- """
- # Find the section for the specified version
- version_pattern = f"## {VERSION}\n"
- print(f"latest version: {VERSION}")
- notes_start_index = content.find(version_pattern) + len(version_pattern)
- prev_version = subprocess.getoutput("git show origin/main:package.json | grep '\"version\":' | cut -d'\"' -f4")
- print(f"prev_version: {prev_version}")
- prev_version_pattern = f"## {prev_version}\n"
- notes_end_index = content.find(prev_version_pattern, notes_start_index) if prev_version_pattern in content else len(content)
-
- return content[notes_start_index:notes_end_index]
-
-with open(CHANGELOG_PATH, 'r') as f:
- content = f.read()
-
-formatted_content = parse_changelog_section(content)
-if not formatted_content:
- print(f"Version {VERSION} not found in changelog", file=sys.stderr)
- sys.exit(1)
-
-print(formatted_content)
-
-# Write the extracted release notes to GITHUB_OUTPUT
-with open(GITHUB_OUTPUT, "a") as gha_output:
- gha_output.write(f"release-notes< and that contains [!IMPORTANT]
- ellipsis_match = re.search(r'(.*?)', pr_body, re.DOTALL)
- if ellipsis_match:
- content = ellipsis_match.group(1).strip()
- important_match = re.search(r'\[!IMPORTANT\](.*?)(?=\[!|$)', content, re.DOTALL)
- if important_match:
- important_text = important_match.group(1).strip()
- important_text = re.sub(r'^-+\s*', '', important_text)
- return important_text.strip()
- return ""
-
-def extract_coderabbit_summary(pr_body):
- # Find content between ## Summary by CodeRabbit and the next ## or end of text
- summary_match = re.search(r'## Summary by CodeRabbit\s*\n(.*?)(?=\n##|$)', pr_body, re.DOTALL)
- return summary_match.group(1).strip() if summary_match else ""
-
-def num_tokens_from_string(string: str, model_name: str) -> int:
- """
- Calculate the number of tokens in a text string for a specific model.
-
- Args:
- string: The input text to count tokens for
- model_name: Name of the OpenAI model to use for token counting
-
- Returns:
- int: Number of tokens in the input string
- """
- encoding = tiktoken.encoding_for_model(model_name)
- num_tokens = len(encoding.encode(string))
- return num_tokens
-
-def truncate_to_token_limit(text, max_tokens, model_name):
- """
- Truncate text to fit within a maximum token limit for a specific model.
-
- Args:
- text: The input text to truncate
- max_tokens: Maximum number of tokens allowed
- model_name: Name of the OpenAI model to use for tokenization
-
- Returns:
- str: Truncated text that fits within the token limit
- """
- encoding = tiktoken.encoding_for_model(model_name)
- encoded = encoding.encode(text)
- truncated = encoded[:max_tokens]
- return encoding.decode(truncated)
-
-# Extract sections and combine into PR_OVERVIEW
-description = extract_description_section(PR_BODY)
-important = extract_ellipsis_important(PR_BODY)
-summary = extract_coderabbit_summary(PR_BODY)
-
-PR_OVERVIEW = "\n\n".join(filter(None, [description, important, summary]))
-
-# Get git information
-base_sha = subprocess.getoutput(f"git rev-parse origin/{BASE_REF}") if BASE_REF == 'main' else BASE_REF
-diff_overview = subprocess.getoutput(f"git diff {base_sha}..{HEAD_SHA} --name-status | awk '{{print $2}}' | sort | uniq -c | awk '{{print $2 \": \" $1 \" files changed\"}}'")
-git_log = subprocess.getoutput(f"git log {base_sha}..{HEAD_SHA} --pretty=format:'%h - %s (%an)' --reverse | head -n 50")
-git_diff = subprocess.getoutput(f"git diff {base_sha}..{HEAD_SHA} --minimal --abbrev --ignore-cr-at-eol --ignore-space-at-eol --ignore-space-change --ignore-all-space --ignore-blank-lines --unified=0 --diff-filter=ACDMRT")
-
-max_tokens = 14000 # Reserve some tokens for the response
-changes_summary = truncate_to_token_limit(diff_overview, 1000, MODEL_NAME)
-git_logs = truncate_to_token_limit(git_log, 2000, MODEL_NAME)
-changes_diff = truncate_to_token_limit(git_diff, max_tokens - num_tokens_from_string(changes_summary, MODEL_NAME) - num_tokens_from_string(git_logs, MODEL_NAME) - 1000, MODEL_NAME)
-
-# Get today's existing changelog if any
-existing_changelog = EXISTING_NOTES if EXISTING_NOTES != "null" else None
-existing_changelog_text = f"\nAdditional context:\n{existing_changelog}" if existing_changelog else ""
-TODAY = datetime.now(timezone('US/Eastern')).isoformat(sep=' ', timespec='seconds')
-
-BASE_PROMPT = CUSTOM_PROMPT if CUSTOM_PROMPT else f"""Based on the following 'PR Information', please generate concise and informative release notes to be read by developers.
-Format the release notes with markdown, and always use this structure: a descriptive and very short title (no more than 8 words) with heading level 2, a paragraph with a summary of changes (no header), and if applicable, sections for '🚀 New Features & Improvements', '🐛 Bugs Fixed' and '🔧 Other Updates', with heading level 3, skip respectively the sections if not applicable.
-Finally include the following markdown comment with the PR merged date: .
-Avoid being repetitive and focus on the most important changes and their impact, discard any mention of version bumps/updates, changeset files, environment variables or syntax updates.
-PR Information:"""
-
-OPENAI_PROMPT = f"""{BASE_PROMPT}
-Git log summary:
-{changes_summary}
-Commit Messages:
-{git_logs}
-PR Title:
-{PR_TITLE}
-PR Overview:
-{PR_OVERVIEW}{existing_changelog_text}
-Code Diff:
-{json.dumps(changes_diff)}"""
-
-print("OpenAI Prompt")
-print("----------------------------------------------------------------")
-print(OPENAI_PROMPT)
-
-# Write the prompt to GITHUB_OUTPUT
-with open(GITHUB_OUTPUT, "a") as outputs_file:
- outputs_file.write(f"OPENAI_PROMPT<> $GITHUB_OUTPUT
- PREV_VERSION=$(git show origin/main:package.json | jq -r '.version')
- echo "prev_version=$PREV_VERSION" >> $GITHUB_OUTPUT
- echo "version=$VERSION"
- echo "prev_version=$PREV_VERSION"
-
- # Update CHANGELOG.md with proper format
- - name: Update Changelog Format
- if: ${{ !contains(github.event.pull_request.labels.*.name, 'changelog-ready') }}
- env:
- VERSION: ${{ steps.get_version.outputs.version }}
- PREV_VERSION: ${{ steps.get_version.outputs.prev_version }}
- run: python .github/scripts/overwrite_changeset_changelog.py
-
# Commit and push changelog updates
- name: Push Changelog updates
if: ${{ !contains(github.event.pull_request.labels.*.name, 'changelog-ready') }}
@@ -155,4 +129,4 @@ jobs:
if: false # Needs enablePullRequestAutoMerge in repo settings to work contains(github.event.pull_request.labels.*.name, 'changelog-ready')
run: gh pr merge --auto --merge ${{ github.event.pull_request.number }}
env:
- GH_TOKEN: ${{ secrets.CROSS_REPO_ACCESS_TOKEN }}
+ GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
diff --git a/.github/workflows/code-qa.yml b/.github/workflows/code-qa.yml
index b7292dd9ee..ba85a01b21 100644
--- a/.github/workflows/code-qa.yml
+++ b/.github/workflows/code-qa.yml
@@ -1,118 +1,107 @@
name: Code QA Roo Code
on:
- workflow_dispatch:
- push:
- branches: [main]
- pull_request:
- types: [opened, reopened, ready_for_review, synchronize]
- branches: [main]
+ workflow_dispatch:
+ push:
+ branches: [main]
+ pull_request:
+ types: [opened, reopened, ready_for_review, synchronize]
+ branches: [main]
jobs:
- compile:
- runs-on: ubuntu-latest
- steps:
- - name: Checkout code
- uses: actions/checkout@v4
- - name: Setup Node.js
- uses: actions/setup-node@v4
- with:
- node-version: '18'
- cache: 'npm'
- - name: Install dependencies
- run: npm run install:ci
- - name: Compile
- run: npm run compile
- - name: Check types
- run: npm run check-types
- - name: Lint
- run: npm run lint
+ check-translations:
+ runs-on: ubuntu-latest
+ steps:
+ - name: Checkout code
+ uses: actions/checkout@v4
+ - name: Setup Node.js and pnpm
+ uses: ./.github/actions/setup-node-pnpm
+ - name: Verify all translations are complete
+ run: node scripts/find-missing-translations.js
- knip:
- runs-on: ubuntu-latest
- steps:
- - name: Checkout code
- uses: actions/checkout@v4
- - name: Setup Node.js
- uses: actions/setup-node@v4
- with:
- node-version: '18'
- cache: 'npm'
- - name: Install dependencies
- run: npm run install:ci
- - name: Run knip checks
- run: npm run knip
+ knip:
+ runs-on: ubuntu-latest
+ steps:
+ - name: Checkout code
+ uses: actions/checkout@v4
+ - name: Setup Node.js and pnpm
+ uses: ./.github/actions/setup-node-pnpm
+ - name: Run knip checks
+ run: pnpm knip
- test-extension:
- runs-on: ubuntu-latest
- steps:
- - name: Checkout code
- uses: actions/checkout@v4
- - name: Setup Node.js
- uses: actions/setup-node@v4
- with:
- node-version: '18'
- cache: 'npm'
- - name: Install dependencies
- run: npm run install:ci
- - name: Run unit tests
- run: npx jest --silent
+ compile:
+ runs-on: ubuntu-latest
+ steps:
+ - name: Checkout code
+ uses: actions/checkout@v4
+ - name: Setup Node.js and pnpm
+ uses: ./.github/actions/setup-node-pnpm
+ - name: Lint
+ run: pnpm lint
+ - name: Check types
+ run: pnpm check-types
- test-webview:
- runs-on: ubuntu-latest
- steps:
- - name: Checkout code
- uses: actions/checkout@v4
- - name: Setup Node.js
- uses: actions/setup-node@v4
- with:
- node-version: '18'
- cache: 'npm'
- - name: Install dependencies
- run: npm run install:ci
- - name: Run unit tests
- working-directory: webview-ui
- run: npx jest --silent
+ unit-test:
+ name: platform-unit-test (${{ matrix.name }})
+ runs-on: ${{ matrix.os }}
+ strategy:
+ matrix:
+ include:
+ - os: ubuntu-latest
+ name: ubuntu-latest
+ - os: windows-latest
+ name: windows-latest
+ steps:
+ - name: Checkout code
+ uses: actions/checkout@v4
+ - name: Setup Node.js and pnpm
+ uses: ./.github/actions/setup-node-pnpm
+ - name: Run unit tests
+ run: pnpm test
- unit-test:
- needs: [test-extension, test-webview]
- runs-on: ubuntu-latest
- steps:
- - name: NO-OP
- run: echo "All unit tests passed."
+ check-openrouter-api-key:
+ runs-on: ubuntu-latest
+ outputs:
+ exists: ${{ steps.openrouter-api-key-check.outputs.defined }}
+ steps:
+ - name: Check if OpenRouter API key exists
+ id: openrouter-api-key-check
+ shell: bash
+ run: |
+ if [ "${{ secrets.OPENROUTER_API_KEY }}" != '' ]; then
+ echo "defined=true" >> $GITHUB_OUTPUT;
+ else
+ echo "defined=false" >> $GITHUB_OUTPUT;
+ fi
- check-openrouter-api-key:
- runs-on: ubuntu-latest
- outputs:
- exists: ${{ steps.openrouter-api-key-check.outputs.defined }}
- steps:
- - name: Check if OpenRouter API key exists
- id: openrouter-api-key-check
- shell: bash
- run: |
- if [ "${{ secrets.OPENROUTER_API_KEY }}" != '' ]; then
- echo "defined=true" >> $GITHUB_OUTPUT;
- else
- echo "defined=false" >> $GITHUB_OUTPUT;
- fi
+ integration-test:
+ runs-on: ubuntu-latest
+ needs: [check-openrouter-api-key]
+ if: needs.check-openrouter-api-key.outputs.exists == 'true'
+ steps:
+ - name: Checkout code
+ uses: actions/checkout@v4
+ - name: Setup Node.js and pnpm
+ uses: ./.github/actions/setup-node-pnpm
+ - name: Create .env.local file
+ working-directory: apps/vscode-e2e
+ run: echo "OPENROUTER_API_KEY=${{ secrets.OPENROUTER_API_KEY }}" > .env.local
+ - name: Run integration tests
+ working-directory: apps/vscode-e2e
+ run: xvfb-run -a pnpm test:ci
- integration-test:
- runs-on: ubuntu-latest
- needs: [check-openrouter-api-key]
- if: needs.check-openrouter-api-key.outputs.exists == 'true'
- steps:
- - name: Checkout code
- uses: actions/checkout@v4
- - name: Setup Node.js
- uses: actions/setup-node@v4
- with:
- node-version: '18'
- cache: 'npm'
- - name: Install dependencies
- run: npm run install:ci
- - name: Create env.integration file
- working-directory: e2e
- run: echo "OPENROUTER_API_KEY=${{ secrets.OPENROUTER_API_KEY }}" > .env.integration
- - name: Run integration tests
- working-directory: e2e
- run: xvfb-run -a npm run ci
+ notify-slack-on-failure:
+ runs-on: ubuntu-latest
+ needs: [check-translations, knip, compile, unit-test, integration-test]
+ if: ${{ always() && github.event_name == 'push' && github.ref == 'refs/heads/main' && contains(needs.*.result, 'failure') }}
+ steps:
+ - name: Checkout code
+ uses: actions/checkout@v4
+
+ - name: Send Slack notification on failure
+ uses: ./.github/actions/slack-notify
+ with:
+ webhook-url: ${{ secrets.SLACK_WEBHOOK_URL }}
+ channel: "#ci"
+ workflow-name: "Code QA"
+ failed-jobs: ${{ toJSON(needs) }}
diff --git a/.github/workflows/codeql.yml b/.github/workflows/codeql.yml
index bed91ffd50..0784c8cbad 100644
--- a/.github/workflows/codeql.yml
+++ b/.github/workflows/codeql.yml
@@ -1,15 +1,4 @@
-# For most projects, this workflow file will not need changing; you simply need
-# to commit it to your repository.
-#
-# You may wish to alter this file to override the set of languages analyzed,
-# or to provide custom queries or build logic.
-#
-# ******** NOTE ********
-# We have attempted to detect the languages in your repository. Please check
-# the `language` matrix defined below to confirm you have the correct set of
-# supported CodeQL languages.
-#
-name: "CodeQL Advanced"
+name: CodeQL Advanced
on:
push:
diff --git a/.github/workflows/evals.yml b/.github/workflows/evals.yml
new file mode 100644
index 0000000000..b99fd7659e
--- /dev/null
+++ b/.github/workflows/evals.yml
@@ -0,0 +1,74 @@
+name: Evals
+
+on:
+ pull_request:
+ types: [labeled]
+ workflow_dispatch:
+
+env:
+ DOCKER_BUILDKIT: 1
+ COMPOSE_DOCKER_CLI_BUILD: 1
+
+jobs:
+ evals:
+ # Run if triggered manually or if PR has 'evals' label.
+ if: github.event_name == 'workflow_dispatch' || contains(github.event.label.name, 'evals')
+ runs-on: blacksmith-16vcpu-ubuntu-2404
+ timeout-minutes: 45
+
+ defaults:
+ run:
+ working-directory: packages/evals
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v4
+
+ - name: Set up Docker Buildx
+ uses: docker/setup-buildx-action@v3
+
+ - name: Create environment
+ run: |
+ cat > .env.local << EOF
+ OPENROUTER_API_KEY=${{ secrets.OPENROUTER_API_KEY || 'test-key-for-build' }}
+ EOF
+
+ cat > .env.development << EOF
+ NODE_ENV=development
+ DATABASE_URL=postgresql://postgres:password@db:5432/evals_development
+ REDIS_URL=redis://redis:6379
+ HOST_EXECUTION_METHOD=docker
+ EOF
+
+ - name: Build image
+ uses: docker/build-push-action@v6
+ with:
+ context: .
+ file: packages/evals/Dockerfile.runner
+ tags: evals-runner:latest
+ cache-from: type=gha
+ cache-to: type=gha,mode=max
+ push: false
+ load: true
+
+ - name: Tag image
+ run: docker tag evals-runner:latest evals-runner
+
+ - name: Start containers
+ run: |
+ docker compose up -d db redis
+ timeout 60 bash -c 'until docker compose exec -T db pg_isready -U postgres; do sleep 2; done'
+ timeout 60 bash -c 'until docker compose exec -T redis redis-cli ping | grep -q PONG; do sleep 2; done'
+ docker compose run --rm runner sh -c 'nc -z db 5432 && echo "✓ Runner -> Database connection successful"'
+ docker compose run --rm runner sh -c 'nc -z redis 6379 && echo "✓ Runner -> Redis connection successful"'
+ docker compose run --rm runner docker ps
+
+ - name: Run database migrations
+ run: docker compose run --rm runner pnpm --filter @roo-code/evals db:migrate
+
+ - name: Run evals
+ run: docker compose run --rm runner pnpm --filter @roo-code/evals cli --ci
+
+ - name: Cleanup
+ if: always()
+ run: docker compose down -v --remove-orphans
diff --git a/.github/workflows/marketplace-publish.yml b/.github/workflows/marketplace-publish.yml
index 794e598b80..aef91b2d32 100644
--- a/.github/workflows/marketplace-publish.yml
+++ b/.github/workflows/marketplace-publish.yml
@@ -1,4 +1,5 @@
name: Publish Extension
+
on:
pull_request:
types: [closed]
@@ -10,39 +11,82 @@ env:
jobs:
publish-extension:
runs-on: ubuntu-latest
+ permissions:
+ contents: write # Required for pushing tags.
if: >
( github.event_name == 'pull_request' &&
github.event.pull_request.base.ref == 'main' &&
contains(github.event.pull_request.title, 'Changeset version bump') ) ||
github.event_name == 'workflow_dispatch'
steps:
- - uses: actions/checkout@v4
+ - name: Checkout code
+ uses: actions/checkout@v4
with:
ref: ${{ env.GIT_REF }}
-
- - uses: actions/setup-node@v4
- with:
- node-version: 18
- - run: |
- git config user.name github-actions
- git config user.email github-actions@github.com
- - name: Install Dependencies
+ - name: Setup Node.js and pnpm
+ uses: ./.github/actions/setup-node-pnpm
+ - name: Configure Git
run: |
- npm install -g vsce ovsx
- npm run install:ci
- - name: Package and Publish Extension
+ git config user.name "github-actions[bot]"
+ git config user.email "github-actions[bot]@users.noreply.github.com"
+ - name: Create .env file
+ run: echo "POSTHOG_API_KEY=${{ secrets.POSTHOG_API_KEY }}" >> .env
+ - name: Package Extension
+ run: |
+ current_package_version=$(node -p "require('./src/package.json').version")
+ pnpm vsix
+
+ # Save VSIX contents to a temporary file to avoid broken pipe issues.
+ unzip -l bin/roo-cline-${current_package_version}.vsix > /tmp/roo-code-vsix-contents.txt
+
+ # Check for required files.
+ grep -q "extension/package.json" /tmp/roo-code-vsix-contents.txt || exit 1
+ grep -q "extension/package.nls.json" /tmp/roo-code-vsix-contents.txt || exit 1
+ grep -q "extension/dist/extension.js" /tmp/roo-code-vsix-contents.txt || exit 1
+ grep -q "extension/webview-ui/audio/celebration.wav" /tmp/roo-code-vsix-contents.txt || exit 1
+ grep -q "extension/webview-ui/build/assets/index.js" /tmp/roo-code-vsix-contents.txt || exit 1
+ grep -q "extension/assets/codicons/codicon.ttf" /tmp/roo-code-vsix-contents.txt || exit 1
+ grep -q "extension/assets/vscode-material-icons/icons/3d.svg" /tmp/roo-code-vsix-contents.txt || exit 1
+ grep -q ".env" /tmp/roo-code-vsix-contents.txt || exit 1
+
+ # Clean up temporary file.
+ rm /tmp/roo-code-vsix-contents.txt
+ - name: Create and Push Git Tag
+ run: |
+ current_package_version=$(node -p "require('./src/package.json').version")
+ git tag -a "v${current_package_version}" -m "Release v${current_package_version}"
+ git push origin "v${current_package_version}" --no-verify
+ echo "Successfully created and pushed git tag v${current_package_version}"
+ - name: Publish Extension
env:
VSCE_PAT: ${{ secrets.VSCE_PAT }}
OVSX_PAT: ${{ secrets.OVSX_PAT }}
run: |
- current_package_version=$(node -p "require('./package.json').version")
-
- npm run vsix
- package=$(unzip -l bin/roo-cline-${current_package_version}.vsix)
- echo "$package"
- echo "$package" | grep -q "dist/extension.js" || exit 1
- echo "$package" | grep -q "extension/webview-ui/build/assets/index.js" || exit 1
- echo "$package" | grep -q "extension/node_modules/@vscode/codicons/dist/codicon.ttf" || exit 1
-
- npm run publish:marketplace
+ current_package_version=$(node -p "require('./src/package.json').version")
+ pnpm --filter roo-cline publish:marketplace
echo "Successfully published version $current_package_version to VS Code Marketplace"
+ - name: Create GitHub Release
+ env:
+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+ run: |
+ current_package_version=$(node -p "require('./src/package.json').version")
+
+ # Extract changelog for current version
+ echo "Extracting changelog for version ${current_package_version}"
+ changelog_content=$(sed -n "/## \\[${current_package_version}\\]/,/## \\[/p" CHANGELOG.md | sed '$d')
+
+ # If changelog extraction failed, use a default message
+ if [ -z "$changelog_content" ]; then
+ echo "Warning: No changelog section found for version ${current_package_version}"
+ changelog_content="Release v${current_package_version}"
+ else
+ echo "Found changelog section for version ${current_package_version}"
+ fi
+
+ # Create release with changelog content
+ gh release create "v${current_package_version}" \
+ --title "Release v${current_package_version}" \
+ --notes "$changelog_content" \
+ --target ${{ env.GIT_REF }} \
+ bin/roo-cline-${current_package_version}.vsix
+ echo "Successfully created GitHub Release v${current_package_version}"
diff --git a/.github/workflows/nightly-publish.yml b/.github/workflows/nightly-publish.yml
new file mode 100644
index 0000000000..e25bdba990
--- /dev/null
+++ b/.github/workflows/nightly-publish.yml
@@ -0,0 +1,52 @@
+name: Nightly Publish
+
+on:
+ push:
+ branches: [main]
+ workflow_dispatch: # Allows manual triggering.
+
+jobs:
+ publish-nightly:
+ runs-on: ubuntu-latest
+
+ permissions:
+ contents: read # No tags pushed → read is enough.
+
+ steps:
+ - name: Checkout code
+ uses: actions/checkout@v4
+ with:
+ fetch-depth: 0
+ - name: Setup Node.js and pnpm
+ uses: ./.github/actions/setup-node-pnpm
+ with:
+ install-args: '--frozen-lockfile'
+ - name: Forge numeric Nightly version
+ id: version
+ env:
+ RUN_NUMBER: ${{ github.run_number }}
+ run: echo "number=$(( 5500 + ${RUN_NUMBER} ))" >> $GITHUB_OUTPUT
+ - name: Patch package.json version
+ env:
+ VERSION_NUMBER: ${{ steps.version.outputs.number }}
+ run: |
+ node <<'EOF'
+ const fs = require('fs');
+ const path = require('path');
+ const pkgPath = path.join(__dirname, 'apps', 'vscode-nightly', 'package.nightly.json');
+ const pkg = JSON.parse(fs.readFileSync(pkgPath,'utf8'));
+ const [maj, min] = pkg.version.split('.');
+ pkg.version = `${maj}.${min}.${process.env.VERSION_NUMBER}`;
+ fs.writeFileSync(pkgPath, JSON.stringify(pkg, null, 2));
+ console.log(`🔖 Nightly version set to ${pkg.version}`);
+ EOF
+ - name: Build VSIX
+ run: pnpm vsix:nightly # Produces bin/roo-code-nightly-0.0.[count].vsix
+ - name: Publish to VS Code Marketplace
+ env:
+ VSCE_PAT: ${{ secrets.VSCE_PAT }}
+ run: npx vsce publish --packagePath "bin/$(/bin/ls bin | head -n1)"
+ - name: Publish to Open VSX Registry
+ env:
+ OVSX_PAT: ${{ secrets.OVSX_PAT }}
+ run: npx ovsx publish "bin/$(ls bin | head -n1)"
diff --git a/.github/workflows/update-contributors.yml b/.github/workflows/update-contributors.yml
new file mode 100644
index 0000000000..d04f7b86d8
--- /dev/null
+++ b/.github/workflows/update-contributors.yml
@@ -0,0 +1,46 @@
+name: Update Contributors
+
+on:
+ push:
+ branches:
+ - main
+ workflow_dispatch:
+
+jobs:
+ update-contributors:
+ runs-on: ubuntu-latest
+ permissions:
+ contents: write # Needed for pushing changes.
+ pull-requests: write # Needed for creating PRs.
+ steps:
+ - name: Checkout code
+ uses: actions/checkout@v4
+ - name: Setup Node.js and pnpm
+ uses: ./.github/actions/setup-node-pnpm
+ - name: Disable Husky
+ run: |
+ echo "HUSKY=0" >> $GITHUB_ENV
+ git config --global core.hooksPath /dev/null
+ - name: Update contributors and format
+ run: |
+ pnpm update-contributors
+ npx prettier --write README.md
+ if git diff --quiet; then echo "changes=false" >> $GITHUB_OUTPUT; else echo "changes=true" >> $GITHUB_OUTPUT; fi
+ id: check-changes
+ env:
+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+ - name: Create Pull Request
+ if: steps.check-changes.outputs.changes == 'true'
+ uses: peter-evans/create-pull-request@v7
+ with:
+ token: ${{ secrets.GITHUB_TOKEN }}
+ commit-message: "docs: update contributors list [skip ci]"
+ committer: "github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>"
+ branch: update-contributors
+ delete-branch: true
+ title: "Update contributors list"
+ body: |
+ Automated update of contributors list and related files
+
+ This PR was created automatically by a GitHub Action workflow and includes all changed files.
+ base: main
diff --git a/.github/workflows/website-deploy.yml b/.github/workflows/website-deploy.yml
new file mode 100644
index 0000000000..20eea4288a
--- /dev/null
+++ b/.github/workflows/website-deploy.yml
@@ -0,0 +1,46 @@
+name: Deploy roocode.com
+
+on:
+ push:
+ branches:
+ - main
+ paths:
+ - 'apps/web-roo-code/**'
+ workflow_dispatch:
+
+env:
+ VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
+ VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
+
+jobs:
+ check-secrets:
+ runs-on: ubuntu-latest
+ outputs:
+ has-vercel-token: ${{ steps.check.outputs.has-vercel-token }}
+ steps:
+ - name: Check if VERCEL_TOKEN exists
+ id: check
+ run: |
+ if [ -n "${{ secrets.VERCEL_TOKEN }}" ]; then
+ echo "has-vercel-token=true" >> $GITHUB_OUTPUT
+ else
+ echo "has-vercel-token=false" >> $GITHUB_OUTPUT
+ fi
+
+ deploy:
+ runs-on: ubuntu-latest
+ needs: check-secrets
+ if: ${{ needs.check-secrets.outputs.has-vercel-token == 'true' }}
+ steps:
+ - name: Checkout code
+ uses: actions/checkout@v4
+ - name: Setup Node.js and pnpm
+ uses: ./.github/actions/setup-node-pnpm
+ - name: Install Vercel CLI
+ run: npm install --global vercel@canary
+ - name: Pull Vercel Environment Information
+ run: npx vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
+ - name: Build Project Artifacts
+ run: npx vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
+ - name: Deploy Project Artifacts to Vercel
+ run: npx vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}
diff --git a/.github/workflows/website-preview.yml b/.github/workflows/website-preview.yml
new file mode 100644
index 0000000000..6966005eaf
--- /dev/null
+++ b/.github/workflows/website-preview.yml
@@ -0,0 +1,84 @@
+name: Preview roocode.com
+
+on:
+ push:
+ branches-ignore:
+ - main
+ paths:
+ - "apps/web-roo-code/**"
+ pull_request:
+ paths:
+ - "apps/web-roo-code/**"
+ workflow_dispatch:
+
+env:
+ VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
+ VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
+
+jobs:
+ check-secrets:
+ runs-on: ubuntu-latest
+ outputs:
+ has-vercel-token: ${{ steps.check.outputs.has-vercel-token }}
+ steps:
+ - name: Check if VERCEL_TOKEN exists
+ id: check
+ run: |
+ if [ -n "${{ secrets.VERCEL_TOKEN }}" ]; then
+ echo "has-vercel-token=true" >> $GITHUB_OUTPUT
+ else
+ echo "has-vercel-token=false" >> $GITHUB_OUTPUT
+ fi
+
+ preview:
+ runs-on: ubuntu-latest
+ needs: check-secrets
+ if: ${{ needs.check-secrets.outputs.has-vercel-token == 'true' }}
+ steps:
+ - name: Checkout code
+ uses: actions/checkout@v4
+ - name: Setup Node.js and pnpm
+ uses: ./.github/actions/setup-node-pnpm
+ - name: Install Vercel CLI
+ run: npm install --global vercel@canary
+ - name: Pull Vercel Environment Information
+ run: npx vercel pull --yes --environment=preview --token=${{ secrets.VERCEL_TOKEN }}
+ - name: Build Project Artifacts
+ run: npx vercel build --token=${{ secrets.VERCEL_TOKEN }}
+ - name: Deploy Project Artifacts to Vercel
+ id: deploy
+ run: |
+ DEPLOYMENT_URL=$(npx vercel deploy --prebuilt --token=${{ secrets.VERCEL_TOKEN }})
+ echo "deployment_url=$DEPLOYMENT_URL" >> $GITHUB_OUTPUT
+ echo "Preview deployed to: $DEPLOYMENT_URL"
+
+ - name: Comment PR with preview link
+ if: github.event_name == 'pull_request'
+ uses: actions/github-script@v7
+ with:
+ script: |
+ const deploymentUrl = '${{ steps.deploy.outputs.deployment_url }}';
+ const commentIdentifier = '';
+
+ const { data: comments } = await github.rest.issues.listComments({
+ owner: context.repo.owner,
+ repo: context.repo.repo,
+ issue_number: context.issue.number,
+ });
+
+ const existingComment = comments.find(comment =>
+ comment.body.includes(commentIdentifier)
+ );
+
+ if (existingComment) {
+ return;
+ }
+
+ const comment = commentIdentifier + '\n🚀 **Preview deployed!**\n\nYour changes have been deployed to Vercel:\n\n**Preview URL:** ' + deploymentUrl + '\n\nThis preview will be updated automatically when you push new commits to this PR.';
+
+ await github.rest.issues.createComment({
+ owner: context.repo.owner,
+ repo: context.repo.repo,
+ issue_number: context.issue.number,
+ body: comment
+ });
diff --git a/.gitignore b/.gitignore
index 211d06aa19..6f6bcd99de 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,14 +1,19 @@
+.pnpm-store
dist
out
out-*
node_modules
coverage/
+mock/
.DS_Store
+# IDEs
+.idea
+
# Builds
bin/
-roo-cline-*.vsix
+*.vsix
# Local prompts and rules
/local-prompts
@@ -21,10 +26,22 @@ roo-cline-*.vsix
docs/_site/
# Dotenv
-.env.integration
+.env
+.env.*
+!.env.*.sample
-#Local lint config
-.eslintrc.local.json
-
-#Logging
+# Logging
logs
+*.log
+
+# Vite development
+.vite-port
+
+# Turborepo
+.turbo
+
+# IntelliJ and Qodo plugin folders
+.idea/
+.qodo/
+.vercel
+.roo/mcp.json
diff --git a/.husky/pre-commit b/.husky/pre-commit
index 111a1c0f91..a0e3a53df5 100644
--- a/.husky/pre-commit
+++ b/.husky/pre-commit
@@ -5,4 +5,23 @@ if [ "$branch" = "main" ]; then
exit 1
fi
-npx lint-staged
+# Detect if running on Windows and use pnpm.cmd, otherwise use pnpm.
+if [ "$OS" = "Windows_NT" ]; then
+ pnpm_cmd="pnpm.cmd"
+else
+ if command -v pnpm >/dev/null 2>&1; then
+ pnpm_cmd="pnpm"
+ else
+ pnpm_cmd="npx pnpm"
+ fi
+fi
+
+# Detect if running on Windows and use npx.cmd, otherwise use npx.
+if [ "$OS" = "Windows_NT" ]; then
+ npx_cmd="npx.cmd"
+else
+ npx_cmd="npx"
+fi
+
+$npx_cmd lint-staged
+$pnpm_cmd lint
diff --git a/.husky/pre-push b/.husky/pre-push
index a4fea4a34a..3c206835b7 100644
--- a/.husky/pre-push
+++ b/.husky/pre-push
@@ -5,14 +5,25 @@ if [ "$branch" = "main" ]; then
exit 1
fi
-npm run compile
+# Detect if running on Windows and use pnpm.cmd, otherwise use pnpm.
+if [ "$OS" = "Windows_NT" ]; then
+ pnpm_cmd="pnpm.cmd"
+else
+ if command -v pnpm >/dev/null 2>&1; then
+ pnpm_cmd="pnpm"
+ else
+ pnpm_cmd="npx pnpm"
+ fi
+fi
+
+$pnpm_cmd run check-types
# Check for new changesets.
NEW_CHANGESETS=$(find .changeset -name "*.md" ! -name "README.md" | wc -l | tr -d ' ')
echo "Changeset files: $NEW_CHANGESETS"
-if [ "$NEW_CHANGESETS" == "0" ]; then
+if [ "$NEW_CHANGESETS" = "0" ]; then
echo "-------------------------------------------------------------------------------------"
- echo "Changes detected. Please run 'npm run changeset' to create a changeset if applicable."
+ echo "Changes detected. Please run 'pnpm changeset' to create a changeset if applicable."
echo "-------------------------------------------------------------------------------------"
fi
diff --git a/.npmrc b/.npmrc
deleted file mode 100644
index 5660f81af2..0000000000
--- a/.npmrc
+++ /dev/null
@@ -1 +0,0 @@
-registry=https://registry.npmjs.org/
\ No newline at end of file
diff --git a/.nvmrc b/.nvmrc
index 1a2f5bd204..1d898f1fe5 100644
--- a/.nvmrc
+++ b/.nvmrc
@@ -1 +1 @@
-lts/*
\ No newline at end of file
+v20.19.2
diff --git a/.prettierignore b/.prettierignore
deleted file mode 100644
index 71a9e12197..0000000000
--- a/.prettierignore
+++ /dev/null
@@ -1,5 +0,0 @@
-dist/
-node_modules
-webview-ui/build/
-CHANGELOG.md
-package-lock.json
\ No newline at end of file
diff --git a/.prettierrc.json b/.prettierrc.json
index cd4329335c..520c1bd5f7 100644
--- a/.prettierrc.json
+++ b/.prettierrc.json
@@ -3,5 +3,6 @@
"useTabs": true,
"printWidth": 120,
"semi": false,
- "bracketSameLine": true
+ "bracketSameLine": true,
+ "ignore": ["node_modules", "dist", "build", "out", ".next", ".venv", "pnpm-lock.yaml"]
}
diff --git a/.roo/rules-code/use-safeWriteJson.md b/.roo/rules-code/use-safeWriteJson.md
new file mode 100644
index 0000000000..21e42553da
--- /dev/null
+++ b/.roo/rules-code/use-safeWriteJson.md
@@ -0,0 +1,6 @@
+# JSON File Writing Must Be Atomic
+
+- You MUST use `safeWriteJson(filePath: string, data: any): Promise` from `src/utils/safeWriteJson.ts` instead of `JSON.stringify` with file-write operations
+- `safeWriteJson` will create parent directories if necessary, so do not call `mkdir` prior to `safeWriteJson`
+- `safeWriteJson` prevents data corruption via atomic writes with locking and streams the write to minimize memory footprint
+- Test files are exempt from this rule
diff --git a/.roo/rules-docs-extractor/1_extraction_workflow.xml b/.roo/rules-docs-extractor/1_extraction_workflow.xml
new file mode 100644
index 0000000000..936cba7edd
--- /dev/null
+++ b/.roo/rules-docs-extractor/1_extraction_workflow.xml
@@ -0,0 +1,236 @@
+
+
+ The Docs Extractor mode analyzes features to generate documentation.
+ It extracts technical details, business logic, and user workflows
+ for different audiences.
+
+
+
+
+ Parse Request
+
+ Identify the feature or component in the user's request.
+ Determine if the request is for a review or to generate new documentation.
+ Default to user-friendly docs unless technical output is requested.
+ Note any specific areas to emphasize.
+
+ The initial request determines the workflow path (review vs. generation).
+
+
+
+ Discover Feature
+
+ Find related code with semantic search.
+ Identify entry points and components.
+ Map the high-level architecture.
+
+
+[feature name] implementation main entry point
+
+ ]]>
+
+
+
+
+
+ Code Analysis
+
+
+ Analyze code structure
+
+ - Identify classes, functions, modules
+ - Extract method signatures, parameters
+ - Document return types, data structures
+ - Map inheritance and composition
+
+
+
+ Extract APIs
+
+ - REST endpoints
+ - GraphQL schemas
+ - WebSocket events
+ - RPC interfaces
+
+
+
+ Document configuration
+
+ - Environment variables
+ - Config files and schemas
+ - Feature flags
+ - Runtime parameters
+
+
+
+
+
+
+ Business Logic Extraction
+
+
+ Map workflows
+
+ - User journey
+ - Decision points and branching
+ - State transitions
+ - Roles and permissions
+
+
+
+ Document business rules
+
+ - Validation logic
+ - Formulas and algorithms
+ - Business process implementations
+ - Compliance requirements
+
+
+
+ Identify use cases
+
+ - Primary use cases
+ - Edge cases
+ - Error scenarios
+ - Performance factors
+
+
+
+
+
+
+ Dependency Analysis
+
+
+ Map dependencies
+
+ - Third-party libraries
+ - External services and APIs
+ - Database connections
+ - Message queues
+
+
+
+ Document integration points
+
+ - Incoming webhooks
+ - Outgoing API calls
+ - Event publishers/subscribers
+ - Shared data stores
+
+
+
+ Analyze data flow
+
+ - Data sources and formats
+ - Data transformations
+ - Output formats and destinations
+ - Data retention policies
+
+
+
+
+
+
+ Test Analysis
+
+
+ Assess test coverage
+
+ - Unit test coverage
+ - Integration test scenarios
+ - End-to-end test flows
+ - Performance test results
+
+
+
+ Document error handling
+
+ - Error types and codes
+ - Exception handling
+ - Fallback mechanisms
+ - Recovery procedures
+
+
+
+ Identify quality metrics
+
+ - Code complexity
+ - Performance benchmarks
+ - Security vulnerabilities
+ - Maintainability scores
+
+
+
+
+
+
+ Security Analysis
+
+
+ Document security
+
+ - Auth mechanisms
+ - Access control
+ - Data encryption
+ - Security policies
+
+
+
+ Identify vulnerabilities
+
+ - Known security issues
+ - Attack vectors
+ - Mitigation
+ - Best practices
+
+
+
+ Check compliance
+
+ - Regulatory compliance (GDPR, etc.)
+ - Industry standards
+ - Audit trail requirements
+ - Data privacy
+
+
+
+
+
+
+
+ Workflow branches here: review existing docs or generate new docs.
+
+ Path 1: Review and Recommend
+ Used when a document is provided for review.
+
+ Compare provided docs against codebase analysis.
+ Identify inaccuracies, omissions, and areas for improvement.
+ Categorize issues by severity (Critical, Major, Minor).
+ Formulate a structured recommendation in chat.
+ Do not write files.
+ Final output is only the recommendation.
+
+
+
+ Path 2: Generate Documentation
+ Used when new documentation is requested.
+
+ Select a template from `2_documentation_patterns.xml`.
+ Structure the document with clear sections and examples.
+ Create `DOCS-TEMP-[feature].md` with generated content.
+ Apply tone and examples from `7_user_friendly_examples.xml`.
+
+
+
+
+
+ Code paths analyzed
+ Business logic documented
+ Integration points mapped
+ Security addressed
+ Audience needs met
+ Metadata and links are complete
+
+
\ No newline at end of file
diff --git a/.roo/rules-docs-extractor/2_documentation_patterns.xml b/.roo/rules-docs-extractor/2_documentation_patterns.xml
new file mode 100644
index 0000000000..ef1643d8a4
--- /dev/null
+++ b/.roo/rules-docs-extractor/2_documentation_patterns.xml
@@ -0,0 +1,387 @@
+
+
+ Standard templates for structuring extracted documentation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ---
+ Separate sections.
+
+
+
+
+
+
+
+ Show tool output or UI elements.
+ Use actual file paths and setting names.
+ Include common errors and solutions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Tutorials
+ Use cases
+ Troubleshooting
+ Benefits
+
+
+
+
+
+
+ Code examples
+ API specs
+ Integration patterns
+ Performance
+
+
+
+
+
+
+ Deployment
+ Monitoring
+ Security hardening
+ Backup and recovery
+
+
+
+
+
+
+ Business value
+ Capabilities and limits
+ Competitive advantages
+ Risk assessment
+
+
+
+
+
+
+
+
+
+
+
+ ⚠️ **Deprecated**
+>
+> Deprecated since: [vX.Y.Z] on [date]
+> Removal target: [vA.B.C]
+> Migration: See [migration guide](#migration).
+> Replacement: [new feature/method].
+ ]]>
+
+
+
+ 🔒 **Security Warning**
+>
+> [Description of concern]
+> - **Risk**: [High/Medium/Low]
+> - **Affected**: [versions]
+> - **Mitigation**: [steps]
+> - **References**: [links]
+ ]]>
+
+
+
+ ⚡ **Performance Note**
+>
+> [Description of performance consideration]
+> - **Impact**: [metrics]
+> - **Optimization**: [approach]
+> - **Trade-offs**: [considerations]
+ ]]>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Link Text](#section-anchor)
+ [See Configuration Guide](#configuration)
+
+
+
+ [Link Text](https://external.url)
+ [Official Documentation](https://docs.example.com)
+
+
+
+ 📌 **Related Features**
+> - [Feature A](../feature-a/README.md): [How it relates]
+> - [Feature B](../feature-b/README.md): [How it relates]
+ ]]>
+
+
+
+ 👉 **See Also**
+> - [Related Topic 1](#anchor1)
+> - [Related Topic 2](#anchor2)
+> - [External Resource](https://example.com)
+ ]]>
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-docs-extractor/3_analysis_techniques.xml b/.roo/rules-docs-extractor/3_analysis_techniques.xml
new file mode 100644
index 0000000000..4ab4cb17cc
--- /dev/null
+++ b/.roo/rules-docs-extractor/3_analysis_techniques.xml
@@ -0,0 +1,352 @@
+
+
+ Techniques for analyzing code to extract documentation.
+
+
+
+
+
+ Analyze entry points to understand feature flow.
+
+
+ Find main functions, controllers, or route handlers.
+ Trace execution flow.
+ Map decision branches.
+ Document input validation.
+
+
+
+main function app.listen server.start router controller handler
+
+
+
+
+src/controllers/feature.controller.ts
+
+
+
+
+src
+(app\.(get|post|put|delete)|@(Get|Post|Put|Delete)|router\.(get|post|put|delete))
+
+ ]]>
+
+
+
+
+ Extract API specifications from code.
+
+
+
+
+
+ - HTTP method
+ - Route path
+ - Path/query parameters
+ - Request/response schemas
+ - Status codes
+
+
+
+
+
+ - Schema and input types
+ - Resolvers
+ - Return types
+ - Field arguments
+
+
+
+
+
+
+
+ Map dependencies and integration points.
+
+
+ Import/require statements
+ package.json dependencies
+ External API calls
+ DB connections
+ Message queue integrations
+ Filesystem operations
+
+
+
+src
+^import\s+.*from\s+['"]([^'"]+)['"]|require\s*\(\s*['"]([^'"]+)['"]\s*\)
+
+
+
+
+package.json
+
+
+
+
+src
+(fetch|axios|http\.request|request\(|\.get\(|\.post\()
+
+ ]]>
+
+
+
+
+ Extract data models, schemas, and type definitions.
+
+
+
+
+ - interfaces, types, classes, enums
+
+
+
+
+ - Schema definitions, migration files, ORM models
+
+
+
+
+ - JSON Schema, Joi/Yup/Zod schemas, validation decorators
+
+
+
+
+
+src
+^export\s+(interface|type|class|enum)\s+(\w+)
+
+
+
+
+src/models
+@(Entity|Table|Model)|class\s+\w+\s+extends\s+(Model|BaseEntity)
+
+ ]]>
+
+
+
+
+ Identify and document business rules.
+
+
+ Complex conditionals
+ Calculation functions
+ Validation rules
+ State machines
+ Domain-specific constants and algorithms
+
+
+ Why logic exists (business need)
+ When logic applies (conditions)
+ What logic does (transformation)
+ Edge cases
+ Impact of changes
+
+
+
+
+
+ Document error handling and recovery.
+
+
+ try/catch blocks, error boundaries
+ Custom error classes
+ Error codes and messages
+ Logging, fallbacks, retries, circuit breakers
+
+
+
+src
+try\s*{|catch\s*\(|throw\s+new|class\s+\w*Error\s+extends
+
+
+
+
+src
+ERROR_|_ERROR|ErrorCode|errorCode
+
+ ]]>
+
+
+
+
+ Identify security measures and vulnerabilities.
+
+
+
+
+ - JWT, sessions, OAuth, API keys
+
+
+
+
+ - RBAC, permission checks, ownership validation
+
+
+
+
+ - Encryption, hashing, sensitive data handling
+
+
+
+
+ - Sanitization, SQLi/XSS/CSRF prevention
+
+
+
+
+
+
+
+ Identify performance factors and optimization opportunities.
+
+
+ DB query patterns (N+1)
+ Caching strategies
+ Async usage
+ Batch processing
+ Resource pooling
+ Memory management
+ Algorithm complexity
+
+
+ Time/space complexity
+ DB query counts
+ API response times
+ Memory usage
+ Concurrency handling
+
+
+
+
+
+ Analyze test coverage.
+
+
+
+ __tests__, *.test.ts, *.spec.ts
+ Function coverage
+
+
+ integration/, e2e/
+ Workflow coverage
+
+
+ api-tests/, *.api.test.ts
+ Endpoint coverage
+
+
+
+
+src
+\.(test|spec)\.(ts|js|tsx|jsx)$
+*.test.ts
+
+
+
+
+src
+(describe|it|test)\s*\(\s*['"`]([^'"`]+)['"`]
+
+ ]]>
+
+
+
+
+ Extract configuration options and their impacts.
+
+
+ .env files, config files, CLI args, feature flags
+
+
+ Default values
+ Valid values
+ Behavior impact
+ Config dependencies
+ Security implications
+
+
+
+
+
+
+
+ Map user workflows through the feature.
+
+
+ Identify entry points (UI, API, CLI).
+ Trace user actions.
+ Document decision points.
+ Map data transformations.
+ Identify outcomes.
+
+
+ Flow diagrams, procedures, decision trees, state diagrams.
+
+
+
+
+
+ Document integration with other systems.
+
+
+ Sync API calls, async messaging, events, batch processing, streaming.
+
+
+ Protocols, auth, error handling, data transforms, SLAs.
+
+
+
+
+
+
+
+ package.json, READMEs, migration guides, breaking changes docs.
+
+
+
+.
+"engines":|"peerDependencies":|requires?\s+\w+\s+version|compatible\s+with
+
+ ]]>
+
+
+
+
+ @deprecated, TODO comments, legacy code markers.
+
+
+ Deprecation date, removal timeline, migration path, alternatives.
+
+
+
+
+
+
+
+ Public APIs documented.
+ Examples for complex features.
+ Error scenarios covered.
+ Config options explained.
+ Security addressed.
+
+
+
+
+
+ Cyclomatic complexity, code duplication, test coverage, doc coverage, tech debt.
+
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-docs-extractor/4_tool_usage_guide.xml b/.roo/rules-docs-extractor/4_tool_usage_guide.xml
new file mode 100644
index 0000000000..d746141daa
--- /dev/null
+++ b/.roo/rules-docs-extractor/4_tool_usage_guide.xml
@@ -0,0 +1,380 @@
+
+
+ Guidance on using tools for documentation extraction.
+
+
+
+
+ codebase_search
+ Initial code discovery.
+
+
+ Find feature entry points
+
+authentication login user session JWT token
+
+ ]]>
+
+
+ Find business logic
+
+calculate pricing discount tax invoice billing
+
+ ]]>
+
+
+ Find configuration
+
+config settings environment variables .env process.env
+
+ ]]>
+
+
+
+
+
+ list_code_definition_names
+ Understand code structure.
+
+ Use on core feature directories.
+ Analyze implementation and test directories.
+ Look for naming patterns.
+
+
+src/features/authentication
+
+ ]]>
+
+
+
+ read_file
+ Analyze specific implementations.
+
+ Read main feature files.
+ Follow imports to find dependencies.
+ Read test files for expected behavior.
+ Examine config and type definition files.
+
+
+
+
+ src/controllers/auth.controller.ts
+
+
+ src/services/auth.service.ts
+
+
+ src/models/user.model.ts
+
+
+ src/types/auth.types.ts
+
+
+ src/__tests__/auth.test.ts
+
+
+
+ ]]>
+
+
+
+ search_files
+ Find specific patterns.
+
+
+ Find API endpoints
+
+src
+@(Get|Post|Put|Delete|Patch)\(['"]([^'"]+)['"]|router\.(get|post|put|delete|patch)\(['"]([^'"]+)['"]
+
+ ]]>
+
+
+ Find error handling
+
+src
+throw new \w+Error|catch \(|\.catch\(|try \{
+
+ ]]>
+
+
+ Find config usage
+
+src
+process\.env\.\w+|config\.get\(['"]([^'"]+)['"]|getConfig\(\)
+
+ ]]>
+
+
+
+
+
+
+
+ Create documentation file for new docs.
+ Not used for reviews. Feedback for reviews is provided in chat.
+ DOCS-TEMP-[feature-name].md
+
+ Use descriptive feature name in filename.
+ Include table of contents.
+ Use consistent Markdown formatting.
+ Include syntax-highlighted code examples.
+
+
+DOCS-TEMP-authentication-system.md
+
+# Authentication System Documentation
+
+## Table of Contents
+1. [Overview](#overview)
+2. [Architecture](#architecture)
+...
+
+## Overview
+The authentication system provides secure user authentication using JWT tokens...
+
+...
+
+ ]]>
+
+
+
+ Clarify ambiguous requirements.
+
+ Multiple features have similar names.
+ Documentation depth is unclear.
+ Audience priorities are undefined.
+
+
+
+Which authentication aspects should be the focus?
+
+The complete flow (JWT, sessions, OAuth).
+Only JWT implementation and validation.
+Only OAuth2 integration.
+Password reset and recovery workflows.
+
+
+ ]]>
+
+What level of technical detail is needed?
+
+High-level overview for all audiences.
+Detailed developer implementation.
+API reference with code examples.
+Full coverage for all audiences.
+
+
+ ]]>
+
+
+
+
+
+
+
+ Find all files related to a feature.
+
+
+
+ Start with semantic search.
+
+feature implementation main logic
+
+ ]]>
+
+
+ List directory structure.
+
+src/features
+true
+
+ ]]>
+
+
+ Find related tests.
+
+src
+describe\(['"].*Feature.*['"]|test\(['"].*feature.*['"]
+*.test.ts
+
+ ]]>
+
+
+ Find config files.
+
+.
+feature.*config|settings.*feature
+*.json
+
+ ]]>
+
+
+
+
+
+
+ Follow import chains to map dependencies.
+
+
+ Read main file.
+ Extract all imports.
+ Read each imported file.
+ Recursively analyze imports.
+ Build dependency graph.
+
+
+
+src/feature
+import\s+(?:{[^}]+}|\*\s+as\s+\w+|\w+)\s+from\s+['"]([^'"]+)['"]
+
+
+
+
+src/feature
+require\(['"]([^'"]+)['"]\)
+
+ ]]>
+
+
+
+
+ Extract API documentation from code.
+
+
+ Route definitions, request/response schemas, auth requirements, rate limiting, error responses.
+
+
+
+ Find route files.
+ Extract route definitions.
+ Find controllers.
+ Analyze request validation.
+ Document response formats.
+
+
+
+
+
+
+ Use tests to document expected behavior.
+
+
+ Tests provide usage examples.
+ Test descriptions explain functionality.
+ Tests cover edge cases.
+ Tests document expected outputs.
+
+
+
+__tests__
+(describe|it|test)\(['"]([^'"]+)['"]
+
+
+
+
+__tests__/feature.test.ts
+
+ ]]>
+
+
+
+
+
+
+ .env.example
+ config/*.json
+ src/config/*
+ README.md (configuration section)
+
+
+
+
+
+
+ Custom error classes
+ Error code constants
+ Error message templates
+ HTTP status codes
+
+
+src
+class\s+\w*Error\s+extends|new Error\(|throw new|ERROR_CODE|HTTP_STATUS
+
+ ]]>
+
+
+
+
+ Authentication methods
+ Authorization rules
+ Data encryption
+ Input validation
+ Rate limiting
+
+
+src
+@Authorized|requireAuth|checkPermission|encrypt|decrypt|sanitize|validate|rateLimit
+
+ ]]>
+
+
+
+
+
+ Organize output for navigation.
+
+ - Clear hierarchy, consistent headings, ToC with links, cross-references.
+
+
+
+
+ Include relevant code examples.
+
+ - Use syntax highlighting, show request/response, include error cases.
+
+
+
+
+ Suggest diagrams where helpful.
+
+ - Architecture, sequence, data flow, state machine diagrams.
+
+
+
+
+ Include important metadata.
+
+ - Version compatibility, last updated, status, performance, security.
+
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-docs-extractor/5_complete_extraction_examples.xml b/.roo/rules-docs-extractor/5_complete_extraction_examples.xml
new file mode 100644
index 0000000000..3975b5b262
--- /dev/null
+++ b/.roo/rules-docs-extractor/5_complete_extraction_examples.xml
@@ -0,0 +1,932 @@
+
+
+ Examples of the documentation extraction workflow.
+
+
+
+
+ Extract documentation for a JWT-based authentication system, including login, token refresh, and RBAC.
+
+
+
+
+ Discover feature
+
+authentication JWT login logout token refresh auth middleware
+
+ ]]>
+
+ - Auth controllers, services, middleware, models, and routes.
+
+
+
+
+ Analyze structure
+
+src/auth
+
+ ]]>
+
+ - Identify main classes/functions.
+ - Map auth flow.
+ - Find token generation/validation logic.
+
+
+
+
+ Read core files
+
+
+
+ src/auth/auth.controller.ts
+
+
+ src/auth/auth.service.ts
+
+
+ src/auth/jwt.strategy.ts
+
+
+ src/auth/auth.guard.ts
+
+
+ src/models/user.model.ts
+
+
+
+ ]]>
+
+
+
+ Extract API endpoints
+
+src/auth
+@(Post|Get)\(['"]\/auth\/[^'"]+['"]|router\.(post|get)\(['"]\/auth\/[^'"]+['"]
+
+ ]]>
+
+ - POST /auth/login, POST /auth/logout, POST /auth/refresh, GET /auth/profile, POST /auth/register
+
+
+
+
+ Extract configuration
+
+src
+JWT_SECRET|JWT_EXPIRATION|AUTH_.*|process\.env\.\w*AUTH\w*
+
+ ]]>
+
+
+
+ Analyze security
+
+src/auth
+bcrypt|hash|salt|encrypt|sanitize|validate|@IsEmail|@MinLength
+
+ ]]>
+
+
+
+ Generate docs
+
+DOCS-TEMP-authentication-system.md
+
+# Authentication System Documentation
+
+## Table of Contents
+1. [Overview](#overview)
+2. [Quick Start](#quick-start)
+3. [Architecture](#architecture)
+4. [API Reference](#api-reference)
+5. [Configuration](#configuration)
+6. [Security](#security)
+7. [User Guide](#user-guide)
+8. [Developer Guide](#developer-guide)
+9. [Troubleshooting](#troubleshooting)
+
+---
+
+## Overview
+
+### Purpose
+The authentication system provides secure user authentication using JWT (JSON Web Tokens) with support for:
+- User registration and login
+- Token-based authentication
+- Refresh token rotation
+- Role-based access control (RBAC)
+- Session management
+- Password reset functionality
+
+### Key Features
+- **JWT Authentication**: Stateless authentication using signed tokens
+- **Refresh Tokens**: Long-lived tokens for seamless user experience
+- **Role-Based Access**: Fine-grained permission control
+- **Security**: bcrypt password hashing, rate limiting, CSRF protection
+- **Multi-device Support**: Token management across devices
+
+### Version Information
+- **Current Version**: 2.1.0
+- **Minimum Node.js**: 14.0.0
+- **Dependencies**:
+ - jsonwebtoken: ^9.0.0
+ - bcrypt: ^5.1.0
+ - passport: ^0.6.0
+
+---
+
+## Quick Start
+
+### For Users
+1. Register a new account:
+ ```bash
+ POST /api/auth/register
+ {
+ "email": "user@example.com",
+ "password": "SecurePassword123!",
+ "name": "John Doe"
+ }
+ ```
+
+2. Login to receive tokens:
+ ```bash
+ POST /api/auth/login
+ {
+ "email": "user@example.com",
+ "password": "SecurePassword123!"
+ }
+ ```
+
+3. Use the access token in subsequent requests:
+ ```bash
+ Authorization: Bearer
+ ```
+
+### For Developers
+```typescript
+// Import authentication module
+import { AuthModule } from './auth/auth.module';
+
+// Configure in app module
+@Module({
+ imports: [
+ AuthModule.forRoot({
+ jwtSecret: process.env.JWT_SECRET,
+ jwtExpiration: '15m',
+ refreshExpiration: '7d'
+ })
+ ]
+})
+export class AppModule {}
+```
+
+---
+
+## Architecture
+
+### System Overview
+```
+┌─────────────┐ ┌──────────────┐ ┌─────────────┐
+│ Client │────▶│ Auth Guard │────▶│ Service │
+└─────────────┘ └──────────────┘ └─────────────┘
+ │ │
+ ▼ ▼
+ ┌──────────────┐ ┌─────────────┐
+ │ JWT Strategy │ │ Database │
+ └──────────────┘ └─────────────┘
+```
+
+### Components
+- **AuthController**: Handles HTTP requests for authentication endpoints
+- **AuthService**: Core authentication logic and token management
+- **JwtStrategy**: Passport strategy for JWT validation
+- **AuthGuard**: Route protection middleware
+- **UserService**: User management and database operations
+
+### Token Flow
+1. User provides credentials
+2. System validates credentials against database
+3. Generate access token (short-lived) and refresh token (long-lived)
+4. Client stores tokens securely
+5. Access token used for API requests
+6. Refresh token used to obtain new access token
+
+---
+
+## API Reference
+
+### Authentication Endpoints
+
+#### `POST /api/auth/register`
+Register a new user account.
+
+**Request Body**:
+```json
+{
+ "email": "string (required)",
+ "password": "string (required, min 8 chars)",
+ "name": "string (required)",
+ "role": "string (optional, default: 'user')"
+}
+```
+
+**Response** (201 Created):
+```json
+{
+ "user": {
+ "id": "uuid",
+ "email": "user@example.com",
+ "name": "John Doe",
+ "role": "user",
+ "createdAt": "2024-01-01T00:00:00Z"
+ },
+ "tokens": {
+ "accessToken": "jwt_token",
+ "refreshToken": "refresh_token",
+ "expiresIn": 900
+ }
+}
+```
+
+**Error Responses**:
+- `400 Bad Request`: Invalid input data
+- `409 Conflict`: Email already exists
+
+#### `POST /api/auth/login`
+Authenticate user and receive tokens.
+
+**Request Body**:
+```json
+{
+ "email": "string (required)",
+ "password": "string (required)"
+}
+```
+
+**Response** (200 OK):
+```json
+{
+ "user": {
+ "id": "uuid",
+ "email": "user@example.com",
+ "name": "John Doe",
+ "role": "user"
+ },
+ "tokens": {
+ "accessToken": "jwt_token",
+ "refreshToken": "refresh_token",
+ "expiresIn": 900
+ }
+}
+```
+
+**Error Responses**:
+- `401 Unauthorized`: Invalid credentials
+- `429 Too Many Requests`: Rate limit exceeded
+
+#### `POST /api/auth/refresh`
+Refresh access token using refresh token.
+
+**Request Body**:
+```json
+{
+ "refreshToken": "string (required)"
+}
+```
+
+**Response** (200 OK):
+```json
+{
+ "accessToken": "new_jwt_token",
+ "expiresIn": 900
+}
+```
+
+#### `POST /api/auth/logout`
+Invalidate refresh token.
+
+**Headers**:
+- `Authorization: Bearer `
+
+**Request Body**:
+```json
+{
+ "refreshToken": "string (required)"
+}
+```
+
+**Response** (200 OK):
+```json
+{
+ "message": "Logged out successfully"
+}
+```
+
+---
+
+## Configuration
+
+### Environment Variables
+
+| Variable | Type | Default | Description |
+|----------|------|---------|-------------|
+| `JWT_SECRET` | string | - | Secret key for signing JWT tokens (required) |
+| `JWT_EXPIRATION` | string | '15m' | Access token expiration time |
+| `REFRESH_TOKEN_EXPIRATION` | string | '7d' | Refresh token expiration time |
+| `BCRYPT_ROUNDS` | number | 10 | Number of bcrypt hashing rounds |
+| `AUTH_RATE_LIMIT` | number | 5 | Max login attempts per minute |
+| `ENABLE_2FA` | boolean | false | Enable two-factor authentication |
+
+### Configuration File (auth.config.ts)
+```typescript
+export const authConfig = {
+ jwt: {
+ secret: process.env.JWT_SECRET,
+ signOptions: {
+ expiresIn: process.env.JWT_EXPIRATION || '15m',
+ issuer: 'your-app-name',
+ audience: 'your-app-users'
+ }
+ },
+ bcrypt: {
+ rounds: parseInt(process.env.BCRYPT_ROUNDS || '10')
+ },
+ session: {
+ maxDevices: 5,
+ inactivityTimeout: '30d'
+ }
+};
+```
+
+---
+
+## Security
+
+### Authentication Flow
+1. **Password Storage**: Passwords hashed using bcrypt with configurable rounds
+2. **Token Security**: JWT tokens signed with RS256 algorithm
+3. **Refresh Token Rotation**: New refresh token issued on each refresh
+4. **Rate Limiting**: Prevents brute force attacks on login endpoint
+
+### Security Best Practices
+- Store tokens securely (httpOnly cookies recommended)
+- Implement CSRF protection for cookie-based auth
+- Use HTTPS in production
+- Rotate JWT secrets periodically
+- Implement account lockout after failed attempts
+- Enable 2FA for sensitive accounts
+
+### Common Vulnerabilities Addressed
+- **SQL Injection**: Parameterized queries
+- **XSS**: Input sanitization and validation
+- **CSRF**: Token validation
+- **Brute Force**: Rate limiting and account lockout
+- **Token Hijacking**: Short expiration times and refresh rotation
+
+---
+
+## User Guide
+
+### Registration Process
+1. Navigate to registration page
+2. Enter email, password, and name
+3. Verify email (if enabled)
+4. Login with credentials
+
+### Managing Sessions
+- View active sessions in account settings
+- Revoke sessions from other devices
+- Set session timeout preferences
+
+### Password Management
+- Change password from profile settings
+- Reset forgotten password via email
+- Password requirements:
+ - Minimum 8 characters
+ - At least one uppercase letter
+ - At least one number
+ - At least one special character
+
+---
+
+## Developer Guide
+
+### Protecting Routes
+```typescript
+// Use AuthGuard decorator
+@UseGuards(AuthGuard('jwt'))
+@Get('protected')
+async getProtectedData() {
+ return { data: 'This is protected' };
+}
+
+// Role-based protection
+@UseGuards(AuthGuard('jwt'), RolesGuard)
+@Roles('admin')
+@Get('admin')
+async getAdminData() {
+ return { data: 'Admin only' };
+}
+```
+
+### Custom Authentication Logic
+```typescript
+// Extend AuthService
+export class CustomAuthService extends AuthService {
+ async validateUser(email: string, password: string): Promise {
+ // Add custom validation logic
+ const user = await super.validateUser(email, password);
+
+ // Additional checks
+ if (user.suspended) {
+ throw new UnauthorizedException('Account suspended');
+ }
+
+ return user;
+ }
+}
+```
+
+### Testing Authentication
+```typescript
+describe('AuthController', () => {
+ it('should login user', async () => {
+ const response = await request(app.getHttpServer())
+ .post('/auth/login')
+ .send({
+ email: 'test@example.com',
+ password: 'TestPass123!'
+ })
+ .expect(200);
+
+ expect(response.body).toHaveProperty('tokens.accessToken');
+ });
+});
+```
+
+---
+
+## Troubleshooting
+
+### Common Issues
+
+#### Invalid Token Error
+**Problem**: "JsonWebTokenError: invalid token"
+**Solutions**:
+- Verify token format (Bearer prefix)
+- Check token expiration
+- Ensure JWT_SECRET matches
+
+#### Login Rate Limit
+**Problem**: "429 Too Many Requests"
+**Solutions**:
+- Wait for rate limit window to reset
+- Check AUTH_RATE_LIMIT configuration
+- Implement exponential backoff
+
+#### CORS Issues
+**Problem**: "Access blocked by CORS policy"
+**Solutions**:
+- Configure CORS middleware
+- Add origin to allowed list
+- Check preflight requests
+
+### Debug Mode
+Enable debug logging:
+```bash
+DEBUG=auth:* npm start
+```
+
+### Support
+- GitHub Issues: [github.com/yourapp/issues](https://github.com/yourapp/issues)
+- Documentation: [docs.yourapp.com/auth](https://docs.yourapp.com/auth)
+- Email: support@yourapp.com
+
+---
+
+## Changelog
+
+### v2.1.0 (2024-01-15)
+- Added refresh token rotation
+- Improved rate limiting
+- Fixed security vulnerability in password reset
+
+### v2.0.0 (2023-12-01)
+- Breaking: Changed token format
+- Added 2FA support
+- Improved session management
+
+### Migration Guide (v1.x to v2.x)
+1. Update JWT_SECRET format
+2. Run token migration script
+3. Update client-side token handling
+
+---
+
+## References
+- [JWT.io](https://jwt.io) - JWT Documentation
+- [OWASP Authentication Guide](https://owasp.org/www-project-cheat-sheets/cheatsheets/Authentication_Cheat_Sheet)
+- [Passport.js Documentation](http://www.passportjs.org/docs/)
+
+450
+
+ ]]>
+
+
+
+
+ Use semantic search to find related files.
+ Read multiple files for context.
+ Extract API docs from route definitions.
+ Use tests to understand behavior.
+ Document security measures.
+ Include troubleshooting for common errors.
+
+
+
+
+
+ Extract documentation for database models, relationships, and migrations.
+
+
+
+
+ Find DB files
+
+database schema model entity migration table column relationship
+
+ ]]>
+
+
+
+ Analyze models
+
+src/models
+@(Entity|Table|Model)|class\s+\w+\s+extends\s+(Model|BaseEntity)
+
+ ]]>
+
+
+
+ Extract relationships
+
+src/models
+@(OneToMany|ManyToOne|OneToOne|ManyToMany|BelongsTo|HasMany)
+
+ ]]>
+
+
+
+ Document migrations
+
+migrations
+true
+
+ ]]>
+
+
+
+ Generate schema documentation
+
+
+
+
+
+
+
+ Extract comprehensive API documentation including all endpoints,
+ request/response formats, authentication, and examples.
+
+
+
+
+ Find all API routes
+
+src
+(app|router)\.(get|post|put|patch|delete|all)\s*\(\s*['"`]([^'"`]+)['"`]
+
+ ]]>
+
+
+
+ Extract request validation
+
+src
+@(Body|Query|Param|Headers)\(|joi\.object|yup\.object|zod\.object
+
+ ]]>
+
+
+
+ Find response schemas
+
+src
+@ApiResponse|swagger|openapi|response\.json\(|res\.send\(
+
+ ]]>
+
+
+
+ Document authentication requirements
+
+src
+@(UseGuards|Authorized|Public)|passport\.authenticate|requireAuth
+
+ ]]>
+
+
+
+ Generate OpenAPI/Swagger documentation
+
+ - OpenAPI 3.0 specification
+ - Postman collection
+ - API client examples
+ - cURL commands
+ - SDK usage examples
+
+
+
+
+
+
+
+ Document React/Vue/Angular components including props, events,
+ slots, styling, and usage examples.
+
+
+
+
+ Find component files
+
+src/components
+export\s+(default\s+)?(function|class|const)\s+\w+|@Component
+*.tsx
+
+ ]]>
+
+
+
+ Extract component props/inputs
+
+src/components
+interface\s+\w+Props|type\s+\w+Props|@Input\(\)|props:\s*{
+
+ ]]>
+
+
+
+ Find component usage examples
+
+src
+
+
+ ]]>
+
+
+
+ Document styling and themes
+
+src/components
+styled\.|makeStyles|@apply|className=|style=
+
+ ]]>
+
+
+
+ Extract Storybook stories
+
+src
+export\s+default\s+{.*title:|\.stories\.
+*.stories.tsx
+
+ ]]>
+
+
+
+ Generate component documentation
+
+
+
+
+
+
+
+ Document all configuration options, environment variables,
+ feature flags, and their impacts on system behavior.
+
+
+
+
+ Find configuration files
+
+.
+false
+
+ ]]>
+
+ - .env.example
+ - config/
+ - settings.json
+ - app.config.ts
+
+
+
+
+ Extract environment variables
+
+.
+process\.env\.(\w+)|getenv\(['"](\w+)['"]\)
+
+ ]]>
+
+
+
+ Find feature flags
+
+src
+feature\.|featureFlag|isEnabled\(['"]|flags\.
+
+ ]]>
+
+
+
+ Document configuration impacts
+
+ - How each config affects behavior
+ - Dependencies between configs
+ - Performance implications
+ - Security considerations
+ - Default values and overrides
+
+
+
+
+ Generate configuration guide
+
+
+
+
+
+
+ Review a user-provided documentation section for accuracy against the codebase
+ and provide recommendations for improvement in the chat.
+
+
+
+ User provides documentation for review
+
+ "Here's our current draft for the JWT_SECRET setting. Can you check it for accuracy? 'The `JWT_SECRET` is an optional key for enhancing security.'"
+
+
+
+ Analyze relevant code
+
+JWT_SECRET configuration implementation
+
+ ]]>
+
+ - Code where `JWT_SECRET` is read (e.g., `process.env.JWT_SECRET`)
+ - Logic that fails if the secret is missing
+ - Default values or error handling related to the secret
+
+
+
+ Formulate and provide feedback in chat
+
+
+I have reviewed the documentation section provided for the `JWT_SECRET` setting. Here are my recommendations for improvement:
+
+**Overall Assessment**: The current draft is critically inaccurate and could lead to security vulnerabilities if followed.
+
+**Recommendations for Improvement**:
+
+* **Critical Inaccuracy**:
+ * The documentation states that `JWT_SECRET` is optional. However, the application will fail to start if it is not provided. It is a **required** setting for the application to function securely.
+ * **Suggestion**: "The `JWT_SECRET` is a **required** environment variable used to sign and verify JSON Web Tokens. The application will not run without it."
+
+This feedback can be copied and pasted for your documentation team.
+
+
+ ]]>
+ No file is written. The feedback is provided directly to the user in the chat interface.
+
+
+
+
+
+
+ Ensure all aspects are documented
+
+ Technical implementation details
+ Business logic and rules
+ User workflows and journeys
+ API specifications
+ Configuration options
+ Security measures
+ Performance characteristics
+ Error handling
+ Testing strategies
+ Deployment procedures
+
+
+
+
+ Tailor content for different readers
+
+
+ Focus on how-to guides and troubleshooting
+
+
+ Include code examples and technical details
+
+
+ Emphasize configuration and maintenance
+
+
+ Highlight business value and metrics
+
+
+
+
+
+ Create documentation that's easy to update
+
+ Use clear section headers
+ Include version information
+ Add last-updated timestamps
+ Cross-reference related sections
+ Provide migration guides
+
+
+
+
+ Include practical examples throughout
+
+ Code snippets with syntax highlighting
+ API request/response pairs
+ Configuration examples
+ Command-line usage
+ Error scenarios and solutions
+
+
+
+
+
+
+ Table of contents with working links
+ All sections properly formatted
+ Code examples are syntactically correct
+ No placeholder text remaining
+ Version information included
+ Cross-references are valid
+ Metadata is complete
+ File follows naming convention
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-docs-extractor/6_communication_guidelines.xml b/.roo/rules-docs-extractor/6_communication_guidelines.xml
new file mode 100644
index 0000000000..908b1fcfb6
--- /dev/null
+++ b/.roo/rules-docs-extractor/6_communication_guidelines.xml
@@ -0,0 +1,283 @@
+
+
+ Guidelines for user communication and output formatting.
+
+
+
+
+ Act on the user's request immediately.
+ Only ask for clarification if the request is ambiguous.
+
+
+
+
+ Multiple features with similar names are found.
+ The request is ambiguous.
+ The user explicitly asks for options.
+
+
+
+Found multiple auth systems. Which to document?
+
+JWT-based system (src/auth/jwt/*)
+OAuth2 integration (src/auth/oauth/*)
+Basic auth middleware (src/middleware/basic-auth.ts)
+All of them
+
+
+ ]]>
+
+
+
+
+ Starting a major analysis phase.
+ Extraction is complete.
+ Unexpected complexity is found.
+
+
+
+
+ Analyzing [component]...
+ - Found [X] related files.
+ - Identified [Y] API endpoints.
+ - Found [Z] config options.
+
+
+
+
+
+
+
+ Alert user to security concerns found during analysis.
+
+
+ Note deprecated features needing migration docs.
+
+
+ Highlight code that lacks inline documentation.
+
+
+ Warn about complex dependency chains.
+
+
+
+
+
+
+
+
+
+
+
+ Use # for main title, ## for major sections, ### for subsections.
+ Never skip heading levels.
+
+
+
+ Always specify language for syntax highlighting (e.g., typescript, json, bash).
+ Include file paths as comments where relevant.
+ {
+ // Implementation
+ }
+}
+```
+ ]]>
+
+
+
+ Use tables for structured data like configs.
+ Include headers and align columns.
+ Keep cell content brief.
+
+
+
+
+ Use bullets for unordered lists, numbers for sequential steps.
+ Keep list items parallel in structure.
+
+
+
+
+
+ [Link text](#section-anchor)
+ Use lowercase, hyphenated anchors. Test all links.
+
+
+
+ [Link text](https://example.com)
+ Use HTTPS. Link to official docs.
+
+
+
+ `path/to/file.ts`
+ Use relative paths from project root, in backticks.
+
+
+
+
+
+
+ > ⚠️ **Warning**: [message]
+ Security, breaking changes, deprecations.
+
+
+ > 📝 **Note**: [message]
+ Important info, clarifications.
+
+
+ > 💡 **Tip**: [message]
+ Best practices, optimizations.
+
+
+
+
+
+
+
+
+
+
+
+ Be direct, not conversational.
+ Use active voice.
+ Lead with benefits.
+ Use concrete examples.
+ Keep paragraphs short.
+ Avoid unnecessary technical details.
+
+
+
+
+ Technical and direct.
+ Standard programming terms.
+ Code snippets, implementation details.
+
+
+ Instructional, step-by-step.
+ Simple language, no jargon.
+ Screenshots, real-world scenarios.
+
+
+ Operational focus.
+ IT/DevOps terms.
+ CLI examples, configs.
+
+
+
+
+
+
+ Summary of documented feature.
+ Key findings.
+ File location.
+ Next step suggestions (if applicable).
+
+
+
+
+
+
+
+
+
+
+ Could not find a feature matching "[feature name]". Similar features found:
+ - [List similar features]
+ Document one of these instead?
+
+
+
+
+
+ Code for [feature] has limited inline documentation. Extracting from code structure, tests, and usage patterns.
+
+
+
+
+
+ This feature is complex. Choose documentation scope:
+ - Document comprehensively
+ - Focus on core functionality
+ - Split into multiple documents
+
+
+
+
+
+
+
+ No placeholder content remains.
+ Code examples are correct.
+ Links and cross-references work.
+ Tables are formatted correctly.
+ Version info is included.
+ Filename follows conventions.
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-docs-extractor/7_user_friendly_examples.xml b/.roo/rules-docs-extractor/7_user_friendly_examples.xml
new file mode 100644
index 0000000000..6b94e88de6
--- /dev/null
+++ b/.roo/rules-docs-extractor/7_user_friendly_examples.xml
@@ -0,0 +1,218 @@
+
+
+ Examples for creating user-focused, practical documentation.
+
+
+
+
+ The concurrent file read feature uses parallel processing.
+ Read multiple files at once, reducing interruptions.
+
+
+
+ This improves efficiency.
+ Instead of approving 10 file reads one-by-one, approve them all at once.
+
+
+
+ The feature uses a thread pool with configurable concurrency limits.
+ Roo reads up to 100 files at once (changeable in settings).
+
+
+
+ Users must configure the concurrent file read limit parameter.
+ Adjust how many files Roo reads at once in settings.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The system imposes a hard limit of 100 concurrent operations.
+ Roo handles up to 100 files at once.
+
+
+
+ Error: Maximum concurrency threshold exceeded.
+ Too many files requested. Lower the file limit in settings.
+
+
+
+ Reduces API call overhead through request batching.
+ Get answers faster by reading all needed files at once.
+
+
+
+
+
+ Error: ⚠️
+ Tip: 💡
+ Note: 📝
+ Security: 🔒
+
+
+
+ For emphasis
+ For settings, file paths, or commands
+ For callouts or warnings
+
+
+
+
+
+ Concurrent File Reads Doc
+
+
+
+
+ Does it start with benefits?
+ Are technical terms avoided?
+ Is the tone direct?
+ Are there practical examples?
+ Are sections short and scannable?
+ Does it answer user questions?
+ Is help accessible?
+
+
\ No newline at end of file
diff --git a/.roo/rules-integration-tester/1_workflow.xml b/.roo/rules-integration-tester/1_workflow.xml
new file mode 100644
index 0000000000..b0ebc535e2
--- /dev/null
+++ b/.roo/rules-integration-tester/1_workflow.xml
@@ -0,0 +1,198 @@
+
+
+ Understand Test Requirements
+
+ Use ask_followup_question to determine what type of integration test is needed:
+
+
+ What type of integration test would you like me to create or work on?
+
+ New E2E test for a specific feature or workflow
+ Fix or update an existing integration test
+ Create test utilities or helpers for common patterns
+ Debug failing integration tests
+
+
+
+
+
+
+ Gather Test Specifications
+
+ Based on the test type, gather detailed requirements:
+
+ For New E2E Tests:
+ - What specific user workflow or feature needs testing?
+ - What are the expected inputs and outputs?
+ - What edge cases or error scenarios should be covered?
+ - Are there specific API interactions to validate?
+ - What events should be monitored during the test?
+
+ For Existing Test Issues:
+ - Which test file is failing or needs updates?
+ - What specific error messages or failures are occurring?
+ - What changes in the codebase might have affected the test?
+
+ For Test Utilities:
+ - What common patterns are being repeated across tests?
+ - What helper functions would improve test maintainability?
+
+ Use multiple ask_followup_question calls if needed to gather complete information.
+
+
+
+
+ Explore Existing Test Patterns
+
+ Use codebase_search FIRST to understand existing test patterns and similar functionality:
+
+ For New Tests:
+ - Search for similar test scenarios in apps/vscode-e2e/src/suite/
+ - Find existing test utilities and helpers
+ - Identify patterns for the type of functionality being tested
+
+ For Test Fixes:
+ - Search for the failing test file and related code
+ - Find similar working tests for comparison
+ - Look for recent changes that might have broken the test
+
+ Example searches:
+ - "file creation test mocha" for file operation tests
+ - "task completion waitUntilCompleted" for task monitoring patterns
+ - "api message validation" for API interaction tests
+
+ After codebase_search, use:
+ - read_file on relevant test files to understand structure
+ - list_code_definition_names on test directories
+ - search_files for specific test patterns or utilities
+
+
+
+
+ Analyze Test Environment and Setup
+
+ Examine the test environment configuration:
+
+ 1. Read the test runner configuration:
+ - apps/vscode-e2e/package.json for test scripts
+ - apps/vscode-e2e/src/runTest.ts for test setup
+ - Any test configuration files
+
+ 2. Understand the test workspace setup:
+ - How test workspaces are created
+ - What files are available during tests
+ - How the extension API is accessed
+
+ 3. Review existing test utilities:
+ - Helper functions for common operations
+ - Event listening patterns
+ - Assertion utilities
+ - Cleanup procedures
+
+ Document findings including:
+ - Test environment structure
+ - Available utilities and helpers
+ - Common patterns and best practices
+
+
+
+
+ Design Test Structure
+
+ Plan the test implementation based on gathered information:
+
+ For New Tests:
+ - Define test suite structure with suite/test blocks
+ - Plan setup and teardown procedures
+ - Identify required test data and fixtures
+ - Design event listeners and validation points
+ - Plan for both success and failure scenarios
+
+ For Test Fixes:
+ - Identify the root cause of the failure
+ - Plan the minimal changes needed to fix the issue
+ - Consider if the test needs to be updated due to code changes
+ - Plan for improved error handling or debugging
+
+ Create a detailed test plan including:
+ - Test file structure and organization
+ - Required setup and cleanup
+ - Specific assertions and validations
+ - Error handling and edge cases
+
+
+
+
+ Implement Test Code
+
+ Implement the test following established patterns:
+
+ CRITICAL: Never write a test file with a single write_to_file call.
+ Always implement tests in parts:
+
+ 1. Start with the basic test structure (suite, setup, teardown)
+ 2. Add individual test cases one by one
+ 3. Implement helper functions separately
+ 4. Add event listeners and validation logic incrementally
+
+ Follow these implementation guidelines:
+ - Use suite() and test() blocks following Mocha TDD style
+ - Always use the global api object for extension interactions
+ - Implement proper async/await patterns with waitFor utility
+ - Use waitUntilCompleted and waitUntilAborted helpers for task monitoring
+ - Listen to and validate appropriate events (message, taskCompleted, etc.)
+ - Test both positive flows and error scenarios
+ - Validate message content using proper type assertions
+ - Create reusable test utilities when patterns emerge
+ - Use meaningful test descriptions that explain the scenario
+ - Always clean up tasks with cancelCurrentTask or clearCurrentTask
+ - Ensure tests are independent and can run in any order
+
+
+
+
+ Run and Validate Tests
+
+ Execute the tests to ensure they work correctly:
+
+ ALWAYS use the correct working directory and commands:
+ - Working directory: apps/vscode-e2e
+ - Test command: npm run test:run
+ - For specific tests: TEST_FILE="filename.test" npm run test:run
+ - Example: cd apps/vscode-e2e && TEST_FILE="apply-diff.test" npm run test:run
+
+ Test execution process:
+ 1. Run the specific test file first
+ 2. Check for any failures or errors
+ 3. Analyze test output and logs
+ 4. Debug any issues found
+ 5. Re-run tests after fixes
+
+ If tests fail:
+ - Add console.log statements to track execution flow
+ - Log important events like task IDs, file paths, and AI responses
+ - Check test output carefully for error messages and stack traces
+ - Verify file creation in correct workspace directories
+ - Ensure proper event handling and timeouts
+
+
+
+
+ Document and Complete
+
+ Finalize the test implementation:
+
+ 1. Add comprehensive comments explaining complex test logic
+ 2. Document any new test utilities or patterns created
+ 3. Ensure test descriptions clearly explain what is being tested
+ 4. Verify all cleanup procedures are in place
+ 5. Confirm tests can run independently and in any order
+
+ Provide the user with:
+ - Summary of tests created or fixed
+ - Instructions for running the tests
+ - Any new patterns or utilities that can be reused
+ - Recommendations for future test improvements
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-integration-tester/2_test_patterns.xml b/.roo/rules-integration-tester/2_test_patterns.xml
new file mode 100644
index 0000000000..62bef1631b
--- /dev/null
+++ b/.roo/rules-integration-tester/2_test_patterns.xml
@@ -0,0 +1,303 @@
+
+
+ Standard Mocha TDD structure for integration tests
+
+ Basic Test Suite Structure
+
+ ```typescript
+ import { suite, test, suiteSetup, suiteTeardown } from 'mocha';
+ import * as assert from 'assert';
+ import * as vscode from 'vscode';
+ import { waitFor, waitUntilCompleted, waitUntilAborted } from '../utils/testUtils';
+
+ suite('Feature Name Tests', () => {
+ let testWorkspaceDir: string;
+ let testFiles: { [key: string]: string } = {};
+
+ suiteSetup(async () => {
+ // Setup test workspace and files
+ testWorkspaceDir = vscode.workspace.workspaceFolders![0].uri.fsPath;
+ // Create test files in workspace
+ });
+
+ suiteTeardown(async () => {
+ // Cleanup test files and tasks
+ await api.cancelCurrentTask();
+ });
+
+ test('should perform specific functionality', async () => {
+ // Test implementation
+ });
+ });
+ ```
+
+
+
+
+ Event Listening Pattern
+
+ ```typescript
+ test('should handle task completion events', async () => {
+ const events: any[] = [];
+
+ const messageListener = (message: any) => {
+ events.push({ type: 'message', data: message });
+ };
+
+ const taskCompletedListener = (result: any) => {
+ events.push({ type: 'taskCompleted', data: result });
+ };
+
+ api.onDidReceiveMessage(messageListener);
+ api.onTaskCompleted(taskCompletedListener);
+
+ try {
+ // Perform test actions
+ await api.startTask('test prompt');
+ await waitUntilCompleted();
+
+ // Validate events
+ assert(events.some(e => e.type === 'taskCompleted'));
+ } finally {
+ // Cleanup listeners
+ api.onDidReceiveMessage(() => {});
+ api.onTaskCompleted(() => {});
+ }
+ });
+ ```
+
+
+
+
+ File Creation Test Pattern
+
+ ```typescript
+ test('should create files in workspace', async () => {
+ const fileName = 'test-file.txt';
+ const expectedContent = 'test content';
+
+ await api.startTask(`Create a file named ${fileName} with content: ${expectedContent}`);
+ await waitUntilCompleted();
+
+ // Check multiple possible locations
+ const possiblePaths = [
+ path.join(testWorkspaceDir, fileName),
+ path.join(process.cwd(), fileName),
+ // Add other possible locations
+ ];
+
+ let fileFound = false;
+ let actualContent = '';
+
+ for (const filePath of possiblePaths) {
+ if (fs.existsSync(filePath)) {
+ actualContent = fs.readFileSync(filePath, 'utf8');
+ fileFound = true;
+ break;
+ }
+ }
+
+ assert(fileFound, `File ${fileName} not found in any expected location`);
+ assert.strictEqual(actualContent.trim(), expectedContent);
+ });
+ ```
+
+
+
+
+
+
+ Basic Task Execution
+
+ ```typescript
+ // Start a task and wait for completion
+ await api.startTask('Your prompt here');
+ await waitUntilCompleted();
+ ```
+
+
+
+
+ Task with Auto-Approval Settings
+
+ ```typescript
+ // Enable auto-approval for specific actions
+ await api.updateSettings({
+ alwaysAllowWrite: true,
+ alwaysAllowExecute: true
+ });
+
+ await api.startTask('Create and execute a script');
+ await waitUntilCompleted();
+ ```
+
+
+
+
+ Message Validation
+
+ ```typescript
+ const messages: any[] = [];
+ api.onDidReceiveMessage((message) => {
+ messages.push(message);
+ });
+
+ await api.startTask('test prompt');
+ await waitUntilCompleted();
+
+ // Validate specific message types
+ const toolMessages = messages.filter(m =>
+ m.type === 'say' && m.say === 'api_req_started'
+ );
+ assert(toolMessages.length > 0, 'Expected tool execution messages');
+ ```
+
+
+
+
+
+
+ Task Abortion Handling
+
+ ```typescript
+ test('should handle task abortion', async () => {
+ await api.startTask('long running task');
+
+ // Abort after short delay
+ setTimeout(() => api.abortTask(), 1000);
+
+ await waitUntilAborted();
+
+ // Verify task was properly aborted
+ const status = await api.getTaskStatus();
+ assert.strictEqual(status, 'aborted');
+ });
+ ```
+
+
+
+
+ Error Message Validation
+
+ ```typescript
+ test('should handle invalid input gracefully', async () => {
+ const errorMessages: any[] = [];
+
+ api.onDidReceiveMessage((message) => {
+ if (message.type === 'error' || message.text?.includes('error')) {
+ errorMessages.push(message);
+ }
+ });
+
+ await api.startTask('invalid prompt that should fail');
+ await waitFor(() => errorMessages.length > 0, 5000);
+
+ assert(errorMessages.length > 0, 'Expected error messages');
+ });
+ ```
+
+
+
+
+
+
+ File Location Helper
+
+ ```typescript
+ function findFileInWorkspace(fileName: string, workspaceDir: string): string | null {
+ const possiblePaths = [
+ path.join(workspaceDir, fileName),
+ path.join(process.cwd(), fileName),
+ path.join(os.tmpdir(), fileName),
+ // Add other common locations
+ ];
+
+ for (const filePath of possiblePaths) {
+ if (fs.existsSync(filePath)) {
+ return filePath;
+ }
+ }
+
+ return null;
+ }
+ ```
+
+
+
+
+ Event Collection Helper
+
+ ```typescript
+ class EventCollector {
+ private events: any[] = [];
+
+ constructor(private api: any) {
+ this.setupListeners();
+ }
+
+ private setupListeners() {
+ this.api.onDidReceiveMessage((message: any) => {
+ this.events.push({ type: 'message', timestamp: Date.now(), data: message });
+ });
+
+ this.api.onTaskCompleted((result: any) => {
+ this.events.push({ type: 'taskCompleted', timestamp: Date.now(), data: result });
+ });
+ }
+
+ getEvents(type?: string) {
+ return type ? this.events.filter(e => e.type === type) : this.events;
+ }
+
+ clear() {
+ this.events = [];
+ }
+ }
+ ```
+
+
+
+
+
+
+ Comprehensive Logging
+
+ ```typescript
+ test('should log execution flow for debugging', async () => {
+ console.log('Starting test execution');
+
+ const events: any[] = [];
+ api.onDidReceiveMessage((message) => {
+ console.log('Received message:', JSON.stringify(message, null, 2));
+ events.push(message);
+ });
+
+ console.log('Starting task with prompt');
+ await api.startTask('test prompt');
+
+ console.log('Waiting for task completion');
+ await waitUntilCompleted();
+
+ console.log('Task completed, events received:', events.length);
+ console.log('Final workspace state:', fs.readdirSync(testWorkspaceDir));
+ });
+ ```
+
+
+
+
+ State Validation
+
+ ```typescript
+ function validateTestState(description: string) {
+ console.log(`=== ${description} ===`);
+ console.log('Workspace files:', fs.readdirSync(testWorkspaceDir));
+ console.log('Current working directory:', process.cwd());
+ console.log('Task status:', api.getTaskStatus?.() || 'unknown');
+ console.log('========================');
+ }
+ ```
+
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-integration-tester/3_best_practices.xml b/.roo/rules-integration-tester/3_best_practices.xml
new file mode 100644
index 0000000000..e495ea5f0a
--- /dev/null
+++ b/.roo/rules-integration-tester/3_best_practices.xml
@@ -0,0 +1,104 @@
+
+
+ - Always use suite() and test() blocks following Mocha TDD style
+ - Use descriptive test names that explain the scenario being tested
+ - Implement proper setup and teardown in suiteSetup() and suiteTeardown()
+ - Create test files in the VSCode workspace directory during suiteSetup()
+ - Store file paths in a test-scoped object for easy reference across tests
+ - Ensure tests are independent and can run in any order
+ - Clean up all test files and tasks in suiteTeardown() to avoid test pollution
+
+
+
+ - Always use the global api object for extension interactions
+ - Implement proper async/await patterns with the waitFor utility
+ - Use waitUntilCompleted and waitUntilAborted helpers for task monitoring
+ - Set appropriate auto-approval settings (alwaysAllowWrite, alwaysAllowExecute) for the functionality being tested
+ - Listen to and validate appropriate events (message, taskCompleted, taskAborted, etc.)
+ - Always clean up tasks with cancelCurrentTask or clearCurrentTask after tests
+ - Use meaningful timeouts that account for actual task execution time
+
+
+
+ - Be aware that files may be created in the workspace directory (/tmp/roo-test-workspace-*) rather than expected locations
+ - Always check multiple possible file locations when verifying file creation
+ - Use flexible file location checking that searches workspace directories
+ - Verify files exist after creation to catch setup issues early
+ - Account for the fact that the workspace directory is created by runTest.ts
+ - The AI may use internal tools instead of the documented tools - verify outcomes rather than methods
+
+
+
+ - Add multiple event listeners (taskStarted, taskCompleted, taskAborted) for better debugging
+ - Don't rely on parsing AI messages to detect tool usage - the AI's message format may vary
+ - Use terminal shell execution events (onDidStartTerminalShellExecution, onDidEndTerminalShellExecution) for command tracking
+ - Tool executions are reported via api_req_started messages with type="say" and say="api_req_started"
+ - Focus on testing outcomes (files created, commands executed) rather than message parsing
+ - There is no "tool_result" message type - tool results appear in "completion_result" or "text" messages
+
+
+
+ - Test both positive flows and error scenarios
+ - Validate message content using proper type assertions
+ - Implement proper error handling and edge cases
+ - Use try-catch blocks around critical test operations
+ - Log important events like task IDs, file paths, and AI responses for debugging
+ - Check test output carefully for error messages and stack traces
+
+
+
+ - Remove unnecessary waits for specific tool executions - wait for task completion instead
+ - Simplify message handlers to only capture essential error information
+ - Use the simplest possible test structure that verifies the outcome
+ - Avoid complex message parsing logic that depends on AI behavior
+ - Terminal events are more reliable than message parsing for command execution verification
+ - Keep prompts simple and direct - complex instructions may confuse the AI
+
+
+
+ - Add console.log statements to track test execution flow
+ - Log important events like task IDs, file paths, and AI responses
+ - Use codebase_search first to find similar test patterns before writing new tests
+ - Create helper functions for common file location checks
+ - Use descriptive variable names for file paths and content
+ - Always log the expected vs actual locations when tests fail
+ - Add comprehensive comments explaining complex test logic
+
+
+
+ - Create reusable test utilities when patterns emerge
+ - Implement helper functions for common operations like file finding
+ - Use event collection utilities for consistent event handling
+ - Create assertion helpers for common validation patterns
+ - Document any new test utilities or patterns created
+ - Share common utilities across test files to reduce duplication
+
+
+
+ - Keep prompts simple and direct - complex instructions may lead to unexpected behavior
+ - Allow for variations in how the AI accomplishes tasks
+ - The AI may not always use the exact tool you specify in the prompt
+ - Be prepared to adapt tests based on actual AI behavior rather than expected behavior
+ - The AI may interpret instructions creatively - test results rather than implementation details
+ - The AI will not see the files in the workspace directory, you must tell it to assume they exist and proceed
+
+
+
+ - ALWAYS use the correct working directory: apps/vscode-e2e
+ - The test command is: npm run test:run
+ - To run specific tests use environment variable: TEST_FILE="filename.test" npm run test:run
+ - Example: cd apps/vscode-e2e && TEST_FILE="apply-diff.test" npm run test:run
+ - Never use npm test directly as it doesn't exist
+ - Always check available scripts with npm run if unsure
+ - Run tests incrementally during development to catch issues early
+
+
+
+ - Never write a test file with a single write_to_file tool call
+ - Always implement tests in parts: structure first, then individual test cases
+ - Group related tests in the same suite
+ - Use consistent naming conventions for test files and functions
+ - Separate test utilities into their own files when they become substantial
+ - Follow the existing project structure and conventions
+
+
\ No newline at end of file
diff --git a/.roo/rules-integration-tester/4_common_mistakes.xml b/.roo/rules-integration-tester/4_common_mistakes.xml
new file mode 100644
index 0000000000..88a7473643
--- /dev/null
+++ b/.roo/rules-integration-tester/4_common_mistakes.xml
@@ -0,0 +1,109 @@
+
+
+ - Writing a test file with a single write_to_file tool call instead of implementing in parts
+ - Not using proper Mocha TDD structure with suite() and test() blocks
+ - Forgetting to implement suiteSetup() and suiteTeardown() for proper cleanup
+ - Creating tests that depend on each other or specific execution order
+ - Not cleaning up tasks and files after test completion
+ - Using describe/it blocks instead of the required suite/test blocks
+
+
+
+ - Not using the global api object for extension interactions
+ - Forgetting to set auto-approval settings (alwaysAllowWrite, alwaysAllowExecute) when testing functionality that requires user approval
+ - Not implementing proper async/await patterns with waitFor utilities
+ - Using incorrect timeout values that are too short for actual task execution
+ - Not properly cleaning up tasks with cancelCurrentTask or clearCurrentTask
+ - Assuming the AI will use specific tools instead of testing outcomes
+
+
+
+ - Assuming files will be created in the expected location without checking multiple paths
+ - Not accounting for the workspace directory being created by runTest.ts
+ - Creating test files in temporary directories instead of the VSCode workspace directory
+ - Not verifying files exist after creation during setup
+ - Forgetting that the AI may not see files in the workspace directory
+ - Not using flexible file location checking that searches workspace directories
+
+
+
+ - Relying on parsing AI messages to detect tool usage instead of using proper event listeners
+ - Expecting tool results in "tool_result" message type (which doesn't exist)
+ - Not listening to terminal shell execution events for command tracking
+ - Depending on specific message formats that may vary
+ - Not implementing proper event cleanup after tests
+ - Parsing complex AI conversation messages instead of focusing on outcomes
+
+
+
+ - Using npm test instead of npm run test:run
+ - Not using the correct working directory (apps/vscode-e2e)
+ - Running tests from the wrong directory
+ - Not checking available scripts with npm run when unsure
+ - Forgetting to use TEST_FILE environment variable for specific tests
+ - Not running tests incrementally during development
+
+
+
+ - Not adding sufficient logging to track test execution flow
+ - Not logging important events like task IDs, file paths, and AI responses
+ - Not using codebase_search to find similar test patterns before writing new tests
+ - Not checking test output carefully for error messages and stack traces
+ - Not validating test state at critical points
+ - Assuming test failures are due to code issues without checking test logic
+
+
+
+ - Using complex instructions that may confuse the AI
+ - Expecting the AI to use exact tools specified in prompts
+ - Not allowing for variations in how the AI accomplishes tasks
+ - Testing implementation details instead of outcomes
+ - Not adapting tests based on actual AI behavior
+ - Forgetting to tell the AI to assume files exist in the workspace directory
+
+
+
+ - Adding unnecessary waits for specific tool executions
+ - Using complex message parsing logic that depends on AI behavior
+ - Not using the simplest possible test structure
+ - Depending on specific AI message formats
+ - Not using terminal events for reliable command execution verification
+ - Making tests too brittle by depending on exact AI responses
+
+
+
+ - Not understanding that files may be created in /tmp/roo-test-workspace-* directories
+ - Assuming the AI can see files in the workspace directory
+ - Not checking multiple possible file locations when verifying creation
+ - Creating files outside the VSCode workspace during tests
+ - Not properly setting up the test workspace in suiteSetup()
+ - Forgetting to clean up workspace files in suiteTeardown()
+
+
+
+ - Expecting specific message types for tool execution results
+ - Not understanding that ClineMessage types have specific values
+ - Trying to parse tool execution from AI conversation messages
+ - Not checking packages/types/src/message.ts for valid message types
+ - Depending on message parsing instead of outcome verification
+ - Not using api_req_started messages to verify tool execution
+
+
+
+ - Using timeouts that are too short for actual task execution
+ - Not accounting for AI processing time in test timeouts
+ - Waiting for specific tool executions instead of task completion
+ - Not implementing proper retry logic for flaky operations
+ - Using fixed delays instead of condition-based waiting
+ - Not considering that some operations may take longer in CI environments
+
+
+
+ - Not creating test files in the correct workspace directory
+ - Using hardcoded paths that don't work across different environments
+ - Not storing file paths in test-scoped objects for easy reference
+ - Creating test data that conflicts with other tests
+ - Not cleaning up test data properly after tests complete
+ - Using test data that's too complex for the AI to handle reliably
+
+
\ No newline at end of file
diff --git a/.roo/rules-integration-tester/5_test_environment.xml b/.roo/rules-integration-tester/5_test_environment.xml
new file mode 100644
index 0000000000..8e872b1dfc
--- /dev/null
+++ b/.roo/rules-integration-tester/5_test_environment.xml
@@ -0,0 +1,209 @@
+
+
+ VSCode E2E testing framework using Mocha and VSCode Test
+
+ - Mocha TDD framework for test structure
+ - VSCode Test framework for extension testing
+ - Custom test utilities and helpers
+ - Event-driven testing patterns
+ - Workspace-based test execution
+
+
+
+
+ apps/vscode-e2e/src/suite/
+ apps/vscode-e2e/src/utils/
+ apps/vscode-e2e/src/runTest.ts
+ apps/vscode-e2e/package.json
+ packages/types/
+
+
+
+ apps/vscode-e2e
+
+ npm run test:run
+ TEST_FILE="filename.test" npm run test:run
+ cd apps/vscode-e2e && TEST_FILE="apply-diff.test" npm run test:run
+ npm run
+
+
+ - Never use npm test directly as it doesn't exist
+ - Always use the correct working directory
+ - Use TEST_FILE environment variable for specific tests
+ - Check available scripts with npm run if unsure
+
+
+
+
+ Global api object for extension interactions
+
+
+ - api.startTask(prompt: string): Start a new task
+ - api.cancelCurrentTask(): Cancel the current task
+ - api.clearCurrentTask(): Clear the current task
+ - api.abortTask(): Abort the current task
+ - api.getTaskStatus(): Get current task status
+
+
+ - api.onDidReceiveMessage(callback): Listen to messages
+ - api.onTaskCompleted(callback): Listen to task completion
+ - api.onTaskAborted(callback): Listen to task abortion
+ - api.onTaskStarted(callback): Listen to task start
+ - api.onDidStartTerminalShellExecution(callback): Terminal start events
+ - api.onDidEndTerminalShellExecution(callback): Terminal end events
+
+
+ - api.updateSettings(settings): Update extension settings
+ - api.getSettings(): Get current settings
+
+
+
+
+
+
+
+ Wait for a condition to be true
+ await waitFor(() => condition, timeout)
+ await waitFor(() => fs.existsSync(filePath), 5000)
+
+
+ Wait until current task is completed
+ await waitUntilCompleted()
+ Default timeout for task completion
+
+
+ Wait until current task is aborted
+ await waitUntilAborted()
+ Default timeout for task abortion
+
+
+
+
+
+ Helper to find files in multiple possible locations
+ Use when files might be created in different workspace directories
+
+
+ Utility to collect and analyze events during test execution
+ Use for comprehensive event tracking and validation
+
+
+ Custom assertion functions for common test patterns
+ Use for consistent validation across tests
+
+
+
+
+
+
+ Test workspaces are created by runTest.ts
+ /tmp/roo-test-workspace-*
+ vscode.workspace.workspaceFolders![0].uri.fsPath
+
+
+
+ Create all test files in suiteSetup() before any tests run
+ Always create files in the VSCode workspace directory
+ Verify files exist after creation to catch setup issues early
+ Clean up all test files in suiteTeardown() to avoid test pollution
+ Store file paths in a test-scoped object for easy reference
+
+
+
+ The AI will not see the files in the workspace directory
+ Tell the AI to assume files exist and proceed as if they do
+ Always verify outcomes rather than relying on AI file visibility
+
+
+
+
+ Understanding message types for proper event handling
+ Check packages/types/src/message.ts for valid message types
+
+
+
+ say
+ api_req_started
+ Indicates tool execution started
+ JSON with tool name and execution details
+ Most reliable way to verify tool execution
+
+
+
+ Contains tool execution results
+ Tool results appear here, not in "tool_result" type
+
+
+
+ General AI conversation messages
+ Format may vary, don't rely on parsing these for tool detection
+
+
+
+
+
+ Settings to enable automatic approval of AI actions
+
+ Enable for file creation/modification tests
+ Enable for command execution tests
+ Enable for browser-related tests
+
+
+ ```typescript
+ await api.updateSettings({
+ alwaysAllowWrite: true,
+ alwaysAllowExecute: true
+ });
+ ```
+
+ Without proper auto-approval settings, the AI won't be able to perform actions without user approval
+
+
+
+
+ Use console.log for tracking test execution flow
+
+ - Log test phase transitions
+ - Log important events and data
+ - Log file paths and workspace state
+ - Log expected vs actual outcomes
+
+
+
+
+ Helper functions to validate test state at critical points
+
+ - Workspace file listing
+ - Current working directory
+ - Task status
+ - Event counts
+
+
+
+
+ Tools for analyzing test failures
+
+ - Stack trace analysis
+ - Event timeline reconstruction
+ - File system state comparison
+ - Message flow analysis
+
+
+
+
+
+
+ Appropriate timeout values for different operations
+ Use generous timeouts for task completion (30+ seconds)
+ Shorter timeouts for file system operations (5-10 seconds)
+ Medium timeouts for event waiting (10-15 seconds)
+
+
+
+ Proper cleanup to avoid resource leaks
+ Always clean up event listeners after tests
+ Cancel or clear tasks in teardown
+ Remove test files to avoid disk space issues
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-issue-fixer/1_Workflow.xml b/.roo/rules-issue-fixer/1_Workflow.xml
new file mode 100644
index 0000000000..91682de658
--- /dev/null
+++ b/.roo/rules-issue-fixer/1_Workflow.xml
@@ -0,0 +1,560 @@
+
+
+ Retrieve Issue Context
+
+ The user should provide a full GitHub issue URL (e.g., "https://github.com/owner/repo/issues/123") for implementation.
+
+ Parse the URL to extract:
+ - Owner (organization or username)
+ - Repository name
+ - Issue number
+
+ For example, from https://github.com/RooCodeInc/Roo-Code/issues/123:
+ - Owner: RooCodeInc
+ - Repo: Roo-Code
+ - Issue: 123
+
+ Then retrieve the issue:
+
+
+ gh issue view [issue-number] --repo [owner]/[repo] --json number,title,body,state,labels,assignees,milestone,createdAt,updatedAt,closedAt,author
+
+
+ If the command fails with an authentication error (e.g., "gh: Not authenticated" or "HTTP 401"), ask the user to authenticate:
+
+ GitHub CLI is not authenticated. Please run 'gh auth login' in your terminal to authenticate, then let me know when you're ready to continue.
+
+ I've authenticated, please continue
+ I need help with authentication
+ Let's use a different approach
+
+
+
+ Analyze the issue to determine:
+ 1. All requirements and acceptance criteria
+ 2. Technical details mentioned
+ 3. Any linked issues or discussions
+
+ Note: For PR review feedback, users should use the dedicated pr-fixer mode instead.
+
+
+
+
+ Review Issue Comments and Related Context
+
+ Get all comments on the issue to understand:
+ - Additional context or clarifications
+ - Maintainer feedback
+ - Community suggestions
+ - Any decisions or changes to requirements
+
+
+ gh issue view [issue number] --repo [owner]/[repo] --comments
+
+
+ Also check for:
+ 1. Related issues mentioned in the body or comments
+ 2. Linked pull requests
+ 3. Referenced discussions
+
+ If related PRs are mentioned, view them:
+
+ gh pr view [pr-number] --repo [owner]/[repo]
+
+
+ Document all requirements and constraints found.
+
+
+
+
+ Explore Codebase and Related Files
+
+ Use codebase_search FIRST to understand the codebase structure and find ALL related files:
+
+ For Bug Fixes:
+ - Search for the broken functionality
+ - Find error handling and logging
+ - Locate related test files
+ - Identify dependencies and imports
+ - Find similar patterns in the codebase
+
+ For Features:
+ - Search for similar existing features
+ - Find integration points
+ - Locate configuration files
+ - Identify patterns to follow
+ - Find related components and utilities
+
+ Example searches based on issue type:
+ - Bug: Search for error messages, function names, component names
+ - Feature: Search for similar functionality, API endpoints, UI components
+
+ CRITICAL: Always read multiple related files together to understand:
+ - Current code patterns and conventions
+ - How similar functionality is implemented
+ - Testing patterns used in the project
+ - Import/export patterns
+ - Error handling approaches
+ - Configuration and setup patterns
+
+ Then use other tools:
+ - list_code_definition_names to understand file structure
+ - read_file to examine specific implementations (read multiple files at once)
+ - search_files for specific patterns or error messages
+
+ Also use GitHub CLI to check recent changes:
+
+ gh api repos/[owner]/[repo]/commits?path=[file-path]&per_page=10 --jq '.[].sha + " " + .[].commit.message'
+
+
+ Search for related PRs:
+
+ gh pr list --repo [owner]/[repo] --search "[relevant search terms]" --limit 10
+
+
+ Document:
+ - All files that need modification
+ - Current implementation details and patterns
+ - Code conventions to follow (naming, structure, etc.)
+ - Test file locations and patterns
+ - Related files that might be affected
+
+
+
+
+ Create Implementation Plan
+
+ Based on the issue analysis, create a detailed implementation plan:
+
+ For Bug Fixes:
+ 1. Reproduce the bug locally (if possible)
+ 2. Identify root cause
+ 3. Plan the fix approach. The plan should be focused on resolving the issue with a high-quality, targeted fix, while avoiding unrelated changes.
+ 4. Identify files to modify.
+ 5. Plan test cases to prevent regression.
+
+ For Feature Implementation:
+ 1. Break down the feature into components
+ 2. Identify all files that need changes
+ 3. Plan the implementation approach
+ 4. Consider edge cases and error handling
+ 5. Plan test coverage
+
+ Present the plan to the user:
+
+
+ I've analyzed issue #[number]: "[title]"
+
+ Here's my implementation plan to resolve the issue:
+
+ [Detailed plan with steps and affected files]
+
+ This plan focuses on providing a quality fix for the reported problem without introducing unrelated changes.
+
+ Would you like me to proceed with this implementation?
+
+ Yes, proceed with the implementation
+ Let me review the issue first
+ Modify the approach for: [specific aspect]
+ Focus only on: [specific part]
+
+
+
+
+
+
+ Implement the Solution
+
+ Implement the fix or feature following the plan:
+
+ General Guidelines:
+ 1. Follow existing code patterns and style
+ 2. Add appropriate error handling
+ 3. Include necessary comments
+ 4. Update related documentation
+ 5. Ensure backward compatibility (if applicable)
+
+ For Bug Fixes:
+ 1. Implement the planned fix, focusing on quality and precision.
+ 2. The scope of the fix should be as narrow as possible to address the issue. Avoid making changes to code that is not directly related to the fix. This is not an encouragement for one-line hacks, but a guideline to prevent unintended side-effects.
+ 3. Add regression tests.
+ 4. Verify the fix resolves the issue.
+ 5. Check for side effects.
+
+ For Features:
+ 1. Implement incrementally
+ 2. Test each component as you build
+ 3. Follow the acceptance criteria exactly
+ 4. Add comprehensive tests
+ 5. Update documentation
+
+ Use appropriate tools:
+ - apply_diff for targeted changes
+ - write_to_file for new files
+ - search_and_replace for systematic updates
+
+ After each significant change, run relevant tests:
+ - execute_command to run test suites
+ - Check for linting errors
+ - Verify functionality works as expected
+
+
+
+
+ Verify Acceptance Criteria
+
+ Systematically verify all acceptance criteria from the issue:
+
+ For Bug Fixes:
+ 1. Confirm the bug no longer reproduces
+ 2. Follow the exact reproduction steps
+ 3. Verify expected behavior now occurs
+ 4. Check no new bugs introduced
+ 5. Run all related tests
+
+ For Features:
+ 1. Test each acceptance criterion
+ 2. Verify all Given/When/Then scenarios
+ 3. Test edge cases
+ 4. Verify UI changes (if applicable)
+ 5. Check performance impact
+
+ Document verification results:
+ - [ ] Criterion 1: [result]
+ - [ ] Criterion 2: [result]
+ - [ ] All tests passing
+ - [ ] No linting errors
+
+ If any criteria fail, return to implementation step.
+
+
+
+
+ Check for Translation Requirements
+
+ After implementing changes, analyze if any translations are required:
+
+ Translation is needed if the implementation includes:
+ 1. New user-facing text strings in UI components
+ 2. New error messages or user notifications
+ 3. Updated documentation files that need localization
+ 4. New command descriptions or tooltips
+ 5. Changes to announcement files or release notes
+ 6. New configuration options with user-visible descriptions
+
+ Check for these patterns:
+ - Hard-coded strings in React components (.tsx/.jsx files)
+ - New entries needed in i18n JSON files
+ - Updated markdown documentation files
+ - New VSCode command contributions
+ - Changes to user-facing configuration schemas
+
+ If translations are required:
+
+
+ translate
+ Translation needed for issue #[issue-number] implementation.
+
+ The following changes require translation into all supported languages:
+
+ **Files with new/updated user-facing content:**
+ - [List specific files and what content needs translation]
+ - [Include context about where the strings appear]
+ - [Note any special formatting or constraints]
+
+ **Translation scope:**
+ - [Specify if it's new strings, updated strings, or both]
+ - [List specific JSON keys that need attention]
+ - [Note any markdown files that need localization]
+
+ **Context for translators:**
+ - [Explain the feature/fix being implemented]
+ - [Provide context about how the text is used]
+ - [Note any technical terms or constraints]
+
+ Please ensure all translations maintain consistency with existing terminology and follow the project's localization guidelines.
+
+
+ Wait for the translation task to complete before proceeding to testing.
+
+ If no translations are required, continue to the next step.
+
+
+
+
+ Run Tests and Checks
+
+ Run comprehensive tests to ensure quality:
+
+ 1. Run unit tests for modified files:
+ ```
+ npm test [test file paths]
+ ```
+
+ 2. Run integration tests if applicable:
+ ```
+ npm run test:integration
+ ```
+
+ 3. Check for linting errors:
+ ```
+ npm run lint
+ ```
+
+ 4. Run type checking:
+ ```
+ npm run type-check
+ ```
+
+ 5. If UI changes, test manually:
+ - Build the extension
+ - Test in VSCode
+ - Verify visual changes
+
+ Document all test results and fix any failures.
+
+
+
+
+ Prepare Summary
+
+ Create a comprehensive summary of the implementation:
+
+ ## Summary of Changes
+
+ **Issue:** #[number] - [title]
+ **Type:** [Bug Fix/Feature Implementation]
+
+ ### What was done:
+ - [List key changes]
+ - [Files modified]
+ - [Tests added]
+
+ ### How it addresses the issue:
+ [Explain how each requirement is met]
+
+ ### Testing performed:
+ - [List all tests run]
+ - [Manual testing done]
+ - [Verification of acceptance criteria]
+
+ ### Files changed:
+ - `path/to/file1.ts` - [brief description]
+ - `path/to/file2.ts` - [brief description]
+
+ ### Potential impacts:
+ - [Any breaking changes]
+ - [Performance considerations]
+ - [Compatibility notes]
+
+ Present to user for review:
+
+
+ I've completed the implementation for issue #[number]. Here's what was done:
+
+ [Insert summary]
+
+ All acceptance criteria have been met and tests are passing.
+
+ Would you like me to prepare a pull request, or would you like to review the changes first?
+
+ Create a pull request with these changes
+ Show me the key changes in detail
+ Run additional tests for: [specific area]
+ Make additional changes to: [specific file]
+
+
+
+
+
+
+ Prepare for Pull Request
+
+ If user wants to create a pull request, prepare everything needed:
+
+ 1. Create appropriate branch name:
+ - Bug fix: `fix/issue-[number]-[brief-description]`
+ - Feature: `feat/issue-[number]-[brief-description]`
+
+ 2. Ensure all changes are committed:
+ ```bash
+ git status
+ git add [modified files]
+ git commit -m "fix: [description] (#[issue-number])"
+ ```
+
+ 3. Push to a fork or branch (depending on user's access):
+ ```bash
+ git push origin [branch-name]
+ ```
+
+ 4. Prepare comprehensive PR description:
+ ```markdown
+ ## Description
+
+ Fixes #[issue number]
+
+ [Detailed description of what was changed and why]
+
+ ## Changes Made
+
+ - [Specific change 1 with file references]
+ - [Specific change 2 with technical details]
+ - [Any refactoring or cleanup done]
+
+ ## Testing
+
+ - [x] All existing tests pass
+ - [x] Added tests for [specific functionality]
+ - [x] Manual testing completed:
+ - [Specific manual test 1]
+ - [Specific manual test 2]
+
+ ## Verification of Acceptance Criteria
+
+ [For each criterion from the issue, show it's met]
+ - [x] Criterion 1: [How it's verified]
+ - [x] Criterion 2: [How it's verified]
+
+ ## Checklist
+
+ - [x] Code follows project style guidelines
+ - [x] Self-review completed
+ - [x] Comments added for complex logic
+ - [x] Documentation updated (if needed)
+ - [x] No breaking changes (or documented if any)
+ - [x] Accessibility checked (for UI changes)
+
+ ## Screenshots/Demo (if applicable)
+
+ [Add before/after screenshots for UI changes]
+ [Add terminal output for CLI changes]
+ ```
+
+ 5. Ask user for final approval:
+
+
+ I've prepared everything for the pull request:
+
+ **Branch:** [branch-name]
+ **Title:** [PR title]
+ **Target:** [owner]/[repo] (main branch)
+
+ Here's the PR description:
+
+ [Show prepared PR description]
+
+ Would you like me to create this pull request to [owner]/[repo]?
+
+ Yes, create the pull request
+ Let me review the PR description first
+ Change the PR title to: [let me specify]
+ Add more details about: [specific aspect]
+
+
+
+
+
+
+ Create Pull Request
+
+ Once user approves, create the pull request using GitHub CLI:
+
+ If the user doesn't have push access to [owner]/[repo], fork the repository:
+
+ gh repo fork [owner]/[repo] --clone
+
+
+ Create the pull request:
+
+ gh pr create --repo [owner]/[repo] --base main --title "[Type]: [Brief description] (#[issue-number])" --body "[Complete PR description from step 10]" --maintainer-can-modify
+
+
+ The gh CLI will automatically handle the fork workflow if needed.
+
+ After PR creation:
+ 1. Capture the PR number and URL from the command output
+ 2. Link the PR to the issue by commenting on the issue
+ 3. Inform the user of the successful creation
+
+
+ gh issue comment [original issue number] --repo [owner]/[repo] --body "PR #[new PR number] has been created to address this issue"
+
+
+ Final message to user:
+ ```
+ ✅ Pull Request Created Successfully!
+
+ PR #[number]: [title]
+ URL: [PR URL]
+
+ The PR has been created and linked to issue #[issue number].
+
+ Next steps:
+ 1. The PR will be reviewed by maintainers
+ 2. Address any feedback in the PR comments
+ 3. Once approved, it will be merged
+
+ You can track the PR status at: [PR URL]
+ ```
+
+
+
+
+ Monitor PR Checks
+
+ After the PR is created, monitor the CI/CD checks to ensure they pass:
+
+
+ gh pr checks [PR number] --repo [owner]/[repo] --watch
+
+
+ This command will:
+ 1. Display all CI/CD checks configured for the repository
+ 2. Show the status of each check in real-time
+ 3. Update automatically as checks complete
+ 4. Exit when all checks have finished running
+
+ Monitor the output and note:
+ - Which checks are running (e.g., tests, linting, build)
+ - Any checks that fail and their error messages
+ - The overall status of the PR checks
+
+ If any checks fail:
+ 1. Analyze the failure logs
+ 2. Identify what needs to be fixed
+ 3. Ask the user if they want you to address the failures
+
+
+ The PR checks have completed. Here's the status:
+
+ [Show check results - passing/failing]
+
+ [If all pass]: All checks have passed successfully! The PR is ready for review.
+
+ [If any fail]: Some checks have failed:
+ - [Failed check 1]: [Brief error description]
+ - [Failed check 2]: [Brief error description]
+
+ Would you like me to fix these issues?
+
+ Yes, please fix the failing checks
+ Show me the detailed error logs
+ I'll handle the failures manually
+ The PR is fine as-is, these failures are expected
+
+
+
+ If user wants fixes:
+ 1. Create a plan to address each failure
+ 2. Make necessary code changes
+ 3. Commit and push the fixes
+ 4. Monitor checks again to ensure they pass
+
+ Important notes:
+ - The --watch flag will keep the command running until all checks complete
+ - This step helps ensure the PR meets all quality standards before review
+ - Early detection of CI/CD failures saves reviewer time
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-issue-fixer/2_best_practices.xml b/.roo/rules-issue-fixer/2_best_practices.xml
new file mode 100644
index 0000000000..dede40a92f
--- /dev/null
+++ b/.roo/rules-issue-fixer/2_best_practices.xml
@@ -0,0 +1,18 @@
+
+ - Always read the entire issue and all comments before starting
+ - Follow the project's coding standards and patterns
+ - Focus exclusively on addressing the issue's requirements.
+ - Make minimal, high-quality changes for bug fixes. The goal is a narrow, targeted fix, not a one-line hack.
+ - Test thoroughly - both automated and manual testing
+ - Document complex logic with comments
+ - Keep commits focused and well-described
+ - Reference the issue number in commits
+ - Verify all acceptance criteria are met
+ - Consider performance and security implications
+ - Update documentation when needed
+ - Add tests for any new functionality
+ - Check for accessibility issues (for UI changes)
+ - Delegate translation tasks to translate mode when implementing user-facing changes
+ - Always check for hard-coded strings and internationalization needs
+ - Wait for translation completion before proceeding to final testing
+
\ No newline at end of file
diff --git a/.roo/rules-issue-fixer/3_common_patterns.xml b/.roo/rules-issue-fixer/3_common_patterns.xml
new file mode 100644
index 0000000000..0fdffa8b69
--- /dev/null
+++ b/.roo/rules-issue-fixer/3_common_patterns.xml
@@ -0,0 +1,21 @@
+
+
+ 1. Reproduce the issue
+ 2. Identify root cause
+ 3. Implement minimal fix
+ 4. Add regression test
+ 5. Verify fix works
+ 6. Check for side effects
+
+
+
+ 1. Understand all requirements
+ 2. Design the solution
+ 3. Implement incrementally
+ 4. Test each component
+ 5. Integrate components
+ 6. Verify acceptance criteria
+ 7. Add comprehensive tests
+ 8. Update documentation
+
+
\ No newline at end of file
diff --git a/.roo/rules-issue-fixer/4_github_cli_usage.xml b/.roo/rules-issue-fixer/4_github_cli_usage.xml
new file mode 100644
index 0000000000..e12fb06a5b
--- /dev/null
+++ b/.roo/rules-issue-fixer/4_github_cli_usage.xml
@@ -0,0 +1,221 @@
+
+
+ This mode uses the GitHub CLI (gh) for all GitHub operations.
+ The mode assumes the user has gh installed and authenticated. If authentication errors occur,
+ the mode will prompt the user to authenticate.
+
+ Users must provide full GitHub issue URLs (e.g., https://github.com/owner/repo/issues/123)
+ so the mode can extract the repository information dynamically.
+
+
+
+ https://github.com/[owner]/[repo]/issues/[number]
+
+ - Owner: The organization or username
+ - Repo: The repository name
+ - Number: The issue number
+
+
+
+
+ Assume authenticated, handle errors gracefully
+ Only check authentication if a gh command fails with auth error
+
+ - "gh: Not authenticated"
+ - "HTTP 401"
+ - "HTTP 403: Resource not accessible"
+
+
+
+
+
+ Retrieve the issue details at the start
+ Always use first to get the full issue content
+ gh issue view [issue-number] --repo [owner]/[repo] --json number,title,body,state,labels,assignees,milestone,createdAt,updatedAt,closedAt,author
+
+
+ gh issue view 123 --repo octocat/hello-world --json number,title,body,state,labels,assignees,milestone,createdAt,updatedAt,closedAt,author
+
+
+
+
+
+ Get additional context and requirements from issue comments
+ Always use after viewing issue to see full discussion
+ gh issue view [issue-number] --repo [owner]/[repo] --comments
+
+
+ gh issue view 123 --repo octocat/hello-world --comments
+
+
+
+
+
+
+ Find recent changes to affected files
+ Use during codebase exploration
+ gh api repos/[owner]/[repo]/commits?path=[file-path]&per_page=10
+
+
+ gh api repos/octocat/hello-world/commits?path=src/api/index.ts&per_page=10 --jq '.[].sha + " " + .[].commit.message'
+
+
+
+
+
+ Search for code patterns on GitHub
+ Use to supplement local codebase_search
+ gh search code "[search-query]" --repo [owner]/[repo]
+
+
+ gh search code "function handleError" --repo octocat/hello-world --limit 10
+
+
+
+
+
+
+
+ Add progress updates or ask questions on issues
+ Use if clarification needed or to show progress
+ gh issue comment [issue-number] --repo [owner]/[repo] --body "[comment]"
+
+
+ gh issue comment 123 --repo octocat/hello-world --body "Working on this issue. Found the root cause in the theme detection logic."
+
+
+
+
+
+ Find related or similar PRs
+ Use to understand similar changes
+ gh pr list --repo [owner]/[repo] --search "[search-terms]"
+
+
+ gh pr list --repo octocat/hello-world --search "dark theme" --limit 10
+
+
+
+
+
+ View the diff of a pull request
+ Use to understand changes in a PR
+ gh pr diff [pr-number] --repo [owner]/[repo]
+
+
+ gh pr diff 456 --repo octocat/hello-world
+
+
+
+
+
+
+
+ Create a pull request
+ Use in step 11 after user approval
+
+ - Target the repository from the provided URL
+ - Use "main" as the base branch unless specified otherwise
+ - Include issue number in PR title
+ - Use --maintainer-can-modify flag
+
+ gh pr create --repo [owner]/[repo] --base main --title "[title]" --body "[body]" --maintainer-can-modify
+
+
+ gh pr create --repo octocat/hello-world --base main --title "fix: Resolve dark theme button visibility (#123)" --body "## Description
+
+Fixes #123
+
+[Full PR description]" --maintainer-can-modify
+
+
+
+ If working from a fork, ensure the fork is set as the remote and push the branch there first.
+ The gh CLI will automatically handle the fork workflow.
+
+
+
+
+ Fork the repository if user doesn't have push access
+ Use if user needs to work from a fork
+ gh repo fork [owner]/[repo] --clone
+
+
+ gh repo fork octocat/hello-world --clone
+
+
+
+
+
+ Monitor CI/CD checks on a pull request
+ Use after creating PR to ensure checks pass
+ gh pr checks [pr-number] --repo [owner]/[repo] --watch
+
+
+ gh pr checks 789 --repo octocat/hello-world --watch
+
+
+
+
+
+
+
+ Access GitHub API directly for advanced operations
+ Use when specific gh commands don't provide needed functionality
+
+
+
+ gh api repos/[owner]/[repo] --jq '.default_branch'
+
+
+
+
+ gh api repos/[owner]/[repo]/contents/README.md --jq '.content' | base64 -d
+
+
+
+
+ gh api repos/[owner]/[repo]/actions/runs --jq '.workflow_runs[0:5] | .[] | .id, .status, .conclusion'
+
+
+
+
+
+ Check GitHub Actions workflow status
+ Use to monitor CI/CD pipeline
+ gh run list --repo [owner]/[repo] --limit 5
+
+
+ gh run list --repo octocat/hello-world --limit 5
+
+
+
+
+
+
+
+ gh: Not authenticated. Run 'gh auth login' to authenticate.
+
+ Ask user to authenticate:
+
+ GitHub CLI is not authenticated. Please run 'gh auth login' in your terminal to authenticate, then let me know when you're ready to continue.
+
+ I've authenticated, please continue
+ I need help with authentication
+ Let's use a different approach
+
+
+
+
+
+
+ HTTP 403: Resource not accessible by integration
+
+ Check if working from a fork is needed:
+
+ gh repo fork [owner]/[repo] --clone
+
+
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-issue-fixer/5_pull_request_workflow.xml b/.roo/rules-issue-fixer/5_pull_request_workflow.xml
new file mode 100644
index 0000000000..aaba5dea4b
--- /dev/null
+++ b/.roo/rules-issue-fixer/5_pull_request_workflow.xml
@@ -0,0 +1,52 @@
+
+
+ 1. Ensure all changes are committed with proper message format
+ 2. Push to appropriate branch (fork or direct)
+ 3. Prepare comprehensive PR description
+ 4. Get user approval before creating PR
+ 5. Extract owner and repo from the provided GitHub URL
+
+
+
+ - Bug fixes: "fix: [description] (#[issue-number])"
+ - Features: "feat: [description] (#[issue-number])"
+ - Follow conventional commit format
+
+
+
+ Must include:
+ - Link to issue (Fixes #[number])
+ - Detailed description of changes
+ - Testing performed
+ - Verification of acceptance criteria
+ - Checklist items
+ - Screenshots/demos if applicable
+
+
+
+ Use GitHub CLI to create the pull request:
+
+ gh pr create --repo [owner]/[repo] --base main --title "[title]" --body "[description]" --maintainer-can-modify
+
+
+ If working from a fork, ensure you've forked first:
+
+ gh repo fork [owner]/[repo] --clone
+
+
+ The gh CLI automatically handles fork workflows.
+
+
+
+ 1. Comment on original issue with PR link:
+
+ gh issue comment [issue-number] --repo [owner]/[repo] --body "PR #[pr-number] has been created to address this issue"
+
+ 2. Inform user of successful creation
+ 3. Provide next steps and tracking info
+ 4. Monitor PR checks:
+
+ gh pr checks [pr-number] --repo [owner]/[repo] --watch
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-issue-fixer/6_testing_guidelines.xml b/.roo/rules-issue-fixer/6_testing_guidelines.xml
new file mode 100644
index 0000000000..721a89f2b9
--- /dev/null
+++ b/.roo/rules-issue-fixer/6_testing_guidelines.xml
@@ -0,0 +1,10 @@
+
+ - Always run existing tests before making changes (baseline)
+ - Add tests for any new functionality
+ - Add regression tests for bug fixes
+ - Test edge cases and error conditions
+ - Run the full test suite before completing
+ - For UI changes, test in multiple themes
+ - Verify accessibility (keyboard navigation, screen readers)
+ - Test performance impact for large operations
+
\ No newline at end of file
diff --git a/.roo/rules-issue-fixer/7_communication_style.xml b/.roo/rules-issue-fixer/7_communication_style.xml
new file mode 100644
index 0000000000..a2a2ada082
--- /dev/null
+++ b/.roo/rules-issue-fixer/7_communication_style.xml
@@ -0,0 +1,8 @@
+
+ - Be clear about what you're doing at each step
+ - Explain technical decisions and trade-offs
+ - Ask for clarification if requirements are ambiguous
+ - Provide regular progress updates for complex issues
+ - Summarize changes clearly for non-technical stakeholders
+ - Use issue numbers and links for reference
+
\ No newline at end of file
diff --git a/.roo/rules-issue-fixer/8_github_communication_guidelines.xml b/.roo/rules-issue-fixer/8_github_communication_guidelines.xml
new file mode 100644
index 0000000000..627908f1f7
--- /dev/null
+++ b/.roo/rules-issue-fixer/8_github_communication_guidelines.xml
@@ -0,0 +1,16 @@
+
+
+ - Provide brief status updates when working on complex issues
+ - Ask specific questions if requirements are unclear
+ - Share findings when investigation reveals important context
+ - Keep progress updates factual and concise
+ - Example: "Found the root cause in the theme detection logic. Working on a fix that preserves backward compatibility."
+
+
+
+ - Follow conventional commit format: "type: description (#issue-number)"
+ - Keep first line under 72 characters
+ - Be specific about what changed
+ - Example: "fix: resolve button visibility in dark theme (#123)"
+
+
\ No newline at end of file
diff --git a/.roo/rules-issue-fixer/9_pr_template.xml b/.roo/rules-issue-fixer/9_pr_template.xml
new file mode 100644
index 0000000000..4c35819b1f
--- /dev/null
+++ b/.roo/rules-issue-fixer/9_pr_template.xml
@@ -0,0 +1,205 @@
+
+
+ This file contains the official Roo Code PR template that must be used when creating pull requests.
+ All PRs must follow this exact format to ensure consistency and proper documentation.
+
+
+
+
+ The PR body must follow this exact Roo Code PR template with all required sections.
+ Replace placeholder content in square brackets with actual information.
+
+
+
+### Related GitHub Issue
+
+
+
+Closes: #[ISSUE_NUMBER]
+
+### Roo Code Task Context (Optional)
+
+
+
+[TASK_CONTEXT]
+
+### Description
+
+
+
+[DESCRIPTION_CONTENT]
+
+### Test Procedure
+
+
+
+[TEST_PROCEDURE_CONTENT]
+
+### Pre-Submission Checklist
+
+
+
+- [x] **Issue Linked**: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
+- [x] **Scope**: My changes are focused on the linked issue (one major feature/fix per PR).
+- [x] **Self-Review**: I have performed a thorough self-review of my code.
+- [x] **Testing**: New and/or updated tests have been added to cover my changes (if applicable).
+- [x] **Documentation Impact**: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
+- [x] **Contribution Guidelines**: I have read and agree to the [Contributor Guidelines](/CONTRIBUTING.md).
+
+### Screenshots / Videos
+
+
+
+[SCREENSHOTS_CONTENT]
+
+### Documentation Updates
+
+
+
+[DOCUMENTATION_UPDATES_CONTENT]
+
+### Additional Notes
+
+
+
+[ADDITIONAL_NOTES_CONTENT]
+
+### Get in Touch
+
+
+
+[DISCORD_USERNAME]
+ ]]>
+
+
+
+
+ Valid GitHub CLI commands for creating PRs with the proper template
+
+
+
+ Create a PR using the filled template
+
+ The PR body should be saved to a temporary file first, then referenced with --body-file
+
+
+
+ Alternative: Create PR with inline body (for shorter content)
+
+ Use this only if the body content doesn't contain special characters that need escaping
+
+
+
+ Fork repository if user doesn't have push access
+
+ The --clone=false flag prevents cloning since we're already in the repo
+
+
+
+
+ PR titles should follow conventional commit format
+
+ fix: [brief description] (#[issue-number])
+ feat: [brief description] (#[issue-number])
+ docs: [brief description] (#[issue-number])
+ refactor: [brief description] (#[issue-number])
+ test: [brief description] (#[issue-number])
+ chore: [brief description] (#[issue-number])
+
+
+
+
+ How to fill in the template placeholders
+
+
+ The GitHub issue number being addressed
+ 123
+
+
+ Optional Roo Code task links if used during development
+ https://app.roocode.com/share/task-abc123
+ _No Roo Code task context for this PR_
+
+
+ Detailed explanation of implementation approach
+
+ - Focus on HOW you solved the problem
+ - Mention key design decisions
+ - Highlight any trade-offs made
+ - Point out areas needing special review attention
+
+
+
+ Steps to verify the changes work correctly
+
+ - List specific test commands run
+ - Describe manual testing performed
+ - Include steps for reviewers to reproduce tests
+ - Mention test environment details if relevant
+
+
+
+ Visual evidence of changes for UI modifications
+ _No UI changes in this PR_
+
+
+ Documentation impact assessment
+ - [x] No documentation updates are required.
+
+
+ Any extra context for reviewers
+ _No additional notes_
+
+
+ Discord username for communication
+ @username
+
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-issue-writer/1_workflow.xml b/.roo/rules-issue-writer/1_workflow.xml
new file mode 100644
index 0000000000..fe2bfc2e8b
--- /dev/null
+++ b/.roo/rules-issue-writer/1_workflow.xml
@@ -0,0 +1,338 @@
+
+
+ Determine Issue Type
+
+ Use ask_followup_question to determine if the user wants to create:
+
+
+ What type of issue would you like to create?
+
+ Bug Report - Report a problem with existing functionality
+ Detailed Feature Proposal - Propose a new feature or enhancement
+
+
+
+
+
+
+ Gather Initial Information
+
+ Based on the user's initial prompt or request, extract key information.
+ If the user hasn't provided enough detail, use ask_followup_question to gather
+ the required fields from the appropriate template.
+
+ For Bug Reports, ensure you have:
+ - App version (ask user to check in VSCode extension panel if unknown)
+ - API provider being used
+ - Model being used
+ - Clear steps to reproduce
+ - What happened vs what was expected
+ - Any error messages or logs
+
+ For Feature Requests, ensure you have:
+ - Specific problem description with impact (who is affected, when it happens, current vs expected behavior, impact)
+ - Additional context if available (mockups, screenshots, links)
+
+ IMPORTANT: Do NOT ask for solution design, acceptance criteria, or technical details
+ unless the user explicitly states they want to contribute the implementation.
+
+ Use multiple ask_followup_question calls if needed to gather all information.
+ Be specific in your questions based on what's missing.
+
+
+
+
+ Search GitHub Discussions
+
+ Search GitHub Discussions for related feature requests or bug reports:
+
+ 1. Use the GitHub web interface or API to search discussions in:
+ https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests
+
+ 2. Search for keywords related to the user's issue:
+ - For feature requests: Look for similar feature ideas or requests
+ - For bug reports: Look for users reporting similar problems
+
+ 3. Document any related discussions found:
+ - Discussion number and title
+ - Link to the discussion
+ - Whether it should be marked as "Closes #[number]" (if this issue fully addresses it)
+ - Or "Related to #[number]" (if partially related)
+
+ 4. If multiple related discussions exist, list them all for inclusion in the issue
+
+
+
+
+ Determine if User Wants to Contribute
+
+ Before exploring the codebase, determine if the user wants to contribute the implementation:
+
+
+ Are you interested in implementing this feature yourself, or are you just reporting the problem for the Roo team to solve?
+
+ Just reporting the problem - the Roo team can design the solution
+ I want to contribute and implement this feature myself
+ I'm not sure yet, but I'd like to provide technical analysis
+
+
+
+ Based on their response:
+ - If just reporting: Skip to step 6 (Draft Issue - Problem Only)
+ - If contributing: Continue to step 5 (Explore Codebase)
+ - If providing analysis: Continue to step 5 but make technical sections optional
+
+
+
+
+ Explore Codebase for Contributors
+
+ ONLY perform this step if the user wants to contribute or provide technical analysis.
+
+ Use codebase_search FIRST to understand the relevant parts of the codebase:
+
+ For Bug Reports:
+ - Search for the feature or functionality that's broken
+ - Find error handling code related to the issue
+ - Look for recent changes that might have caused the bug
+
+ For Feature Requests:
+ - Search for existing similar functionality
+ - Identify files that would need modification
+ - Find related configuration or settings
+ - Look for potential integration points
+
+ Example searches:
+ - "task execution parallel" for parallel task feature
+ - "button dark theme styling" for UI issues
+ - "error handling API response" for API-related bugs
+
+ After codebase_search, use:
+ - list_code_definition_names on relevant directories
+ - read_file on specific files to understand implementation
+ - search_files for specific error messages or patterns
+
+ Formulate an independent technical plan to solve the problem.
+
+ Document all relevant findings including:
+ - File paths and line numbers
+ - Current implementation details
+ - Your proposed implementation plan
+ - Related code that might be affected
+
+ Then gather additional technical details:
+ - Ask for proposed solution approach
+ - Request acceptance criteria in Given/When/Then format
+ - Discuss technical considerations and trade-offs
+
+
+
+
+ Draft Issue Content
+
+ Create the issue body based on whether the user is just reporting or contributing.
+
+ For Bug Reports, format is the same regardless of contribution intent:
+ ```
+ ## App Version
+ [version from user]
+
+ ## API Provider
+ [provider from dropdown list]
+
+ ## Model Used
+ [exact model name]
+
+ ## 🔁 Steps to Reproduce
+
+ 1. [First step with specific details]
+ 2. [Second step with exact actions]
+ 3. [Continue numbering all steps]
+
+ Include:
+ - Exact button clicks or menu selections
+ - Specific input text or prompts used
+ - File names and paths involved
+ - Any settings or configuration
+
+ ## 💥 Outcome Summary
+
+ Expected: [what should have happened]
+ Actual: [what actually happened]
+
+ ## 📄 Relevant Logs or Errors
+
+ ```[language]
+ [paste any error messages or logs]
+ ```
+
+ [If user is contributing, add:]
+ ## Technical Analysis
+
+ Based on my investigation:
+ - The issue appears to be in [file:line]
+ - Related code: [brief description with file references]
+ - Possible cause: [technical explanation]
+ - **Proposed Fix:** [Detail the fix from your implementation plan.]
+ ```
+
+ For Feature Requests - PROBLEM REPORTERS (not contributing):
+ ```
+ ## What specific problem does this solve?
+
+ [Detailed problem description following the template guidelines]
+
+ **Who is affected:** [user groups]
+ **When this happens:** [specific scenarios]
+ **Current behavior:** [what happens now]
+ **Expected behavior:** [what should happen]
+ **Impact:** [time wasted, errors, productivity loss]
+
+ ## Additional context
+
+ [Any mockups, screenshots, links, or other supporting information]
+
+ ## Related Discussions
+
+ [If any related discussions were found, list them here]
+ - Closes #[discussion number] - [discussion title]
+ - Related to #[discussion number] - [discussion title]
+ ```
+
+ For Feature Requests - CONTRIBUTORS (implementing the feature):
+ ```
+ ## What specific problem does this solve?
+
+ [Detailed problem description following the template guidelines]
+
+ **Who is affected:** [user groups]
+ **When this happens:** [specific scenarios]
+ **Current behavior:** [what happens now]
+ **Expected behavior:** [what should happen]
+ **Impact:** [time wasted, errors, productivity loss]
+
+ ## Additional context
+
+ [Any mockups, screenshots, links, or other supporting information]
+
+ ---
+
+ ## 🛠️ Contributing & Technical Analysis
+
+ ✅ **I'm interested in implementing this feature**
+ ✅ **I understand this needs approval before implementation begins**
+
+ ## How should this be solved?
+
+ [Based on your analysis, describe the proposed solution]
+
+ **What will change:**
+ - [Specific change 1]
+ - [Specific change 2]
+
+ **User interaction:**
+ - [How users will use this feature]
+ - [What they'll see in the UI]
+
+ ## Acceptance Criteria
+
+ ```
+ Given [context]
+ When [action]
+ Then [result]
+ And [additional expectation]
+ But [what should not happen]
+ ```
+
+ [Add multiple scenarios as needed]
+
+ ## Technical Considerations
+
+ **Implementation approach:**
+ - Key files to modify: [list with paths]
+ - Current architecture: [brief description]
+ - Integration points: [where this fits]
+ - Similar patterns in codebase: [examples]
+
+ **Performance implications:**
+ [Any performance considerations]
+
+ **Compatibility concerns:**
+ [Any compatibility issues]
+
+ ## Trade-offs and Risks
+
+ **Alternatives considered:**
+ - [Alternative 1]: [Why not chosen]
+ - [Alternative 2]: [Why not chosen]
+
+ **Potential risks:**
+ - [Risk 1]: [Mitigation strategy]
+ - [Risk 2]: [Mitigation strategy]
+
+ **Breaking changes:**
+ [Any breaking changes or migration needs]
+
+ ## Related Discussions
+
+ [If any related discussions were found, list them here]
+ - Closes #[discussion number] - [discussion title]
+ - Related to #[discussion number] - [discussion title]
+ ```
+
+
+
+
+ Review and Confirm with User
+
+ Present the complete drafted issue to the user for review:
+
+
+ I've prepared the following GitHub issue. Please review it carefully:
+
+ [Show the complete formatted issue content]
+
+ Would you like me to create this issue, or would you like to make any changes?
+
+ Yes, create this issue in RooCodeInc/Roo-Code
+ Modify the problem description
+ Add more technical details
+ Change the title to: [let me specify]
+
+
+
+ If user requests changes, make them and show the updated version for confirmation.
+
+
+
+
+ Create GitHub Issue
+
+ Once user confirms, create the issue using the GitHub CLI:
+
+ First, save the issue body to a temporary file:
+
+ cat > /tmp/issue_body.md << 'EOF'
+[The complete formatted issue body from step 6]
+EOF
+
+
+ Then create the issue:
+
+ gh issue create --repo RooCodeInc/Roo-Code --title "[Create a descriptive title based on the issue content]" --body-file /tmp/issue_body.md --label "bug"
+
+
+ For feature requests, use labels "proposal,enhancement":
+
+ gh issue create --repo RooCodeInc/Roo-Code --title "[Create a descriptive title based on the issue content]" --body-file /tmp/issue_body.md --label "proposal" --label "enhancement"
+
+
+ The command will return the issue URL. Inform the user of the created issue number and URL.
+
+ Clean up the temporary file:
+
+ rm /tmp/issue_body.md
+
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-issue-writer/2_github_issue_templates.xml b/.roo/rules-issue-writer/2_github_issue_templates.xml
new file mode 100644
index 0000000000..3130f2026e
--- /dev/null
+++ b/.roo/rules-issue-writer/2_github_issue_templates.xml
@@ -0,0 +1,219 @@
+
+
+ Bug Report
+ Clearly report a bug with detailed repro steps
+ ["bug"]
+
+
+
+ What version of Roo Code are you using? (e.g., v3.3.1)
+
+
+
+
+ - Anthropic
+ - AWS Bedrock
+ - Chutes AI
+ - DeepSeek
+ - Glama
+ - Google Gemini
+ - Google Vertex AI
+ - Groq
+ - Human Relay Provider
+ - LiteLLM
+ - LM Studio
+ - Mistral AI
+ - Ollama
+ - OpenAI
+ - OpenAI Compatible
+ - OpenRouter
+ - Requesty
+ - Unbound
+ - VS Code Language Model API
+ - xAI (Grok)
+ - Not Applicable / Other
+
+
+
+
+ Exact model name (e.g., Claude 3.7 Sonnet). Use N/A if irrelevant.
+
+
+
+
+ Help us see what you saw. Give clear, numbered steps:
+
+ 1. Setup (OS, extension version, settings)
+ 2. Exact actions (clicks, input, files, commands)
+ 3. What happened after each step
+
+ Think like you're writing a recipe. Without this, we can't reproduce the issue.
+
+
+
+
+
+ Recap what went wrong in one or two lines.
+
+ Example: "Expected code to run, but got an empty response and no error."
+
+ Expected ___, but got ___.
+
+
+
+ Paste API logs, terminal output, or errors here. Use triple backticks (```) for code formatting.
+ shell
+
+
+
+
+
+ Detailed Feature Proposal
+ Report a specific problem that needs solving in Roo Code
+ ["proposal", "enhancement"]
+
+
+
+
+ **Be concrete and detailed.** Explain the problem from a user's perspective.
+
+ ✅ **Good examples (specific, clear impact):**
+ - "When running large tasks, users wait 5+ minutes because tasks execute sequentially instead of in parallel, blocking productivity"
+ - "AI can only read one file per request, forcing users to make multiple requests for multi-file projects, increasing wait time from 30s to 5+ minutes"
+ - "Dark theme users can't see the submit button because it uses white text on light grey background"
+
+ ❌ **Poor examples (vague, unclear impact):**
+ - "The UI looks weird" -> What specifically looks weird? On which screen? What's the impact?
+ - "System prompt is not good" -> What's wrong with it? What behaviour does it cause? What should it do instead?
+ - "Performance could be better" -> Where? How slow is it currently? What's the user impact?
+
+ **Your problem description should answer:**
+ - Who is affected? (all users, specific user types, etc.)
+ - When does this happen? (specific scenarios/steps)
+ - What's the current behaviour vs expected behaviour?
+ - What's the impact? (time wasted, errors caused, etc.)
+
+ Be specific about the problem, who it affects, and the impact. Avoid generic statements like "it's slow" or "it's confusing."
+
+
+
+ Mockups, screenshots, links, user quotes, or other relevant information that supports your proposal.
+
+
+
+
+
+
+
+ **Important:** If you check "Yes" below, the technical sections become REQUIRED.
+ We need detailed technical analysis from contributors to ensure quality implementation.
+
+
+
+
+
+
+
+
+
+
+ **If you want to implement this feature, this section is REQUIRED.**
+
+ **Describe your solution in detail.** Explain not just what to build, but how it should work.
+
+ ✅ **Good examples:**
+ - "Add parallel task execution: Allow up to 3 tasks to run simultaneously with a queue system for additional tasks. Show progress for each active task in the UI."
+ - "Enable multi-file AI processing: Modify the request handler to accept multiple files in a single request and process them together, reducing round trips."
+ - "Fix button contrast: Change submit button to use primary colour on dark theme (white text on blue background) instead of current grey."
+
+ ❌ **Poor examples:**
+ - "Make it faster" -> How? What specific changes?
+ - "Improve the UI" -> Which part? What specific improvements?
+ - "Fix the prompt" -> What should the new prompt do differently?
+
+ **Your solution should explain:**
+ - What exactly will change?
+ - How will users interact with it?
+ - What will the new behaviour look like?
+
+ Describe the specific changes and how they will work. Include user interaction details if relevant.
+
+
+
+
+ **If you want to implement this feature, this section is REQUIRED.**
+
+ **This is crucial - don't skip it.** Define what "working" looks like with specific, testable criteria.
+
+ **Format suggestion:**
+ ```
+ Given [context/situation]
+ When [user action]
+ Then [expected result]
+ And [additional expectations]
+ But [what should NOT happen]
+ ```
+
+ **Example:**
+ ```
+ Given I have 5 large tasks to run
+ When I start all of them
+ Then they execute in parallel (max 3 at once, can be configured)
+ And I see progress for each active task
+ And queued tasks show "waiting" status
+ But the UI doesn't freeze or become unresponsive
+ ```
+
+
+ Define specific, testable criteria. What should users be able to do? What should happen? What should NOT happen?
+ Use the Given/When/Then format above or your own clear structure.
+
+
+
+
+
+ **If you want to implement this feature, this section is REQUIRED.**
+
+ Share technical insights that could help planning:
+ - Implementation approach or architecture changes
+ - Performance implications
+ - Compatibility concerns
+ - Systems that might be affected
+ - Potential blockers you can foresee
+
+ e.g., "Will need to refactor task manager", "Could impact memory usage on large files", "Requires a large portion of code to be rewritten"
+
+
+
+
+ **If you want to implement this feature, this section is REQUIRED.**
+
+ What could go wrong or what alternatives did you consider?
+ - Alternative approaches and why you chose this one
+ - Potential negative impacts (performance, UX, etc.)
+ - Breaking changes or migration concerns
+ - Edge cases that need careful handling
+
+ e.g., "Alternative: use library X but it is 500KB larger", "Risk: might slow older devices", "Breaking: changes API response format"
+
+
+
+
+
+
+ Template now focuses on problem reporting first, with solution contribution as optional
+
+
+ Only problem description and context are required for basic submission
+
+
+ Technical fields (solution, acceptance criteria, etc.) are only required if user wants to contribute
+
+
+ Users can submit after describing the problem without technical details
+
+
+ Implementation guidance moved to contributor section only
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-issue-writer/3_best_practices.xml b/.roo/rules-issue-writer/3_best_practices.xml
new file mode 100644
index 0000000000..6d70cba144
--- /dev/null
+++ b/.roo/rules-issue-writer/3_best_practices.xml
@@ -0,0 +1,38 @@
+
+
+ - Focus on helping users describe problems clearly, not solutions
+ - The Roo team will design solutions unless the user explicitly wants to contribute
+ - Don't push users to provide technical details they may not have
+ - Make it easy for non-technical users to report issues effectively
+
+
+
+ - Always search for existing similar issues before creating a new one
+ - Search GitHub Discussions (especially feature-requests category) for related topics
+ - Include specific version numbers and environment details
+ - Use code blocks with syntax highlighting for code snippets
+ - Make titles descriptive but concise (e.g., "Dark theme: Submit button invisible due to white-on-grey text")
+ - For bugs, always test if the issue is reproducible
+ - Include screenshots or mockups when relevant (ask user to provide)
+ - Link to related issues or PRs if found during exploration
+ - Add "Closes #[number]" for discussions that would be fully addressed by the issue
+ - Add "Related to #[number]" for partially related discussions
+
+
+
+ - Only explore codebase if user wants to contribute
+ - Reference specific files and line numbers from codebase exploration
+ - Ensure technical proposals align with project architecture
+ - Include implementation steps and technical analysis
+ - Provide clear acceptance criteria in Given/When/Then format
+ - Consider trade-offs and alternative approaches
+
+
+
+ - Be supportive and encouraging to problem reporters
+ - Don't overwhelm users with technical questions upfront
+ - Clearly indicate when technical sections are optional
+ - Guide contributors through the additional requirements
+ - Make the "submit now" option clear for problem reporters
+
+
\ No newline at end of file
diff --git a/.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml b/.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml
new file mode 100644
index 0000000000..2013bd73d8
--- /dev/null
+++ b/.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml
@@ -0,0 +1,30 @@
+
+
+ - Vague descriptions like "doesn't work" or "broken"
+ - Missing reproduction steps for bugs
+ - Feature requests without clear problem statements
+ - Not explaining the impact on users
+ - Forgetting to specify when/how the problem occurs
+ - Using wrong labels or no labels
+ - Titles that don't summarize the issue
+ - Not checking for duplicates
+
+
+
+ - Asking for technical details from non-contributing users
+ - Exploring codebase before confirming user wants to contribute
+ - Requiring acceptance criteria from problem reporters
+ - Making the process too complex for simple problem reports
+ - Not clearly indicating the "submit now" option
+ - Overwhelming users with contributor requirements upfront
+
+
+
+ - Starting implementation before approval
+ - Not providing detailed technical analysis when contributing
+ - Missing acceptance criteria for contributed features
+ - Forgetting to include technical context from code exploration
+ - Not considering trade-offs and alternatives
+ - Proposing solutions without understanding current architecture
+
+
\ No newline at end of file
diff --git a/.roo/rules-issue-writer/5_github_cli_usage.xml b/.roo/rules-issue-writer/5_github_cli_usage.xml
new file mode 100644
index 0000000000..8beb024d15
--- /dev/null
+++ b/.roo/rules-issue-writer/5_github_cli_usage.xml
@@ -0,0 +1,273 @@
+
+
+ The GitHub CLI (gh) provides comprehensive tools for interacting with GitHub.
+ Here's when and how to use each command in the issue creation workflow.
+
+ Note: Issue body formatting should follow the templates defined in
+ 2_github_issue_templates.xml, with different formats for problem reporters
+ vs contributors.
+
+
+
+
+
+ ALWAYS use this FIRST before creating any issue to check for duplicates.
+ Search for keywords from the user's problem description.
+
+
+
+ gh issue list --repo RooCodeInc/Roo-Code --search "dark theme button visibility" --state all --limit 20
+
+
+
+ --search: Search query for issue titles and bodies
+ --state: all, open, or closed
+ --label: Filter by specific labels
+ --limit: Number of results to show
+ --json: Get structured JSON output
+
+
+
+
+
+ Use for more advanced searches across issues and pull requests.
+ Supports GitHub's advanced search syntax.
+
+
+
+ gh search issues --repo RooCodeInc/Roo-Code "dark theme button" --limit 10
+
+
+
+
+
+
+ Use when you find a potentially related issue and need full details.
+ Check if the user's issue is already reported or related.
+
+
+
+ gh issue view 123 --repo RooCodeInc/Roo-Code --comments
+
+
+
+ --comments: Include issue comments
+ --json: Get structured data
+ --web: Open in browser
+
+
+
+
+
+
+ These commands should ONLY be used if the user has indicated they want to
+ contribute the implementation. Skip these for problem reporters.
+
+
+
+
+ Get repository information and recent activity.
+
+
+
+ gh repo view RooCodeInc/Roo-Code --json defaultBranchRef,description,updatedAt
+
+
+
+
+
+
+ Check recent PRs that might be related to the issue.
+ Look for PRs that modified relevant code.
+
+
+
+ gh search prs --repo RooCodeInc/Roo-Code "dark theme" --limit 10 --state all
+
+
+
+
+
+
+ For bug reports from contributors, check recent commits that might have introduced the issue.
+ Use after cloning the repository locally.
+
+
+
+ git log --oneline --grep="theme" -n 20
+
+
+
+
+
+
+
+
+ Only use after:
+ 1. Confirming no duplicates exist
+ 2. Gathering all required information
+ 3. Determining if user is contributing or just reporting
+ 4. Getting user confirmation
+
+
+
+ gh issue create --repo RooCodeInc/Roo-Code --title "[Descriptive title of the bug]" --body-file /tmp/issue_body.md --label "bug"
+
+
+
+
+ gh issue create --repo RooCodeInc/Roo-Code --title "[Problem-focused title]" --body-file /tmp/issue_body.md --label "proposal" --label "enhancement"
+
+
+
+ --title: Issue title (required)
+ --body: Issue body text
+ --body-file: Read body from file
+ --label: Add labels (can use multiple times)
+ --assignee: Assign to user
+ --project: Add to project
+ --web: Open in browser to create
+
+
+
+
+
+
+
+ ONLY use if user wants to add additional information after creation.
+
+
+
+ gh issue comment 456 --repo RooCodeInc/Roo-Code --body "Additional context or comments."
+
+
+
+
+
+
+ Use if user realizes they need to update the issue after creation.
+ Can update title, body, or labels.
+
+
+
+ gh issue edit 456 --repo RooCodeInc/Roo-Code --title "[Updated title]" --body "[Updated body]"
+
+
+
+
+
+
+
+ After user selects issue type, immediately search for related issues:
+ 1. Use `gh issue list --search` with keywords from their description
+ 2. Show any similar issues found
+ 3. Ask if they want to continue or comment on existing issue
+
+
+
+ When searching GitHub Discussions:
+ 1. Note that GitHub CLI doesn't currently have full discussions support
+ 2. Use web search or instruct user to manually search discussions at:
+ https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests
+ 3. Ask user to provide any related discussion numbers they find
+ 4. Include these in the "Related Discussions" section of the issue
+
+
+
+ Decision point for contribution:
+ 1. Ask user if they want to contribute implementation
+ 2. If yes: Use contributor commands for codebase investigation
+ 3. If no: Skip directly to creating a problem-focused issue
+ 4. This saves time for problem reporters
+
+
+
+ During codebase exploration (CONTRIBUTORS ONLY):
+ 1. Clone repo locally if needed: `gh repo clone RooCodeInc/Roo-Code`
+ 2. Use `git log` to find recent changes to affected files
+ 3. Use `gh search prs` for related pull requests
+ 4. Include findings in the technical context section
+
+
+
+ When creating the issue:
+ 1. Format differently based on contributor vs problem reporter
+ 2. Problem reporters: Simple problem description + context
+ 3. Contributors: Full template with technical sections
+ 4. Save formatted body to temporary file
+ 5. Use `gh issue create` with appropriate labels
+ 6. Capture the returned issue URL
+ 7. Show user the created issue URL
+
+
+
+
+
+ When creating issues with long bodies:
+ 1. Save to temporary file: `cat > /tmp/issue_body.md << 'EOF'`
+ 2. Use --body-file flag with gh issue create
+ 3. Clean up after: `rm /tmp/issue_body.md`
+
+
+
+ Use specific search terms:
+ - Include error messages in quotes
+ - Use label filters when appropriate
+ - Limit results to avoid overwhelming output
+
+
+
+ Use --json flag for structured data when needed:
+ - Easier to parse programmatically
+ - Consistent format across commands
+ - Example: `gh issue list --json number,title,state`
+
+
+
+
+
+ If search finds exact duplicate:
+ - Show the existing issue to user using `gh issue view`
+ - Ask if they want to add a comment instead
+ - Use `gh issue comment` if they agree
+
+
+
+ If `gh issue create` fails:
+ - Check error message (auth, permissions, network)
+ - Ensure gh is authenticated: `gh auth status`
+ - Save the drafted issue content for user
+ - Suggest using --web flag to create in browser
+
+
+
+ Ensure GitHub CLI is authenticated:
+ - Check status: `gh auth status`
+ - Login if needed: `gh auth login`
+ - Select appropriate scopes for issue creation
+
+
+
+
+
+ gh issue create - Create new issue
+ gh issue list - List and search issues
+ gh issue view - View issue details
+ gh issue comment - Add comment to issue
+ gh issue edit - Edit existing issue
+ gh issue close - Close an issue
+ gh issue reopen - Reopen closed issue
+
+
+
+ gh search issues - Search issues and PRs
+ gh search prs - Search pull requests
+ gh search repos - Search repositories
+
+
+
+ gh repo view - View repository info
+ gh repo clone - Clone repository
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-mode-writer/1_mode_creation_workflow.xml b/.roo/rules-mode-writer/1_mode_creation_workflow.xml
new file mode 100644
index 0000000000..15a48aa804
--- /dev/null
+++ b/.roo/rules-mode-writer/1_mode_creation_workflow.xml
@@ -0,0 +1,142 @@
+
+
+ This workflow guides you through creating a new custom mode to be used in the Roo Code Software,
+ from initial requirements gathering to final implementation.
+
+
+
+
+ Gather Requirements
+
+ Understand what the user wants the mode to accomplish
+
+
+ Ask about the mode's primary purpose and use cases
+ Identify what types of tasks the mode should handle
+ Determine what tools and file access the mode needs
+ Clarify any special behaviors or restrictions
+
+
+
+ What is the primary purpose of this new mode? What types of tasks should it handle?
+
+ A mode for writing and maintaining documentation
+ A mode for database schema design and migrations
+ A mode for API endpoint development and testing
+ A mode for performance optimization and profiling
+
+
+
+
+
+
+ Design Mode Configuration
+
+ Create the mode definition with all required fields
+
+
+
+ Unique identifier (lowercase, hyphens allowed)
+ Keep it short and descriptive (e.g., "api-dev", "docs-writer")
+
+
+ Display name with optional emoji
+ Use an emoji that represents the mode's purpose
+
+
+ Detailed description of the mode's role and expertise
+
+ Start with "You are Roo Code, a [specialist type]..."
+ List specific areas of expertise
+ Mention key technologies or methodologies
+
+
+
+ Tool groups the mode can access
+
+
+
+
+
+
+
+
+
+
+
+ Clear description for the Orchestrator
+ Explain specific scenarios and task types
+
+
+
+ Do not include customInstructions in the .roomodes configuration.
+ All detailed instructions should be placed in XML files within
+ the .roo/rules-[mode-slug]/ directory instead.
+
+
+
+
+ Implement File Restrictions
+
+ Configure appropriate file access permissions
+
+
+ Restrict edit access to specific file types
+
+groups:
+ - read
+ - - edit
+ - fileRegex: \.(md|txt|rst)$
+ description: Documentation files only
+ - command
+
+
+
+ Use regex patterns to limit file editing scope
+ Provide clear descriptions for restrictions
+ Consider the principle of least privilege
+
+
+
+
+ Create XML Instruction Files
+
+ Design structured instruction files in .roo/rules-[mode-slug]/
+
+
+ Main workflow and step-by-step processes
+ Guidelines and conventions
+ Reusable code patterns and examples
+ Specific tool usage instructions
+ Complete workflow examples
+
+
+ Use semantic tag names that describe content
+ Nest tags hierarchically for better organization
+ Include code examples in CDATA sections when needed
+ Add comments to explain complex sections
+
+
+
+
+ Test and Refine
+
+ Verify the mode works as intended
+
+
+ Mode appears in the mode list
+ File restrictions work correctly
+ Instructions are clear and actionable
+ Mode integrates well with Orchestrator
+ All examples are accurate and helpful
+
+
+
+
+
+ Create mode in .roomodes for project-specific modes
+ Create mode in global custom_modes.yaml for system-wide modes
+ Use list_files to verify .roo folder structure
+ Test file regex patterns with search_files
+
+
\ No newline at end of file
diff --git a/.roo/rules-mode-writer/2_xml_structuring_best_practices.xml b/.roo/rules-mode-writer/2_xml_structuring_best_practices.xml
new file mode 100644
index 0000000000..639f855c0c
--- /dev/null
+++ b/.roo/rules-mode-writer/2_xml_structuring_best_practices.xml
@@ -0,0 +1,220 @@
+
+
+ XML tags help Claude parse prompts more accurately, leading to higher-quality outputs.
+ This guide covers best practices for structuring mode instructions using XML.
+
+
+
+
+ Clearly separate different parts of your instructions and ensure well-structured content
+
+
+ Reduce errors caused by Claude misinterpreting parts of your instructions
+
+
+ Easily find, add, remove, or modify parts of instructions without rewriting everything
+
+
+ Having Claude use XML tags in its output makes it easier to extract specific parts of responses
+
+
+
+
+
+ Use the same tag names throughout your instructions
+
+ Always use for workflow steps, not sometimes or
+
+
+
+
+ Tag names should clearly describe their content
+
+ detailed_steps
+ error_handling
+ validation_rules
+
+
+ stuff
+ misc
+ data1
+
+
+
+
+ Nest tags to show relationships and structure
+
+
+
+ Gather requirements
+ Validate inputs
+
+
+ Process data
+ Generate output
+
+
+
+
+
+
+
+
+ For step-by-step processes
+
+ High-level description
+
+ Required condition 1
+ Required condition 2
+
+
+
+ Step Title
+ What this step accomplishes
+
+ Specific action to take
+
+ How to verify success
+
+
+
+ ]]>
+
+
+
+ For providing code examples and demonstrations
+
+
+ What this example demonstrates
+ When to use this approach
+
+ // Your code example here
+
+
+ Key points about the implementation
+
+
+
+ ]]>
+
+
+
+ For rules and best practices
+
+
+ The specific rule or guideline
+ Why this is important
+ When this doesn't apply
+
+
+ ]]>
+
+
+
+ For documenting how to use specific tools
+
+ What this tool accomplishes
+ Specific scenarios for this tool
+
+ The exact command format
+
+
+ What this parameter does
+ string|number|boolean
+ example_value
+
+
+
+
+
+ Actual usage example
+
+
+
+
+ ]]>
+
+
+
+
+
+ Use consistent indentation (2 or 4 spaces) for nested elements
+
+
+ Add line breaks between major sections for readability
+
+
+ Use XML comments to explain complex sections
+
+
+ Use CDATA for code blocks or content with special characters:
+ ]]>
+
+
+ Use attributes for metadata, elements for content:
+
+
+ The actual step content
+
+
+
+
+
+
+
+ Avoid completely flat structures without hierarchy
+
+Do this
+Then this
+Finally this
+
+ ]]>
+
+
+ Do this
+ Then this
+ Finally this
+
+
+ ]]>
+
+
+
+ Don't mix naming conventions
+
+ Mixing camelCase, snake_case, and kebab-case in tag names
+
+
+ Pick one convention (preferably snake_case for XML) and stick to it
+
+
+
+
+ Avoid tags that don't convey meaning
+ data, info, stuff, thing, item
+ user_input, validation_result, error_message, configuration
+
+
+
+
+
+ Reference XML content in instructions:
+ "Using the workflow defined in <workflow> tags..."
+
+
+ Combine XML structure with other techniques like multishot prompting
+
+
+ Use XML tags in expected outputs to make parsing easier
+
+
+ Create reusable XML templates for common patterns
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-mode-writer/3_mode_configuration_patterns.xml b/.roo/rules-mode-writer/3_mode_configuration_patterns.xml
new file mode 100644
index 0000000000..82a5f845ac
--- /dev/null
+++ b/.roo/rules-mode-writer/3_mode_configuration_patterns.xml
@@ -0,0 +1,261 @@
+
+
+ Common patterns and templates for creating different types of modes, with examples from existing modes in the Roo-Code software.
+
+
+
+
+
+ Modes focused on specific technical domains or tasks
+
+
+ Deep expertise in a particular area
+ Restricted file access based on domain
+ Specialized tool usage patterns
+
+ -
+ You are Roo Code, an API development specialist with expertise in:
+ - RESTful API design and implementation
+ - GraphQL schema design
+ - API documentation with OpenAPI/Swagger
+ - Authentication and authorization patterns
+ - Rate limiting and caching strategies
+ - API versioning and deprecation
+
+ You ensure APIs are:
+ - Well-documented and discoverable
+ - Following REST principles or GraphQL best practices
+ - Secure and performant
+ - Properly versioned and maintainable
+ whenToUse: >-
+ Use this mode when designing, implementing, or refactoring APIs.
+ This includes creating new endpoints, updating API documentation,
+ implementing authentication, or optimizing API performance.
+ groups:
+ - read
+ - - edit
+ - fileRegex: (api/.*\.(ts|js)|.*\.openapi\.yaml|.*\.graphql|docs/api/.*)$
+ description: API implementation files, OpenAPI specs, and API documentation
+ - command
+ - mcp
+ ]]>
+
+
+
+
+ Modes that guide users through multi-step processes
+
+
+ Step-by-step workflow guidance
+ Heavy use of ask_followup_question
+ Process validation at each step
+
+ -
+ You are Roo Code, a migration specialist who guides users through
+ complex migration processes:
+ - Database schema migrations
+ - Framework version upgrades
+ - API version migrations
+ - Dependency updates
+ - Breaking change resolutions
+
+ You provide:
+ - Step-by-step migration plans
+ - Automated migration scripts
+ - Rollback strategies
+ - Testing approaches for migrations
+ whenToUse: >-
+ Use this mode when performing any kind of migration or upgrade.
+ This mode will analyze the current state, plan the migration,
+ and guide you through each step with validation.
+ groups:
+ - read
+ - edit
+ - command
+ ]]>
+
+
+
+
+ Modes focused on code analysis and reporting
+
+
+ Read-heavy operations
+ Limited or no edit permissions
+ Comprehensive reporting outputs
+
+ -
+ You are Roo Code, a security analysis specialist focused on:
+ - Identifying security vulnerabilities
+ - Analyzing authentication and authorization
+ - Reviewing data validation and sanitization
+ - Checking for common security anti-patterns
+ - Evaluating dependency vulnerabilities
+ - Assessing API security
+
+ You provide detailed security reports with:
+ - Vulnerability severity ratings
+ - Specific remediation steps
+ - Security best practice recommendations
+ whenToUse: >-
+ Use this mode to perform security audits on codebases.
+ This mode will analyze code for vulnerabilities, check
+ dependencies, and provide actionable security recommendations.
+ groups:
+ - read
+ - command
+ - - edit
+ - fileRegex: (SECURITY\.md|\.github/security/.*|docs/security/.*)$
+ description: Security documentation files only
+ ]]>
+
+
+
+
+ Modes for generating new content or features
+
+
+ Broad file creation permissions
+ Template and boilerplate generation
+ Interactive design process
+
+ -
+ You are Roo Code, a UI component design specialist who creates:
+ - Reusable React/Vue/Angular components
+ - Component documentation and examples
+ - Storybook stories
+ - Unit tests for components
+ - Accessibility-compliant interfaces
+
+ You follow design system principles and ensure components are:
+ - Highly reusable and composable
+ - Well-documented with examples
+ - Fully tested
+ - Accessible (WCAG compliant)
+ - Performance optimized
+ whenToUse: >-
+ Use this mode when creating new UI components or refactoring
+ existing ones. This mode helps design component APIs, implement
+ the components, and create comprehensive documentation.
+ groups:
+ - read
+ - - edit
+ - fileRegex: (components/.*|stories/.*|__tests__/.*\.test\.(tsx?|jsx?))$
+ description: Component files, stories, and component tests
+ - browser
+ - command
+ ]]>
+
+
+
+
+
+ For modes that only work with documentation
+
+
+
+
+ For modes that work with test files
+
+
+
+
+ For modes that manage configuration
+
+
+
+
+ For modes that need broad access
+
+
+
+
+
+
+ Use lowercase with hyphens
+ api-dev, test-writer, docs-manager
+ apiDev, test_writer, DocsManager
+
+
+
+ Use title case with descriptive emoji
+ 🔧 API Developer, 📝 Documentation Writer
+ api developer, DOCUMENTATION WRITER
+
+
+
+
+ 🧪
+ 📝
+ 🎨
+ 🪲
+ 🏗️
+ 🔒
+ 🔌
+ 🗄️
+ ⚡
+ ⚙️
+
+
+
+
+
+
+ Ensure whenToUse is clear for Orchestrator mode
+
+ Specify concrete task types the mode handles
+ Include trigger keywords or phrases
+ Differentiate from similar modes
+ Mention specific file types or areas
+
+
+
+
+ Define clear boundaries between modes
+
+ Avoid overlapping responsibilities
+ Make handoff points explicit
+ Use switch_mode when appropriate
+ Document mode interactions
+
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-mode-writer/4_instruction_file_templates.xml b/.roo/rules-mode-writer/4_instruction_file_templates.xml
new file mode 100644
index 0000000000..3afcfa28f4
--- /dev/null
+++ b/.roo/rules-mode-writer/4_instruction_file_templates.xml
@@ -0,0 +1,367 @@
+
+
+ Templates and examples for creating XML instruction files that provide
+ detailed guidance for each mode's behavior and workflows.
+
+
+
+ Number files to indicate execution order
+ Use descriptive names that indicate content
+ Keep related instructions together
+
+ 1_workflow.xml - Main workflow and processes
+ 2_best_practices.xml - Guidelines and conventions
+ 3_common_patterns.xml - Reusable code patterns
+ 4_tool_usage.xml - Specific tool instructions
+ 5_examples.xml - Complete workflow examples
+ 6_error_handling.xml - Error scenarios and recovery
+ 7_communication.xml - User interaction guidelines
+
+
+
+
+ Template for main workflow files (1_workflow.xml)
+
+
+ Brief description of what this mode does and its primary purpose
+
+
+
+
+ Understand the user's request
+
+ Parse the user's input to identify:
+ - Primary objective
+ - Specific requirements
+ - Constraints or limitations
+
+
+
+
+ Gather necessary context
+
+ codebase_search - Find relevant existing code
+ list_files - Understand project structure
+ read_file - Examine specific implementations
+
+
+
+
+
+
+ Analyze the current state and requirements
+
+ Identify affected components
+ Assess impact of changes
+ Plan implementation approach
+
+
+
+
+ Execute the planned changes
+
+ Create/modify necessary files
+ Ensure consistency across codebase
+ Add appropriate documentation
+
+
+
+
+ Verify the implementation
+
+ Check for errors or inconsistencies
+ Validate against requirements
+ Ensure no regressions
+
+
+
+
+
+ All requirements have been addressed
+ Code follows project conventions
+ Changes are properly documented
+ No breaking changes introduced
+
+
+ ]]>
+
+
+
+ Template for best practices files (2_best_practices.xml)
+
+
+
+ Principle Name
+ Detailed explanation of the principle
+ Why this principle is important
+
+ When this applies
+ Correct approach
+ What to avoid
+
+
+
+
+
+
+ Specific naming convention
+
+ goodExampleName
+ bad_example-name
+
+
+
+
+ How to structure code/files
+
+ // Example structure
+
+
+
+
+
+
+ Common mistake to avoid
+ Explanation of issues it causes
+ How to do it properly
+
+
+
+
+
+ Understand requirements fully
+ Check existing implementations
+
+
+ Follow established patterns
+ Write clear documentation
+
+
+ Review all changes
+ Verify requirements met
+
+
+
+ ]]>
+
+
+
+ Template for tool usage files (4_tool_usage.xml)
+
+
+
+ codebase_search
+ Always use first to find relevant code
+ Semantic search finds functionality better than keywords
+
+
+ read_file
+ After identifying files with codebase_search
+ Get full context of implementations
+
+
+
+
+
+
+ Always read file first to ensure exact content match
+ Make multiple changes in one diff when possible
+ Include line numbers for accuracy
+
+
+src/config.ts
+
+<<<<<<< SEARCH
+:start_line:10
+-------
+export const config = {
+ apiUrl: 'http://localhost:3000',
+ timeout: 5000
+};
+=======
+export const config = {
+ apiUrl: process.env.API_URL || 'http://localhost:3000',
+ timeout: parseInt(process.env.TIMEOUT || '5000'),
+ retries: 3
+};
+>>>>>>> REPLACE
+
+
+ ]]>
+
+
+
+
+ Provide 2-4 specific, actionable suggestions
+ Order suggestions by likelihood or importance
+ Make suggestions complete (no placeholders)
+
+
+Which database system should I configure for this project?
+
+PostgreSQL with the default configuration
+MySQL 8.0 with InnoDB storage engine
+SQLite for local development only
+MongoDB for document-based storage
+
+
+ ]]>
+
+
+
+
+
+
+ codebase_search - Find relevant files
+ list_code_definition_names - Understand structure
+ read_file - Get full context
+ apply_diff or write_to_file - Make changes
+
+
+
+
+
+ list_files - Check file exists
+ read_file - Verify current content
+ ask_followup_question - Confirm approach
+ apply_diff - Implement changes
+
+
+
+
+ ]]>
+
+
+
+ Template for example files (5_examples.xml)
+
+
+
+ Detailed description of the use case this example covers
+
+
+
+ The initial request from the user
+
+
+
+
+ First step description
+
+search query here
+
+ ]]>
+ What we learn from this step
+
+
+
+ Second step description
+
+path/to/file.ts
+
+ ]]>
+ How we interpret the results
+
+
+
+ Implementation step
+
+path/to/file.ts
+
+<<<<<<< SEARCH
+:start_line:1
+-------
+original content
+=======
+new content
+>>>>>>> REPLACE
+
+
+ ]]>
+
+
+
+
+
+Summary of what was accomplished and how it addresses the user's request
+
+
+ ]]>
+
+
+ Important lesson from this example
+ Pattern that can be reused
+
+
+
+ ]]>
+
+
+
+ Template for communication guidelines (7_communication.xml)
+
+
+ Be direct and technical, not conversational
+ Focus on actions taken and results achieved
+
+ Great! I'll help you with that...
+ Certainly! Let me...
+ Sure thing!
+
+
+ I'll analyze the codebase to...
+ Implementing the requested changes...
+ The analysis shows...
+
+
+
+
+
+ Missing critical information
+ Multiple valid approaches exist
+ Potential breaking changes
+
+
+
+ Be specific about what you need
+ Provide actionable options
+ Explain implications of choices
+
+
+
+
+ During long-running operations
+
+ Analyzing [X] files for [purpose]...
+ Implementing [feature] in [location]...
+ Validating changes against [criteria]...
+
+
+
+
+
+ What was accomplished
+ Key changes made
+ Any important notes or warnings
+
+
+ Questions at the end
+ Offers for further assistance
+ Conversational closings
+
+
+
+ ]]>
+
+
\ No newline at end of file
diff --git a/.roo/rules-mode-writer/5_complete_mode_examples.xml b/.roo/rules-mode-writer/5_complete_mode_examples.xml
new file mode 100644
index 0000000000..45fd577c53
--- /dev/null
+++ b/.roo/rules-mode-writer/5_complete_mode_examples.xml
@@ -0,0 +1,96 @@
+
+
+ Generate OpenAPI documentation for a REST API with user management endpoints
+
+
+
+
+ Discover API endpoints
+
+express router app.get app.post app.put app.delete @Route @Get @Post
+
+ ]]>
+ Found routes in src/routes/users.ts
+
+
+
+ Analyze endpoint implementation
+
+src/routes/users.ts
+
+ ]]>
+
+
+
+ Generate OpenAPI specification
+
+docs/api/openapi.yaml
+
+openapi: 3.0.0
+info:
+ title: User Management API
+ version: 1.0.0
+ description: API for managing user accounts
+
+servers:
+ - url: https://api.example.com/v1
+ description: Production server
+ - url: http://localhost:3000/v1
+ description: Development server
+
+paths:
+ /users:
+ get:
+ summary: List all users
+ operationId: listUsers
+ tags:
+ - Users
+ parameters:
+ - name: page
+ in: query
+ schema:
+ type: integer
+ default: 1
+ - name: limit
+ in: query
+ schema:
+ type: integer
+ default: 20
+ responses:
+ '200':
+ description: Successful response
+ content:
+ application/json:
+ schema:
+ type: object
+ properties:
+ users:
+ type: array
+ items:
+ $ref: '#/components/schemas/User'
+ pagination:
+ $ref: '#/components/schemas/Pagination'
+
+components:
+ schemas:
+ User:
+ type: object
+ required:
+ - id
+ - email
+ properties:
+ id:
+ type: string
+ format: uuid
+ email:
+ type: string
+ format: email
+ name:
+ type: string
+ createdAt:
+ type: string
+ format: date-time
\ No newline at end of file
diff --git a/.roo/rules-mode-writer/6_mode_testing_validation.xml b/.roo/rules-mode-writer/6_mode_testing_validation.xml
new file mode 100644
index 0000000000..db65b31c22
--- /dev/null
+++ b/.roo/rules-mode-writer/6_mode_testing_validation.xml
@@ -0,0 +1,207 @@
+
+
+ Guidelines for testing and validating newly created modes to ensure they function correctly and integrate well with the Roo Code ecosystem.
+
+
+
+
+
+ Mode slug is unique and follows naming conventions
+ No spaces, lowercase, hyphens only
+
+
+ All required fields are present and non-empty
+ slug, name, roleDefinition, groups
+
+
+ No customInstructions field in .roomodes
+ All instructions must be in XML files in .roo/rules-[slug]/
+
+
+ File restrictions use valid regex patterns
+
+.
+your_file_regex_here
+
+ ]]>
+
+
+ whenToUse clearly differentiates from other modes
+ Compare with existing mode descriptions
+
+
+
+
+
+ XML files are well-formed and valid
+ No syntax errors, proper closing tags
+
+
+ Instructions follow XML best practices
+ Semantic tag names, proper nesting
+
+
+ Examples use correct tool syntax
+ Tool parameters match current API
+
+
+ File paths in examples are consistent
+ Use project-relative paths
+
+
+
+
+
+ Mode appears in mode list
+ Switch to the new mode and verify it loads
+
+
+ Tool permissions work as expected
+ Try using each tool group and verify access
+
+
+ File restrictions are enforced
+ Attempt to edit allowed and restricted files
+
+
+ Mode handles edge cases gracefully
+ Test with minimal input, errors, edge cases
+
+
+
+
+
+
+ Configuration Testing
+
+ Verify mode appears in available modes list
+ Check that mode metadata displays correctly
+ Confirm mode can be activated
+
+
+I've created the mode configuration. Can you see the new mode in your mode list?
+
+Yes, I can see the new mode and switch to it
+No, the mode doesn't appear in the list
+The mode appears but has errors when switching
+
+
+ ]]>
+
+
+
+ Permission Testing
+
+
+ Use read tools on various files
+ All read operations should work
+
+
+ Try editing allowed file types
+ Edits succeed for matching patterns
+
+
+ Try editing restricted file types
+ FileRestrictionError for non-matching files
+
+
+
+
+
+ Workflow Testing
+
+ Execute main workflow from start to finish
+ Test each decision point
+ Verify error handling
+ Check completion criteria
+
+
+
+
+ Integration Testing
+
+ Orchestrator mode compatibility
+ Mode switching functionality
+ Tool handoff between modes
+ Consistent behavior with other modes
+
+
+
+
+
+
+ Mode doesn't appear in list
+
+ Syntax error in YAML
+ Invalid mode slug
+ File not saved
+
+ Check YAML syntax, validate slug format
+
+
+
+ File restriction not working
+
+ Invalid regex pattern
+ Escaping issues in regex
+ Wrong file path format
+
+ Test regex pattern, use proper escaping
+
+
+
+
+ Mode not following instructions
+
+ Instructions not in .roo/rules-[slug]/ folder
+ XML parsing errors
+ Conflicting instructions
+
+ Verify file locations and XML validity
+
+
+
+
+
+ Verify instruction files exist in correct location
+
+.roo
+true
+
+ ]]>
+
+
+
+ Check mode configuration syntax
+
+.roomodes
+
+ ]]>
+
+
+
+ Test file restriction patterns
+
+.
+your_file_pattern_here
+
+ ]]>
+
+
+
+
+ Test incrementally as you build the mode
+ Start with minimal configuration and add complexity
+ Document any special requirements or dependencies
+ Consider edge cases and error scenarios
+ Get feedback from potential users of the mode
+
+
\ No newline at end of file
diff --git a/.roo/rules-pr-fixer/1_workflow.xml b/.roo/rules-pr-fixer/1_workflow.xml
new file mode 100644
index 0000000000..db74ead7ee
--- /dev/null
+++ b/.roo/rules-pr-fixer/1_workflow.xml
@@ -0,0 +1,75 @@
+
+
+ This mode is designed to help resolve issues in existing pull requests. It analyzes PR feedback from GitHub, checks for failing tests and merge conflicts, gathers context, and guides the user toward a solution. All GitHub operations are performed using the GitHub CLI.
+
+
+
+
+ Understand the user's request
+
+ Parse the user's input to identify the pull request URL or number. Extract the repository owner and name.
+
+
+
+ Gather PR context
+
+ gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles,comments,reviews
+ gh pr checks [PR_NUMBER] --repo [owner]/[repo] - Check workflow status for failing tests
+ gh pr view [PR_NUMBER] --repo [owner]/[repo] --json mergeable,mergeStateStatus - Check for merge conflicts
+
+
+
+
+
+
+ Analyze the gathered information to identify the core problems.
+
+ Summarize review comments and requested changes from gh pr view output.
+ Identify the root cause of failing tests by analyzing workflow logs with 'gh run view'.
+ Determine if merge conflicts exist from mergeable status.
+
+
+
+
+ Synthesize the findings and present them to the user.
+
+ Present a summary of the issues found (reviews, failing tests, conflicts).
+ Use ask_followup_question to ask the user how they want to proceed with fixing the issues.
+
+
+
+
+ Execute the user's chosen course of action.
+
+ Check out the PR branch locally using 'gh pr checkout [PR_NUMBER] --repo [owner]/[repo] --force'.
+ Determine if the PR is from a fork by checking 'gh pr view [PR_NUMBER] --repo [owner]/[repo] --json isCrossRepository'.
+ Apply code changes based on review feedback using file editing tools.
+ Fix failing tests by modifying test files or source code as needed.
+ For conflict resolution: Use GIT_EDITOR=true for non-interactive rebases, then resolve conflicts via file editing.
+ If changes affect user-facing content (i18n files, UI components, announcements), delegate translation updates using the new_task tool with translate mode.
+ Review modified files with 'git status --porcelain' to ensure no temporary files are included.
+ Stage files selectively using 'git add -u' (for modified tracked files) or 'git add ' (for new files).
+ Verify staged files with 'git diff --cached --name-only' before committing.
+ Commit changes using git commands with descriptive messages.
+ Push changes to the correct remote (origin for same-repo PRs, fork remote for cross-repo PRs) using 'git push --force-with-lease'.
+
+
+
+
+ Verify that the pushed changes resolve the issues.
+
+ Use 'gh pr checks [PR_NUMBER] --repo [owner]/[repo] --watch' to monitor check status in real-time until all checks complete.
+ If needed, check specific workflow runs with 'gh run list --pr [PR_NUMBER] --repo [owner]/[repo]' for detailed CI/CD pipeline status.
+ Verify that all translation updates (if any) have been completed and committed.
+ Confirm PR is ready for review by checking mergeable state with 'gh pr view [PR_NUMBER] --repo [owner]/[repo] --json mergeable,mergeStateStatus'.
+
+
+
+
+
+ All actionable review comments have been addressed.
+ All tests are passing.
+ The PR is free of merge conflicts.
+ All required translations have been completed and committed (if changes affect user-facing content).
+
+
\ No newline at end of file
diff --git a/.roo/rules-pr-fixer/2_best_practices.xml b/.roo/rules-pr-fixer/2_best_practices.xml
new file mode 100644
index 0000000000..50a8395b9c
--- /dev/null
+++ b/.roo/rules-pr-fixer/2_best_practices.xml
@@ -0,0 +1,83 @@
+
+
+
+ Context is Key
+ Always gather full context before attempting a fix. This includes reading all relevant PR comments, checking CI/CD logs, and understanding the surrounding code.
+ Without full context, fixes may be incomplete or introduce new issues.
+
+
+ Incremental Fixes
+ Address issues one at a time (e.g., fix tests first, then address comments). This makes the process more manageable and easier to validate.
+ Tackling all issues at once can be complex and error-prone.
+
+
+ Handle Fork Remotes Correctly
+ Always check if a PR comes from a fork (cross-repository) before pushing changes. Use 'gh pr view --json isCrossRepository' to determine the correct remote.
+ Pushing to the wrong remote (e.g., origin instead of fork) will fail for cross-repository PRs.
+
+ PR from a fork
+ Check isCrossRepository, add fork remote if needed, push to fork
+ Always push to origin without checking PR source
+
+
+
+ Safe File Staging
+ Always review files before staging to avoid committing temporary files, build artifacts, or system files. Use selective git commands that respect .gitignore.
+ Committing unwanted files can expose sensitive data, clutter the repository, and cause CI/CD failures.
+
+ Staging files for commit
+ Use 'git add -u' to stage only modified tracked files, or explicitly list files to add
+ Use 'git add .' which stages everything including temp files
+
+
+ Review git status before staging
+ Check for temporary files (.swp, .DS_Store, *.tmp)
+ Exclude build artifacts (dist/, build/, *.pyc)
+ Avoid IDE-specific files (.idea/, .vscode/)
+ Verify .gitignore is properly configured
+
+
+
+
+
+
+ How to correctly escape conflict markers when using apply_diff.
+
+When removing merge conflict markers from files, you must **escape** them in your `SEARCH` section by prepending a backslash (`\`) at the beginning of the line. This prevents the system from mistaking them for actual diff syntax.
+
+**Correct Format Example:**
+
+```
+<<<<<<< SEARCH
+content before
+\<<<<<<< HEAD <-- Note the backslash here
+content after
+=======
+replacement content
+>>>>>>> REPLACE
+```
+
+Without escaping, the system confuses your content with real diff markers.
+
+You may include multiple diff blocks in a single request, but if any of the following markers appear within your `SEARCH` or `REPLACE` content, they must be escaped:
+
+```
+\<<<<<<< SEARCH
+\=======
+\>>>>>>> REPLACE
+```
+
+Only these three need to be escaped when used in content.
+
+
+
+
+
+
+ Have all review comments been addressed?
+ Are all CI/CD checks passing?
+ Is the PR free of merge conflicts?
+ Have the changes been tested locally?
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-pr-fixer/3_common_patterns.xml b/.roo/rules-pr-fixer/3_common_patterns.xml
new file mode 100644
index 0000000000..1c6c0bcf65
--- /dev/null
+++ b/.roo/rules-pr-fixer/3_common_patterns.xml
@@ -0,0 +1,142 @@
+
+
+ A set of commands to quickly assess the state of a Pull Request.
+
+
+ gh pr status --json number,title,state,conflict,reviewDecision,headRefName,headRepositoryOwner
+
+
+ gh pr checks
+
+
+ gh pr view --comments
+
+
+
+
+ Commands to investigate why a specific test is failing.
+
+
+ gh run list --workflow= --branch= --json databaseId,name,status,conclusion
+
+
+ gh run view --log-failed
+
+
+
+
+ Commands to detect merge conflicts.
+
+ Fetch latest main branch
+ git fetch origin main
+ Check if rebase would create conflicts
+ git rebase --dry-run origin/main
+
+
+
+
+ Rebase operations using GIT_EDITOR to prevent interactive prompts.
+
+ git checkout
+ GIT_EDITOR=true git rebase main
+ If conflicts occur, resolve them manually then use 'git rebase --continue'
+ git push --force-with-lease
+
+
+
+
+ Check current conflict status without interactive input.
+
+ git status --porcelain
+ git diff --name-only --diff-filter=U
+ List files with unresolved conflicts
+ git ls-files --unmerged
+
+
+
+ Check out a pull request branch locally.
+
+ gh pr checkout --force
+ Alternative if gh checkout fails:
+ git fetch origin pull//head: && git checkout
+
+
+
+
+ Determine the correct remote to push to (handles forks).
+
+ Get PR metadata to check if it's from a fork
+ gh pr view --json headRepositoryOwner,headRefName,isCrossRepository
+ If isCrossRepository is true, it's from a fork
+ git remote -v
+ Check if fork remote exists, otherwise add it
+ git remote add fork https://github.com//.git
+ Use appropriate remote based on PR source
+
+
+
+
+ Monitor PR checks in real-time as they run.
+
+ gh pr checks --watch
+ Continuously monitor check status with automatic updates
+ For one-time status check: gh pr checks --json state,conclusion,name,detailsUrl
+ gh run list --pr --json databaseId,status,conclusion
+
+
+
+
+ Push operations that handle both origin and fork remotes correctly.
+
+ First determine the correct remote (origin or fork)
+ gh pr view --json headRepositoryOwner,headRefName,isCrossRepository
+ If isCrossRepository is false, push to origin
+ git push --force-with-lease origin
+ If isCrossRepository is true, push to fork remote
+ git push --force-with-lease fork
+ If force-with-lease fails, fetch and retry
+ git fetch
+ git push --force
+
+
+
+
+ Commit operations that work in automated environments while respecting .gitignore.
+
+ Review what files have been modified
+ git status --porcelain
+ Add only tracked files that were modified (respects .gitignore)
+ git add -u
+ If you need to add specific new files, list them explicitly
+ git add
+ git commit -m ""
+
+
+
+ Safely stage files for commit while avoiding temporary files and respecting .gitignore.
+
+ First, check what files are currently modified or untracked
+ git status --porcelain
+ Review the output to identify files that should NOT be committed:
+ - Files starting with . (hidden files like .DS_Store, .swp)
+ - Build artifacts (dist/, build/, *.pyc, *.o)
+ - IDE files (.idea/, .vscode/, *.iml)
+ - Temporary files (*.tmp, *.temp, *~)
+
+ Option 1: Stage only modified tracked files (safest)
+ git add -u
+
+ Option 2: Stage specific files by path
+ git add src/file1.ts src/file2.ts
+
+ Option 3: Use pathspec to add files matching a pattern
+ git add '*.ts' '*.tsx' --
+
+ Option 4: Interactive staging to review each change
+ git add -p
+
+ Always verify what's staged before committing
+ git diff --cached --name-only
+
+
+
diff --git a/.roo/rules-pr-fixer/4_tool_usage.xml b/.roo/rules-pr-fixer/4_tool_usage.xml
new file mode 100644
index 0000000000..90d20a0382
--- /dev/null
+++ b/.roo/rules-pr-fixer/4_tool_usage.xml
@@ -0,0 +1,136 @@
+
+
+
+ gh pr view
+ Use at the start to get all review comments and PR metadata.
+ Provides the core context of what needs to be fixed from a human perspective.
+
+
+ gh pr checks
+ After getting comments, to check the technical status.
+ Quickly identifies if there are failing automated checks that need investigation.
+
+
+ new_task (mode: translate)
+ When changes affect user-facing content, i18n files, or UI components that require translation.
+ Ensures translation consistency across all supported languages when PR fixes involve user-facing changes.
+
+
+ gh pr checks --watch
+ After pushing a fix, to confirm that the changes have resolved the CI/CD failures.
+ Provides real-time feedback on whether the fix was successful.
+
+
+
+
+
+
+ Always fetch details with --json to get structured data: gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles,comments,reviews,mergeable,mergeStateStatus,isCrossRepository
+ Parse the JSON output to extract branch name, owner, repo slug, and mergeable state.
+
+
+
+
+
+ Use gh pr view --json comments to get all comments in structured format.
+ Parse all comments to create a checklist of required changes.
+ Ignore comments that are not actionable or have been resolved.
+
+
+
+
+
+ Use this command to get the exact error messages from failing tests.
+ Search the log for keywords like 'error', 'failed', or 'exception' to quickly find the root cause.
+ Always specify run ID explicitly to avoid interactive selection prompts: gh run view [RUN_ID] --log-failed
+ Get run IDs with: gh run list --pr [PR_NUMBER] --repo [owner]/[repo]
+
+
+
+
+
+ Use --force flag: 'gh pr checkout [PR_NUMBER] --repo [owner]/[repo] --force'
+ If gh checkout fails, use: git fetch origin pull/[PR_NUMBER]/head:[branch_name]
+
+
+
+
+
+ Use --force-with-lease for safer force pushing.
+ Use GIT_EDITOR=true to prevent interactive prompts during rebases.
+ Always determine the correct remote before pushing (origin vs fork).
+
+
+ Check if PR is from a fork: 'gh pr view [PR_NUMBER] --repo [owner]/[repo] --json isCrossRepository'
+ If isCrossRepository is true, add fork remote if needed
+ Push to appropriate remote: 'git push --force-with-lease [remote] [branch]'
+
+
+ Use 'GIT_EDITOR=true git rebase main' to start rebase
+ If conflicts occur, edit files to resolve them
+ Use 'git add .' and 'git rebase --continue' to proceed
+
+
+
+
+
+ Use --watch flag to monitor checks in real-time: 'gh pr checks [PR_NUMBER] --repo [owner]/[repo] --watch'
+ For one-time status checks, use --json flag: 'gh pr checks [PR_NUMBER] --repo [owner]/[repo] --json state,conclusion,name'
+ The --watch flag automatically updates the display as check statuses change.
+ Use 'gh run list --pr [PR_NUMBER] --repo [owner]/[repo]' to get detailed workflow status if needed.
+
+
+
+
+
+ After analyzing all the problems (reviews, tests, conflicts), present a summary to the user.
+ Provide clear, actionable next steps as suggestions.
+ Example suggestions: "Address review comments first.", "Tackle the failing tests.", "Resolve merge conflicts."
+
+
+
+
+
+ Use when PR fixes involve changes to user-facing strings, i18n files, or UI components.
+ Provide specific details about what content needs translation in the message.
+ Include file paths and descriptions of the changes made.
+ List all affected languages that need updates.
+ Wait for translation completion before proceeding to validation phase.
+
+
+ Changes to webview-ui/src/i18n/locales/en/*.json files
+ Changes to src/i18n/locales/en/*.json files
+ Modifications to UI components with user-facing text
+ Updates to announcement files or documentation requiring localization
+ Addition of new error messages or user notifications
+
+
+translate
+Translation updates needed for PR #1234 fixes. Please translate the following changes:
+
+Files modified:
+- webview-ui/src/i18n/locales/en/common.json: Added new error message "connection_failed"
+- webview-ui/src/components/settings/ApiSettings.tsx: Updated button text from "Save" to "Save Configuration"
+
+Please ensure all supported languages (ca, de, es, fr, hi, id, it, ja, ko, nl, pl, pt-BR, ru, tr, vi, zh-CN, zh-TW) are updated with appropriate translations for these changes.
+
+ ]]>
+
+
+
+
+
+ gh pr view [PR_NUMBER] --repo [owner]/[repo] --json [fields]
+ gh pr checkout [PR_NUMBER] --repo [owner]/[repo] --force
+ gh pr checks [PR_NUMBER] --repo [owner]/[repo] [--watch|--json]
+ gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body "[text]"
+
+
+
+ gh run list --pr [PR_NUMBER] --repo [owner]/[repo]
+ gh run view [RUN_ID] --repo [owner]/[repo] --log-failed
+ gh workflow view [WORKFLOW_NAME] --repo [owner]/[repo]
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-pr-fixer/5_examples.xml b/.roo/rules-pr-fixer/5_examples.xml
new file mode 100644
index 0000000000..03fa287c16
--- /dev/null
+++ b/.roo/rules-pr-fixer/5_examples.xml
@@ -0,0 +1,203 @@
+
+
+
+ A pull request has a failing CI check and a review comment asking for a change.
+
+
+
+ Fix PR #4365 in RooCodeInc/Roo-Code.
+
+
+
+
+ Get PR details and review comments.
+
+
+gh pr view 4365 --repo RooCodeInc/Roo-Code --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles,comments,reviews,mergeable,mergeStateStatus
+
+
+ Get the branch name, list of review comments, and check for mergeability.
+
+
+
+ Check CI status.
+
+
+gh pr checks 4365 --repo RooCodeInc/Roo-Code
+
+
+ Identify which check is failing.
+
+
+
+ Get logs for the failing check.
+
+
+gh run list --pr 4365 --repo RooCodeInc/Roo-Code
+
+
+ Get the run ID of the failing workflow.
+
+
+
+ View the failed logs.
+
+
+gh run view [run_id] --repo RooCodeInc/Roo-Code --log-failed
+
+
+ Find the specific error message causing the test to fail.
+
+
+
+ Check out the pull request branch.
+
+
+ gh pr checkout 4365 --repo RooCodeInc/Roo-Code --force
+
+
+ The PR branch is now ready for local edits.
+
+
+
+ Summarize findings and ask the user for the next action.
+
+
+I've checked out the branch. I've found a failing test related to 'XYZ' and a review comment asking to rename a variable. How should we proceed?
+
+First, apply the change requested in the review comment.
+Let's start by fixing the failing test.
+Show me the code for the failing test and the file with the requested change.
+
+
+
+
+
+ After pushing the changes, monitor PR checks in real-time.
+
+
+ gh pr checks 4365 --repo RooCodeInc/Roo-Code --watch
+
+
+ Monitor checks continuously until all complete. The --watch flag provides real-time updates as check statuses change.
+
+
+
+
+ Always gather all information before proposing a solution.
+ Use the GitHub CLI to get a complete picture of the PR's status.
+ The --watch flag on gh pr checks provides real-time monitoring of CI status.
+
+
+
+
+
+ A pull request has review comments requesting UI text changes that require translation updates across all supported languages.
+
+
+
+ Fix PR #1234 in RooCodeInc/Roo-Code - the reviewer asked to change button text and there are some failing tests.
+
+
+
+
+ Get PR details and analyze changes.
+
+
+gh pr view 1234 --repo RooCodeInc/Roo-Code --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles,comments,reviews
+
+
+ Identify the files changed and review feedback requiring UI text modifications.
+
+
+
+ Check out PR and apply the requested changes.
+
+
+gh pr checkout 1234 --repo RooCodeInc/Roo-Code --force
+
+
+ Make the requested button text changes in the UI components.
+
+
+
+ Identify translation requirements and delegate to translate mode.
+
+
+translate
+Translation updates needed for PR #1234 fixes. The following changes were made based on review feedback:
+
+Files modified:
+- webview-ui/src/components/settings/ApiSettings.tsx: Changed button text from "Save" to "Save Configuration"
+- webview-ui/src/i18n/locales/en/common.json: Updated key "save_button" to "save_config_button"
+
+Please update all supported languages (ca, de, es, fr, hi, id, it, ja, ko, nl, pl, pt-BR, ru, tr, vi, zh-CN, zh-TW) with appropriate translations for:
+- New key "save_config_button" with translation equivalent to "Save Configuration"
+- Any other text changes that affect user-facing content
+
+Ensure consistency across all language files and maintain the same context and tone as existing translations.
+
+
+ Translation subtask created and all language files updated.
+
+
+
+ Review and commit changes including translations.
+
+
+git status --porcelain
+
+
+ Review the list of modified files to ensure only intended changes are present.
+
+
+
+ Stage only the intended files for commit.
+
+
+git add -u && git commit -m "fix: update button text and translations as requested in review"
+
+
+ Using 'git add -u' stages only modified tracked files, avoiding any temporary files.
+
+
+
+ Check if PR is from a fork and push to correct remote.
+
+
+gh pr view 1234 --repo RooCodeInc/Roo-Code --json isCrossRepository,headRepositoryOwner,headRefName
+
+
+ Determine if this is a cross-repository PR to know which remote to push to.
+
+
+
+ Push changes to the appropriate remote.
+
+
+git push --force-with-lease origin [branch_name]
+
+
+ Push changes safely to update the pull request. Use 'fork' remote instead if PR is from a fork.
+
+
+
+ Monitor CI status in real-time.
+
+
+gh pr checks 1234 --repo RooCodeInc/Roo-Code --watch
+
+
+ Watch CI checks continuously until all tests pass. The --watch flag provides automatic updates as check statuses change.
+
+
+
+
+ Always check if PR fixes involve user-facing content that requires translation.
+ Use new_task with translate mode to ensure consistent translation updates.
+ Include detailed context about what changed and why in translation requests.
+ Verify translation completeness before considering the PR fix complete.
+ Use gh pr view --json to get structured data about PR properties.
+
+
+
diff --git a/.roo/rules-pr-reviewer/1_orchestrator_workflow.xml b/.roo/rules-pr-reviewer/1_orchestrator_workflow.xml
new file mode 100644
index 0000000000..8bb94694d6
--- /dev/null
+++ b/.roo/rules-pr-reviewer/1_orchestrator_workflow.xml
@@ -0,0 +1,202 @@
+
+
+ This workflow orchestrates a comprehensive pull request review process by delegating
+ specialized analysis tasks to appropriate modes while maintaining context through
+ structured report files. The orchestrator ensures critical review coverage while
+ avoiding redundant feedback. All GitHub operations are performed using the GitHub CLI.
+
+
+
+
+ Parse PR Information and Initialize Context
+
+ Extract PR information from user input (URL or PR number).
+ Create context directory and tracking files.
+ If called by another mode (Issue Fixer, PR Fixer), set calledByMode field.
+
+
+ - Parse PR URL or number from user input
+ - Create directory: .roo/temp/pr-[PR_NUMBER]/
+ - Initialize review-context.json with PR metadata
+ - Check if called by another mode and record it
+
+
+
+
+
+
+ Fetch PR Details and Context
+
+ Use GitHub CLI to fetch comprehensive PR details.
+
+
+ gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles
+
+ .roo/temp/pr-[PR_NUMBER]/pr-metadata.json
+
+
+
+ Fetch Linked Issue
+
+ If PR references an issue, fetch its details for context.
+
+
+ gh issue view [issue_number] --repo [owner]/[repo] --json number,title,body,author,state
+
+ .roo/temp/pr-[PR_NUMBER]/linked-issue.json
+
+
+
+ Fetch Existing Comments and Reviews
+
+ CRITICAL: Get all existing feedback to avoid redundancy.
+
+
+ gh pr view [PR_NUMBER] --repo [owner]/[repo] --json comments --jq '.comments'
+ gh pr view [PR_NUMBER] --repo [owner]/[repo] --json reviews --jq '.reviews'
+
+ .roo/temp/pr-[PR_NUMBER]/existing-feedback.json
+
+
+
+ Check Out PR Locally
+ gh pr checkout [PR_NUMBER] --repo [owner]/[repo]
+ Enable local code analysis and pattern comparison
+
+
+
+
+
+ Delegate Pattern Analysis
+
+ Create a subtask to analyze code patterns and organization.
+
+
+ code
+
+ - Identifying similar existing features/components
+ - Checking if implementations follow established patterns
+ - Finding potential code redundancy
+ - Verifying test organization
+ - Checking file/directory structure consistency
+
+
+
+
+
+
+ Delegate Architecture Review
+
+ Create a subtask for architectural analysis.
+
+
+ architect
+
+ - Module boundary violations
+ - Dependency management issues
+ - Separation of concerns
+ - Potential circular dependencies
+ - Overall architectural consistency
+
+
+
+
+
+
+ Delegate Test Coverage Analysis
+
+ If test files are modified or added, delegate test analysis.
+
+
+ test
+
+ - Test organization and location
+ - Test coverage adequacy
+ - Test naming conventions
+ - Mock usage patterns
+ - Edge case coverage
+
+
+
+
+
+
+
+
+ Synthesize Findings
+
+ Collect all delegated analysis results and create comprehensive review.
+
+
+ - Read all analysis files from .roo/temp/pr-[PR_NUMBER]/
+ - Identify critical issues vs suggestions
+ - Check against existing comments to avoid redundancy
+ - Prioritize findings by impact
+
+
+
+
+ Create Final Review Report
+
+ Generate comprehensive review report with all findings.
+
+
+
+ - Executive Summary
+ - Critical Issues (must fix)
+ - Pattern Inconsistencies
+ - Redundancy Findings
+ - Architecture Concerns
+ - Test Coverage Issues
+ - Minor Suggestions
+
+
+
+
+
+
+ Present Review to User
+
+ Show the review findings and ask for action.
+
+
+
+ Only present the analysis report, do not comment on PR
+
+
+ Ask user if they want to post the review as a comment
+
+
+
+
+
+ Post Review Comment (if approved)
+
+ If user approves and not called by another mode, post review using GitHub CLI.
+
+
+ gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body-file .roo/temp/pr-[PR_NUMBER]/final-review.md
+
+
+
+
+
+
+
+ Inform user to run 'gh auth login' and check authentication status
+
+
+ Verify PR number and repository, ask user to confirm details
+
+
+ Wait briefly and retry, inform user about rate limiting
+
+
+
+ Continue with available analysis and note limitations
+
+
+ Always save intermediate results to temp files
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-pr-reviewer/2_critical_review_guidelines.xml b/.roo/rules-pr-reviewer/2_critical_review_guidelines.xml
new file mode 100644
index 0000000000..ebccff3dbc
--- /dev/null
+++ b/.roo/rules-pr-reviewer/2_critical_review_guidelines.xml
@@ -0,0 +1,208 @@
+
+
+ These guidelines ensure PR reviews are appropriately critical while remaining
+ constructive. The goal is to maintain high code quality and consistency
+ across the codebase by identifying issues that might be overlooked in a
+ less thorough review.
+
+
+
+
+ Always support criticism with evidence from the codebase
+
+ Instead of: "This doesn't follow our patterns"
+ Say: "This implementation differs from the pattern used in src/api/handlers/*.ts
+ where we consistently use the factory pattern for endpoint creation"
+
+
+
+
+ Reference similar existing implementations
+
+ 1. Find 2-3 examples of similar features
+ 2. Identify the common patterns they follow
+ 3. Explain how the PR deviates from these patterns
+ 4. Suggest alignment with existing approaches
+
+
+
+
+ Challenge architectural choices when appropriate
+
+ - "Why was this implemented as a separate module instead of extending the existing X module?"
+ - "This introduces a new pattern for Y. Have we considered using the established pattern from Z?"
+ - "This creates a circular dependency with module A. Could we restructure to maintain cleaner boundaries?"
+
+
+
+
+
+
+ Do new endpoints follow the same structure as existing ones?
+ Are error responses consistent with other endpoints?
+ Is authentication/authorization handled the same way?
+ Are request validations following established patterns?
+
+
+
+ Do components follow the same file structure (types, helpers, component)?
+ Are props interfaces defined consistently?
+ Is state management approach consistent with similar components?
+ Are hooks used in the same patterns as elsewhere?
+
+
+
+ Are test files in the correct directory structure?
+ Do test descriptions follow the same format?
+ Are mocking strategies consistent with other tests?
+ Is test data generation following established patterns?
+
+
+
+ Could this utility already exist elsewhere?
+ Should this be added to an existing utility module?
+ Does the naming convention match other utilities?
+ Are similar transformations already implemented?
+
+
+
+
+
+
+ Search for similar functionality by behavior
+
+ If PR adds a "formatDate" function, search for:
+ - "date format"
+ - "format.*date"
+ - "dateFormat"
+ - Existing date manipulation utilities
+
+
+
+
+ Search for similar code patterns
+
+ If PR adds error handling, search for:
+ - try/catch patterns in similar contexts
+ - Error boundary implementations
+ - Existing error utilities
+
+
+
+
+ Check what similar files import
+
+ Look at imports in files with similar purposes
+ to discover existing utilities that could be reused
+
+
+
+
+
+
+ Reimplementing existing utilities
+
+ - String manipulation functions
+ - Array transformations
+ - Date formatting
+ - API response transformations
+
+
+
+
+ Creating similar components
+
+ - Modal variations that could use a base modal
+ - Form inputs that could extend existing inputs
+ - List components with slight variations
+
+
+
+
+ Repeating business logic
+
+ - Validation rules implemented multiple times
+ - Permission checks duplicated across files
+ - Data transformation logic repeated
+
+
+
+
+
+
+
+
+ "I notice this [feature] implements [pattern X], but our existing
+ [similar features] consistently use [pattern Y]. For example:
+ - [Link to example 1]
+ - [Link to example 2]
+
+ Consider aligning with the established pattern to maintain consistency.
+ If there's a specific reason for the deviation, it would be helpful
+ to document it."
+
+
+
+
+
+ "This functionality appears to overlap with existing code in
+ [file/module]. Specifically, [existing function/component] already
+ handles [similar use case].
+
+ Could we either:
+ 1. Reuse the existing implementation
+ 2. Extend it to cover this use case
+ 3. Extract a shared utility if both are needed"
+
+
+
+
+
+ "For better code organization, this [file/component/test] would
+ fit better in [suggested location] alongside [similar items].
+ This follows our pattern where [explanation of pattern]."
+
+
+
+
+
+ "I see the tests are in [current location], but our other
+ [type] tests are organized in [correct location]. Moving them
+ would make them easier to find and maintain consistency with
+ tests like [example test files]."
+
+
+
+
+
+
+ Issues that should block PR approval
+
+ - Security vulnerabilities
+ - Breaking changes without migration path
+ - Significant pattern violations that would confuse future developers
+ - Major redundancy that adds maintenance burden
+
+
+
+
+ Important issues that need addressing
+
+ - Test files in wrong location
+ - Inconsistent error handling
+ - Missing critical test cases
+ - Code organization that violates module boundaries
+
+
+
+
+ Improvements that would benefit the codebase
+
+ - Minor pattern inconsistencies
+ - Opportunities for code reuse
+ - Additional test coverage
+ - Documentation improvements
+
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-pr-reviewer/3_delegation_patterns.xml b/.roo/rules-pr-reviewer/3_delegation_patterns.xml
new file mode 100644
index 0000000000..9632c7dcf7
--- /dev/null
+++ b/.roo/rules-pr-reviewer/3_delegation_patterns.xml
@@ -0,0 +1,238 @@
+
+
+ Patterns for effectively delegating analysis tasks to specialized modes
+ while maintaining context and ensuring comprehensive review coverage.
+
+
+
+
+
+ When PR contains new features or significant code changes
+
+ code
+
+ Analyze the following changed files for pattern consistency:
+ [List of changed files]
+
+ Please focus on:
+ 1. Finding similar existing implementations in the codebase
+ 2. Identifying established patterns for this type of feature
+ 3. Checking if the new code follows these patterns
+ 4. Looking for potential code redundancy
+ 5. Verifying proper file organization
+
+ Use codebase_search and search_files to find similar code.
+ Document all findings with specific examples and file references.
+
+ Save your analysis to: .roo/temp/pr-[PR_NUMBER]/pattern-analysis.md
+
+ Format the output as:
+ ## Pattern Analysis for PR #[PR_NUMBER]
+ ### Similar Existing Implementations
+ ### Established Patterns
+ ### Pattern Deviations
+ ### Redundancy Findings
+ ### Organization Issues
+
+
+
+
+
+ When PR modifies core modules, adds new modules, or changes dependencies
+
+ architect
+
+ Review the architectural implications of PR #[PR_NUMBER]:
+
+ Changed files:
+ [List of changed files]
+
+ PR Description:
+ [PR description]
+
+ Please analyze:
+ 1. Module boundary adherence
+ 2. Dependency management (new dependencies, circular dependencies)
+ 3. Separation of concerns
+ 4. Impact on system architecture
+ 5. Consistency with architectural patterns
+
+ Save your findings to: .roo/temp/pr-[PR_NUMBER]/architecture-review.md
+
+ Format as:
+ ## Architecture Review for PR #[PR_NUMBER]
+ ### Module Boundaries
+ ### Dependency Analysis
+ ### Architectural Concerns
+ ### Recommendations
+
+
+
+
+
+ When PR adds or modifies test files
+
+ test
+
+ Analyze test changes in PR #[PR_NUMBER]:
+
+ Test files changed:
+ [List of test files]
+
+ Please review:
+ 1. Test file organization and location
+ 2. Test naming conventions
+ 3. Coverage of edge cases
+ 4. Mock usage patterns
+ 5. Consistency with existing test patterns
+
+ Compare with similar existing tests in the codebase.
+
+ Save analysis to: .roo/temp/pr-[PR_NUMBER]/test-analysis.md
+
+ Format as:
+ ## Test Analysis for PR #[PR_NUMBER]
+ ### Test Organization
+ ### Coverage Assessment
+ ### Pattern Consistency
+ ### Recommendations
+
+
+
+
+
+ When PR modifies UI components or adds new ones
+
+ design-engineer
+
+ Review UI changes in PR #[PR_NUMBER]:
+
+ UI files changed:
+ [List of UI files]
+
+ Please analyze:
+ 1. Component structure consistency
+ 2. Styling approach (Tailwind usage)
+ 3. Accessibility considerations
+ 4. i18n implementation
+ 5. Component reusability
+
+ Save findings to: .roo/temp/pr-[PR_NUMBER]/ui-review.md
+
+
+
+
+
+
+ Always save delegation results to temp files
+ .roo/temp/pr-[PR_NUMBER]/[analysis-type].md
+
+
+
+ Request structured markdown output from delegates
+
+ - Easy to parse and combine
+ - Consistent formatting
+ - Clear section headers
+
+
+
+
+ Include relevant context in delegation requests
+
+ - PR number and description
+ - List of changed files
+ - Specific areas of concern
+ - Output file location
+
+
+
+
+
+
+ Delegate tasks one at a time, using results to inform next delegation
+
+ 1. Pattern analysis first
+ 2. If patterns violated, delegate architecture review
+ 3. If tests affected, delegate test analysis
+
+
+
+
+ Delegate multiple independent analyses simultaneously
+
+ - Pattern analysis (code mode)
+ - Test analysis (test mode)
+ - UI review (design-engineer mode)
+
+
+
+
+ Only delegate based on file types changed
+
+ - If *.test.ts changed -> delegate to test mode
+ - If src/components/* changed -> delegate to design-engineer
+ - If package.json changed -> delegate to architect
+
+
+
+
+
+
+ Read all analysis files from temp directory
+
+ - pattern-analysis.md
+ - architecture-review.md
+ - test-analysis.md
+ - ui-review.md
+
+
+
+
+ Find common issues across analyses
+
+ - Pattern violations mentioned multiple times
+ - Redundancy identified by different modes
+ - Organizational issues
+
+
+
+
+ Categorize by severity
+
+ - Critical (blocks PR)
+ - Important (should fix)
+ - Suggestions (nice to have)
+
+
+
+
+ Combine all findings into final review
+
+ ## PR Review Summary
+ ### Critical Issues
+ ### Pattern Inconsistencies
+ ### Architecture Concerns
+ ### Test Coverage
+ ### Suggestions
+
+
+
+
+
+
+ Continue with available analyses
+ Document which analyses couldn't be completed
+
+
+
+ Perform basic analysis in orchestrator mode
+ Note limitations in final report
+
+
+
+ Use completed analyses
+ Set reasonable time limits for delegations
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-pr-reviewer/4_github_operations.xml b/.roo/rules-pr-reviewer/4_github_operations.xml
new file mode 100644
index 0000000000..ad1fdc4459
--- /dev/null
+++ b/.roo/rules-pr-reviewer/4_github_operations.xml
@@ -0,0 +1,224 @@
+
+
+ Guidelines for handling GitHub operations using the GitHub CLI (gh).
+ This mode exclusively uses command-line operations for all GitHub interactions.
+
+
+
+
+ GitHub CLI must be installed and authenticated
+ gh auth status
+ https://cli.github.com/
+
+
+ User must be authenticated with appropriate permissions
+ gh auth login
+
+
+
+
+
+ Fetch comprehensive PR metadata
+ gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles
+ JSON
+ .roo/temp/pr-[PR_NUMBER]/pr-metadata.json
+
+
+
+ Get the full diff of PR changes
+ gh pr diff [PR_NUMBER] --repo [owner]/[repo]
+ .roo/temp/pr-[PR_NUMBER]/pr.diff
+
+
+
+ List all files changed in the PR
+ gh pr view [PR_NUMBER] --repo [owner]/[repo] --json files --jq '.files[].path'
+ Line-separated file paths
+
+
+
+ Get all comments on the PR
+ gh pr view [PR_NUMBER] --repo [owner]/[repo] --json comments --jq '.comments'
+ JSON array of comments
+
+
+
+ Get all reviews on the PR
+ gh pr view [PR_NUMBER] --repo [owner]/[repo] --json reviews --jq '.reviews'
+ JSON array of reviews
+
+
+
+ Check out PR branch locally for analysis
+ gh pr checkout [PR_NUMBER] --repo [owner]/[repo]
+ This switches the current branch to the PR branch
+
+
+
+ Post a comment on the PR
+ gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body-file [file_path]
+ gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body "[comment_text]"
+
+
+
+ Create a PR review with comments
+ gh pr review [PR_NUMBER] --repo [owner]/[repo] --comment --body-file [review_file]
+
+
+
+
+
+
+
+
+ Get issue details (for linked issues)
+ gh issue view [issue_number] --repo [owner]/[repo] --json number,title,body,author,state
+ JSON
+
+
+
+
+
+
+ Error contains "authentication" or "not logged in"
+
+
+ 1. Inform user about auth issue
+ 2. Suggest running: gh auth login
+ 3. Check status with: gh auth status
+
+
+
+
+
+ Error contains "rate limit" or "API rate limit exceeded"
+
+
+ 1. Wait 30-60 seconds before retry
+ 2. Inform user about rate limiting
+ 3. Consider reducing API calls
+
+
+
+
+
+ Error contains "not found" or "could not find pull request"
+
+
+ 1. Verify PR number and repository format
+ 2. Check if repository is accessible
+ 3. Ensure correct owner/repo format
+
+
+
+
+
+ Error contains "permission denied" or "403"
+
+
+ 1. Check repository permissions
+ 2. Verify authentication scope
+ 3. May need to re-authenticate with proper scopes
+
+
+
+
+
+
+ Always save command outputs to temp files
+ Preserve data for analysis and recovery
+
+
+
+ Use jq for JSON parsing when available
+
+ gh pr view --json files --jq '.files[].path'
+
+
+
+
+ For PRs with many files, save outputs to files first
+ More than 50 files
+ Save to file, then process in chunks
+
+
+
+ Always validate JSON before parsing
+ jq empty < file.json || echo "Invalid JSON"
+
+
+
+
+
+ gh pr view [number]
+
+
+
+
+
+
+ number, title, author, state, body, url,
+ headRefName, baseRefName, files, additions,
+ deletions, changedFiles, comments, reviews,
+ isDraft, mergeable, mergeStateStatus
+
+
+
+
+
+ gh pr checkout [number]: Check out PR locally
+ gh pr diff [number]: View PR diff
+ gh pr comment [number] --body "[text]": Add comment
+ gh pr review [number]: Create review
+ gh pr close [number]: Close PR
+ gh pr reopen [number]: Reopen PR
+
+
+
+
+ gh issue view [number]
+
+ number, title, body, author, state,
+ labels, assignees, milestone, comments
+
+
+
+
+
+ gh repo view --json [fields]: Get repo info
+ gh repo clone [owner]/[repo]: Clone repository
+
+
+
+
+
+ Always specify --repo to avoid ambiguity
+ Use --json for structured data that needs parsing
+ Save command outputs to temp files for reliability
+ Check gh auth status before starting operations
+ Handle both personal repos and organization repos
+ Use meaningful file names when saving outputs
+ Include error handling for all commands
+ Document the expected format of saved files
+
+
+
+
+ Fetch all PR data for analysis
+
+ gh pr view 123 --repo owner/repo --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles > .roo/temp/pr-123/metadata.json
+ gh pr view 123 --repo owner/repo --json comments > .roo/temp/pr-123/comments.json
+ gh pr view 123 --repo owner/repo --json reviews > .roo/temp/pr-123/reviews.json
+ gh pr diff 123 --repo owner/repo > .roo/temp/pr-123/pr.diff
+
+
+
+
+ Post a comprehensive review
+
+ Create review content in .roo/temp/pr-123/review.md
+ gh pr review 123 --repo owner/repo --comment --body-file .roo/temp/pr-123/review.md
+
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-pr-reviewer/5_context_management.xml b/.roo/rules-pr-reviewer/5_context_management.xml
new file mode 100644
index 0000000000..4b55431c74
--- /dev/null
+++ b/.roo/rules-pr-reviewer/5_context_management.xml
@@ -0,0 +1,356 @@
+
+
+ Strategies for maintaining review context across delegated tasks and
+ ensuring no information is lost during the orchestration process.
+
+
+
+
+ Central tracking file for the entire review process
+ .roo/temp/pr-[PR_NUMBER]/review-context.json
+
+ {
+ "prNumber": "string",
+ "repository": "string",
+ "reviewStartTime": "ISO timestamp",
+ "calledByMode": "string or null",
+ "prMetadata": {
+ "title": "string",
+ "author": "string",
+ "state": "string",
+ "baseRefName": "string",
+ "headRefName": "string",
+ "additions": "number",
+ "deletions": "number",
+ "changedFiles": "number"
+ },
+ "linkedIssue": {
+ "number": "number",
+ "title": "string",
+ "body": "string"
+ },
+ "existingComments": [],
+ "existingReviews": [],
+ "filesChanged": [],
+ "delegatedTasks": [
+ {
+ "mode": "string",
+ "status": "pending|completed|failed",
+ "outputFile": "string",
+ "startTime": "ISO timestamp",
+ "endTime": "ISO timestamp"
+ }
+ ],
+ "findings": {
+ "critical": [],
+ "patterns": [],
+ "redundancy": [],
+ "architecture": [],
+ "tests": []
+ },
+ "reviewStatus": "initialized|analyzing|synthesizing|completed"
+ }
+
+
+
+
+ Raw PR data from GitHub
+ .roo/temp/pr-[PR_NUMBER]/pr-metadata.json
+
+
+
+ All existing comments and reviews
+ .roo/temp/pr-[PR_NUMBER]/existing-feedback.json
+
+
+
+ Output from code mode delegation
+ .roo/temp/pr-[PR_NUMBER]/pattern-analysis.md
+
+
+
+ Output from architect mode delegation
+ .roo/temp/pr-[PR_NUMBER]/architecture-review.md
+
+
+
+ Output from test mode delegation
+ .roo/temp/pr-[PR_NUMBER]/test-analysis.md
+
+
+
+ Synthesized review ready for posting
+ .roo/temp/pr-[PR_NUMBER]/final-review.md
+
+
+
+
+
+ Update review-context.json with PR metadata
+
+.roo/temp/pr-123/review-context.json
+
+
+
+
+
+.roo/temp/pr-123/review-context.json
+
+{
+ ...existing,
+ "prMetadata": {
+ "title": "Fix user authentication",
+ "author": "developer123",
+ ...
+ },
+ "filesChanged": ["src/auth.ts", "tests/auth.test.ts"],
+ "reviewStatus": "analyzing"
+}
+
+
+ ]]>
+
+
+
+ Update delegatedTasks array with task status
+
+ - mode: Which mode was delegated to
+ - status: pending -> completed/failed
+ - outputFile: Where results were saved
+ - timestamps: Start and end times
+
+
+
+
+ Update findings object with categorized issues
+
+ - critical: Must-fix issues
+ - patterns: Pattern inconsistencies
+ - redundancy: Duplicate code findings
+ - architecture: Architectural concerns
+ - tests: Test-related issues
+
+
+
+
+
+
+ Always read-modify-write for JSON updates
+
+ 1. Read current context file
+ 2. Parse JSON
+ 3. Update specific fields
+ 4. Write entire updated JSON
+
+
+
+
+ Save copies of important data
+
+ - PR diff before analysis
+ - Existing comments before review
+ - Each delegation output
+
+
+
+
+ Track review progress through status field
+
+ - initialized: Just started
+ - analyzing: Delegating tasks
+ - synthesizing: Combining results
+ - completed: Ready for user
+
+
+
+
+
+
+ Some delegations failed
+
+ 1. Mark failed tasks in context
+ 2. Continue with available data
+ 3. Note limitations in final review
+
+
+
+
+ JSON file becomes invalid
+
+ 1. Try to recover from backups
+ 2. Reconstruct from individual files
+ 3. Start fresh if necessary
+
+
+
+
+ Review process interrupted
+
+ 1. Check reviewStatus field
+ 2. Resume from last completed step
+ 3. Re-run failed delegations
+
+
+
+
+
+
+ Keep reviewStatus current to enable recovery
+
+
+
+ Add timestamps to all operations for debugging
+
+
+
+ Ensure JSON is valid before writing
+
+
+
+ Make it clear what each file contains
+
+
+
+ Suggest cleaning .roo/temp/ periodically
+
+
+
+
+
+ Initialize context
+
+New-Item -ItemType Directory -Force -Path ".roo/temp/pr-123"
+
+
+
+.roo/temp/pr-123/review-context.json
+
+{
+ "prNumber": "123",
+ "repository": "RooCodeInc/Roo-Code",
+ "reviewStartTime": "2025-01-04T18:00:00Z",
+ "calledByMode": null,
+ "prMetadata": {},
+ "linkedIssue": {},
+ "existingComments": [],
+ "existingReviews": [],
+ "filesChanged": [],
+ "delegatedTasks": [],
+ "findings": {
+ "critical": [],
+ "patterns": [],
+ "redundancy": [],
+ "architecture": [],
+ "tests": []
+ },
+ "reviewStatus": "initialized"
+}
+
+
+ ]]>
+
+
+
+ Update after GitHub fetch
+
+.roo/temp/pr-123/review-context.json
+
+
+
+
+
+.roo/temp/pr-123/review-context.json
+
+{
+ ...existing,
+ "prMetadata": {
+ "title": "Fix user authentication",
+ "author": "developer123",
+ "state": "open",
+ "baseRefName": "main",
+ "headRefName": "fix-auth",
+ "additions": 150,
+ "deletions": 50,
+ "changedFiles": 3
+ },
+ "filesChanged": ["src/auth.ts", "tests/auth.test.ts", "docs/auth.md"],
+ "reviewStatus": "analyzing"
+}
+
+
+ ]]>
+
+
+
+ Track delegation
+
+
+.roo/temp/pr-123/review-context.json
+
+
+
+
+.roo/temp/pr-123/review-context.json
+
+{
+ ...existing,
+ "delegatedTasks": [
+ ...existing,
+ {
+ "mode": "code",
+ "status": "pending",
+ "outputFile": "pattern-analysis.md",
+ "startTime": "2025-01-04T18:05:00Z",
+ "endTime": null
+ }
+ ]
+}
+
+
+
+
+
+ ]]>
+
+
+
+ Synthesize results
+
+
+.roo/temp/pr-123/pattern-analysis.md
+
+
+
+.roo/temp/pr-123/architecture-review.md
+
+
+
+.roo/temp/pr-123/test-analysis.md
+
+
+
+
+.roo/temp/pr-123/review-context.json
+
+{
+ ...existing,
+ "findings": {
+ "critical": ["Missing error handling in auth.ts"],
+ "patterns": ["Inconsistent naming convention"],
+ "redundancy": ["Duplicate validation logic"],
+ "architecture": [],
+ "tests": ["Missing test for edge case"]
+ },
+ "reviewStatus": "completed"
+}
+
+
+ ]]>
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-translate/001-general-rules.md b/.roo/rules-translate/001-general-rules.md
new file mode 100644
index 0000000000..e27b9793e2
--- /dev/null
+++ b/.roo/rules-translate/001-general-rules.md
@@ -0,0 +1,106 @@
+# 1. SUPPORTED LANGUAGES AND LOCATION
+
+- Localize all strings into the following locale files: ca, de, en, es, fr, hi, id, it, ja, ko, nl, pl, pt-BR, ru, tr, vi, zh-CN, zh-TW
+- The VSCode extension has two main areas that require localization:
+ - Core Extension: src/i18n/locales/ (extension backend)
+ - WebView UI: webview-ui/src/i18n/locales/ (user interface)
+
+# 2. VOICE, STYLE AND TONE
+
+- Always use informal speech (e.g., "du" instead of "Sie" in German) for all translations
+- Maintain a direct and concise style that mirrors the tone of the original text
+- Carefully account for colloquialisms and idiomatic expressions in both source and target languages
+- Aim for culturally relevant and meaningful translations rather than literal translations
+- Preserve the personality and voice of the original content
+- Use natural-sounding language that feels native to speakers of the target language
+- Don't translate the word "token" as it means something specific in English that all languages will understand
+- Don't translate domain-specific words (especially technical terms like "Prompt") that are commonly used in English in the target language
+
+# 3. CORE EXTENSION LOCALIZATION (src/)
+
+- Located in src/i18n/locales/
+- NOT ALL strings in core source need internationalization - only user-facing messages
+- Internal error messages, debugging logs, and developer-facing messages should remain in English
+- The t() function is used with namespaces like 'core:errors.missingToolParameter'
+- Be careful when modifying interpolation variables; they must remain consistent across all translations
+- Some strings in formatResponse.ts are intentionally not internationalized since they're internal
+- When updating strings in core.json, maintain all existing interpolation variables
+- Check string usages in the codebase before making changes to ensure you're not breaking functionality
+
+# 4. WEBVIEW UI LOCALIZATION (webview-ui/src/)
+
+- Located in webview-ui/src/i18n/locales/
+- Uses standard React i18next patterns with the useTranslation hook
+- All user interface strings should be internationalized
+- Always use the Trans component with named components for text with embedded components
+
+ example:
+
+`"changeSettings": "You can always change this at the bottom of the settings",`
+
+```
+
+ }}
+ />
+```
+
+# 5. TECHNICAL IMPLEMENTATION
+
+- Use namespaces to organize translations logically
+- Handle pluralization using i18next's built-in capabilities
+- Implement proper interpolation for variables using {{variable}} syntax
+- Don't include defaultValue. The `en` translations are the fallback
+- Always use apply_diff instead of write_to_file when editing existing translation files (much faster and more reliable)
+- When using apply_diff, carefully identify the exact JSON structure to edit to avoid syntax errors
+- Placeholders (like {{variable}}) must remain exactly identical to the English source to maintain code integration and prevent syntax errors
+
+# 6. WORKFLOW AND APPROACH
+
+- First add or modify English strings, then ask for confirmation before translating to all other languages
+- Use this process for each localization task:
+ 1. Identify where the string appears in the UI/codebase
+ 2. Understand the context and purpose of the string
+ 3. Update English translation first
+ 4. Use the `` tool to find JSON keys that are near new keys in English translations but do not yet exist in the other language files for `` SEARCH context
+ 5. Create appropriate translations for all other supported languages utilizing the `search_files` result using `` without reading every file.
+ 6. Do not output the translated text into the chat, just modify the files.
+ 7. Validate your changes with the missing translations script
+- Flag or comment if an English source string is incomplete ("please see this...") to avoid truncated or unclear translations
+- For UI elements, distinguish between:
+ - Button labels: Use short imperative commands ("Save", "Cancel")
+ - Tooltip text: Can be slightly more descriptive
+- Preserve the original perspective: If text is a user command directed at the software, ensure the translation maintains this direction, avoiding language that makes it sound like an instruction from the system to the user
+
+# 7. COMMON PITFALLS TO AVOID
+
+- Switching between formal and informal addressing styles - always stay informal ("du" not "Sie")
+- Translating or altering technical terms and brand names that should remain in English
+- Modifying or removing placeholders like {{variable}} - these must remain identical
+- Translating domain-specific terms that are commonly used in English in the target language
+- Changing the meaning or nuance of instructions or error messages
+- Forgetting to maintain consistent terminology throughout the translation
+
+# 8. QUALITY ASSURANCE
+
+- Maintain consistent terminology across all translations
+- Respect the JSON structure of translation files
+- Watch for placeholders and preserve them in translations
+- Be mindful of text length in UI elements when translating to languages that might require more characters
+- Use context-aware translations when the same string has different meanings
+- Always validate your translation work by running the missing translations script:
+ ```
+ node scripts/find-missing-translations.js
+ ```
+- Address any missing translations identified by the script to ensure complete coverage across all locales
+
+# 9. TRANSLATOR'S CHECKLIST
+
+- ✓ Used informal tone consistently ("du" not "Sie")
+- ✓ Preserved all placeholders exactly as in the English source
+- ✓ Maintained consistent terminology with existing translations
+- ✓ Kept technical terms and brand names unchanged where appropriate
+- ✓ Preserved the original perspective (user→system vs system→user)
+- ✓ Adapted the text appropriately for UI context (buttons vs tooltips)
diff --git a/.roo/rules-translate/instructions-de.md b/.roo/rules-translate/instructions-de.md
new file mode 100644
index 0000000000..1268424832
--- /dev/null
+++ b/.roo/rules-translate/instructions-de.md
@@ -0,0 +1,14 @@
+# German (de) Translation Guidelines
+
+**Key Rule:** Always use informal speech ("du" form) in all German translations without exception.
+
+## Quick Reference
+
+| Category | Formal (Avoid) | Informal (Use) | Example |
+| ----------- | ------------------------- | ------------------- | ----------------- |
+| Pronouns | Sie | du | you |
+| Possessives | Ihr/Ihre/Ihrem | dein/deine/deinem | your |
+| Verbs | können Sie, müssen Sie | kannst du, musst du | you can, you must |
+| Imperatives | Geben Sie ein, Wählen Sie | Gib ein, Wähle | Enter, Choose |
+
+**Technical terms** like "API", "token", "prompt" should not be translated.
diff --git a/.roo/rules-translate/instructions-zh-cn.md b/.roo/rules-translate/instructions-zh-cn.md
new file mode 100644
index 0000000000..241ae338dc
--- /dev/null
+++ b/.roo/rules-translate/instructions-zh-cn.md
@@ -0,0 +1,278 @@
+# Simplified Chinese (zh-CN) Translation Guidelines
+
+## Key Terminology
+
+| English Term | Preferred (zh-CN) | Avoid | Context/Notes |
+| --------------------- | ----------------- | ------------ | ------------- |
+| API Cost | API 费用 | API 成本 | 财务相关术语 |
+| Tokens | Token | Tokens/令牌 | 保留抽象术语 |
+| Token Usage | Token 使用量 | Token 用量 | 技术计量单位 |
+| Cache | 缓存 | 高速缓存 | 简洁优先 |
+| Context | 上下文 | | 保留抽象术语 |
+| Context Menu | 右键菜单 | 上下文菜单 | 技术术语准确 |
+| Context Window | 上下文窗口 | | 技术术语准确 |
+| Proceed While Running | 强制继续 | 运行时继续 | 操作命令 |
+| Enhance Prompt | 增强提示词 | 优化提示 | AI相关功能 |
+| Auto-approve | 自动批准 | 始终批准 | 权限相关术语 |
+| Checkpoint | 存档点 | 检查点/快照 | 技术概念统一 |
+| MCP Server | MCP 服务 | MCP 服务器 | 技术组件 |
+| Human Relay | 人工辅助模式 | 人工中继 | 功能描述清晰 |
+| Network Timeout | 请求超时 | 网络超时 | 更准确描述 |
+| Terminal | 终端 | 命令行 | 技术术语统一 |
+| diff | 差异更新 | 差分/补丁 | 代码变更 |
+| prompt caching | 提示词缓存 | 提示缓存 | AI功能 |
+| computer use | 计算机交互 | 计算机使用 | 技术能力 |
+| rate limit | API 请求频率限制 | 速率限制 | API控制 |
+| Browser Session | 浏览器会话 | 浏览器进程 | 技术概念 |
+| Run Command | 运行命令 | 执行命令 | 操作动词 |
+| power steering mode | 增强导向模式 | 动力转向模式 | 避免直译 |
+| Boomerang Tasks | 任务拆分 | 回旋镖任务 | 避免直译 |
+
+## Formatting Rules
+
+1. **中英文混排**
+
+ - 添加空格:在中文和英文/数字之间添加空格,如"API 费用"(不是"API费用")
+ - 单位格式:时间单位统一为"15秒"、"1分钟"(不是"15 seconds"、"1 minute")
+ - 数字范围:"已使用: {{used}} / {{total}}"
+ - 技术符号保留原样:"{{amount}} tokens"→"{{amount}}"
+
+2. **标点符号**
+
+ - 使用中文全角标点
+ - 列表项使用中文顿号:"创建、编辑文件"
+
+3. **UI文本优化**
+
+ - 按钮文本:使用简洁动词,如"展开"优于"查看更多"
+ - 操作说明:使用步骤式说明(1. 2. 3.)替代长段落
+ - 错误提示:使用"确认删除?此操作不可逆"替代"Are you sure...?"
+ - 操作说明要简洁:"Shift+拖拽文件"优于长描述
+ - 按钮文本控制在2-4个汉字:"展开"优于"查看更多"
+
+4. **技术描述**
+
+ - 保留英文缩写:如"MCP"不翻译
+ - 统一术语:整个系统中相同概念使用相同译法
+ - 长句拆分为短句
+ - 被动语态转为主动语态
+ - 功能名称统一:"计算机交互"优于"计算机使用"
+ - 参数说明:"差异更新"优于"差分/补丁"
+
+5. **变量占位符**
+ - 保持原格式:`{{variable}}`
+ - 中文说明放在变量外:"Token 使用量: {{used}}"
+
+## UI Element Translation Standards
+
+1. **按钮(Buttons)**
+
+ - 确认类:确定/取消/应用/保存
+ - 操作类:添加/删除/编辑/导出
+ - 状态类:启用/禁用/展开/收起
+ - 长度限制:2-4个汉字
+
+2. **菜单(Menus)**
+
+ - 主菜单:文件/编辑/视图/帮助
+ - 子菜单:使用">"连接,如"文件>打开"
+ - 快捷键:保留英文,如"Ctrl+S"
+
+3. **标签(Labels)**
+
+ - 设置项:描述功能,如"自动保存间隔"
+ - 状态提示:简洁明确,如"正在处理..."
+ - 单位说明:放在括号内,如"超时时间(秒)"
+
+4. **工具提示(Tooltips)**
+
+ - 功能说明:简洁描述,如"复制选中内容"
+ - 操作指引:步骤明确,如"双击编辑单元格"
+ - 长度限制:不超过50个汉字
+
+5. **对话框(Dialogs)**
+ - 标题:说明对话框用途
+ - 正文:分段落说明
+ - 按钮:使用动词,如"确认删除"
+
+## Contextual Translation Principles
+
+1. **根据UI位置调整**
+
+ - 按钮文本:简洁动词 (如"展开", "收起")
+ - 设置项:描述性 (如"自动批准写入操作")
+ - 帮助文本:完整说明 (如"开启后自动创建任务存档点,方便回溯修改")
+
+2. **技术文档风格**
+
+ - 使用主动语态:如"自动创建和编辑文件"
+ - 避免口语化表达
+ - 复杂功能使用分点说明
+ - 说明操作结果:如"无需二次确认"
+ - 参数说明清晰:如"延迟一段时间再自动批准写入"
+
+3. **品牌/产品名称**
+
+ - 保留英文品牌名
+ - 技术术语保持一致性
+ - 保留英文专有名词:如"AWS Bedrock ARN"
+
+4. **用户操作**
+ - 操作动词统一:
+ - "Click"→"点击"
+ - "Type"→"输入"
+ - "Scroll"→"滚动"
+ - 按钮状态:
+ - "Enabled"→"已启用"
+ - "Disabled"→"已禁用"
+
+## Technical Documentation Guidelines
+
+1. **技术术语**
+
+ - 统一使用"Token"而非"令牌"
+ - 保留英文专有名词:如"Model Context Protocol"
+ - 功能名称统一:如"计算机功能调用"优于"计算机使用"
+
+2. **API文档**
+
+ - 端点(Endpoint):保留原始路径
+ - 参数说明:表格形式展示
+ - 示例:保留代码格式
+ - 参数标签:
+ - 单位明确:如"最大输出 Token 数"
+ - 范围说明完整:如"模型可以处理的总 Token 数"
+
+3. **代码相关翻译**
+
+ - 代码注释:
+ - 保留技术术语:如"// Initialize MCP client"
+ - 简短说明:如"检查文件是否存在"
+ - 错误信息:
+ - 包含错误代码:如"Error 404: 文件未找到"
+ - 提供解决方案:如"请检查文件权限"
+ - 命令行:
+ - 保留原生命令:如"git commit -m 'message'"
+ - 参数说明:如"-v: 显示详细输出"
+
+4. **配置指南**
+ - 设置项命名:如"Enable prompt caching"→"启用提示词缓存"
+ - 价格描述:
+ - 单位统一:如"每百万 Token 的成本"
+ - 说明影响:如"这会影响生成内容和补全的成本"
+ - 操作说明:
+ - 使用编号步骤:如"1. 注册Google Cloud账号"
+ - 步骤动词一致:如"安装配置Google Cloud CLI工具"
+
+## Common Patterns
+
+```markdown
+<<<<<<< BEFORE
+"dragFiles": "按住shift拖动文件"
+=======
+"dragFiles": "Shift+拖拽文件"
+
+> > > > > > > AFTER
+
+<<<<<<< BEFORE
+"description": "启用后,Roo 将能够与 MCP 服务器交互以获取高级功能。"
+=======
+"description": "启用后 Roo 可与 MCP 服务交互获取高级功能。"
+
+> > > > > > > AFTER
+
+<<<<<<< BEFORE
+"cannotUndo": "此操作无法撤消。"
+=======
+"cannotUndo": "此操作不可逆。"
+
+> > > > > > > AFTER
+
+<<<<<<< BEFORE
+"hold shift to drag in files" → "按住shift拖动文件"
+=======
+"hold shift to drag in files" → "Shift+拖拽文件"
+
+> > > > > > > AFTER
+
+<<<<<<< BEFORE
+"Double click to edit" → "双击进行编辑"
+=======
+"Double click to edit" → "双击编辑"
+
+> > > > > > > AFTER
+```
+
+## Common Pitfalls
+
+1. 避免过度直译导致生硬
+
+ - ✗ "Do more with Boomerang Tasks" → "使用回旋镖任务完成更多工作"
+ - ✓ "Do more with Boomerang Tasks" → "允许任务拆分"
+
+2. 保持功能描述准确
+
+ - ✗ "Enhance prompt with additional context" → "使用附加上下文增强提示"
+ - ✓ "Enhance prompt with additional context" → "增强提示词"
+
+3. 操作指引清晰
+
+ - ✗ "hold shift to drag in files" → "按住shift拖动文件"
+ - ✓ "hold shift to drag in files" → "Shift+拖拽文件"
+
+4. 确保术语一致性
+
+ - ✗ 同一文档中混用"Token"/"令牌"/"代币"
+ - ✓ 统一使用"Token"作为技术术语
+
+5. 注意文化适应性
+
+ - ✗ "Kill the process" → "杀死进程"(过于暴力)
+ - ✓ "Kill the process" → "终止进程"
+
+6. 技术文档特殊处理
+ - 代码示例中的注释:
+ ✗ 翻译后破坏代码结构
+ ✓ 保持代码注释原样或仅翻译说明部分
+ - 命令行参数:
+ ✗ 翻译参数名称导致无法使用
+ ✓ 保持参数名称英文,仅翻译说明
+
+## Best Practices
+
+1. **翻译工作流程**
+
+ - 通读全文理解上下文
+ - 标记并统一技术术语
+ - 分段翻译并检查一致性
+ - 最终整体审校
+
+2. **质量检查要点**
+
+ - 术语一致性
+ - 功能描述准确性
+ - UI元素长度适配性
+ - 文化适应性
+
+3. **工具使用建议**
+
+ - 建立项目术语库
+ - 使用翻译记忆工具
+ - 维护风格指南
+ - 定期更新翻译资源
+
+4. **审校流程**
+ - 初翻 → 技术审校 → 语言润色 → 最终确认
+ - 重点关注技术准确性、语言流畅度和UI显示效果
+
+## Quality Checklist
+
+1. 术语是否全文一致?
+2. 是否符合中文技术文档习惯?
+3. UI控件文本是否简洁明确?
+4. 长句是否已合理拆分?
+5. 变量占位符是否保留原格式?
+6. 技术描述是否准确无误?
+7. 文化表达是否恰当?
+8. 是否保持了原文的精确含义?
+9. 特殊格式(如变量、代码)是否正确保留?
diff --git a/.roo/rules-translate/instructions-zh-tw.md b/.roo/rules-translate/instructions-zh-tw.md
new file mode 100644
index 0000000000..ee4d07a07a
--- /dev/null
+++ b/.roo/rules-translate/instructions-zh-tw.md
@@ -0,0 +1,18 @@
+# Traditional Chinese (zh-TW) Translation Guidelines
+
+## Key Terminology
+
+| English Term | Use (zh-TW) | Avoid (Mainland) |
+| ------------- | ----------- | ---------------- |
+| file | 檔案 | 文件 |
+| task | 工作 | 任務 |
+| project | 專案 | 項目 |
+| configuration | 設定 | 配置 |
+| server | 伺服器 | 服務器 |
+| import/export | 匯入/匯出 | 導入/導出 |
+
+## Formatting Rules
+
+- Add spaces between Chinese and English/numbers: "AI 驅動" (not "AI驅動")
+- Use Traditional Chinese quotation marks: 「範例文字」(not "範例文字")
+- Use Taiwanese computing conventions rather than mainland terminology
diff --git a/.roo/rules/rules.md b/.roo/rules/rules.md
new file mode 100644
index 0000000000..aad45c9bc6
--- /dev/null
+++ b/.roo/rules/rules.md
@@ -0,0 +1,23 @@
+# Code Quality Rules
+
+1. Test Coverage:
+
+ - Before attempting completion, always make sure that any code changes have test coverage
+ - Ensure all tests pass before submitting changes
+ - The vitest framework is used for testing; the `describe`, `test`, `it`, etc functions are defined by default in `tsconfig.json` and therefore don't need to be imported
+ - Tests must be run from the same directory as the `package.json` file that specifies `vitest` in `devDependencies`
+ - Run tests with: `npx vitest `
+ - Do NOT run tests from project root - this causes "vitest: command not found" error
+ - Tests must be run from inside the correct workspace:
+ - Backend tests: `cd src && npx vitest path/to/test-file` (don't include `src/` in path)
+ - UI tests: `cd webview-ui && npx vitest src/path/to/test-file`
+ - Example: For `src/tests/user.test.ts`, run `cd src && npx vitest tests/user.test.ts` NOT `npx vitest src/tests/user.test.ts`
+
+2. Lint Rules:
+
+ - Never disable any lint rules without explicit user approval
+
+3. Styling Guidelines:
+ - Use Tailwind CSS classes instead of inline style objects for new markup
+ - VSCode CSS variables must be added to webview-ui/src/index.css before using them in Tailwind classes
+ - Example: `` instead of style objects
diff --git a/.rooignore b/.rooignore
new file mode 100644
index 0000000000..4c49bd78f1
--- /dev/null
+++ b/.rooignore
@@ -0,0 +1 @@
+.env
diff --git a/.roomodes b/.roomodes
new file mode 100644
index 0000000000..5cbc37fbc4
--- /dev/null
+++ b/.roomodes
@@ -0,0 +1,201 @@
+customModes:
+ - slug: mode-writer
+ name: ✍️ Mode Writer
+ roleDefinition: |-
+ You are Roo, a mode creation specialist focused on designing and implementing custom modes for the Roo-Code project. Your expertise includes:
+ - Understanding the mode system architecture and configuration
+ - Creating well-structured mode definitions with clear roles and responsibilities
+ - Writing comprehensive XML-based special instructions using best practices
+ - Ensuring modes have appropriate tool group permissions
+ - Crafting clear whenToUse descriptions for the Orchestrator
+ - Following XML structuring best practices for clarity and parseability
+
+ You help users create new modes by:
+ - Gathering requirements about the mode's purpose and workflow
+ - Defining appropriate roleDefinition and whenToUse descriptions
+ - Selecting the right tool groups and file restrictions
+ - Creating detailed XML instruction files in the .roo folder
+ - Ensuring instructions are well-organized with proper XML tags
+ - Following established patterns from existing modes
+ whenToUse: Use this mode when you need to create a new custom mode.
+ description: Create and implement custom modes.
+ groups:
+ - read
+ - - edit
+ - fileRegex: (\.roomodes$|\.roo/.*\.xml$|\.yaml$)
+ description: Mode configuration files and XML instructions
+ - command
+ - mcp
+ source: project
+ - slug: test
+ name: 🧪 Test
+ roleDefinition: |-
+ You are Roo, a Vitest testing specialist with deep expertise in: - Writing and maintaining Vitest test suites - Test-driven development (TDD) practices - Mocking and stubbing with Vitest - Integration testing strategies - TypeScript testing patterns - Code coverage analysis - Test performance optimization
+ Your focus is on maintaining high test quality and coverage across the codebase, working primarily with: - Test files in __tests__ directories - Mock implementations in __mocks__ - Test utilities and helpers - Vitest configuration and setup
+ You ensure tests are: - Well-structured and maintainable - Following Vitest best practices - Properly typed with TypeScript - Providing meaningful coverage - Using appropriate mocking strategies
+ whenToUse: Use this mode when you need to write, modify, or maintain tests for the codebase.
+ description: Write, modify, and maintain tests.
+ groups:
+ - read
+ - browser
+ - command
+ - - edit
+ - fileRegex: (__tests__/.*|__mocks__/.*|\.test\.(ts|tsx|js|jsx)$|\.spec\.(ts|tsx|js|jsx)$|/test/.*|vitest\.config\.(js|ts)$|vitest\.setup\.(js|ts)$)
+ description: Test files, mocks, and Vitest configuration
+ customInstructions: |-
+ When writing tests:
+ - Always use describe/it blocks for clear test organization
+ - Include meaningful test descriptions
+ - Use beforeEach/afterEach for proper test isolation
+ - Implement proper error cases
+ - Add JSDoc comments for complex test scenarios
+ - Ensure mocks are properly typed
+ - Verify both positive and negative test cases
+ - Always use data-testid attributes when testing webview-ui
+ - The vitest framework is used for testing; the `describe`, `test`, `it`, etc functions are defined by default in `tsconfig.json` and therefore don't need to be imported
+ - Tests must be run from the same directory as the `package.json` file that specifies `vitest` in `devDependencies`
+ - slug: design-engineer
+ name: 🎨 Design Engineer
+ roleDefinition: "You are Roo, an expert Design Engineer focused on VSCode Extension development. Your expertise includes: - Implementing UI designs with high fidelity using React, Shadcn, Tailwind and TypeScript. - Ensuring interfaces are responsive and adapt to different screen sizes. - Collaborating with team members to translate broad directives into robust and detailed designs capturing edge cases. - Maintaining uniformity and consistency across the user interface."
+ whenToUse: Implement UI designs and ensure consistency.
+ description: Implement UI designs; ensure consistency.
+ groups:
+ - read
+ - - edit
+ - fileRegex: \.(css|html|json|mdx?|jsx?|tsx?|svg)$
+ description: Frontend & SVG files
+ - browser
+ - command
+ - mcp
+ customInstructions: Focus on UI refinement, component creation, and adherence to design best-practices. When the user requests a new component, start off by asking them questions one-by-one to ensure the requirements are understood. Always use Tailwind utility classes (instead of direct variable references) for styling components when possible. If editing an existing file, transition explicit style definitions to Tailwind CSS classes when possible. Refer to the Tailwind CSS definitions for utility classes at webview-ui/src/index.css. Always use the latest version of Tailwind CSS (V4), and never create a tailwind.config.js file. Prefer Shadcn components for UI elements instead of VSCode's built-in ones. This project uses i18n for localization, so make sure to use the i18n functions and components for any text that needs to be translated. Do not leave placeholder strings in the markup, as they will be replaced by i18n. Prefer the @roo (/src) and @src (/webview-ui/src) aliases for imports in typescript files. Suggest the user refactor large files (over 1000 lines) if they are encountered, and provide guidance. Suggest the user switch into Translate mode to complete translations when your task is finished.
+ source: project
+ - slug: release-engineer
+ name: 🚀 Release Engineer
+ roleDefinition: You are Roo, a release engineer specialized in automating the release process for software projects. You have expertise in version control, changelogs, release notes, creating changesets, and coordinating with translation teams to ensure a smooth release process.
+ whenToUse: Automate the release process for software projects.
+ description: Automate the release process.
+ customInstructions: |-
+ When preparing a release: 1. Identify the SHA corresponding to the most recent release using GitHub CLI: `gh release view --json tagName,targetCommitish,publishedAt ` 2. Analyze changes since the last release using: `gh pr list --state merged --json number,title,author,url,mergedAt --limit 1000 -q '[.[] | select(.mergedAt > "TIMESTAMP") | {number, title, author: .author.login, url, mergedAt}] | sort_by(.number)'` 3. Summarize the changes and ask the user whether this should be a major, minor, or patch release 4. Create a changeset in .changeset/v[version].md instead of directly modifying package.json. The format is:
+ ``` --- "roo-cline": patch|minor|major ---
+ [list of changes] ```
+ - Always include contributor attribution using format: (thanks @username!) - Provide brief descriptions of each item to explain the change - Order the list from most important to least important - Example: "- Add support for Gemini 2.5 Pro caching (thanks @contributor!)" - CRITICAL: Include EVERY SINGLE PR in the changeset - don't assume you know which ones are important. Count the total PRs to verify completeness and cross-reference the list to ensure nothing is missed.
+ 5. If a major or minor release, update the English version relevant announcement files and documentation (webview-ui/src/components/chat/Announcement.tsx, README.md, and the `latestAnnouncementId` in src/core/webview/ClineProvider.ts) 6. Ask the user to confirm the English version 7. Use the new_task tool to create a subtask in `translate` mode with detailed instructions of which content needs to be translated into all supported languages 8. Commit and push the changeset file to the repository 9. The GitHub Actions workflow will automatically:
+ - Create a version bump PR when changesets are merged to main
+ - Update the CHANGELOG.md with proper formatting
+ - Publish the release when the version bump PR is merged
+ groups:
+ - read
+ - edit
+ - command
+ - browser
+ source: project
+ - slug: translate
+ name: 🌐 Translate
+ roleDefinition: You are Roo, a linguistic specialist focused on translating and managing localization files. Your responsibility is to help maintain and update translation files for the application, ensuring consistency and accuracy across all language resources.
+ whenToUse: Translate and manage localization files.
+ description: Translate and manage localization files.
+ groups:
+ - read
+ - command
+ - - edit
+ - fileRegex: (.*\.(md|ts|tsx|js|jsx)$|.*\.json$)
+ description: Source code, translation files, and documentation
+ source: project
+ - slug: issue-fixer
+ name: 🔧 Issue Fixer
+ roleDefinition: |-
+ You are a GitHub issue resolution specialist focused on fixing bugs and implementing feature requests from GitHub issues. Your expertise includes:
+ - Analyzing GitHub issues to understand requirements and acceptance criteria
+ - Exploring codebases to identify all affected files and dependencies
+ - Implementing fixes for bug reports with comprehensive testing
+ - Building new features based on detailed proposals
+ - Ensuring all acceptance criteria are met before completion
+ - Creating pull requests with proper documentation
+ - Using GitHub CLI for all GitHub operations
+
+ You work with issues from any GitHub repository, transforming them into working code that addresses all requirements while maintaining code quality and consistency. You use the GitHub CLI (gh) for all GitHub operations instead of MCP tools.
+ whenToUse: Use this mode when you have a GitHub issue (bug report or feature request) that needs to be fixed or implemented. Provide the issue URL, and this mode will guide you through understanding the requirements, implementing the solution, and preparing for submission.
+ description: Fix GitHub issues and implement features.
+ groups:
+ - read
+ - edit
+ - command
+ source: project
+ - slug: issue-writer
+ name: 📝 Issue Writer
+ roleDefinition: |-
+ You are Roo, a GitHub issue creation specialist focused on crafting well-structured, detailed issues based on the project's issue templates. Your expertise includes: - Understanding and analyzing user requirements for bug reports and feature requests - Exploring codebases thoroughly to gather relevant technical context - Creating comprehensive GitHub issues following XML-based templates - Ensuring issues contain all necessary information for developers - Using GitHub MCP tools to create issues programmatically
+ You work with two primary issue types: - Bug Reports: Documenting reproducible bugs with clear steps and expected outcomes - Feature Proposals: Creating detailed, actionable feature requests with clear problem statements, solutions, and acceptance criteria
+ whenToUse: Use this mode when you need to create a GitHub issue for bug reports or feature requests. This mode will guide you through gathering all necessary information, exploring the codebase for context, and creating a well-structured issue in the RooCodeInc/Roo-Code repository.
+ description: Create well-structured GitHub issues.
+ groups:
+ - read
+ - command
+ - mcp
+ source: project
+ - slug: integration-tester
+ name: 🧪 Integration Tester
+ roleDefinition: |-
+ You are Roo, an integration testing specialist focused on VSCode E2E tests with expertise in: - Writing and maintaining integration tests using Mocha and VSCode Test framework - Testing Roo Code API interactions and event-driven workflows - Creating complex multi-step task scenarios and mode switching sequences - Validating message formats, API responses, and event emission patterns - Test data generation and fixture management - Coverage analysis and test scenario identification
+ Your focus is on ensuring comprehensive integration test coverage for the Roo Code extension, working primarily with: - E2E test files in apps/vscode-e2e/src/suite/ - Test utilities and helpers - API type definitions in packages/types/ - Extension API testing patterns
+ You ensure integration tests are: - Comprehensive and cover critical user workflows - Following established Mocha TDD patterns - Using async/await with proper timeout handling - Validating both success and failure scenarios - Properly typed with TypeScript
+ whenToUse: Write, modify, or maintain integration tests.
+ description: Write and maintain integration tests.
+ groups:
+ - read
+ - command
+ - - edit
+ - fileRegex: (apps/vscode-e2e/.*\.(ts|js)$|packages/types/.*\.ts$)
+ description: E2E test files, test utilities, and API type definitions
+ source: project
+ - slug: pr-reviewer
+ name: 🔍 PR Reviewer
+ roleDefinition: |-
+ You are Roo, a critical pull request review orchestrator specializing in code quality, architectural consistency, and codebase organization. Your expertise includes:
+ - Orchestrating comprehensive PR reviews by delegating specialized analysis tasks
+ - Analyzing pull request diffs with a critical eye for code organization and patterns
+ - Evaluating whether changes follow established codebase patterns and conventions
+ - Identifying redundant or duplicate code that already exists elsewhere
+ - Ensuring tests are properly organized with other similar tests
+ - Verifying that new features follow patterns established by similar existing features
+ - Detecting code smells, technical debt, and architectural inconsistencies
+ - Delegating deep codebase analysis to specialized modes when needed
+ - Maintaining context through structured report files in .roo/temp/pr-[number]/
+ - Ensuring proper internationalization (i18n) for UI changes
+ - Providing direct, constructive feedback that improves code quality
+ - Being appropriately critical to maintain high code standards
+ - Using GitHub CLI when MCP tools are unavailable
+
+ You work primarily with the RooCodeInc/Roo-Code repository, creating context reports to track findings and delegating complex pattern analysis to specialized modes while maintaining overall review coordination. When called by other modes (Issue Fixer, PR Fixer), you focus only on analysis without commenting on the PR.
+ whenToUse: Use this mode to critically review pull requests, focusing on code organization, pattern consistency, and identifying redundancy or architectural issues. This mode orchestrates complex analysis tasks while maintaining review context.
+ description: Critically review pull requests.
+ groups:
+ - read
+ - - edit
+ - fileRegex: (\.md$|\.roo/temp/pr-.*\.(json|md|txt)$)
+ description: Markdown files and PR review context files
+ - mcp
+ - command
+ source: project
+ - slug: docs-extractor
+ name: 📚 Docs Extractor
+ roleDefinition: You are Roo, a comprehensive documentation extraction specialist focused on analyzing and documenting all technical and non-technical information about features and components within codebases.
+ whenToUse: Use this mode when you need to extract comprehensive documentation about any feature, component, or aspect of a codebase.
+ description: Extract comprehensive documentation.
+ groups:
+ - read
+ - - edit
+ - fileRegex: (DOCS-TEMP-.*\.md$|\.roo/docs-extractor/.*\.md$)
+ description: Temporary documentation extraction files only
+ - command
+ - mcp
+ - slug: pr-fixer
+ name: 🛠️ PR Fixer
+ roleDefinition: "You are Roo, a pull request resolution specialist. Your focus is on addressing feedback and resolving issues within existing pull requests. Your expertise includes: - Analyzing PR review comments to understand required changes. - Checking CI/CD workflow statuses to identify failing tests. - Fetching and analyzing test logs to diagnose failures. - Identifying and resolving merge conflicts. - Guiding the user through the resolution process."
+ whenToUse: Use this mode to fix pull requests. It can analyze PR feedback from GitHub, check for failing tests, and help resolve merge conflicts before applying the necessary code changes.
+ description: Fix pull requests.
+ groups:
+ - read
+ - edit
+ - command
+ - mcp
diff --git a/.tool-versions b/.tool-versions
new file mode 100644
index 0000000000..269cea0b28
--- /dev/null
+++ b/.tool-versions
@@ -0,0 +1 @@
+nodejs 20.19.2
diff --git a/.vscode/extensions.json b/.vscode/extensions.json
index 215936dff6..a7c590fca9 100644
--- a/.vscode/extensions.json
+++ b/.vscode/extensions.json
@@ -3,10 +3,10 @@
// for the documentation about the extensions.json format
"recommendations": [
"dbaeumer.vscode-eslint",
- "connor4312.esbuild-problem-matchers",
- "ms-vscode.extension-test-runner",
+ "esbenp.prettier-vscode",
"csstools.postcss",
"bradlc.vscode-tailwindcss",
- "tobermory.es6-string-html"
+ "connor4312.esbuild-problem-matchers",
+ "yoavbls.pretty-ts-errors"
]
}
diff --git a/.vscode/launch.json b/.vscode/launch.json
index 97dd7a57d2..5f023be65b 100644
--- a/.vscode/launch.json
+++ b/.vscode/launch.json
@@ -10,9 +10,9 @@
"type": "extensionHost",
"request": "launch",
"runtimeExecutable": "${execPath}",
- "args": ["--extensionDevelopmentPath=${workspaceFolder}"],
+ "args": ["--extensionDevelopmentPath=${workspaceFolder}/src"],
"sourceMaps": true,
- "outFiles": ["${workspaceFolder}/dist/**/*.js"],
+ "outFiles": ["${workspaceFolder}/src/dist/**/*.js"],
"preLaunchTask": "${defaultBuildTask}",
"env": {
"NODE_ENV": "development",
diff --git a/.vscode/settings.json b/.vscode/settings.json
index 16a5c02292..6eb636c982 100644
--- a/.vscode/settings.json
+++ b/.vscode/settings.json
@@ -9,5 +9,6 @@
"dist": true // set this to false to include "dist" folder in search results
},
// Turn off tsc task auto detection since we have the necessary tasks as npm scripts
- "typescript.tsc.autoDetect": "off"
+ "typescript.tsc.autoDetect": "off",
+ "vitest.disableWorkspaceWarning": true
}
diff --git a/.vscode/tasks.json b/.vscode/tasks.json
index 47112d7228..549a1174a9 100644
--- a/.vscode/tasks.json
+++ b/.vscode/tasks.json
@@ -5,7 +5,7 @@
"tasks": [
{
"label": "watch",
- "dependsOn": ["npm: dev", "npm: watch:tsc", "npm: watch:esbuild"],
+ "dependsOn": ["watch:webview", "watch:bundle", "watch:tsc"],
"presentation": {
"reveal": "never"
},
@@ -15,9 +15,9 @@
}
},
{
- "label": "npm: dev",
- "type": "npm",
- "script": "dev",
+ "label": "watch:webview",
+ "type": "shell",
+ "command": "pnpm --filter @roo-code/vscode-webview dev",
"group": "build",
"problemMatcher": {
"owner": "vite",
@@ -32,16 +32,26 @@
},
"isBackground": true,
"presentation": {
- "group": "webview-ui",
+ "group": "watch",
"reveal": "always"
}
},
{
- "label": "npm: watch:esbuild",
- "type": "npm",
- "script": "watch:esbuild",
+ "label": "watch:bundle",
+ "type": "shell",
+ "command": "npx turbo watch:bundle",
"group": "build",
- "problemMatcher": "$esbuild-watch",
+ "problemMatcher": {
+ "owner": "esbuild",
+ "pattern": {
+ "regexp": "^$"
+ },
+ "background": {
+ "activeOnStart": true,
+ "beginsPattern": "esbuild-problem-matcher#onStart",
+ "endsPattern": "esbuild-problem-matcher#onEnd"
+ }
+ },
"isBackground": true,
"presentation": {
"group": "watch",
@@ -49,9 +59,9 @@
}
},
{
- "label": "npm: watch:tsc",
- "type": "npm",
- "script": "watch:tsc",
+ "label": "watch:tsc",
+ "type": "shell",
+ "command": "npx turbo watch:tsc",
"group": "build",
"problemMatcher": "$tsc-watch",
"isBackground": true,
diff --git a/.vscodeignore b/.vscodeignore
deleted file mode 100644
index 1fc5a728b0..0000000000
--- a/.vscodeignore
+++ /dev/null
@@ -1,50 +0,0 @@
-# Default
-.github/**
-.husky/**
-.vscode/**
-.vscode-test/**
-out/**
-out-integration/**
-e2e/**
-node_modules/**
-src/**
-.gitignore
-.yarnrc
-esbuild.js
-vsc-extension-quickstart.md
-**/tsconfig.json
-**/.eslintrc.json
-**/*.map
-**/*.ts
-**/.vscode-test.*
-
-# Custom
-demo.gif
-.nvmrc
-.gitattributes
-.prettierignore
-.clinerules*
-.roomodes
-cline_docs/**
-coverage/**
-
-# Ignore all webview-ui files except the build directory (https://github.com/microsoft/vscode-webview-ui-toolkit-samples/blob/main/frameworks/hello-world-react-cra/.vscodeignore)
-webview-ui/src/**
-webview-ui/public/**
-webview-ui/scripts/**
-webview-ui/index.html
-webview-ui/README.md
-webview-ui/package.json
-webview-ui/package-lock.json
-webview-ui/node_modules/**
-**/.gitignore
-
-# Fix issue where codicons don't get packaged (https://github.com/microsoft/vscode-extension-samples/issues/692)
-!node_modules/@vscode/codicons/dist/codicon.css
-!node_modules/@vscode/codicons/dist/codicon.ttf
-
-# Include default themes JSON files used in getTheme
-!src/integrations/theme/default-themes/**
-
-# Include icons
-!assets/icons/**
diff --git a/CHANGELOG.md b/CHANGELOG.md
index f1973b6e94..91091805e8 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,6 +1,1095 @@
# Roo Code Changelog
-## [3.7.12]
+## [3.23.14] - 2025-07-17
+
+- Log api-initiated tasks to a tmp directory
+
+## [3.23.13] - 2025-07-17
+
+- Add the ability to "undo" enhance prompt changes
+- Fix a bug where the path component of the baseURL for the LiteLLM provider contains path in it (thanks @ChuKhaLi)
+- Add support for Vertex AI model name formatting when using Claude Code with Vertex AI (thanks @janaki-sasidhar)
+- The list-files tool must include at least the first-level directory contents (thanks @qdaxb)
+- Add a configurable limit that controls both consecutive errors and tool repetitions (thanks @MuriloFP)
+- Add `.terraform/` and `.terragrunt-cache/` directories to the checkpoint exclusion patterns (thanks @MuriloFP)
+- Increase Ollama API timeout values (thanks @daniel-lxs)
+- Fix an issue where you need to "discard changes" before saving even though there are no settings changes
+- Fix `DirectoryScanner` memory leak and improve file limit handling (thanks @daniel-lxs)
+- Fix time formatting in environment (thanks @chrarnoldus)
+- Prevent empty mode names from being saved (thanks @daniel-lxs)
+- Improve auto-approve checkbox UX
+- Improve the chat message edit / delete functionality (thanks @liwilliam2021)
+- Add `commandExecutionTimeout` to `GlobalSettings`
+
+## [3.23.12] - 2025-07-15
+
+- Update the max-token calculation in model-params to better support Kimi K2 and others
+
+## [3.23.11] - 2025-07-14
+
+- Add Kimi K2 model to Groq along with fixes to context condensing math
+- Add Cmd+Shift+. keyboard shortcut for previous mode switching
+
+## [3.23.10] - 2025-07-14
+
+- Prioritize built-in model dimensions over custom dimensions (thanks @daniel-lxs!)
+- Add padding to the index model options
+
+## [3.23.9] - 2025-07-14
+
+- Enable Claude Code provider to run natively on Windows (thanks @SannidhyaSah!)
+- Add gemini-embedding-001 model to code-index service (thanks @daniel-lxs!)
+- Resolve vector dimension mismatch error when switching embedding models
+- Return the cwd in the exec tool's response so that the model is not lost after subsequent calls (thanks @chris-garrett!)
+- Add configurable timeout for command execution in VS Code settings
+
+## [3.23.8] - 2025-07-13
+
+- Add enable/disable toggle for code indexing (thanks @daniel-lxs!)
+- Add a command auto-deny list to auto-approve settings
+- Add navigation link to history tab in HistoryPreview
+
+## [3.23.7] - 2025-07-11
+
+- Fix Mermaid syntax warning (thanks @MuriloFP!)
+- Expand Vertex AI region config to include all available regions in GCP Vertex AI (thanks @shubhamgupta731!)
+- Handle Qdrant vector dimension mismatch when switching embedding models (thanks @daniel-lxs!)
+- Fix typos in comment & document (thanks @noritaka1166!)
+- Improve the display of codebase search results
+- Correct translation fallback logic for embedding errors (thanks @daniel-lxs!)
+- Clean up MCP tool disabling
+- Link to marketplace from modes and MCP tab
+- Fix TTS button display (thanks @sensei-woo!)
+- Add Devstral Medium model support
+- Add comprehensive error telemetry to code-index service (thanks @daniel-lxs!)
+- Exclude cache tokens from context window calculation (thanks @daniel-lxs!)
+- Enable dynamic tool selection in architect mode for context discovery
+- Add configurable max output tokens setting for claude-code
+
+## [3.23.6] - 2025-07-10
+
+- Grok 4
+
+## [3.23.5] - 2025-07-09
+
+- Fix: use decodeURIComponent in openFile (thanks @vivekfyi!)
+- Fix(embeddings): Translate error messages before sending to UI (thanks @daniel-lxs!)
+- Make account tab visible
+
+## [3.23.4] - 2025-07-09
+
+- Update chat area icons for better discoverability & consistency
+- Fix a bug that allowed `list_files` to return directory results that should be excluded by .gitignore
+- Add an overflow header menu to make the UI a little tidier (thanks @dlab-anton)
+- Fix a bug the issue where null custom modes configuration files cause a 'Cannot read properties of null' error (thanks @daniel-lxs!)
+- Replace native title attributes with StandardTooltip component for consistency (thanks @daniel-lxs!)
+
+## [3.23.3] - 2025-07-09
+
+- Remove erroneous line from announcement modal
+
+## [3.23.2] - 2025-07-09
+
+- Fix bug where auto-approval was intermittently failing
+
+## [3.23.1] - 2025-07-09
+
+- Always show the code indexing dot under the chat text area
+
+## [3.23.0] - 2025-07-08
+
+- Move codebase indexing out of experimental (thanks @daniel-lxs and @MuriloFP!)
+- Add todo list tool (thanks @qdaxb!)
+- Fix code index secret persistence and improve settings UX (thanks @daniel-lxs!)
+- Add Gemini embedding provider for codebase indexing (thanks @SannidhyaSah!)
+- Support full endpoint URLs in OpenAI Compatible provider (thanks @SannidhyaSah!)
+- Add markdown support to codebase indexing (thanks @MuriloFP!)
+- Add Search/Filter Functionality to API Provider Selection in Settings (thanks @GOODBOY008!)
+- Add configurable max search results (thanks @MuriloFP!)
+- Add copy prompt button to task actions (thanks @Juice10 and @vultrnerd!)
+- Fix insertContentTool to create new files with content (thanks @Ruakij!)
+- Fix typescript compiler watch path inconsistency (thanks @bbenshalom!)
+- Use actual max_completion_tokens from OpenRouter API (thanks @shariqriazz!)
+- Prevent completion sound from replaying when reopening completed tasks (thanks @SannidhyaSah!)
+- Fix access_mcp_resource fails to handle images correctly (thanks @s97712!)
+- Prevent chatbox focus loss during automated file editing (thanks @hannesrudolph!)
+- Resolve intermittent hangs and lack of clear error feedback in apply_diff tool (thanks @lhish!)
+- Resolve Go duplicate references in tree-sitter queries (thanks @MuriloFP!)
+- Chat UI consistency and layout shifts (thanks @seedlord!)
+- Chat index UI enhancements (thanks @MuriloFP!)
+- Fix model search being prefilled on dropdown (thanks @kevinvandijk!)
+- Improve chat UI - add camera icon margin and make placeholder non-selectable (thanks @MuriloFP!)
+- Delete .roo/rules-{mode} folder when custom mode is deleted
+- Enforce file restrictions for all edit tools in architect mode
+- Add User-Agent header to API providers
+- Fix auto question timer unmount (thanks @liwilliam2021!)
+- Fix new_task tool streaming issue
+- Optimize file listing when maxWorkspaceFiles is 0 (thanks @daniel-lxs!)
+- Correct export/import of OpenAI Compatible codebase indexing settings (thanks @MuriloFP!)
+- Resolve workspace path inconsistency in code indexing for multi-workspace scenarios
+
+## [3.22.6] - 2025-07-02
+
+- Add timer-based auto approve for follow up questions (thanks @liwilliam2021!)
+- Add import/export modes functionality
+- Add persistent version indicator on chat screen
+- Add automatic configuration import on extension startup (thanks @takakoutso!)
+- Add user-configurable search score threshold slider for semantic search (thanks @hannesrudolph!)
+- Add default headers and testing for litellm fetcher (thanks @andrewshu2000!)
+- Fix consistent cancellation error messages for thinking vs streaming phases
+- Fix AWS Bedrock cross-region inference profile mapping (thanks @KevinZhao!)
+- Fix URL loading timeout issues in @ mentions (thanks @MuriloFP!)
+- Fix API retry exponential backoff capped at 10 minutes (thanks @MuriloFP!)
+- Fix Qdrant URL field auto-filling with default value (thanks @SannidhyaSah!)
+- Fix profile context condensation threshold (thanks @PaperBoardOfficial!)
+- Fix apply_diff tool documentation for multi-file capabilities
+- Fix cache files excluded from rules compilation (thanks @MuriloFP!)
+- Add streamlined extension installation and documentation (thanks @devxpain!)
+- Prevent Architect mode from providing time estimates
+- Remove context size from environment details
+- Change default mode to architect for new installations
+- Suppress Mermaid error rendering
+- Improve Mermaid buttons with light background in light mode (thanks @chrarnoldus!)
+- Add .vscode/ to write-protected files/directories
+- Update AWS Bedrock cross-region inference profile mapping (thanks @KevinZhao!)
+
+## [3.22.5] - 2025-06-28
+
+- Remove Gemini CLI provider while we work with Google on a better integration
+
+## [3.22.4] - 2025-06-27
+
+- Fix: resolve E2BIG error by passing large prompts via stdin to Claude CLI (thanks @Fovty!)
+- Add optional mode suggestions to follow-up questions
+- Fix: move StandardTooltip inside PopoverTrigger in ShareButton (thanks @daniel-lxs!)
+
+## [3.22.3] - 2025-06-27
+
+- Restore JSON backwards compatibility for .roomodes files (thanks @daniel-lxs!)
+
+## [3.22.2] - 2025-06-27
+
+- Fix: eliminate XSS vulnerability in CodeBlock component (thanks @KJ7LNW!)
+- Fix terminal keyboard shortcut error when adding content to context (thanks @MuriloFP!)
+- Fix checkpoint popover not opening due to StandardTooltip wrapper conflict (thanks @daniel-lxs!)
+- Fix(i18n): correct gemini cli error translation paths (thanks @daniel-lxs!)
+- Code Index (Qdrant) recreate services when change configurations (thanks @catrielmuller!)
+
+## [3.22.1] - 2025-06-26
+
+- Add Gemini CLI provider (thanks Cline!)
+- Fix undefined mcp command (thanks @qdaxb!)
+- Use upstream_inference_cost for OpenRouter BYOK cost calculation and show cached token count (thanks @chrarnoldus!)
+- Update maxTokens value for qwen/qwen3-32b model on Groq (thanks @KanTakahiro!)
+- Standardize tooltip delays to 300ms
+
+## [3.22.0] - 2025-06-25
+
+- Add 1-click task sharing
+- Add support for loading rules from a global .roo directory (thanks @samhvw8!)
+- Modes selector improvements (thanks @brunobergher!)
+- Use safeWriteJson for all JSON file writes to avoid task history corruption (thanks @KJ7LNW!)
+- Improve YAML error handling when editing modes
+- Register importSettings as VSCode command (thanks @shivamd1810!)
+- Add default task names for empty tasks (thanks @daniel-lxs!)
+- Improve translation workflow to avoid unnecessary file reads (thanks @KJ7LNW!)
+- Allow write_to_file to handle newline-only and empty content (thanks @Githubguy132010!)
+- Address multiple memory leaks in CodeBlock component (thanks @kiwina!)
+- Memory cleanup (thanks @xyOz-dev!)
+- Fix port handling bug in code indexing for HTTPS URLs (thanks @benashby!)
+- Improve Bedrock error handling for throttling and streaming contexts
+- Handle long Claude code messages (thanks @daniel-lxs!)
+- Fixes to Claude Code caching and image upload
+- Disable reasoning budget UI controls for Claude Code provider
+- Remove temperature parameter for Azure OpenAI reasoning models (thanks @ExactDoug!)
+- Allowed commands import/export (thanks @catrielmuller!)
+- Add VS Code setting to disable quick fix context actions (thanks @OlegOAndreev!)
+
+## [3.21.5] - 2025-06-23
+
+- Fix Qdrant URL prefix handling for QdrantClient initialization (thanks @CW-B-W!)
+- Improve LM Studio model detection to show all downloaded models (thanks @daniel-lxs!)
+- Resolve Claude Code provider JSON parsing and reasoning block display
+
+## [3.21.4] - 2025-06-23
+
+- Fix start line not working in multiple apply diff (thanks @samhvw8!)
+- Resolve diff editor issues with markdown preview associations (thanks @daniel-lxs!)
+- Resolve URL port handling bug for HTTPS URLs in Qdrant (thanks @benashby!)
+- Mark unused Ollama schema properties as optional (thanks @daniel-lxs!)
+- Close the local browser when used as fallback for remote (thanks @markijbema!)
+- Add Claude Code provider for local CLI integration (thanks @BarreiroT!)
+
+## [3.21.3] - 2025-06-21
+
+- Add profile-specific context condensing thresholds (thanks @SannidhyaSah!)
+- Fix context length for lmstudio and ollama (thanks @thecolorblue!)
+- Resolve MCP tool eye icon state and hide in chat context (thanks @daniel-lxs!)
+
+## [3.21.2] - 2025-06-20
+
+- Add LaTeX math equation rendering in chat window
+- Add toggle for excluding MCP server tools from the prompt (thanks @Rexarrior!)
+- Add symlink support to list_files tool
+- Fix marketplace blanking after populating
+- Fix recursive directory scanning in @ mention "Add Folder" functionality (thanks @village-way!)
+- Resolve phantom subtask display on cancel during API retry
+- Correct Gemini 2.5 Flash pricing (thanks @daniel-lxs!)
+- Resolve marketplace timeout issues and display installed MCPs (thanks @daniel-lxs!)
+- Onboarding tweaks to emphasize modes (thanks @brunobergher!)
+- Rename 'Boomerang Tasks' to 'Task Orchestration' for clarity
+- Remove command execution from attempt_completion
+- Fix markdown for links followed by punctuation (thanks @xyOz-dev!)
+
+## [3.21.1] - 2025-06-19
+
+- Fix tree-sitter issues that were preventing codebase indexing from working correctly
+- Improve error handling for codebase search embeddings
+- Resolve MCP server execution on Windows with node version managers
+- Default 'Enable MCP Server Creation' to false
+- Rate limit correctly when starting a subtask (thanks @olweraltuve!)
+
+## [3.21.0] - 2025-06-17
+
+- Add Roo Marketplace to make it easy to discover and install great MCPs and modes!
+- Add Gemini 2.5 models (Pro, Flash and Flash Lite) (thanks @daniel-lxs!)
+- Add support for Excel (.xlsx) files in tools (thanks @chrarnoldus!)
+- Add max tokens checkbox option for OpenAI compatible provider (thanks @AlexandruSmirnov!)
+- Update provider models and prices for Groq & Mistral (thanks @KanTakahiro!)
+- Add proper error handling for API conversation history issues (thanks @KJ7LNW!)
+- Fix ambiguous model id error (thanks @elianiva!)
+- Fix save/discard/revert flow for Prompt Settings (thanks @hassoncs!)
+- Fix codebase indexing alignment with list-files hidden directory filtering (thanks @daniel-lxs!)
+- Fix subtask completion mismatch (thanks @feifei325!)
+- Fix Windows path normalization in MCP variable injection (thanks @daniel-lxs!)
+- Update marketplace branding to 'Roo Marketplace' (thanks @SannidhyaSah!)
+- Refactor to more consistent history UI (thanks @elianiva!)
+- Adjust context menu positioning to be near Copilot
+- Update evals Docker setup to work on Windows (thanks @StevenTCramer!)
+- Include current working directory in terminal details
+- Encourage use of start_line in multi-file diff to match legacy diff
+- Always focus the panel when clicked to ensure menu buttons are visible (thanks @hassoncs!)
+
+## [3.20.3] - 2025-06-13
+
+- Resolve diff editor race condition in multi-monitor setups (thanks @daniel-lxs!)
+- Add logic to prevent auto-approving edits of configuration files
+- Adjust searching and listing files outside of the workspace to respect the auto-approve settings
+- Add Indonesian translation support (thanks @chrarnoldus and @daniel-lxs!)
+- Fix multi-file diff error handling and UI feedback (thanks @daniel-lxs!)
+- Improve prompt history navigation to not interfere with text editing (thanks @daniel-lxs!)
+- Fix errant maxReadFileLine default
+
+## [3.20.2] - 2025-06-13
+
+- Limit search_files to only look within the workspace for improved security
+- Force tar-fs >=2.1.3 for security vulnerability fix
+- Add cache breakpoints for custom vertex models on Unbound (thanks @pugazhendhi-m!)
+- Reapply reasoning for bedrock with fix (thanks @daniel-lxs!)
+- Sync BatchDiffApproval styling with BatchFilePermission for UI consistency (thanks @samhvw8!)
+- Add max height constraint to MCP execution response for better UX (thanks @samhvw8!)
+- Prevent MCP 'installed' label from being squeezed #4630 (thanks @daniel-lxs!)
+- Allow a lower context condesning threshold (thanks @SECKainersdorfer!)
+- Avoid type system duplication for cleaner codebase (thanks @EamonNerbonne!)
+
+## [3.20.1] - 2025-06-12
+
+- Temporarily revert thinking support for Bedrock models
+- Improve performance of MCP execution block
+- Add indexing status badge to chat view
+
+## [3.20.0] - 2025-06-12
+
+- Add experimental Marketplace for extensions and modes (thanks @Smartsheet-JB-Brown, @elianiva, @monkeyDluffy6017, @NamesMT, @daniel-lxs, Cline, and more!)
+- Add experimental multi-file edits (thanks @samhvw8!)
+- Move concurrent reads setting to context settings with default of 5
+- Improve MCP execution UX (thanks @samhvw8!)
+- Add magic variables support for MCPs with `workspaceFolder` injection (thanks @NamesMT!)
+- Add prompt history navigation via arrow up/down in prompt field
+- Add support for escaping context mentions (thanks @KJ7LNW!)
+- Add DeepSeek R1 support to Chutes provider
+- Add reasoning budget support to Bedrock models for extended thinking
+- Add mermaid diagram support buttons (thanks @qdaxb!)
+- Update XAI models and pricing (thanks @edwin-truthsearch-io!)
+- Update O3 model pricing
+- Add manual OpenAI-compatible format specification and parsing (thanks @dflatline!)
+- Add core tools integration tests for comprehensive coverage
+- Add JSDoc documentation for ClineAsk and ClineSay types (thanks @hannesrudolph!)
+- Populate whenToUse descriptions for built-in modes
+- Fix file write tool with early relPath & newContent validation checks (thanks @Ruakij!)
+- Fix TaskItem display and copy issues with HTML tags in task messages (thanks @forestyoo!)
+- Fix OpenRouter cost calculation with BYOK (thanks @chrarnoldus!)
+- Fix terminal busy state reset after manual commands complete
+- Fix undefined output on multi-file apply_diff operations (thanks @daniel-lxs!)
+
+## [3.19.7] - 2025-06-11
+
+- Fix McpHub sidebar focus behavior to prevent unwanted focus grabbing
+- Disable checkpoint functionality when nested git repositories are detected to prevent conflicts
+- Remove unused Storybook components and dependencies to reduce bundle size
+- Add data-testid ESLint rule for improved testing standards (thanks @elianiva!)
+- Update development dependencies including eslint, knip, @types/node, i18next, fast-xml-parser, and @google/genai
+- Improve CI infrastructure with GitHub Actions and Blacksmith runner migrations
+
+## [3.19.6] - 2025-06-09
+
+- Replace explicit caching with implicit caching to reduce latency for Gemini models
+- Clarify that the default concurrent file read limit is 15 files (thanks @olearycrew!)
+- Fix copy button logic (thanks @samhvw8!)
+- Fade buttons on history preview if no interaction in progress (thanks @sachasayan!)
+- Allow MCP server refreshing, fix state changes in MCP server management UI view (thanks @taylorwilsdon!)
+- Remove unnecessary npx usage in some npm scripts (thanks @user202729!)
+- Bug fix for trailing slash error when using LiteLLM provider (thanks @kcwhite!)
+
+## [3.19.5] - 2025-06-05
+
+- Fix Gemini 2.5 Pro Preview thinking budget bug
+
+## [3.19.4] - 2025-06-05
+
+- Add Gemini Pro 06-05 model support (thanks @daniel-lxs and @shariqriazz!)
+- Fix reading PDF, DOCX, and IPYNB files in read_file tool (thanks @samhvw8!)
+- Fix Mermaid CSP errors with enhanced bundling strategy (thanks @KJ7LNW!)
+- Improve model info detection for custom Bedrock ARNs (thanks @adamhill!)
+- Add OpenAI Compatible embedder for codebase indexing (thanks @SannidhyaSah!)
+- Fix multiple memory leaks in ChatView component (thanks @kiwina!)
+- Fix WorkspaceTracker resource leaks by disposing FileSystemWatcher (thanks @kiwina!)
+- Fix RooTips setTimeout cleanup to prevent state updates on unmounted components (thanks @kiwina!)
+- Fix FileSystemWatcher leak in RooIgnoreController (thanks @kiwina!)
+- Fix clipboard memory leak by clearing setTimeout in useCopyToClipboard (thanks @kiwina!)
+- Fix ClineProvider instance cleanup (thanks @xyOz-dev!)
+- Enforce codebase_search as primary tool for code understanding tasks (thanks @hannesrudolph!)
+- Improve Docker setup for evals
+- Move evals into pnpm workspace, switch from SQLite to Postgres
+- Refactor MCP to use getDefaultEnvironment for stdio client transport (thanks @samhvw8!)
+- Get rid of "partial" component in names referencing not necessarily partial messages (thanks @wkordalski!)
+- Improve feature request template (thanks @elianiva!)
+
+## [3.19.3] - 2025-06-02
+
+- Fix SSE MCP Invocation - Fixed SSE connection issue in McpHub.ts by ensuring transport.start override only applies to stdio transports, allowing SSE and streamable-http transports to retain their original start methods (thanks @taylorwilsdon!)
+
+## [3.19.2] - 2025-06-01
+
+- Add support for Streamable HTTP Transport MCP servers (thanks @taylorwilsdon!)
+- Add cached read and writes to stats and cost calculation for LiteLLM provider (thanks @mollux!)
+- Prevent dump of an entire file into the context on user edit (thanks @KJ7LNW!)
+- Fix directory link handling in markdown (thanks @KJ7LNW!)
+- Prevent start_line/end_line in apply_diff REPLACE (thanks @KJ7LNW!)
+- Unify history item UI with TaskItem and TaskItemHeader (thanks @KJ7LNW!)
+- Fix the label of the OpenAI-compatible API keys
+- Fix Virtuoso footer re-rendering issue (thanks @kiwina!)
+- Optimize ChatRowContent layout and styles (thanks @zhangtony239!)
+- Release memory in apply diff (thanks @xyOz-dev!)
+- Upgrade Node.js to v20.19.2 for security enhancements (thanks @PeterDaveHello!)
+- Fix typos (thanks @noritaka1166!)
+
+## [3.19.1] - 2025-05-30
+
+- Experimental feature to allow reading multiple files at once (thanks @samhvw8!)
+- Fix to correctly pass headers to SSE MCP servers
+- Adding support for custom VPC endpoints when using Amazon Bedrock (thanks @kcwhite!)
+- Fix bug with context condensing in Amazon Bedrock
+- Fix UTF-8 encoding in ExecaTerminalProcess (thanks @mr-ryan-james!)
+- Set sidebar name bugfix (thanks @chrarnoldus!)
+- Fix link to CONTRIBUTING.md in feature request template (thanks @cannuri!)
+- Add task metadata to Unbound and improve caching logic (thanks @pugazhendhi-m!)
+
+## [3.19.0] - 2025-05-29
+
+- Enable intelligent content condensing by default and move condense button out of expanded task menu
+- Skip condense and show error if context grows during condensing
+- Transform Prompts tab into Modes tab and move support prompts to Settings for better organization
+- Add DeepSeek R1 0528 model support to Chutes provider (thanks @zeozeozeo!)
+- Fix @directory not respecting .rooignore files (thanks @xyOz-dev!)
+- Add rooignore checking for insert_content and search_and_replace tools
+- Fix menu breaking when Roo is moved between primary and secondary sidebars (thanks @chrarnoldus!)
+- Resolve memory leak in ChatView by stabilizing callback props (thanks @samhvw8!)
+- Fix write_to_file to properly create empty files when content is empty (thanks @Ruakij!)
+- Fix chat input clearing during running tasks (thanks @xyOz-dev!)
+- Update AWS regions to include Spain and Hyderabad
+- Improve POSIX shell compatibility in pre-push hook (thanks @PeterDaveHello and @chrarnoldus!)
+- Update PAGER environment variable for Windows compatibility in Terminal (thanks @SmartManoj!)
+- Add environment variable injection support for whole MCP config (thanks @NamesMT!)
+- Update codebase search description to emphasize English query requirements (thanks @ChuKhaLi!)
+
+## [3.18.5] - 2025-05-27
+
+- Add thinking controls for Requesty (thanks @dtrugman!)
+- Re-enable telemetry
+- Improve zh-TW Traditional Chinese locale (thanks @PeterDaveHello and @chrarnoldus!)
+- Improve model metadata for LiteLLM
+
+## [3.18.4] - 2025-05-25
+
+- Fix codebase indexing settings saving and Ollama indexing (thanks @daniel-lxs!)
+- Fix handling BOM when user rejects apply_diff (thanks @avtc!)
+- Fix wrongfully clearing input on auto-approve (thanks @Ruakij!)
+- Fix correct spawnSync parameters for pnpm check in bootstrap.mjs (thanks @ChuKhaLi!)
+- Update xAI models and default model ID (thanks @PeterDaveHello!)
+- Add metadata to create message (thanks @dtrugman!)
+
+## [3.18.3] - 2025-05-24
+
+- Add reasoning support for Claude 4 and Gemini 2.5 Flash on OpenRouter, plus a fix for o1-pro
+- Add experimental codebase indexing + semantic search feature (thanks @daniel-lxs!)
+- For providers that used to default to Sonnet 3.7, change to Sonnet 4
+- Enable prompt caching for Gemini 2.5 Flash Preview (thanks @shariqriazz!)
+- Preserve model settings when selecting a specific OpenRouter provider
+- Add ability to refresh LiteLLM models list
+- Improve tool descriptions to guide proper file editing tool selection
+- Fix MCP Server error loading config when running with npx and bunx (thanks @devxpain!)
+- Improve pnpm bootstrapping and add compile script (thanks @KJ7LNW!)
+- Simplify object assignment & use startsWith (thanks @noritaka1166!)
+- Fix mark-as-read logic in the context tracker (thanks @samhvw8!)
+- Remove deprecated claude-3.7-sonnet models from vscodelm (thanks @shariqriazz!)
+
+## [3.18.2] - 2025-05-23
+
+- Fix vscode-material-icons in the filer picker
+- Fix global settings export
+- Respect user-configured terminal integration timeout (thanks @KJ7LNW)
+- Context condensing enhancements (thanks @SannidhyaSah)
+
+## [3.18.1] - 2025-05-22
+
+- Add support for Claude Sonnet 4 and Claude Opus 4 models with thinking variants in Anthropic, Bedrock, and Vertex (thanks @shariqriazz!)
+- Fix README gif display in all localized versions
+- Fix referer URL
+- Switch codebase to a monorepo and create an automated "nightly" build
+
+## [3.18.0] - 2025-05-21
+
+- Add support for Gemini 2.5 Flash preview models (thanks @shariqriazz and @daniel-lxs!)
+- Add button to task header to intelligently condense content with visual feedback
+- Add YAML support for mode definitions (thanks @R-omk!)
+- Add allowedMaxRequests feature to cap consecutive auto-approved requests (inspired by Cline, thanks @hassoncs!)
+- Add Qwen3 model series to the Chutes provider (thanks @zeozeozeo!)
+- Fix more causes of grey screen issues (thanks @xyOz-dev!)
+- Add LM Studio reasoning support (thanks @avtc!)
+- Add refresh models button for Unbound provider (thanks @pugazhendhi-m!)
+- Add template variables for version numbers in announcement strings (thanks @ChuKhaLi!)
+- Make prompt input textareas resizable again
+- Fix diffview scroll display (thanks @qdaxb!)
+- Fix LM Studio and Ollama usage tracking (thanks @xyOz-dev!)
+- Fix links to filename:0 (thanks @RSO!)
+- Fix missing or inconsistent syntax highlighting across UI components (thanks @KJ7LNW!)
+- Fix packaging to include correct tiktoken.wasm (thanks @vagadiya!)
+- Fix import settings bugs and position error messages correctly (thanks @ChuKhaLi!)
+- Move audio playing to the webview to ensure cross-platform support (thanks @SmartManoj and @samhvw8!)
+- Simplify loop syntax in multiple components (thanks @noritaka1166!)
+- Auto reload extension core changes in dev mode (thanks @hassoncs!)
+
+## [3.17.2] - 2025-05-15
+
+- Revert "Switch to the new Roo message parser" (appears to cause a tool parsing bug)
+- Lock the versions of vsce and ovsx
+
+## [3.17.1] - 2025-05-15
+
+- Fix the display of the command to execute during approval
+- Fix incorrect reserved tokens calculation on OpenRouter (thanks @daniel-lxs!)
+
+## [3.17.0] - 2025-05-14
+
+- Enable Gemini implicit caching
+- Add "when to use" section to mode definitions to enable better orchestration
+- Add experimental feature to intelligently condense the task context instead of truncating it
+- Fix one of the causes of the gray screen issue (thanks @xyOz-dev!)
+- Focus improvements for better UI interactions (thanks Cline!)
+- Switch to the new Roo message parser for improved performance (thanks Cline!)
+- Enable source maps for improved debugging (thanks @KJ7LNW!)
+- Update OpenRouter provider to use provider-specific model info (thanks @daniel-lxs!)
+- Fix Requesty cost/token reporting (thanks @dtrugman!)
+- Improve command execution UI
+- Add more in-app links to relevant documentation
+- Update the new task tool description and the ask mode custom instructions in the system prompt
+- Add IPC types to roo-code.d.ts
+- Add build VSIX workflow to pull requests (thanks @SmartManoj!)
+- Improve apply_diff tool to intelligently deduce line numbers (thanks @samhvw8!)
+- Fix command validation for shell array indexing (thanks @KJ7LNW!)
+- Handle diagnostics that point at a directory URI (thanks @daniel-lxs!)
+- Fix "Current ask promise was ignored" error (thanks @zxdvd!)
+
+## [3.16.6] - 2025-05-12
+
+- Restore "Improve provider profile management in the external API"
+- Fix to subtask sequencing (thanks @wkordalski!)
+- Fix webview terminal output processing error (thanks @KJ7LNW!)
+- Fix textarea empty string fallback logic (thanks @elianiva!)
+
+## [3.16.5] - 2025-05-10
+
+- Revert "Improve provider profile management in the external API" until we track down a bug with defaults
+
+## [3.16.4] - 2025-05-09
+
+- Improve provider profile management in the external API
+- Enforce provider selection in OpenRouter by using 'only' parameter and disabling fallbacks (thanks @shariqriazz!)
+- Fix display issues with long profile names (thanks @cannuri!)
+- Prevent terminal focus theft on paste after command execution (thanks @MuriloFP!)
+- Save OpenAI compatible custom headers correctly
+- Fix race condition when updating prompts (thanks @elianiva!)
+- Fix display issues in high contrast themes (thanks @zhangtony239!)
+- Fix not being able to use specific providers on Openrouter (thanks @daniel-lxs!)
+- Show properly formatted multi-line commands in preview (thanks @KJ7LNW!)
+- Handle unsupported language errors gracefully in read_file tool (thanks @KJ7LNW!)
+- Enhance focus styles in select-dropdown and fix docs URL (thanks @zhangtony239!)
+- Properly handle mode name overflow in UI (thanks @elianiva!)
+- Fix project MCP always allow issue (thanks @aheizi!)
+
+## [3.16.3] - 2025-05-08
+
+- Revert Tailwind migration while we fix a few spots
+- Add Elixir file extension support in language parser (thanks @pfitz!)
+
+## [3.16.2] - 2025-05-07
+
+- Clarify XML tool use formatting instructions
+- Error handling code cleanup (thanks @monkeyDluffy6017!)
+
+## [3.16.1] - 2025-05-07
+
+- Add LiteLLM provider support
+- Improve stability by detecting and preventing tool loops
+- Add Dutch localization (thanks @Githubguy132010!)
+- Add editor name to telemetry for better analytics
+- Migrate to Tailwind CSS for improved UI consistency
+- Fix footer button wrapping in About section on narrow screens (thanks @ecmasx!)
+- Update evals defaults
+- Update dependencies to latest versions
+
+## [3.16.0] - 2025-05-06
+
+- Add vertical tab navigation to the settings (thanks @dlab-anton)
+- Add Groq and Chutes API providers (thanks @shariqriazz)
+- Clickable code references in code block (thanks @KJ7LNW)
+- Improve accessibility of ato-approve toggles (thanks @Deon588)
+- Requesty provider fixes (thanks @dtrugman)
+- Fix migration and persistence of per-mode API profiles (thanks @alasano)
+- Fix usage of `path.basename` in the extension webview (thanks @samhvw8)
+- Fix display issue of the programming language dropdown in the code block component (thanks @zhangtony239)
+- MCP server errors are now captured and shown in a new "Errors" tab (thanks @robertheadley)
+- Error logging will no longer break MCP functionality if the server is properly connected (thanks @ksze)
+- You can now toggle the `terminal.integrated.inheritEnv` VSCode setting directly for the Roo Code settings (thanks @KJ7LNW)
+- Add `gemini-2.5-pro-preview-05-06` to the Vertex and Gemini providers (thanks @zetaloop)
+- Ensure evals exercises are up-to-date before running evals (thanks @shariqriazz)
+- Lots of general UI improvements (thanks @elianiva)
+- Organize provider settings into separate components
+- Improved icons and translations for the code block component
+- Add support for tests that use ESM libraries
+- Move environment detail generation to a separate module
+- Enable prompt caching by default for supported Gemini models
+
+## [3.15.5] - 2025-05-05
+
+- Update @google/genai to 0.12 (includes some streaming completion bug fixes)
+- Rendering performance improvements for code blocks in chat (thanks @KJ7LNW)
+
+## [3.15.4] - 2025-05-04
+
+- Fix a nasty bug that would cause Roo Code to hang, particularly in orchestrator mode
+- Improve Gemini caching efficiency
+
+## [3.15.3] - 2025-05-02
+
+- Terminal: Fix empty command bug
+- Terminal: More robust process killing
+- Optimize Gemini prompt caching for OpenRouter
+- Chat view performance improvements
+
+## [3.15.2] - 2025-05-02
+
+- Fix terminal performance issues
+- Handle Mermaid validation errors
+- Add customizable headers for OpenAI-compatible provider (thanks @mark-bradshaw!)
+- Add config option to overwrite OpenAI's API base (thanks @GOODBOY008!)
+- Fixes to padding and height issues when resizing the sidebar (thanks @zhangtony239!)
+- Remove tool groups from orchestrator mode definition
+- Add telemetry for title button clicks
+
+## [3.15.1] - 2025-04-30
+
+- Capture stderr in execa-spawned processes
+- Play sound only when action needed from the user (thanks @olearycrew)
+- Make retries respect the global auto approve checkbox
+- Fix a selection mode bug in the history view (thanks @jr)
+
+## [3.15.0] - 2025-04-30
+
+- Add prompt caching to the Google Vertex provider (thanks @ashktn)
+- Add a fallback mechanism for executing terminal commands if VSCode terminal shell integration fails
+- Improve the UI/UX of code snippets in the chat (thanks @KJ7LNW)
+- Add a reasoning effort setting for the OpenAI Compatible provider (thanks @mr-ryan-james)
+- Allow terminal commands to be stopped directly from the chat UI
+- Adjust chat view padding to accommodate small width layouts (thanks @zhangtony239)
+- Fix file mentions for filenames containing spaces
+- Improve the auto-approve toggle buttons for some high-contrast VSCode themes
+- Offload expensive count token operations to a web worker (thanks @samhvw8)
+- Improve support for mult-root workspaces (thanks @snoyiatk)
+- Simplify and streamline Roo Code's quick actions
+- Allow Roo Code settings to be imported from the welcome screen (thanks @julionav)
+- Remove unused types (thanks @wkordalski)
+- Improve the performance of mode switching (thanks @dlab-anton)
+- Fix importing & exporting of custom modes (thanks @julionav)
+
+## [3.14.3] - 2025-04-25
+
+- Add Boomerang Orchestrator as a built-in mode
+- Improve home screen UI
+- Make token count estimation more efficient to reduce gray screens
+- Revert change to automatically close files after edit until we figure out how to make it work well with diagnostics
+- Clean up settings data model
+- Omit reasoning params for non-reasoning models
+- Clearer documentation for adding settings (thanks @shariqriazz!)
+- Fix word wrapping in Roo message title (thanks @zhangtony239!)
+- Update default model id for Unbound from claude 3.5 to 3.7 (thanks @pugazhendhi-m!)
+
+## [3.14.2] - 2025-04-24
+
+- Enable prompt caching for Gemini (with some improvements)
+- Allow users to turn prompt caching on / off for Gemini 2.5 on OpenRouter
+- Compress terminal output with backspace characters (thanks @KJ7LNW)
+- Add Russian language (Спасибо @asychin)
+
+## [3.14.1] - 2025-04-24
+
+- Disable Gemini caching while we investigate issues reported by the community.
+
+## [3.14.0] - 2025-04-23
+
+- Add prompt caching for `gemini-2.5-pro-preview-03-25` in the Gemini provider (Vertex and OpenRouter coming soon!)
+- Improve the search_and_replace and insert_content tools and bring them out of experimental, and deprecate append_to_file (thanks @samhvw8!)
+- Use material icons for files and folders in mentions (thanks @elianiva!)
+- Make the list_files tool more efficient and smarter about excluding directories like .git/
+- Fix file drag and drop on Windows and when using SSH tunnels (thanks @NyxJae!)
+- Correctly revert changes and suggest alternative tools when write_to_file fails on a missing line count
+- Allow interpolation of `workspace`, `mode`, `language`, `shell`, and `operatingSystem` into custom system prompt overrides (thanks @daniel-lxs!)
+- Fix interpolation bug in the “add to context” code action (thanks @elianiva!)
+- Preserve editor state and prevent tab unpinning during diffs (thanks @seedlord!)
+- Improvements to icon rendering on Linux (thanks @elianiva!)
+- Improvements to Requesty model list fetching (thanks @dtrugman!)
+- Fix user feedback not being added to conversation history in API error state, redundant ‘TASK RESUMPTION’ prompts, and error messages not showing after cancelling API requests (thanks @System233!)
+- Track tool use errors in evals
+- Fix MCP hub error when dragging extension to another sidebar
+- Improve display of long MCP tool arguments
+- Fix redundant ‘TASK RESUMPTION’ prompts (thanks @System233!)
+- Fix bug opening files when editor has no workspace root
+- Make the VS Code LM provider show the correct model information (thanks @QuinsZouls!)
+- Fixes to make the focusInput command more reliable (thanks @hongzio!)
+- Better handling of aftercursor content in context mentions (thanks @elianiva!)
+- Support injecting environment variables in MCP config (thanks @NamesMT!)
+- Better handling of FakeAI “controller” object (thanks @wkordalski)
+- Remove unnecessary calculation from VS Code LM provider (thanks @d-oit!)
+- Allow Amazon Bedrock Marketplace ARNs (thanks @mlopezr!)
+- Give better loading feedback on chat rows (thanks @elianiva!)
+- Performance improvements to task size calculations
+- Don’t immediately show a model ID error when changing API providers
+- Fix apply_diff edge cases
+- Use a more sensible task export icon
+- Use path aliases in webview source files
+- Display a warning when the system prompt is overridden
+- Better progress indicator for apply_diff tools (thanks @qdaxb!)
+- Fix terminal carriage return handling for correct progress bar display (thanks @Yikai-Liao!)
+
+## [3.13.2] - 2025-04-18
+
+- Allow custom URLs for Gemini provider
+
+## [3.13.1] - 2025-04-18
+
+- Support Gemini 2.5 Flash thinking mode (thanks @monotykamary)
+- Make auto-approval toggle on/off states more obvious (thanks @sachasayan)
+- Add telemetry for shell integration errors
+- Fix the path of files dragging into the chat textarea on Windows (thanks @NyxJae)
+
+## [3.13.0] - 2025-04-17
+
+- UI improvements to task header, chat view, history preview, and welcome view (thanks @sachasayan!)
+- Add append_to_file tool for appending content to files (thanks @samhvw8!)
+- Add Gemini 2.5 Flash Preview to Gemini and Vertex providers (thanks @nbihan-mediware!)
+- Fix image support in Bedrock (thanks @Smartsheet-JB-Brown!)
+- Make diff edits more resilient to models passing in incorrect parameters
+
+## [3.12.3] - 2025-04-17
+
+- Fix character escaping issues in Gemini diff edits
+- Support dragging and dropping tabs into the chat box (thanks @NyxJae!)
+- Make sure slash commands only fire at the beginning of the chat box (thanks @logosstone!)
+
+## [3.12.2] - 2025-04-16
+
+- Add OpenAI o3 & 4o-mini (thanks @PeterDaveHello!)
+- Improve file/folder context mention UI (thanks @elianiva!)
+- Improve diff error telemetry
+
+## [3.12.1] - 2025-04-16
+
+- Bugfix to Edit button visibility in the select dropdowns
+
+## [3.12.0] - 2025-04-15
+
+- Add xAI provider and expose reasoning effort options for Grok on OpenRouter (thanks Cline!)
+- Make diff editing config per-profile and improve pre-diff string normalization
+- Make checkpoints faster and more reliable
+- Add a search bar to mode and profile select dropdowns (thanks @samhvw8!)
+- Add telemetry for code action usage, prompt enhancement usage, and consecutive mistake errors
+- Suppress zero cost values in the task header (thanks @do-it!)
+- Make JSON parsing safer to avoid crashing the webview on bad input
+- Allow users to bind a keyboard shortcut for accepting suggestions or input in the chat view (thanks @axkirillov!)
+
+## [3.11.17] - 2025-04-14
+
+- Improvements to OpenAI cache reporting and cost estimates (thanks @monotykamary and Cline!)
+- Visual improvements to the auto-approve toggles (thanks @sachasayan!)
+- Bugfix to diff apply logic (thanks @avtc for the test case!) and telemetry to track errors going forward
+- Fix race condition in capturing short-running terminal commands (thanks @KJ7LNW!)
+- Fix eslint error (thanks @nobu007!)
+
+## [3.11.16] - 2025-04-14
+
+- Add gpt-4.1, gpt-4.1-mini, and gpt-4.1-nano to the OpenAI provider
+- Include model ID in environment details and when exporting tasks (thanks @feifei325!)
+
+## [3.11.15] - 2025-04-13
+
+- Add ability to filter task history by workspace (thanks @samhvw8!)
+- Fix Node.js version in the .tool-versions file (thanks @bogdan0083!)
+- Fix duplicate suggested mentions for open tabs (thanks @samhvw8!)
+- Fix Bedrock ARN validation and token expiry issue when using profiles (thanks @vagadiya!)
+- Add Anthropic option to pass API token as Authorization header instead of X-Api-Key (thanks @mecab!)
+- Better documentation for adding new settings (thanks @KJ7LNW!)
+- Localize package.json (thanks @samhvw8!)
+- Add option to hide the welcome message and fix the background color for the new profile dialog (thanks @zhangtony239!)
+- Restore the focus ring for the VSCodeButton component (thanks @pokutuna!)
+
+## [3.11.14] - 2025-04-11
+
+- Support symbolic links in rules folders to directories and other symbolic links (thanks @taisukeoe!)
+- Stronger enforcement of the setting to always read full files instead of doing partial reads
+
+## [3.11.13] - 2025-04-11
+
+- Loads of terminal improvements: command delay, PowerShell counter, and ZSH EOL mark (thanks @KJ7LNW!)
+- Add file context tracking system (thanks @samhvw8 and @canvrno!)
+- Improved display of diff errors + easy copying for investigation
+- Fixes to .vscodeignore (thanks @franekp!)
+- Fix a zh-CN translation for model capabilities (thanks @zhangtony239!)
+- Rename AWS Bedrock to Amazon Bedrock (thanks @ronyblum!)
+- Update extension title and description (thanks @StevenTCramer!)
+
+## [3.11.12] - 2025-04-09
+
+- Make Grok3 streaming work with OpenAI Compatible (thanks @amittell!)
+- Tweak diff editing logic to make it more tolerant of model errors
+
+## [3.11.11] - 2025-04-09
+
+- Fix highlighting interaction with mode/profile dropdowns (thanks @atlasgong!)
+- Add the ability to set Host header and legacy OpenAI API in the OpenAI-compatible provider for better proxy support
+- Improvements to TypeScript, C++, Go, Java, Python tree-sitter parsers (thanks @KJ7LNW!)
+- Fixes to terminal working directory logic (thanks @KJ7LNW!)
+- Improve readFileTool XML output format (thanks @KJ7LNW!)
+- Add o1-pro support (thanks @arthurauffray!)
+- Follow symlinked rules files/directories to allow for more flexible rule setups
+- Focus Roo Code in the sidebar when running tasks in the sidebar via the API
+- Improve subtasks UI
+
+## [3.11.10] - 2025-04-08
+
+- Fix bug where nested .roo/rules directories are not respected properly (thanks @taisukeoe!)
+- Handle long command output more efficiently in the chat row (thanks @samhvw8!)
+- Fix cache usage tracking for OpenAI-compatible providers
+- Add custom translation instructions for zh-CN (thanks @System233!)
+- Code cleanup after making rate-limits per-profile (thanks @ross!)
+
+## [3.11.9] - 2025-04-07
+
+- Rate-limit setting updated to be per-profile (thanks @ross and @olweraltuve!)
+- You can now place multiple rules files in the .roo/rules/ and .roo/rules-{mode}/ folders (thanks @upamune!)
+- Prevent unnecessary autoscroll when buttons appear (thanks @shtse8!)
+- Add Gemini 2.5 Pro Preview to Vertex AI (thanks @nbihan-mediware!)
+- Tidy up following ClineProvider refactor (thanks @diarmidmackenzie!)
+- Clamp negative line numbers when reading files (thanks @KJ7LNW!)
+- Enhance Rust tree-sitter parser with advanced language structures (thanks @KJ7LNW!)
+- Persist settings on api.setConfiguration (thanks @gtaylor!)
+- Add deep links to settings sections
+- Add command to focus Roo Code input field (thanks @axkirillov!)
+- Add resize and hover actions to the browser (thanks @SplittyDev!)
+- Add resumeTask and isTaskInHistory to the API (thanks @franekp!)
+- Fix bug displaying boolean/numeric suggested answers
+- Dynamic Vite port detection for webview development (thanks @KJ7LNW!)
+
+## [3.11.8] - 2025-04-05
+
+- Improve combineApiRequests performance to reduce gray screens of death (thanks @kyle-apex!)
+- Add searchable dropdown to API config profiles on the settings screen (thanks @samhvw8!)
+- Add workspace tracking to history items in preparation for future filtering (thanks @samhvw8!)
+- Fix search highlighting UI in history search (thanks @samhvw8!)
+- Add support for .roorules and give deprecation warning for .clinerules (thanks @upamune!)
+- Fix nodejs version format in .tool-versions file (thanks @upamune!)
+
+## [3.11.7] - 2025-04-04
+
+- Improve file tool context formatting and diff error guidance
+- Improve zh-TW localization (thanks @PeterDaveHello!)
+- Implement reference counting for McpHub disposal
+- Update buttons to be more consistent (thanks @kyle-apex!)
+- Improve zh-CN localization (thanks @System233!)
+
+## [3.11.6] - 2025-04-04
+
+- Add the gemini 2.5 pro preview model with upper bound pricing
+
+## [3.11.5] - 2025-04-03
+
+- Add prompt caching for Amazon Bedrock (thanks @Smartsheet-JB-Brown!)
+- Add support for configuring the current working directory of MCP servers (thanks @shoopapa!)
+- Add profile management functions to API (thanks @gtaylor!)
+- Improvements to diff editing functionality, tests, and error messages (thanks @p12tic!)
+- Fix for follow-up questions grabbing the focus (thanks @diarmidmackenzie!)
+- Show menu buttons when popping the extension out into a new tab (thanks @benny123tw!)
+
+## [3.11.4] - 2025-04-02
+
+- Correctly post state to webview when the current task is cleared (thanks @wkordalski!)
+- Fix unit tests to run properly on Windows (thanks @StevenTCramer!)
+- Tree-sitter enhancements: TSX, TypeScript, JSON, and Markdown support (thanks @KJ7LNW!)
+- Fix issue with line number stripping for deletions in apply_diff
+- Update history selection mode button spacing (thanks @kyle-apex!)
+- Limit dropdown menu height to 80% of the viewport (thanks @axmo!)
+- Update dependencies via `npm audit fix` (thanks @PeterDaveHello!)
+- Enable model select when api fails (thanks @kyle-apex!)
+- Fix issue where prompts and settings tabs were not scrollable when accessed from dropdown menus
+- Update AWS region dropdown menu to the most recent data (thanks @Smartsheet-JB-Brown!)
+- Fix prompt enhancement for Bedrock (thanks @Smartsheet-JB-Brown!)
+- Allow processes to access the Roo Code API via a unix socket
+- Improve zh-TW Traditional Chinese translations (thanks @PeterDaveHello!)
+- Add support for Azure AI Inference Service with DeepSeek-V3 model (thanks @thomasjeung!)
+- Fix off-by-one error in tree-sitter line numbers
+- Remove the experimental unified diff
+- Make extension icon more visible in different themes
+
+## [3.11.3] - 2025-03-31
+
+- Revert mention changes in case they're causing performance issues/crashes
+
+## [3.11.2] - 2025-03-31
+
+- Fix bug in loading Requesty key balance
+- Fix bug with Bedrock inference profiles
+- Update the webview when changing settings via the API
+- Refactor webview messages code (thanks @diarmidmackenzie!)
+
+## [3.11.1] - 2025-03-30
+
+- Relax provider profiles schema and add telemetry
+
+## [3.11.0] - 2025-03-30
+
+- Replace single-block-diff with multi-block-diff fast editing strategy
+- Support project-level MCP config in .roo/mcp.json (thanks @aheizi!)
+- Show OpenRouter and Requesty key balance on the settings screen
+- Support import/export of settings
+- Add pinning and sorting for API configuration dropdown (thanks @jwcraig!)
+- Add Gemini 2.5 Pro to GCP Vertex AI provider (thanks @nbihan-mediware!)
+- Smarter retry logic for Gemini
+- Fix Gemini command escaping
+- Support @-mentions of files with spaces in the name (thanks @samhvw8!)
+- Improvements to partial file reads (thanks @KJ7LNW!)
+- Fix list_code_definition_names to support files (thanks @KJ7LNW!)
+- Refactor tool-calling logic to make the code a lot easier to work with (thanks @diarmidmackenzie, @bramburn, @KJ7LNW, and everyone else who helped!)
+- Prioritize “Add to Context” in the code actions and include line numbers (thanks @samhvw8!)
+- Add an activation command that other extensions can use to interface with Roo Code (thanks @gtaylor!)
+- Preserve language characters in file @-mentions (thanks @aheizi!)
+- Browser tool improvements (thanks @afshawnlotfi!)
+- Display info about partial reads in the chat row
+- Link to the settings page from the auto-approve toolbar
+- Link to provider docs from the API options
+- Fix switching profiles to ensure only the selected profile is switched (thanks @feifei325!)
+- Allow custom o3-mini- model from OpenAI-compatible providers (thanks @snoyiatk!)
+- Edit suggested answers before accepting them (thanks @samhvw8!)
+
+## [3.10.5] - 2025-03-25
+
+- Updated value of max tokens for gemini-2.5-pro-03-25 to 65,536 (thanks @linegel!)
+- Fix logic around when we fire task completion events
+
+## [3.10.4] - 2025-03-25
+
+- Dynamically fetch instructions for creating/editing custom modes and MCP servers (thanks @diarmidmackenzie!)
+- Added Gemini 2.5 Pro model to Google Gemini provider (thanks @samsilveira!)
+- Add settings to control whether to auto-approve reads and writes outside of the workspace
+- Update UX for chat text area (thanks @chadgauth!)
+- Support a custom storage path for tasks (thanks @Chenjiayuan195!)
+- Add a New Task command in the Command Palette (thanks @qdaxb!)
+- Add R1 support checkbox to Open AI compatible provider to support QWQ (thanks @teddyOOXX!)
+- Support test declarations in TypeScript tree-sitter queries (thanks @KJ7LNW!)
+- Add Bedrock support for application-inference-profile (thanks @maekawataiki!)
+- Rename and migrate global MCP and modes files (thanks @StevenTCramer!)
+- Add watchPaths option to McpHub for file change detection (thanks @01Rian!)
+- Read image responses from MCP calls (thanks @nevermorec!)
+- Add taskCreated event to API and subscribe to Cline events earlier (thanks @wkordalski!)
+- Fixes to numeric formatting suffix internationalization (thanks @feifei325!)
+- Fix open tab support in the context mention suggestions (thanks @aheizi!)
+- Better display of OpenRouter “overloaded” error messages
+- Fix browser tool visibility in system prompt preview (thanks @cannuri!)
+- Fix the supportsPromptCache value for OpenAI models (thanks @PeterDaveHello!)
+- Fix readme links to docs (thanks @kvokka!)
+- Run ‘npm audit fix’ on all of our libraries
+
+## [3.10.3] - 2025-03-23
+
+- Update the welcome page to provide 1-click OAuth flows with LLM routers (thanks @dtrugman!)
+- Switch to a more direct method of tracking OpenRouter tokens/spend
+- Make partial file reads backwards-compatible with custom system prompts and give users more control over the chunk size
+- Fix issues where questions and suggestions weren’t showing up for non-streaming models and were hard to read in some themes
+- A variety of fixes and improvements to experimental multi-block diff (thanks @KJ7LNW!)
+- Fix opacity of drop-down menus in settings (thanks @KJ7LNW!)
+- Fix bugs with reading and mentioning binary files like PDFs
+- Fix the pricing information for OpenRouter free models (thanks @Jdo300!)
+- Fix an issue with our unit tests on Windows (thanks @diarmidmackenzie!)
+- Fix a maxTokens issue for the Outbound provider (thanks @pugazhendhi-m!)
+- Fix a line number issue with partial file reads (thanks @samhvw8!)
+
+## [3.10.2] - 2025-03-21
+
+- Fixes to context mentions on Windows
+- Fixes to German translations (thanks @cannuri!)
+- Fixes to telemetry banner internationalization
+- Sonnet 3.7 non-thinking now correctly uses 8192 max output tokens
+
+## [3.10.1] - 2025-03-20
+
+- Make the suggested responses optional to not break overridden system prompts
+
+## [3.10.0] - 2025-03-20
+
+- Suggested responses to questions (thanks samhvw8!)
+- Support for reading large files in chunks (thanks samhvw8!)
+- More consistent @-mention lookups of files and folders
+- Consolidate code actions into a submenu (thanks samhvw8!)
+- Fix MCP error logging (thanks aheizi!)
+- Improvements to search_files tool formatting and logic (thanks KJ7LNW!)
+- Fix changelog formatting in GitHub Releases (thanks pdecat!)
+- Add fake provider for integration tests (thanks franekp!)
+- Reflect Cross-region inference option in ap-xx region (thanks Yoshino-Yukitaro!)
+- Fix bug that was causing task history to be lost when using WSL
+
+## [3.9.2] - 2025-03-19
+
+- Update GitHub Actions workflow to automatically create GitHub Releases (thanks @pdecat!)
+- Correctly persist the text-to-speech speed state (thanks @heyseth!)
+- Fixes to French translations (thanks @arthurauffray!)
+- Optimize build time for local development (thanks @KJ7LNW!)
+- VSCode theme fixes for select, dropdown and command components
+- Bring back the ability to manually enter a model name in the model picker
+- Fix internationalization of the announcement title and the browser
+
+## [3.9.1] - 2025-03-18
+
+- Pass current language to system prompt correctly so Roo thinks and speaks in the selected language
+
+## [3.9.0] - 2025-03-18
+
+- Internationalize Roo Code into Catalan, German, Spanish, French, Hindi, Italian, Japanese, Korean, Polish, Portuguese, Turkish, Vietnamese, Simplified Chinese, and Traditional Chinese (thanks @feifei325!)
+- Bring back support for MCP over SSE (thanks @aheizi!)
+- Add a text-to-speech option to have Roo talk to you as it works (thanks @heyseth!)
+- Choose a specific provider when using OpenRouter (thanks PhunkyBob!)
+- Support batch deletion of task history (thanks @aheizi!)
+- Internationalize Human Relay, adjust the layout, and make it work on the welcome screen (thanks @NyxJae!)
+- Fix shell integration race condition (thanks @KJ7LNW!)
+- Fix display updating for Bedrock custom ARNs that are prompt routers (thanks @Smartsheet-JB-Brown!)
+- Fix to exclude search highlighting when copying items from task history (thanks @im47cn!)
+- Fix context mentions to work with multiple-workspace projects (thanks @teddyOOXX!)
+- Fix to task history saving when running multiple Roos (thanks @samhvw8!)
+- Improve task deletion when underlying files are missing (thanks @GitlyHallows!)
+- Improve support for NixOS & direnv (thanks @wkordalski!)
+- Fix wheel scrolling when Roo is opened in editor tabs (thanks @GitlyHallows!)
+- Don’t automatically mention the file when using the "Add to context" code action (thanks @qdaxb!)
+- Expose task stack in `RooCodeAPI` (thanks @franekp!)
+- Give the models visibility into the current task's API cost
+
+## [3.8.6] - 2025-03-13
+
+- Revert SSE MCP support while we debug some config validation issues
+
+## [3.8.5] - 2025-03-12
+
+- Refactor terminal architecture to address critical issues with the current design (thanks @KJ7LNW!)
+- MCP over SSE (thanks @aheizi!)
+- Support for remote browser connections (thanks @afshawnlotfi!)
+- Preserve parent-child relationship when cancelling subtasks (thanks @cannuri!)
+- Custom baseUrl for Google AI Studio Gemini (thanks @dqroid!)
+- PowerShell-specific command handling (thanks @KJ7LNW!)
+- OpenAI-compatible DeepSeek/QwQ reasoning support (thanks @lightrabbit!)
+- Anthropic-style prompt caching in the OpenAI-compatible provider (thanks @dleen!)
+- Add Deepseek R1 for AWS Bedrock (thanks @ATempsch!)
+- Fix MarkdownBlock text color for Dark High Contrast theme (thanks @cannuri!)
+- Add gemini-2.0-pro-exp-02-05 model to vertex (thanks @shohei-ihaya!)
+- Bring back progress status for multi-diff edits (thanks @qdaxb!)
+- Refactor alert dialog styles to use the correct vscode theme (thanks @cannuri!)
+- Custom ARNs in AWS Bedrock (thanks @Smartsheet-JB-Brown!)
+- Update MCP servers directory path for platform compatibility (thanks @hannesrudolph!)
+- Fix browser system prompt inclusion rules (thanks @cannuri!)
+- Publish git tags to github from CI (thanks @pdecat!)
+- Fixes to OpenAI-style cost calculations (thanks @dtrugman!)
+- Fix to allow using an excluded directory as your working directory (thanks @Szpadel!)
+- Kotlin language support in list_code_definition_names tool (thanks @kohii!)
+- Better handling of diff application errors (thanks @qdaxb!)
+- Update Bedrock prices to the latest (thanks @Smartsheet-JB-Brown!)
+- Fixes to OpenRouter custom baseUrl support
+- Fix usage tracking for SiliconFlow and other providers that include usage on every chunk
+- Telemetry for checkpoint save/restore/diff and diff strategies
+
+## [3.8.4] - 2025-03-09
+
+- Roll back multi-diff progress indicator temporarily to fix a double-confirmation in saving edits
+- Add an option in the prompts tab to save tokens by disabling the ability to ask Roo to create/edit custom modes for you (thanks @hannesrudolph!)
+
+## [3.8.3] - 2025-03-09
+
+- Fix VS Code LM API model picker truncation issue
+
+## [3.8.2] - 2025-03-08
+
+- Create an auto-approval toggle for subtask creation and completion (thanks @shaybc!)
+- Show a progress indicator when using the multi-diff editing strategy (thanks @qdaxb!)
+- Add o3-mini support to the OpenAI-compatible provider (thanks @yt3trees!)
+- Fix encoding issue where unreadable characters were sometimes getting added to the beginning of files
+- Fix issue where settings dropdowns were getting truncated in some cases
+
+## [3.8.1] - 2025-03-07
+
+- Show the reserved output tokens in the context window visualization
+- Improve the UI of the configuration profile dropdown (thanks @DeXtroTip!)
+- Fix bug where custom temperature could not be unchecked (thanks @System233!)
+- Fix bug where decimal prices could not be entered for OpenAI-compatible providers (thanks @System233!)
+- Fix bug with enhance prompt on Sonnet 3.7 with a high thinking budget (thanks @moqimoqidea!)
+- Fix bug with the context window management for thinking models (thanks @ReadyPlayerEmma!)
+- Fix bug where checkpoints were no longer enabled by default
+- Add extension and VSCode versions to telemetry
+
+## [3.8.0] - 2025-03-07
+
+- Add opt-in telemetry to help us improve Roo Code faster (thanks Cline!)
+- Fix terminal overload / gray screen of death, and other terminal issues
+- Add a new experimental diff editing strategy that applies multiple diff edits at once (thanks @qdaxb!)
+- Add support for a .rooignore to prevent Roo Code from read/writing certain files, with a setting to also exclude them from search/lists (thanks Cline!)
+- Update the new_task tool to return results to the parent task on completion, supporting better orchestration (thanks @shaybc!)
+- Support running Roo in multiple editor windows simultaneously (thanks @samhvw8!)
+- Make checkpoints asynchronous and exclude more files to speed them up
+- Redesign the settings page to make it easier to navigate
+- Add credential-based authentication for Vertex AI, enabling users to easily switch between Google Cloud accounts (thanks @eonghk!)
+- Update the DeepSeek provider with the correct baseUrl and track caching correctly (thanks @olweraltuve!)
+- Add a new “Human Relay” provider that allows you to manually copy information to a Web AI when needed, and then paste the AI's response back into Roo Code (thanks @NyxJae)!
+- Add observability for OpenAI providers (thanks @refactorthis!)
+- Support speculative decoding for LM Studio local models (thanks @adamwlarson!)
+- Improve UI for mode/provider selectors in chat
+- Improve styling of the task headers (thanks @monotykamary!)
+- Improve context mention path handling on Windows (thanks @samhvw8!)
+
+## [3.7.12] - 2025-03-03
- Expand max tokens of thinking models to 128k, and max thinking budget to over 100k (thanks @monotykamary!)
- Fix issue where keyboard mode switcher wasn't updating API profile (thanks @aheizi!)
@@ -12,19 +1101,19 @@
- Update the warning text for the VS LM API
- Correctly populate the default OpenRouter model on the welcome screen
-## [3.7.11]
+## [3.7.11] - 2025-03-02
- Don't honor custom max tokens for non thinking models
- Include custom modes in mode switching keyboard shortcut
- Support read-only modes that can run commands
-## [3.7.10]
+## [3.7.10] - 2025-03-01
- Add Gemini models on Vertex AI (thanks @ashktn!)
- Keyboard shortcuts to switch modes (thanks @aheizi!)
- Add support for Mermaid diagrams (thanks Cline!)
-## [3.7.9]
+## [3.7.9] - 2025-03-01
- Delete task confirmation enhancements
- Smarter context window management
@@ -34,19 +1123,19 @@
- UI fix to dropdown hover colors (thanks @SamirSaji!)
- Add support for Claude Sonnet 3.7 thinking via Vertex AI (thanks @lupuletic!)
-## [3.7.8]
+## [3.7.8] - 2025-02-27
- Add Vertex AI prompt caching support for Claude models (thanks @aitoroses and @lupuletic!)
- Add gpt-4.5-preview
- Add an advanced feature to customize the system prompt
-## [3.7.7]
+## [3.7.7] - 2025-02-27
- Graduate checkpoints out of beta
- Fix enhance prompt button when using Thinking Sonnet
- Add tooltips to make what buttons do more obvious
-## [3.7.6]
+## [3.7.6] - 2025-02-26
- Handle really long text better in the in the ChatRow similar to TaskHeader (thanks @joemanley201!)
- Support multiple files in drag-and-drop
@@ -54,56 +1143,56 @@
- Better OpenRouter error handling (no more "Provider Error")
- Add slider to control max output tokens for thinking models
-## [3.7.5]
+## [3.7.5] - 2025-02-26
-- Fix context window truncation math (see [#1173](https://github.com/RooVetGit/Roo-Code/issues/1173))
+- Fix context window truncation math (see [#1173](https://github.com/RooCodeInc/Roo-Code/issues/1173))
- Fix various issues with the model picker (thanks @System233!)
- Fix model input / output cost parsing (thanks @System233!)
- Add drag-and-drop for files
- Enable the "Thinking Budget" slider for Claude 3.7 Sonnet on OpenRouter
-## [3.7.4]
+## [3.7.4] - 2025-02-25
- Fix a bug that prevented the "Thinking" setting from properly updating when switching profiles.
-## [3.7.3]
+## [3.7.3] - 2025-02-25
- Support for ["Thinking"](https://docs.anthropic.com/en/docs/build-with-claude/extended-thinking) Sonnet 3.7 when using the Anthropic provider.
-## [3.7.2]
+## [3.7.2] - 2025-02-24
- Fix computer use and prompt caching for OpenRouter's `anthropic/claude-3.7-sonnet:beta` (thanks @cte!)
- Fix sliding window calculations for Sonnet 3.7 that were causing a context window overflow (thanks @cte!)
- Encourage diff editing more strongly in the system prompt (thanks @hannesrudolph!)
-## [3.7.1]
+## [3.7.1] - 2025-02-24
- Add AWS Bedrock support for Sonnet 3.7 and update some defaults to Sonnet 3.7 instead of 3.5
-## [3.7.0]
+## [3.7.0] - 2025-02-24
- Introducing Roo Code 3.7, with support for the new Claude Sonnet 3.7. Because who cares about skipping version numbers anymore? Thanks @lupuletic and @cte for the PRs!
-## [3.3.26]
+## [3.3.26] - 2025-02-27
- Adjust the default prompt for Debug mode to focus more on diagnosis and to require user confirmation before moving on to implementation
-## [3.3.25]
+## [3.3.25] - 2025-02-21
- Add a "Debug" mode that specializes in debugging tricky problems (thanks [Ted Werbel](https://x.com/tedx_ai/status/1891514191179309457) and [Carlos E. Perez](https://x.com/IntuitMachine/status/1891516362486337739)!)
- Add an experimental "Power Steering" option to significantly improve adherence to role definitions and custom instructions
-## [3.3.24]
+## [3.3.24] - 2025-02-20
- Fixed a bug with region selection preventing AWS Bedrock profiles from being saved (thanks @oprstchn!)
- Updated the price of gpt-4o (thanks @marvijo-code!)
-## [3.3.23]
+## [3.3.23] - 2025-02-20
- Handle errors more gracefully when reading custom instructions from files (thanks @joemanley201!)
- Bug fix to hitting "Done" on settings page with unsaved changes (thanks @System233!)
-## [3.3.22]
+## [3.3.22] - 2025-02-20
- Improve the Provider Settings configuration with clear Save buttons and warnings about unsaved changes (thanks @System233!)
- Correctly parse `` reasoning tags from Ollama models (thanks @System233!)
@@ -113,7 +1202,7 @@
- Fix a bug where the .roomodes file was not automatically created when adding custom modes from the Prompts tab
- Allow setting a wildcard (`*`) to auto-approve all command execution (use with caution!)
-## [3.3.21]
+## [3.3.21] - 2025-02-17
- Fix input box revert issue and configuration loss during profile switch (thanks @System233!)
- Fix default preferred language for zh-cn and zh-tw (thanks @System233!)
@@ -122,7 +1211,7 @@
- Fix system prompt to make sure Roo knows about all available modes
- Enable streaming mode for OpenAI o1
-## [3.3.20]
+## [3.3.20] - 2025-02-14
- Support project-specific custom modes in a .roomodes file
- Add more Mistral models (thanks @d-oit and @bramburn!)
@@ -130,7 +1219,7 @@
- Add a setting to control the number of open editor tabs to tell the model about (665 is probably too many!)
- Fix race condition bug with entering API key on the welcome screen
-## [3.3.19]
+## [3.3.19] - 2025-02-12
- Fix a bug where aborting in the middle of file writes would not revert the write
- Honor the VS Code theme for dialog backgrounds
@@ -138,7 +1227,7 @@
- Add a help button that links to our new documentation site (which we would love help from the community to improve!)
- Switch checkpoints logic to use a shadow git repository to work around issues with hot reloads and polluting existing repositories (thanks Cline for the inspiration!)
-## [3.3.18]
+## [3.3.18] - 2025-02-11
- Add a per-API-configuration model temperature setting (thanks @joemanley201!)
- Add retries for fetching usage stats from OpenRouter (thanks @jcbdev!)
@@ -149,18 +1238,18 @@
- Fix logic error where automatic retries were waiting twice as long as intended
- Rework the checkpoints code to avoid conflicts with file locks on Windows (sorry for the hassle!)
-## [3.3.17]
+## [3.3.17] - 2025-02-09
- Fix the restore checkpoint popover
- Unset git config that was previously set incorrectly by the checkpoints feature
-## [3.3.16]
+## [3.3.16] - 2025-02-09
- Support Volcano Ark platform through the OpenAI-compatible provider
- Fix jumpiness while entering API config by updating on blur instead of input
- Add tooltips on checkpoint actions and fix an issue where checkpoints were overwriting existing git name/email settings - thanks for the feedback!
-## [3.3.15]
+## [3.3.15] - 2025-02-08
- Improvements to MCP initialization and server restarts (thanks @MuriloFP and @hannesrudolph!)
- Add a copy button to the recent tasks (thanks @hannesrudolph!)
@@ -485,7 +1574,7 @@ Join us at https://www.reddit.com/r/RooCode to share your custom modes and be pa
## [2.2.16]
-- Incorporate Premshay's [PR](https://github.com/RooVetGit/Roo-Cline/pull/60) to add support for Amazon Nova and Meta Llama Models via Bedrock (3, 3.1, 3.2) and unified Bedrock calls using BedrockClient and Bedrock Runtime API
+- Incorporate Premshay's [PR](https://github.com/RooCodeInc/Roo-Code/pull/60) to add support for Amazon Nova and Meta Llama Models via Bedrock (3, 3.1, 3.2) and unified Bedrock calls using BedrockClient and Bedrock Runtime API
## [2.2.14 - 2.2.15]
@@ -557,7 +1646,7 @@ Join us at https://www.reddit.com/r/RooCode to share your custom modes and be pa
## [2.1.15]
-- Incorporate dbasclpy's [PR](https://github.com/RooVetGit/Roo-Cline/pull/54) to add support for gemini-exp-1206
+- Incorporate dbasclpy's [PR](https://github.com/RooCodeInc/Roo-Code/pull/54) to add support for gemini-exp-1206
- Make it clear that diff editing is very experimental
## [2.1.14]
@@ -567,7 +1656,7 @@ Join us at https://www.reddit.com/r/RooCode to share your custom modes and be pa
## [2.1.13]
-- Fix https://github.com/RooVetGit/Roo-Cline/issues/50 where sound effects were not respecting settings
+- Fix https://github.com/RooCodeInc/Roo-Code/issues/50 where sound effects were not respecting settings
## [2.1.12]
@@ -575,7 +1664,7 @@ Join us at https://www.reddit.com/r/RooCode to share your custom modes and be pa
## [2.1.11]
-- Incorporate lloydchang's [PR](https://github.com/RooVetGit/Roo-Cline/pull/42) to add support for OpenRouter compression
+- Incorporate lloydchang's [PR](https://github.com/RooCodeInc/Roo-Code/pull/42) to add support for OpenRouter compression
## [2.1.10]
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
new file mode 100644
index 0000000000..fee05d7225
--- /dev/null
+++ b/CODE_OF_CONDUCT.md
@@ -0,0 +1,90 @@
+
+
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+- The use of sexualized language or imagery and unwelcome sexual attention or
+ advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic
+ address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a
+ professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at support@roocode.com. All complaints
+will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from [Cline's version][cline_coc] of the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[cline_coc]: https://github.com/cline/cline/blob/main/CODE_OF_CONDUCT.md
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000000..c23c424f41
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,138 @@
+
+
+# Contributing to Roo Code
+
+Roo Code is a community-driven project, and we deeply value every contribution. To streamline collaboration, we operate on an [Issue-First](#issue-first-approach) basis, meaning all [Pull Requests (PRs)](#submitting-a-pull-request) must first be linked to a GitHub Issue. Please review this guide carefully.
+
+## Table of Contents
+
+- [Before You Contribute](#before-you-contribute)
+- [Finding & Planning Your Contribution](#finding--planning-your-contribution)
+- [Development & Submission Process](#development--submission-process)
+- [Legal](#legal)
+
+## Before You Contribute
+
+### 1. Code of Conduct
+
+All contributors must adhere to our [Code of Conduct](./CODE_OF_CONDUCT.md).
+
+### 2. Project Roadmap
+
+Our roadmap guides the project's direction. Align your contributions with these key goals:
+
+### Reliability First
+
+- Ensure diff editing and command execution are consistently reliable.
+- Reduce friction points that deter regular usage.
+- Guarantee smooth operation across all locales and platforms.
+- Expand robust support for a wide variety of AI providers and models.
+
+### Enhanced User Experience
+
+- Streamline the UI/UX for clarity and intuitiveness.
+- Continuously improve the workflow to meet the high expectations developers have for daily-use tools.
+
+### Leading on Agent Performance
+
+- Establish comprehensive evaluation benchmarks (evals) to measure real-world productivity.
+- Make it easy for everyone to easily run and interpret these evals.
+- Ship improvements that demonstrate clear increases in eval scores.
+
+Mention alignment with these areas in your PRs.
+
+### 3. Join the Roo Code Community
+
+- **Primary:** Join our [Discord](https://discord.gg/roocode) and DM **Hannes Rudolph (`hrudolph`)**.
+- **Alternative:** Experienced contributors can engage directly via [GitHub Projects](https://github.com/orgs/RooCodeInc/projects/1).
+
+## Finding & Planning Your Contribution
+
+### Types of Contributions
+
+- **Bug Fixes:** Addressing code issues.
+- **New Features:** Adding functionality.
+- **Documentation:** Improving guides and clarity.
+
+### Issue-First Approach
+
+All contributions must begin with a GitHub Issue.
+
+- **Check existing issues**: Search [GitHub Issues](https://github.com/RooCodeInc/Roo-Code/issues).
+- **Create an issue**: Use appropriate templates:
+ - **Bugs:** "Bug Report" template.
+ - **Features:** "Detailed Feature Proposal" template. Approval required before starting.
+- **Claim issues**: Comment and await official assignment.
+
+**PRs without approved issues may be closed.**
+
+### Deciding What to Work On
+
+- Check the [GitHub Project](https://github.com/orgs/RooCodeInc/projects/1) for unassigned "Good First Issues."
+- For docs, visit [Roo Code Docs](https://github.com/RooCodeInc/Roo-Code-Docs).
+
+### Reporting Bugs
+
+- Check for existing reports first.
+- Create new bugs using the ["Bug Report" template](https://github.com/RooCodeInc/Roo-Code/issues/new/choose).
+- **Security issues**: Report privately via [security advisories](https://github.com/RooCodeInc/Roo-Code/security/advisories/new).
+
+## Development & Submission Process
+
+### Development Setup
+
+1. **Fork & Clone:**
+
+```
+git clone https://github.com/YOUR_USERNAME/Roo-Code.git
+```
+
+2. **Install Dependencies:**
+
+```
+pnpm install
+```
+
+3. **Debugging:** Open with VS Code (`F5`).
+
+### Writing Code Guidelines
+
+- One focused PR per feature or fix.
+- Follow ESLint and TypeScript best practices.
+- Write clear, descriptive commits referencing issues (e.g., `Fixes #123`).
+- Provide thorough testing (`npm test`).
+- Rebase onto the latest `main` branch before submission.
+
+### Submitting a Pull Request
+
+- Begin as a **Draft PR** if seeking early feedback.
+- Clearly describe your changes following the Pull Request Template.
+- Provide screenshots/videos for UI changes.
+- Indicate if documentation updates are necessary.
+
+### Pull Request Policy
+
+- Must reference pre-approved, assigned issues.
+- PRs without adherence to the policy may be closed.
+- PRs should pass CI tests, align with the roadmap, and have clear documentation.
+
+### Review Process
+
+- **Daily Triage:** Quick checks by maintainers.
+- **Weekly In-depth Review:** Comprehensive assessment.
+- **Iterate promptly** based on feedback.
+
+## Legal
+
+By contributing, you agree your contributions will be licensed under the Apache 2.0 License, consistent with Roo Code's licensing.
diff --git a/LICENSE b/LICENSE
index 194125d855..302fa51c8a 100644
--- a/LICENSE
+++ b/LICENSE
@@ -186,7 +186,7 @@
same "printed page" as the copyright notice for easier
identification within third-party archives.
- Copyright 2025 Roo Veterinary Inc.
+ Copyright 2025 Roo Code, Inc.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
@@ -198,4 +198,4 @@
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
- limitations under the License.
\ No newline at end of file
+ limitations under the License.
diff --git a/PRIVACY.md b/PRIVACY.md
new file mode 100644
index 0000000000..306d52f059
--- /dev/null
+++ b/PRIVACY.md
@@ -0,0 +1,38 @@
+# Roo Code Privacy Policy
+
+**Last Updated: June 10th, 2025**
+
+Roo Code respects your privacy and is committed to transparency about how we handle your data. Below is a simple breakdown of where key pieces of data go—and, importantly, where they don’t.
+
+### **Where Your Data Goes (And Where It Doesn’t)**
+
+- **Code & Files**: Roo Code accesses files on your local machine when needed for AI-assisted features. When you send commands to Roo Code, relevant files may be transmitted to your chosen AI model provider (e.g., OpenAI, Anthropic, OpenRouter) to generate responses. We do not have access to this data, but AI providers may store it per their privacy policies.
+- **Commands**: Any commands executed through Roo Code happen on your local environment. However, when you use AI-powered features, the relevant code and context from your commands may be transmitted to your chosen AI model provider (e.g., OpenAI, Anthropic, OpenRouter) to generate responses. We do not have access to or store this data, but AI providers may process it per their privacy policies.
+- **Prompts & AI Requests**: When you use AI-powered features, your prompts and relevant project context are sent to your chosen AI model provider (e.g., OpenAI, Anthropic, OpenRouter) to generate responses. We do not store or process this data. These AI providers have their own privacy policies and may store data per their terms of service.
+- **API Keys & Credentials**: If you enter an API key (e.g., to connect an AI model), it is stored locally on your device and never sent to us or any third party, except the provider you have chosen.
+- **Telemetry (Usage Data)**: We only collect feature usage and error data if you explicitly opt-in. This telemetry is powered by PostHog and helps us understand feature usage to improve Roo Code. This includes your VS Code machine ID and feature usage patterns and exception reports. We do **not** collect personally identifiable information, your code, or AI prompts.
+- **Marketplace Requests**: When you browse or search the Marketplace for Model Configuration Profiles (MCPs) or Custom Modes, Roo Code makes a secure API call to Roo Code’s backend servers to retrieve listing information. These requests send only the query parameters (e.g., extension version, search term) necessary to fulfill the request and do not include your code, prompts, or personally identifiable information.
+
+### **How We Use Your Data (If Collected)**
+
+- If you opt-in to telemetry, we use it to understand feature usage and improve Roo Code.
+- We do **not** sell or share your data.
+- We do **not** train any models on your data.
+
+### **Your Choices & Control**
+
+- You can run models locally to prevent data being sent to third-parties.
+- By default, telemetry collection is off and if you turn it on, you can opt out of telemetry at any time.
+- You can delete Roo Code to stop all data collection.
+
+### **Security & Updates**
+
+We take reasonable measures to secure your data, but no system is 100% secure. If our privacy policy changes, we will notify you within the extension.
+
+### **Contact Us**
+
+For any privacy-related questions, reach out to us at support@roocode.com.
+
+---
+
+By using Roo Code, you agree to this Privacy Policy.
diff --git a/README.md b/README.md
index 94abdbf087..e94f0d884a 100644
--- a/README.md
+++ b/README.md
@@ -1,19 +1,34 @@