Remove roocode.com web app (#12375)

* Remove contributor and community references

* shutdown notice

* Allow empty web app test suite

.changeset/changelog-config.js

@@ -1,9 +1,9 @@
 const getReleaseLine = async (changeset) => {
-	const [firstLine] = changeset.summary
+	const lines = changeset.summary
 		.split("\n")
 		.map((l) => l.trim())
 		.filter(Boolean)
-	return `- ${firstLine}`
+	return lines.map((line) => (line.startsWith("- ") ? line : `- ${line}`)).join("\n")
 }
 
 const getDependencyReleaseLine = async () => {

.changeset/config.json

@@ -7,5 +7,5 @@
 	"access": "restricted",
 	"baseBranch": "main",
 	"updateInternalDependencies": "patch",
-	"ignore": []
+	"ignore": ["@roo-code/cli"]
 }

.changeset/v3.54.0.md

@@ -0,0 +1,15 @@
+---
+"roo-cline": minor
+---
+
+- Remove: Roo Code Cloud and eval infrastructure from the extension, CLI, workflows, and package surfaces so the release is focused on the standalone extension (PR #12328 by @mrubens)
+- Remove: All telemetry collection and analytics plumbing across the extension, website, shared types, provider flows, and related tests (PR #12324 by @mrubens)
+- Remove: MDM and organization membership enforcement, including host wiring, webview state, user-facing messages, and locale strings (PR #12323 by @mrubens)
+- Remove: The MCP marketplace, marketplace services, webview marketplace UI, package contributions, and related localized copy (PR #12326 by @mrubens)
+- Update: Extension-facing support, diagnostics, and announcement content for the final Roo Code release, including GitHub help paths and links to Roomote, ZooCode, and Cline (PR #12341 by @brunobergher)
+- Add: A cleaned docs app with GitHub Pages deployment support (PR #12344 by @brunobergher)
+- Fix: Configure the docs GitHub Pages base URL so deployed assets and canonical paths load correctly under the repository Pages path (PR #12370 by @mrubens)
+- Update: Point docs links in the root README, localized READMEs, and web app copy to the current GitHub Pages docs URL (PR #12371 by @mrubens)
+- Remove: Stale `roocode.github.io` docs references, including the old CNAME and outdated docs README and robots.txt URLs (PR #12372 by @mrubens)
+- Update: The website to focus almost entirely on the Roo Code extension and remove cloud, team, enterprise, provider, pricing, Slack, and Linear product pages (PR #12180 by @brunobergher)
+- Remove: Contributor, community, social channel, and tutorial references from README files, docs, website copy, issue templates, and workflows (PR #12347 by @brunobergher)

.dockerignore

@@ -76,14 +76,18 @@ src/node_modules
 !pnpm-workspace.yaml
 !scripts/bootstrap.mjs
 !apps/web-evals/
+!apps/cli/
 !src/
 !webview-ui/
 !packages/evals/.docker/entrypoints/runner.sh
 !packages/build/
 !packages/config-eslint/
 !packages/config-typescript/
+!packages/core/
 !packages/evals/
 !packages/ipc/
 !packages/telemetry/
 !packages/types/
+!packages/vscode-shim/
+!packages/cloud/
 !locales/

.github/CODEOWNERS

@@ -1,2 +1,2 @@
 # These owners will be the default owners for everything in the repo
-* @mrubens @cte @jr
+* @mrubens @cte @jr @hannesrudolph @daniel-lxs

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -81,11 +81,9 @@ body:
         - DeepSeek
         - Featherless AI
         - Fireworks AI
-        - Glama
         - Google Gemini
         - Google Vertex AI
         - Groq
-        - Human Relay Provider
         - LiteLLM
         - LM Studio
         - Mistral AI

.github/ISSUE_TEMPLATE/config.yml

@@ -1,8 +1,5 @@
 blank_issues_enabled: false
 contact_links:
-    - name: Feature Request
-      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
       about: Enjoying Roo Code? Leave a review here!

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -64,7 +64,7 @@ body:
     attributes:
       value: |
         ---
-        Optional (for contributors): You can stop here if you're just proposing the improvement.
+        Optional: You can stop here if you're just proposing the improvement.
 
   - type: textarea
     id: acceptance-criteria

.github/pull_request_template.md

@@ -1,75 +0,0 @@
-<!--
-Thank you for contributing to Roo Code!
-
-Before submitting your PR, please ensure:
-- It's linked to an approved GitHub Issue.
-- You've reviewed our [Contributing Guidelines](../CONTRIBUTING.md).
--->
-
-### Related GitHub Issue
-
-<!-- Every PR MUST be linked to an approved issue. -->
-
-Closes: # <!-- Replace with the issue number, e.g., Closes: #123 -->
-
-### Roo Code Task Context (Optional)
-
-<!--
-If you used Roo Code to help create this PR, you can share public task links here.
-This helps reviewers understand your development process and provides additional context.
-Example: https://app.roocode.com/share/task-id
--->
-
-### Description
-
-<!--
-Briefly summarize the changes in this PR and how they address the linked issue.
-The issue should cover the "what" and "why"; this section should focus on:
-- The "how": key implementation details, design choices, or trade-offs made.
-- Anything specific reviewers should pay attention to in this PR.
--->
-
-### Test Procedure
-
-<!--
-Detail the steps to test your changes. This helps reviewers verify your work.
-- How did you test this specific implementation? (e.g., unit tests, manual testing steps)
-- How can reviewers reproduce your tests or verify the fix/feature?
-- Include relevant testing environment details if applicable.
--->
-
-### Pre-Submission Checklist
-
-<!-- Go through this checklist before marking your PR as ready for review. -->
-
-- [ ] **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
-
-<!--
-For UI changes, please provide before-and-after screenshots or a short video of the *actual results*.
-This greatly helps in understanding the visual impact of your changes.
--->
-
-### Documentation Updates
-
-<!--
-Does this PR necessitate updates to user-facing documentation?
-- [ ] No documentation updates are required.
-- [ ] Yes, documentation updates are required. (Please describe what needs to be updated or link to a PR in the docs repository).
--->
-
-### Additional Notes
-
-<!-- Add any other context, questions, or information for reviewers here. -->
-
-### Get in Touch
-
-<!--
-Please provide your Discord username for reviewers or maintainers to reach you if they have questions about your PR
--->

.github/workflows/cli-release.yml

@@ -0,0 +1,394 @@
+name: CLI Release
+
+on:
+  workflow_dispatch:
+    inputs:
+      version:
+        description: 'Version to release (e.g., 0.1.0). Leave empty to use package.json version.'
+        required: false
+        type: string
+      dry_run:
+        description: 'Dry run (build and test but do not create release).'
+        required: false
+        type: boolean
+        default: false
+
+jobs:
+  # Build CLI for each platform.
+  build:
+    strategy:
+      fail-fast: false
+      matrix:
+        include:
+          - os: macos-latest
+            platform: darwin-arm64
+            runs-on: macos-latest
+          - os: ubuntu-latest
+            platform: linux-x64
+            runs-on: ubuntu-latest
+          - os: ubuntu-24.04-arm
+            platform: linux-arm64
+            runs-on: ubuntu-24.04-arm
+
+    runs-on: ${{ matrix.runs-on }}
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - name: Setup Node.js and pnpm
+        uses: ./.github/actions/setup-node-pnpm
+
+      - name: Get version
+        id: version
+        run: |
+          if [ -n "${{ inputs.version }}" ]; then
+            VERSION="${{ inputs.version }}"
+          else
+            VERSION=$(node -p "require('./apps/cli/package.json').version")
+          fi
+          echo "version=$VERSION" >> $GITHUB_OUTPUT
+          echo "tag=cli-v$VERSION" >> $GITHUB_OUTPUT
+          echo "Using version: $VERSION"
+
+      - name: Build extension bundle
+        run: pnpm bundle
+
+      - name: Build CLI
+        run: pnpm --filter @roo-code/cli build
+
+      - name: Create release tarball
+        id: tarball
+        env:
+          VERSION: ${{ steps.version.outputs.version }}
+          PLATFORM: ${{ matrix.platform }}
+        run: |
+          RELEASE_DIR="roo-cli-${PLATFORM}"
+          TARBALL="roo-cli-${PLATFORM}.tar.gz"
+
+          # Clean up any previous build.
+          rm -rf "$RELEASE_DIR"
+          rm -f "$TARBALL"
+
+          # Create directory structure.
+          mkdir -p "$RELEASE_DIR/bin"
+          mkdir -p "$RELEASE_DIR/lib"
+          mkdir -p "$RELEASE_DIR/extension"
+
+          # Copy CLI dist files.
+          echo "Copying CLI files..."
+          cp -r apps/cli/dist/* "$RELEASE_DIR/lib/"
+
+          # Create package.json for npm install.
+          echo "Creating package.json..."
+          node -e "
+            const pkg = require('./apps/cli/package.json');
+            const newPkg = {
+              name: '@roo-code/cli',
+              version: '$VERSION',
+              type: 'module',
+              dependencies: {
+                '@inkjs/ui': pkg.dependencies['@inkjs/ui'],
+                '@trpc/client': pkg.dependencies['@trpc/client'],
+                'commander': pkg.dependencies.commander,
+                'fuzzysort': pkg.dependencies.fuzzysort,
+                'ink': pkg.dependencies.ink,
+                'p-wait-for': pkg.dependencies['p-wait-for'],
+                'react': pkg.dependencies.react,
+                'superjson': pkg.dependencies.superjson,
+                'zustand': pkg.dependencies.zustand
+              }
+            };
+            console.log(JSON.stringify(newPkg, null, 2));
+          " > "$RELEASE_DIR/package.json"
+
+          # Copy extension bundle.
+          echo "Copying extension bundle..."
+          cp -r src/dist/* "$RELEASE_DIR/extension/"
+
+          # Add package.json to extension directory for CommonJS.
+          echo '{"type": "commonjs"}' > "$RELEASE_DIR/extension/package.json"
+
+          # Find and copy ripgrep binary.
+          echo "Looking for ripgrep binary..."
+          RIPGREP_PATH=$(find node_modules -path "*/@vscode/ripgrep/bin/rg" -type f 2>/dev/null | head -1)
+          if [ -n "$RIPGREP_PATH" ] && [ -f "$RIPGREP_PATH" ]; then
+            echo "Found ripgrep at: $RIPGREP_PATH"
+            mkdir -p "$RELEASE_DIR/node_modules/@vscode/ripgrep/bin"
+            cp "$RIPGREP_PATH" "$RELEASE_DIR/node_modules/@vscode/ripgrep/bin/"
+            chmod +x "$RELEASE_DIR/node_modules/@vscode/ripgrep/bin/rg"
+            mkdir -p "$RELEASE_DIR/bin"
+            cp "$RIPGREP_PATH" "$RELEASE_DIR/bin/"
+            chmod +x "$RELEASE_DIR/bin/rg"
+          else
+            echo "Warning: ripgrep binary not found"
+          fi
+
+          # Create the wrapper script
+          echo "Creating wrapper script..."
+          printf '%s\n' '#!/usr/bin/env node' \
+            '' \
+            "import { fileURLToPath } from 'url';" \
+            "import { dirname, join } from 'path';" \
+            '' \
+            'const __filename = fileURLToPath(import.meta.url);' \
+            'const __dirname = dirname(__filename);' \
+            '' \
+            '// Set environment variables for the CLI' \
+            "process.env.ROO_CLI_ROOT = join(__dirname, '..');" \
+            "process.env.ROO_EXTENSION_PATH = join(__dirname, '..', 'extension');" \
+            "process.env.ROO_RIPGREP_PATH = join(__dirname, 'rg');" \
+            '' \
+            '// Import and run the actual CLI' \
+            "await import(join(__dirname, '..', 'lib', 'index.js'));" \
+            > "$RELEASE_DIR/bin/roo"
+
+          chmod +x "$RELEASE_DIR/bin/roo"
+
+          # Create empty .env file.
+          touch "$RELEASE_DIR/.env"
+
+          # Create tarball.
+          echo "Creating tarball..."
+          tar -czvf "$TARBALL" "$RELEASE_DIR"
+
+          # Clean up release directory.
+          rm -rf "$RELEASE_DIR"
+
+          # Create checksum.
+          if command -v sha256sum &> /dev/null; then
+            sha256sum "$TARBALL" > "${TARBALL}.sha256"
+          elif command -v shasum &> /dev/null; then
+            shasum -a 256 "$TARBALL" > "${TARBALL}.sha256"
+          fi
+
+          echo "tarball=$TARBALL" >> $GITHUB_OUTPUT
+          echo "Created: $TARBALL"
+          ls -la "$TARBALL"
+
+      - name: Verify tarball
+        env:
+          PLATFORM: ${{ matrix.platform }}
+        run: |
+          TARBALL="roo-cli-${PLATFORM}.tar.gz"
+
+          # Create temp directory for verification.
+          VERIFY_DIR=$(mktemp -d)
+
+          # Extract and verify structure.
+          tar -xzf "$TARBALL" -C "$VERIFY_DIR"
+
+          echo "Verifying tarball contents..."
+          ls -la "$VERIFY_DIR/roo-cli-${PLATFORM}/"
+
+          # Check required files exist.
+          test -f "$VERIFY_DIR/roo-cli-${PLATFORM}/bin/roo" || { echo "Missing bin/roo"; exit 1; }
+          test -f "$VERIFY_DIR/roo-cli-${PLATFORM}/lib/index.js" || { echo "Missing lib/index.js"; exit 1; }
+          test -f "$VERIFY_DIR/roo-cli-${PLATFORM}/package.json" || { echo "Missing package.json"; exit 1; }
+          test -d "$VERIFY_DIR/roo-cli-${PLATFORM}/extension" || { echo "Missing extension directory"; exit 1; }
+
+          echo "Tarball verification passed!"
+
+          # Cleanup.
+          rm -rf "$VERIFY_DIR"
+
+      - name: Upload artifact
+        uses: actions/upload-artifact@v4
+        with:
+          name: cli-${{ matrix.platform }}
+          path: |
+            roo-cli-${{ matrix.platform }}.tar.gz
+            roo-cli-${{ matrix.platform }}.tar.gz.sha256
+          retention-days: 7
+
+  # Create GitHub release with all platform artifacts.
+  release:
+    needs: build
+    runs-on: ubuntu-latest
+    if: ${{ !inputs.dry_run }}
+    permissions:
+      contents: write
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+
+      - name: Get version
+        id: version
+        run: |
+          if [ -n "${{ inputs.version }}" ]; then
+            VERSION="${{ inputs.version }}"
+          else
+            VERSION=$(node -p "require('./apps/cli/package.json').version")
+          fi
+          echo "version=$VERSION" >> $GITHUB_OUTPUT
+          echo "tag=cli-v$VERSION" >> $GITHUB_OUTPUT
+
+      - name: Download all artifacts
+        uses: actions/download-artifact@v4
+        with:
+          path: artifacts
+
+      - name: Prepare release files
+        run: |
+          mkdir -p release
+          find artifacts -name "*.tar.gz" -exec cp {} release/ \;
+          find artifacts -name "*.sha256" -exec cp {} release/ \;
+          ls -la release/
+
+      - name: Extract changelog
+        id: changelog
+        env:
+          VERSION: ${{ steps.version.outputs.version }}
+        run: |
+          CHANGELOG_FILE="apps/cli/CHANGELOG.md"
+
+          if [ -f "$CHANGELOG_FILE" ]; then
+            # Extract content between version headers.
+            CONTENT=$(awk -v version="$VERSION" '
+              BEGIN { found = 0; content = ""; target = "[" version "]" }
+              /^## \[/ {
+                if (found) { exit }
+                if (index($0, target) > 0) { found = 1; next }
+              }
+              found { content = content $0 "\n" }
+              END { print content }
+            ' "$CHANGELOG_FILE")
+
+            if [ -n "$CONTENT" ]; then
+              echo "Found changelog content"
+              echo "content<<EOF" >> $GITHUB_OUTPUT
+              echo "$CONTENT" >> $GITHUB_OUTPUT
+              echo "EOF" >> $GITHUB_OUTPUT
+            else
+              echo "No changelog content found for version $VERSION"
+              echo "content=" >> $GITHUB_OUTPUT
+            fi
+          else
+            echo "No changelog file found"
+            echo "content=" >> $GITHUB_OUTPUT
+          fi
+
+      - name: Generate checksums summary
+        id: checksums
+        run: |
+          echo "checksums<<EOF" >> $GITHUB_OUTPUT
+          cat release/*.sha256 >> $GITHUB_OUTPUT
+          echo "EOF" >> $GITHUB_OUTPUT
+
+      - name: Check for existing release
+        id: check_release
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          TAG: ${{ steps.version.outputs.tag }}
+        run: |
+          if gh release view "$TAG" &> /dev/null; then
+            echo "exists=true" >> $GITHUB_OUTPUT
+          else
+            echo "exists=false" >> $GITHUB_OUTPUT
+          fi
+
+      - name: Delete existing release
+        if: steps.check_release.outputs.exists == 'true'
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          TAG: ${{ steps.version.outputs.tag }}
+        run: |
+          echo "Deleting existing release $TAG..."
+          gh release delete "$TAG" --yes || true
+          git push origin ":refs/tags/$TAG" || true
+
+      - name: Create GitHub Release
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          VERSION: ${{ steps.version.outputs.version }}
+          TAG: ${{ steps.version.outputs.tag }}
+          CHANGELOG_CONTENT: ${{ steps.changelog.outputs.content }}
+          CHECKSUMS: ${{ steps.checksums.outputs.checksums }}
+        run: |
+          NOTES_FILE=$(mktemp)
+
+          if [ -n "$CHANGELOG_CONTENT" ]; then
+            echo "## What's New" >> "$NOTES_FILE"
+            echo "" >> "$NOTES_FILE"
+            echo "$CHANGELOG_CONTENT" >> "$NOTES_FILE"
+            echo "" >> "$NOTES_FILE"
+          fi
+
+          echo "## Installation" >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo '```bash' >> "$NOTES_FILE"
+          echo "curl -fsSL https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/install.sh | sh" >> "$NOTES_FILE"
+          echo '```' >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo "Or install a specific version:" >> "$NOTES_FILE"
+          echo '```bash' >> "$NOTES_FILE"
+          echo "ROO_VERSION=$VERSION curl -fsSL https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/install.sh | sh" >> "$NOTES_FILE"
+          echo '```' >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo "## Requirements" >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo "- Node.js 20 or higher" >> "$NOTES_FILE"
+          echo "- macOS Apple Silicon (M1/M2/M3/M4), Linux x64, or Linux ARM64" >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo "## Usage" >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo '```bash' >> "$NOTES_FILE"
+          echo "# Run a task" >> "$NOTES_FILE"
+          echo 'roo "What is this project?"' >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo "# See all options" >> "$NOTES_FILE"
+          echo "roo --help" >> "$NOTES_FILE"
+          echo '```' >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo "## Platform Support" >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo "This release includes binaries for:" >> "$NOTES_FILE"
+          echo '- `roo-cli-darwin-arm64.tar.gz` - macOS Apple Silicon (M1/M2/M3)' >> "$NOTES_FILE"
+          echo '- `roo-cli-linux-x64.tar.gz` - Linux x64' >> "$NOTES_FILE"
+          echo '- `roo-cli-linux-arm64.tar.gz` - Linux ARM64' >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo "## Checksums" >> "$NOTES_FILE"
+          echo "" >> "$NOTES_FILE"
+          echo '```' >> "$NOTES_FILE"
+          echo "$CHECKSUMS" >> "$NOTES_FILE"
+          echo '```' >> "$NOTES_FILE"
+
+          gh release create "$TAG" \
+            --title "Roo Code CLI v$VERSION" \
+            --notes-file "$NOTES_FILE" \
+            --prerelease \
+            release/*
+
+          rm -f "$NOTES_FILE"
+          echo "Release created: https://github.com/${{ github.repository }}/releases/tag/$TAG"
+
+  # Summary job for dry runs
+  summary:
+    needs: build
+    runs-on: ubuntu-latest
+    if: ${{ inputs.dry_run }}
+
+    steps:
+      - name: Download all artifacts
+        uses: actions/download-artifact@v4
+        with:
+          path: artifacts
+
+      - name: Show build summary
+        run: |
+          echo "## Dry Run Complete" >> $GITHUB_STEP_SUMMARY
+          echo "" >> $GITHUB_STEP_SUMMARY
+          echo "The following artifacts were built:" >> $GITHUB_STEP_SUMMARY
+          echo "" >> $GITHUB_STEP_SUMMARY
+          find artifacts -name "*.tar.gz" | while read f; do
+            SIZE=$(ls -lh "$f" | awk '{print $5}')
+            echo "- $(basename $f) ($SIZE)" >> $GITHUB_STEP_SUMMARY
+          done
+          echo "" >> $GITHUB_STEP_SUMMARY
+          echo "### Checksums" >> $GITHUB_STEP_SUMMARY
+          echo "\`\`\`" >> $GITHUB_STEP_SUMMARY
+          cat artifacts/*/*.sha256 >> $GITHUB_STEP_SUMMARY
+          echo "\`\`\`" >> $GITHUB_STEP_SUMMARY

.github/workflows/code-qa.yml

@@ -58,66 +58,3 @@ jobs:
               uses: ./.github/actions/setup-node-pnpm
             - name: Run unit tests
               run: pnpm test
-
-    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: Set VS Code test version
-              run: echo "VSCODE_VERSION=1.101.2" >> $GITHUB_ENV
-            - name: Cache VS Code test runtime
-              uses: actions/cache@v4
-              with:
-                  path: apps/vscode-e2e/.vscode-test
-                  key: ${{ runner.os }}-vscode-test-${{ env.VSCODE_VERSION }}
-            - name: Pre-download VS Code test runtime with retry
-              working-directory: apps/vscode-e2e
-              run: |
-                  for attempt in 1 2 3; do
-                    echo "Download attempt $attempt of 3..."
-                    node -e "
-                    const { downloadAndUnzipVSCode } = require('@vscode/test-electron');
-                    downloadAndUnzipVSCode({ version: process.env.VSCODE_VERSION || '1.101.2' })
-                      .then(() => {
-                        console.log('✅ VS Code test runtime downloaded successfully');
-                        process.exit(0);
-                      })
-                      .catch(err => {
-                        console.error('❌ Failed to download VS Code (attempt $attempt):', err);
-                        process.exit(1);
-                      });
-                    " && break || {
-                      if [ $attempt -eq 3 ]; then
-                        echo "All download attempts failed"
-                        exit 1
-                      fi
-                      echo "Retrying in 5 seconds..."
-                      sleep 5
-                    }
-                  done
-            - name: Run integration tests
-              working-directory: apps/vscode-e2e
-              run: xvfb-run -a pnpm test:ci

.github/workflows/docs-pages.yml

@@ -0,0 +1,55 @@
+name: Deploy docs to GitHub Pages
+
+on:
+    push:
+        branches:
+            - main
+        paths:
+            - "apps/docs/**"
+            - ".github/workflows/docs-pages.yml"
+            - ".github/actions/setup-node-pnpm/**"
+            - "package.json"
+            - "pnpm-lock.yaml"
+            - "pnpm-workspace.yaml"
+    workflow_dispatch:
+
+concurrency:
+    group: docs-pages
+    cancel-in-progress: true
+
+permissions:
+    contents: read
+    pages: write
+    id-token: write
+
+jobs:
+    build:
+        runs-on: ubuntu-latest
+        steps:
+            - name: Checkout code
+              uses: actions/checkout@v4
+            - name: Setup Node.js and pnpm
+              uses: ./.github/actions/setup-node-pnpm
+              with:
+                  install-args: "--frozen-lockfile"
+            - name: Run type check
+              run: pnpm --filter @roo-code/docs check-types
+            - name: Run lint
+              run: pnpm --filter @roo-code/docs lint
+            - name: Build docs
+              run: pnpm --filter @roo-code/docs build
+            - name: Upload Pages artifact
+              uses: actions/upload-pages-artifact@v3
+              with:
+                  path: apps/docs/build
+
+    deploy:
+        runs-on: ubuntu-latest
+        needs: build
+        environment:
+            name: github-pages
+            url: ${{ steps.deployment.outputs.page_url }}
+        steps:
+            - name: Deploy to GitHub Pages
+              id: deployment
+              uses: actions/deploy-pages@v4

.github/workflows/evals.yml

@@ -1,74 +0,0 @@
-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

.github/workflows/update-contributors.yml

@@ -1,67 +0,0 @@
-name: Update Contributors # Refresh contrib.rocks image cache
-
-on:
-  workflow_dispatch:
-
-permissions:
-  contents: write
-  pull-requests: write
-
-jobs:
-  refresh-contrib-cache:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v4
-
-      - name: Bump cacheBust in all README files
-        run: |
-          set -euo pipefail
-          TS="$(date +%s)"
-          # Target only the root README.md and localized READMEs under locales/*/README.md
-          mapfile -t FILES < <(git ls-files README.md 'locales/*/README.md' || true)
-
-          if [ "${#FILES[@]}" -eq 0 ]; then
-            echo "No target README files found." >&2
-            exit 1
-          fi
-
-          UPDATED=0
-          for f in "${FILES[@]}"; do
-            if grep -q 'cacheBust=' "$f"; then
-              # Use portable sed in GNU environment of ubuntu-latest
-              sed -i -E "s/cacheBust=[0-9]+/cacheBust=${TS}/g" "$f"
-              echo "Updated cacheBust in $f"
-              UPDATED=1
-            else
-              echo "Warning: cacheBust parameter not found in $f" >&2
-            fi
-          done
-
-          if [ "$UPDATED" -eq 0 ]; then
-            echo "No files were updated. Ensure READMEs embed contrib.rocks with cacheBust param." >&2
-            exit 1
-          fi
-
-      - name: Detect changes
-        id: changes
-        run: |
-          if git diff --quiet; then
-            echo "changed=false" >> $GITHUB_OUTPUT
-          else
-            echo "changed=true" >> $GITHUB_OUTPUT
-          fi
-
-      - name: Create Pull Request
-        if: steps.changes.outputs.changed == '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: refresh-contrib-cache
-          delete-branch: true
-          title: "Refresh contrib.rocks image cache (all READMEs)"
-          body: |
-            Automated refresh of the contrib.rocks image cache by bumping the cacheBust parameter in README.md and locales/*/README.md.
-          base: main

.github/workflows/website-deploy.yml

@@ -1,46 +0,0 @@
-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 }}

.github/workflows/website-preview.yml

@@ -1,84 +0,0 @@
-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 = '<!-- roo-preview-comment -->';
-
-                      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
-                      });

.gitignore

@@ -18,6 +18,7 @@ bin/
 
 # Local prompts and rules
 /local-prompts
+AGENTS.local.md
 
 # Test environment
 .test_env
@@ -49,3 +50,8 @@ logs
 
 # Qdrant
 qdrant_storage/
+
+# Architect plans
+plans/
+
+roo-cli-*.tar.gz*

.roo/commands/cli-release.md

@@ -0,0 +1,86 @@
+---
+description: "Prepare a new release of the Roo Code CLI"
+argument-hint: "[version-description]"
+mode: code
+---
+
+1. Identify changes since the last CLI release:
+
+    - Get the last CLI release tag: `gh release list --limit 10 | grep "cli-v"`
+    - View changes since last release: `git log cli-v<last-version>..HEAD -- apps/cli --oneline`
+    - Or for uncommitted changes: `git diff --stat -- apps/cli`
+
+2. Review and summarize the changes to determine an appropriate changelog entry. Group changes by type:
+
+    - **Added**: New features
+    - **Changed**: Changes to existing functionality
+    - **Fixed**: Bug fixes
+    - **Removed**: Removed features
+    - **Tests**: New or updated tests
+
+3. Bump the version in `apps/cli/package.json`:
+
+    - Increment the patch version (e.g., 0.0.43 → 0.0.44) for bug fixes and minor changes
+    - Increment the minor version (e.g., 0.0.43 → 0.1.0) for new features
+    - Increment the major version (e.g., 0.0.43 → 1.0.0) for breaking changes
+
+4. Update `apps/cli/CHANGELOG.md` with a new entry:
+
+    - Add a new section at the top (below the header) following this format:
+
+    ```markdown
+    ## [X.Y.Z] - YYYY-MM-DD
+
+    ### Added
+
+    - Description of new features
+
+    ### Changed
+
+    - Description of changes
+
+    ### Fixed
+
+    - Description of bug fixes
+    ```
+
+    - Use the current date in YYYY-MM-DD format
+    - Include links to relevant source files where helpful
+    - Describe changes from the user's perspective
+
+5. Create a release branch and commit the changes:
+
+    ```bash
+    # Ensure you're on main and up to date
+    git checkout main
+    git pull origin main
+
+    # Create a new branch for the release
+    git checkout -b cli-release-v<version>
+
+    # Commit the version bump and changelog update
+    git add apps/cli/package.json apps/cli/CHANGELOG.md
+    git commit -m "chore(cli): prepare release v<version>"
+
+    # Push the branch to origin
+    git push -u origin cli-release-v<version>
+    ```
+
+6. Create a pull request for the release:
+
+    ```bash
+    gh pr create --title "chore(cli): prepare release v<version>" \
+        --body "## CLI Release v<version>
+
+    This PR prepares the CLI release v<version>.
+
+    ### Changes
+    - Version bump in package.json
+    - Changelog update
+
+    ### Checklist
+    - [ ] Version number is correct
+    - [ ] Changelog entry is complete and accurate
+    - [ ] All CI checks pass" \
+        --base main
+    ```

.roo/commands/commit.md

@@ -0,0 +1,80 @@
+---
+description: "Commit and push changes with a descriptive message"
+argument-hint: "[optional-context]"
+mode: code
+---
+
+1. Analyze the current changes to understand what needs to be committed:
+
+    ```bash
+    # Check for staged and unstaged changes
+    git status --short
+
+    # View the diff of all changes (staged and unstaged)
+    git diff HEAD
+    ```
+
+2. Based on the diff output, formulate a commit message following conventional commit format:
+
+    - **feat**: New feature or functionality
+    - **fix**: Bug fix
+    - **refactor**: Code restructuring without behavior change
+    - **docs**: Documentation changes
+    - **test**: Adding or updating tests
+    - **chore**: Maintenance tasks, dependencies, configs
+    - **style**: Formatting, whitespace, no logic changes
+
+    Format: `type(scope): brief description`
+
+    Examples:
+
+    - `feat(api): add user authentication endpoint`
+    - `fix(ui): resolve button alignment on mobile`
+    - `refactor(core): simplify error handling logic`
+    - `docs(readme): update installation instructions`
+
+3. Stage all unstaged changes:
+
+    ```bash
+    git add -A
+    ```
+
+4. Commit with the generated message:
+
+    ```bash
+    git commit -m "type(scope): brief description"
+    ```
+
+    **If pre-commit hooks fail:**
+
+    - Review the error output (linter errors, type checking errors, etc.)
+    - Fix the identified issues in the affected files
+    - Re-stage the fixes: `git add -A`
+    - Retry the commit: `git commit -m "type(scope): brief description"`
+
+5. Push to the remote repository:
+
+    ```bash
+    git push
+    ```
+
+    **If pre-push hooks fail:**
+
+    - Review the error output (test failures, linter errors, etc.)
+    - Fix the identified issues in the affected files
+    - Stage and commit the fixes using steps 3-4
+    - Retry the push: `git push`
+
+**Tips for good commit messages:**
+
+- Keep the first line under 72 characters
+- Use imperative mood ("add", "fix", "update", not "added", "fixes", "updated")
+- Be specific but concise
+- If multiple unrelated changes exist, consider splitting into separate commits
+
+**Common hook failures and fixes:**
+
+- **Linter errors**: Run the project's linter (e.g., `npm run lint` or `pnpm lint`) to see all issues, then fix them
+- **Type checking errors**: Run type checker (e.g., `npx tsc --noEmit`) to identify type issues
+- **Test failures**: Run tests (e.g., `npm test` or `pnpm test`) to identify failing tests and fix them
+- **Format issues**: Run formatter (e.g., `npm run format` or `pnpm format`) to auto-fix formatting

.roo/commands/release.md

@@ -1,6 +1,7 @@
 ---
 description: "Create a new release of the Roo Code extension"
 argument-hint: patch | minor | major
+mode: code
 ---
 
 1. Identify the SHA corresponding to the most recent release using GitHub CLI: `gh release view --json tagName,targetCommitish,publishedAt`

.roo/commands/roo-resolve-conflicts.md

@@ -0,0 +1,72 @@
+---
+description: "Resolve merge conflicts intelligently using git history analysis"
+argument-hint: "#PR-number"
+mode: merge-resolver
+---
+
+Resolve merge conflicts for a specific pull request by analyzing git history, commit messages, and code changes to make intelligent resolution decisions.
+
+## Quick Start
+
+1. **Provide a PR number** (e.g., `#123` or just `123`)
+
+2. The workflow will automatically:
+   - Fetch PR information (title, description, branches)
+   - Checkout the PR branch
+   - Rebase onto the target branch to reveal conflicts
+   - Analyze and resolve conflicts using git history
+
+## Workflow Steps
+
+### 1. Initialize PR Resolution
+
+```bash
+# Fetch PR info
+gh pr view [PR_NUMBER] --json title,body,headRefName,baseRefName
+
+# Checkout and rebase
+gh pr checkout [PR_NUMBER] --force
+git fetch origin main
+GIT_EDITOR=true git rebase origin/main
+```
+
+### 2. Identify Conflicts
+
+```bash
+git status --porcelain | grep "^UU"
+```
+
+### 3. Analyze Each Conflict
+
+For each conflicted file:
+- Read the conflict markers
+- Run `git blame` on conflicting sections
+- Fetch commit messages for context
+- Determine the intent behind each change
+
+### 4. Apply Resolution Strategy
+
+Based on the analysis:
+- **Bugfixes** generally take precedence over features
+- **Recent changes** are often more relevant (unless older is a security fix)
+- **Combine** non-conflicting changes when possible
+- **Preserve** test updates alongside code changes
+
+### 5. Complete Resolution
+
+```bash
+git add [resolved-files]
+GIT_EDITOR=true git rebase --continue
+```
+
+## Key Guidelines
+
+- Always escape conflict markers with `\` when using `apply_diff`
+- Document resolution decisions in the summary
+- Verify no syntax errors after resolution
+- Preserve valuable changes from both sides when possible
+
+## Examples
+
+- `/roo-resolve-conflicts #123` - Resolve conflicts for PR #123
+- `/roo-resolve-conflicts 456` - Resolve conflicts for PR #456

.roo/commands/roo-translate.md

@@ -0,0 +1,50 @@
+---
+description: "Translate and localize strings in the Roo Code extension"
+argument-hint: "[language-code or 'all'] [string-key or file-path]"
+mode: translate
+---
+
+Perform translation and localization tasks for the Roo Code extension. This command activates the translation workflow with comprehensive i18n guidelines.
+
+## Quick Start
+
+1. **Identify the translation scope:**
+   - If a specific language code is provided (e.g., `de`, `zh-CN`), focus on that language
+   - If `all` is specified, translate to all supported languages
+   - If a string key is provided, locate and translate that specific string
+   - If a file path is provided, work with that translation file
+
+2. **Supported languages:** ca, de, en, es, fr, hi, id, it, ja, ko, nl, pl, pt-BR, ru, tr, vi, zh-CN, zh-TW
+
+3. **Translation locations:**
+   - Core Extension: `src/i18n/locales/`
+   - WebView UI: `webview-ui/src/i18n/locales/`
+
+## Workflow
+
+1. If adding new strings:
+   - Add the English string first
+   - Ask for confirmation before translating to other languages
+   - Use `apply_diff` for efficient file updates
+
+2. If updating existing strings:
+   - Identify all affected language files
+   - Update English first, then propagate changes
+
+3. Validate your changes:
+   ```bash
+   node scripts/find-missing-translations.js
+   ```
+
+## Key Guidelines
+
+- Use informal speech (e.g., "du" not "Sie" in German)
+- Keep technical terms like "token", "Prompt" in English
+- Preserve all `{{variable}}` placeholders exactly
+- Use `apply_diff` instead of `write_to_file` for existing files
+
+## Examples
+
+- `/roo-translate de` - Focus on German translations
+- `/roo-translate all welcome.title` - Translate a specific key to all languages
+- `/roo-translate zh-CN src/i18n/locales/zh-CN/core.json` - Work on specific file

.roo/guidance/roo-translator.md

@@ -0,0 +1,15 @@
+# Roo Code Translation Guidance
+
+This file contains brand voice, tone, and word choice guidelines for Roo Code translations.
+
+## Brand Voice
+
+<!-- Add brand voice guidelines here -->
+
+## Tone
+
+<!-- Add tone guidelines here -->
+
+## Word Choice
+
+<!-- Add word choice preferences here -->

.roo/roomotes.yml

@@ -1,25 +1,6 @@
 version: "1.0"
 
 commands:
-    - name: Pull latest changes
-      run: git pull
-      timeout: 60
-      execution_phase: task_run
     - name: Install dependencies
       run: pnpm install
       timeout: 60
-      execution_phase: task_run
-
-github_events:
-    - event: issues.opened
-      action:
-          name: github.issue.fix
-    - event: issue_comment.created
-      action:
-          name: github.issue.comment.respond
-    - event: pull_request.opened
-      action:
-          name: github.pr.review
-    - event: pull_request_review_comment.created
-      action:
-          name: github.pr.comment.respond

.roo/rules-debug/cli.md

@@ -0,0 +1,67 @@
+# CLI Debugging with File-Based Logging
+
+When debugging the CLI, `console.log` will break the TUI (Terminal User Interface). Use file-based logging to capture debug output without interfering with the application's display.
+
+## File-Based Logging Strategy
+
+1. **Write logs to a temporary file instead of console**:
+
+    - Create a log file at a known location, e.g., `/tmp/roo-cli-debug.log`
+    - Use `fs.appendFileSync()` to write timestamped log entries
+    - Example logging utility:
+
+        ```typescript
+        import fs from "fs"
+        const DEBUG_LOG = "/tmp/roo-cli-debug.log"
+
+        function debugLog(message: string, data?: unknown) {
+        	const timestamp = new Date().toISOString()
+        	const entry = data
+        		? `[${timestamp}] ${message}: ${JSON.stringify(data, null, 2)}\n`
+        		: `[${timestamp}] ${message}\n`
+        	fs.appendFileSync(DEBUG_LOG, entry)
+        }
+        ```
+
+2. **Clear the log file before each debugging session**:
+    - Run `echo "" > /tmp/roo-cli-debug.log` or use `fs.writeFileSync(DEBUG_LOG, "")` at app startup during debugging
+
+## Iterative Debugging Workflow
+
+Follow this feedback loop to systematically narrow down issues:
+
+1. **Add targeted logging** at suspected problem areas based on your hypotheses
+2. **Instruct the user** to reproduce the issue using the CLI normally
+3. **Read the log file** after the user completes testing:
+    - Run `cat /tmp/roo-cli-debug.log` to retrieve the captured output
+4. **Analyze the log output** to gather clues about:
+    - Execution flow and timing
+    - Variable values at key points
+    - Which code paths were taken
+    - Error conditions or unexpected states
+5. **Refine your logging** based on findings—add more detail where needed, remove noise
+6. **Ask the user to test again** with updated logging
+7. **Repeat** until the root cause is identified
+
+## Best Practices
+
+- Log entry/exit points of functions under investigation
+- Include relevant variable values and state information
+- Use descriptive prefixes to categorize logs: `[STATE]`, `[EVENT]`, `[ERROR]`, `[FLOW]`
+- Log both the "happy path" and error handling branches
+- When dealing with async operations, log before and after `await` statements
+- For user interactions, log the received input and the resulting action
+
+## Example Debug Session
+
+```typescript
+// Add logging to investigate a picker selection issue
+debugLog("[FLOW] PickerSelect onSelect called", { selectedIndex, item })
+debugLog("[STATE] Current selection state", { currentValue, isOpen })
+
+// After async operation
+const result = await fetchOptions()
+debugLog("[FLOW] fetchOptions completed", { resultCount: result.length })
+```
+
+Then ask: "Please reproduce the issue by [specific steps]. When you're done, let me know and I'll analyze the debug logs."

.roo/rules-docs-extractor/1_extraction_workflow.xml

@@ -1,163 +1,113 @@
 <extraction_workflow>
-  <mode_overview>
-    The Docs Extractor mode has exactly two workflow paths:
-    1) Verify provided documentation for factual accuracy against the codebase
-    2) Generate source material for user-facing docs about a requested feature or aspect of the codebase
+  <overview>
+    Extract raw facts from a codebase about a feature or aspect.
+    Output is structured data for documentation teams to use.
+    Do NOT write documentation. Do NOT format prose. Do NOT make structure decisions.
+  </overview>
 
-    Outputs are designed to support explanatory documentation (not merely descriptive):
-    - Capture why users need steps and why certain actions are restricted
-    - Surface constraints, limitations, and trade‑offs
-    - Provide troubleshooting playbooks (symptoms → causes → fixes → prevention)
-    - Recommend targeted visuals for complex states (not step‑by‑step screenshots)
-
-    This mode does not generate final user documentation; it produces verification and source-material reports for docs teams.
-  </mode_overview>
-
-  <initialization_phase>
+  <process>
     <step number="1">
-      <title>Parse Request</title>
+      <title>Identify Target</title>
       <actions>
-        <action>Identify the feature/aspect in the user's request.</action>
-        <action>Decide path: verification vs. source-material generation.</action>
-        <action>For source-material: capture audience (user or developer) and depth (overview vs task-focused).</action>
-        <action>For verification: identify the documentation to be verified (provided text/links/files).</action>
-        <action>Note any specific areas to emphasize or check.</action>
+        <action>Parse the user's request to identify the feature/aspect</action>
+        <action>Clarify scope if ambiguous (ask one question max)</action>
       </actions>
     </step>
 
     <step number="2">
-      <title>Discover Feature</title>
+      <title>Discover Code</title>
       <actions>
-        <action>Locate relevant code and assets using appropriate discovery methods.</action>
-        <action>Identify entry points and key components that affect user experience.</action>
-        <action>Map the high-level workflow a user follows.</action>
+        <action>Use codebase_search to find relevant files</action>
+        <action>Identify entry points, components, and related code</action>
+        <action>Map the boundaries of the feature</action>
       </actions>
     </step>
-  </initialization_phase>
 
-  <analysis_focus>
-    <area>UI components and their interactions</area>
-    <area>User workflows and decision points</area>
-    <area>Configuration that changes user-visible behavior</area>
-    <area>Error states, messages, and recovery</area>
-    <area>Benefits, limits, prerequisites, and version notes</area>
-    <area>Why this exists: user goals, constraints, and design intent</area>
-    <area>“Cannot do” boundaries: permissions, invariants, and business rules</area>
-    <area>Troubleshooting: symptoms, likely causes, diagnostics, fixes, prevention</area>
-    <area>Common pitfalls and anti‑patterns (what to avoid and why)</area>
-    <area>Decision rationale and trade‑offs that affect user choices</area>
-    <area>Complex UI states that merit visuals (criteria for screenshots/diagrams)</area>
-  </analysis_focus>
+    <step number="3">
+      <title>Extract Facts</title>
+      <actions>
+        <action>Read code and extract facts into categories (see fact_categories)</action>
+        <action>Record file paths as sources for each fact</action>
+        <action>Do NOT interpret, summarize, or explain - just extract</action>
+      </actions>
+    </step>
 
-  <workflow_paths>
-    <path name="source_material">
-      <title>Generate Source Material for User-Facing Docs</title>
-      <description>Extract concise, user-oriented facts and structure them for documentation teams.</description>
-      <steps>
-        <step number="1">
-          <title>Scope and Audience</title>
-          <actions>
-            <action>Confirm the feature/aspect and intended audience.</action>
-            <action>List primary tasks the audience performs with this feature.</action>
-          </actions>
-        </step>
-        <step number="2">
-          <title>Extract User-Facing Facts</title>
-          <actions>
-            <action>Summarize what the feature does and key benefits.</action>
-            <action>Explain why users need this (jobs-to-be-done, outcomes) and when to use it.</action>
-            <action>Document step-by-step user workflows and UI interactions.</action>
-            <action>Capture configuration options that impact user behavior (name, default, effect).</action>
-            <action>Clarify constraints, limits, and “cannot do” cases with rationale.</action>
-            <action>Identify common pitfalls and anti-patterns; include “Do/Don’t” guidance.</action>
-            <action>List common errors with user-facing messages, diagnostics, fixes, and prevention.</action>
-            <action>Record prerequisites, permissions, and compatibility/version notes.</action>
-            <action>Flag complex states that warrant visuals (what to show and why), not every step.</action>
-          </actions>
-        </step>
-        <step number="3">
-          <title>Create Source Material Report</title>
-          <actions>
-            <action>Organize findings using user-focused structure (benefits, use cases, how it works, configuration, FAQ, troubleshooting).</action>
-            <action>Include short code/UI snippets or paths where relevant.</action>
-            <action>Create `EXTRACTION-[feature].md` with findings.</action>
-            <action>Highlight items that need visuals (screenshots/diagrams).</action>
-          </actions>
-          <output_format>
-            - Executive summary of the feature/aspect
-            - Why it matters (goals, value, when to use)
-            - User workflows and interactions
-            - Configuration and setup affecting users (with defaults and impact)
-            - Constraints and limitations (with rationale)
-            - Common scenarios and troubleshooting playbooks (symptoms → causes → fixes → prevention)
-            - Do/Don’t and anti‑patterns
-            - Recommended visuals (what complex states to illustrate and why)
-            - FAQ and tips
-            - Version/compatibility notes
-          </output_format>
-        </step>
-      </steps>
-    </path>
+    <step number="4">
+      <title>Output Structured Data</title>
+      <actions>
+        <action>Write extraction to .roo/extraction/EXTRACT-[feature].yaml</action>
+        <action>Use the output schema (see output_format.xml)</action>
+      </actions>
+    </step>
+  </process>
 
-    <path name="verification">
-      <title>Verify Documentation Accuracy</title>
-      <description>Check provided documentation against codebase reality and actual UX.</description>
-      <steps>
-        <step number="1">
-          <title>Analyze Provided Documentation</title>
-          <actions>
-            <action>Parse the documentation to identify claims and descriptions.</action>
-            <action>Extract technical or user-facing specifics mentioned.</action>
-            <action>Note workflows, configuration, and examples described.</action>
-          </actions>
-        </step>
-        <step number="2">
-          <title>Verify Against Codebase</title>
-          <actions>
-            <action>Check claims against actual implementation and UX.</action>
-            <action>Verify endpoints/parameters if referenced.</action>
-            <action>Confirm configuration options and defaults.</action>
-            <action>Validate code snippets and examples.</action>
-            <action>Ensure described workflows match implementation.</action>
-          </actions>
-        </step>
-        <step number="3">
-          <title>Create Verification Report</title>
-          <actions>
-            <action>Categorize findings by severity (Critical, Major, Minor).</action>
-            <action>List inaccuracies with the correct information.</action>
-            <action>Identify missing important information.</action>
-            <action>Provide specific corrections and suggestions.</action>
-            <action>Create `VERIFICATION-[feature].md` with findings.</action>
-          </actions>
-          <output_format>
-            - Verification summary (Accurate/Needs Updates)
-            - Critical inaccuracies that could mislead users
-            - Corrections and missing information
-            - Explanatory gaps (missing “why”, constraints, or decision rationale)
-            - Troubleshooting coverage gaps (missing symptoms/diagnostics/fixes/prevention)
-            - Visual recommendations (which complex states warrant screenshots/diagrams)
-            - Suggestions for clarity improvements
-          </output_format>
-        </step>
-      </steps>
-    </path>
-  </workflow_paths>
+  <fact_categories>
+    <category name="identity">
+      <extracts>
+        <extract>Feature name as it appears in code</extract>
+        <extract>File paths where feature is implemented</extract>
+        <extract>Entry points (commands, UI elements, API endpoints)</extract>
+      </extracts>
+    </category>
 
-  <completion_criteria>
-    <for_source_material>
-      <criterion>Audience and scope captured</criterion>
-      <criterion>User workflows and UI interactions documented</criterion>
-      <criterion>User-impacting configuration recorded</criterion>
-      <criterion>Common errors and troubleshooting documented</criterion>
-      <criterion>Report organized for documentation team use</criterion>
-    </for_source_material>
-    <for_verification>
-      <criterion>All documentation claims verified</criterion>
-      <criterion>Inaccuracies identified and corrected</criterion>
-      <criterion>Missing information noted</criterion>
-      <criterion>Suggestions for improvement provided</criterion>
-      <criterion>Clear verification report created</criterion>
-    </for_verification>
-  </completion_criteria>
+    <category name="behavior">
+      <extracts>
+        <extract>What the feature does (from code logic)</extract>
+        <extract>Inputs it accepts</extract>
+        <extract>Outputs it produces</extract>
+        <extract>Side effects (files created, state changed, etc.)</extract>
+      </extracts>
+    </category>
+
+    <category name="configuration">
+      <extracts>
+        <extract>Settings/options that affect behavior</extract>
+        <extract>Default values</extract>
+        <extract>Valid ranges or allowed values</extract>
+        <extract>Where configured (settings file, env var, UI)</extract>
+      </extracts>
+    </category>
+
+    <category name="constraints">
+      <extracts>
+        <extract>Prerequisites and dependencies</extract>
+        <extract>Limitations (what it cannot do)</extract>
+        <extract>Permissions required</extract>
+        <extract>Compatibility requirements</extract>
+      </extracts>
+    </category>
+
+    <category name="errors">
+      <extracts>
+        <extract>Error conditions in code</extract>
+        <extract>Error messages (exact text)</extract>
+        <extract>Recovery paths in code</extract>
+      </extracts>
+    </category>
+
+    <category name="ui">
+      <extracts>
+        <extract>UI components involved</extract>
+        <extract>User-visible labels and text</extract>
+        <extract>Interaction patterns</extract>
+      </extracts>
+    </category>
+
+    <category name="integration">
+      <extracts>
+        <extract>Other features this interacts with</extract>
+        <extract>External APIs or services called</extract>
+        <extract>Events emitted or consumed</extract>
+      </extracts>
+    </category>
+  </fact_categories>
+
+  <rules>
+    <rule>Extract facts, not opinions</rule>
+    <rule>Include source file paths for every fact</rule>
+    <rule>Use code identifiers and exact strings from source</rule>
+    <rule>Do NOT paraphrase - quote when possible</rule>
+    <rule>Do NOT decide what's important - extract everything relevant</rule>
+    <rule>Do NOT format for end users - output is for docs team</rule>
+  </rules>
 </extraction_workflow>

.roo/rules-docs-extractor/2_documentation_patterns.xml

@@ -1,357 +0,0 @@
-<documentation_patterns>
-  <overview>
-    Standard templates for structuring extracted documentation.
-  </overview>
-
-  <output_structure>
-    <user_focused_template>
-# [Feature Name]
-
-[Description of what the feature does and why a user should care.]
-
-### Key Features
-- [Benefit-oriented feature 1]
-- [Benefit-oriented feature 2]
-- [Benefit-oriented feature 3]
-
----
-
-## Use Case
-
-**Before**: [Description of the old way]
-- [Pain point 1]
-- [Pain point 2]
-
-**With this feature**: [Description of the new experience.]
-
-## How it Works
-
-[Simple explanation of the feature's operation.]
-
-[Suggest visual representations where helpful.]
-
----
-
-## Configuration
-
-[Explanation of relevant settings.]
-
-1. **[Setting Name]**:
-   - **Setting**: `[technical_name]`
-   - **Description**: [What this does.]
-   - **Default**: [Default value and its meaning.]
-
-2. **[Setting Name]**:
-   - **Setting**: `[technical_name]`
-   - **Description**: [What this does.]
-   - **Default**: [Default value and its meaning.]
-
----
-
-## FAQ
-
-**"[User question]"**
-- [Answer.]
-- [Optional tip.]
-
-**"[User question]"**
-- [Answer.]
-- [Optional tip.]
-
-    </user_focused_template>
-
-    <comprehensive_template>
-# [Feature Name] Technical Documentation
-
-## Table of Contents
-1. Overview
-2. Quick Start
-3. Architecture
-4. API Reference
-5. Configuration
-6. User Guide
-7. Developer Guide
-8. Security
-9. Performance
-10. Troubleshooting
-11. FAQ
-12. Changelog
-13. References
-
-[Use this as an internal source-material outline for technical sections; not for final docs.]
-    </comprehensive_template>
-  </output_structure>
-
-  <documentation_patterns>
-    <before_after>
-      <template>
-**Before**: Multiple, sequential file read requests:
-- "Read `src/app.js`?" → Approve
-- "Read `src/utils.js`?" → Approve
-- "Read `src/config.json`?" → Approve
-
-**Now**: One request to read all related files.
-      </template>
-    </before_after>
-
-    <visual_separator>
-      <format>---</format>
-      <purpose>Separate sections.</purpose>
-    </visual_separator>
-
-    <faq>
-      <template>
-## FAQ
-
-**"Why disable this?"**
-- Your AI model handles single files better.
-- You need more control over file access.
-- You are working with very large files.
-
-**"What if some files are blocked?"**
-- Roo reads approved files and works with what it has.
-- `.rooignore` files are excluded automatically.
-- Individual files can still be denied in the batch dialog.
-      </template>
-    </faq>
-
-    <examples>
-      <guideline>Show tool output or UI elements.</guideline>
-      <guideline>Use actual file paths and setting names.</guideline>
-      <guideline>Include common errors and solutions.</guideline>
-    </examples>
-
-    <troubleshooting>
-      <template>
-## Troubleshooting
-
-**"Too many files requested"**
-- Lower the concurrent file limit in settings.
-- Deny individual files in the batch dialog.
-
-**"Feature isn't working"**
-- Ensure "Enable concurrent file reads" is on in settings.
-- Verify the file limit is set correctly (default: 100).
-- Some AI models may not support this feature.
-      </template>
-    </troubleshooting>
-
-    <help>
-      <template>
-## Help
-
-- See the [FAQ](#faq) for common issues.
-- Report problems on [GitHub Issues](https://github.com/RooCodeInc/Roo-Code/issues).
-- Include reproduction steps and error messages.
-      </template>
-    </help>
-  </documentation_patterns>
-
-  <audience_sections>
-    <audience type="user">
-      <focus>
-        <area>Tutorials</area>
-        <area>Use cases</area>
-        <area>Troubleshooting</area>
-        <area>Benefits</area>
-      </focus>
-      <style>
-        <guideline>Simple language</guideline>
-        <guideline>Visual aids</guideline>
-        <guideline>Focus on outcomes</guideline>
-        <guideline>Clear action steps</guideline>
-      </style>
-    </audience>
-
-    <audience type="developer">
-      <focus>
-        <area>Code examples</area>
-        <area>API specs</area>
-        <area>Integration patterns</area>
-        <area>Performance</area>
-      </focus>
-      <style>
-        <guideline>Precise terminology</guideline>
-        <guideline>Code samples</guideline>
-        <guideline>Document edge cases</guideline>
-        <guideline>Debugging guidance</guideline>
-      </style>
-    </audience>
-
-  </audience_sections>
-
-  <metadata_patterns>
-    <version_info>
-      <template>
-### Version Compatibility
-| Component | Min | Recommended | Max | Notes |
-|-----------|-----|-------------|-----|-------|
-| [Component] | [version] | [version] | [version] | [notes] |
-      </template>
-    </version_info>
-
-    <deprecation_notice>
-      <template>
-> ⚠️ **Deprecated**
->
-> Deprecated since: [vX.Y.Z] on [date]
-> Removal target: [vA.B.C]
-> Migration: See [migration guide](#migration).
-> Replacement: [new feature/method].
-      </template>
-    </deprecation_notice>
-
-    <security_warning>
-      <template>
-> 🔒 **Security Warning**
->
-> [Description of concern]
-> - **Risk**: [High/Medium/Low]
-> - **Affected**: [versions]
-> - **Mitigation**: [steps]
-> - **References**: [links]
-      </template>
-    </security_warning>
-
-    <performance_note>
-      <template>
-> ⚡ **Performance Note**
->
-> [Description of performance consideration]
-> - **Impact**: [metrics]
-> - **Optimization**: [approach]
-> - **Trade-offs**: [considerations]
-      </template>
-    </performance_note>
-  </metadata_patterns>
-
-  <code_documentation_patterns>
-    <api_endpoint>
-      <template>
-### `[METHOD] /api/[path]`
-
-**Description**: [What this endpoint does]
-
-**Authentication**: [Required/Optional] - [Type]
-
-**Parameters**:
-| Name | Type | Required | Description | Example |
-|------|------|----------|-------------|---------|
-| [param] | [type] | [Yes/No] | [description] | [example] |
-
-**Request Body**:
-```json
-{
-  "field": "value"
-}
-```
-
-**Response**:
-- **Success (200)**:
-  ```json
-  {
-    "status": "success",
-    "data": {}
-  }
-  ```
-- **Error (4xx/5xx)**:
-  ```json
-  {
-    "error": "error_code",
-    "message": "Human readable message"
-  }
-  ```
-
-**Example**:
-```bash
-curl -X [METHOD] https://api.example.com/[path] \
-  -H "Authorization: Bearer [token]" \
-  -H "Content-Type: application/json" \
-  -d '{"field": "value"}'
-```
-      </template>
-    </api_endpoint>
-
-    <function_documentation>
-      <template>
-### `functionName(parameters)`
-
-**Purpose**: [What this function does]
-
-**Parameters**:
-- `param1` (Type): [Description]
-- `param2` (Type, optional): [Description] - Default: [value]
-
-**Returns**: `Type` - [Description of return value]
-
-**Throws**:
-- `ErrorType`: [When this error occurs]
-
-**Example**:
-```typescript
-const result = functionName(value1, value2);
-// Expected output: [description]
-```
-
-**Notes**:
-- [Important consideration 1]
-- [Important consideration 2]
-      </template>
-    </function_documentation>
-
-    <configuration_option>
-      <template>
-### `CONFIG_NAME`
-
-**Type**: `string | number | boolean`
-
-**Default**: `default_value`
-
-**Environment Variable**: `APP_CONFIG_NAME`
-
-**Description**: [What this configuration controls]
-
-**Valid Values**:
-- `value1`: [Description]
-- `value2`: [Description]
-
-**Example**:
-```yaml
-config:
-  name: value
-```
-
-**Impact**: [What changes when this is modified]
-      </template>
-    </configuration_option>
-  </code_documentation_patterns>
-
-  <cross_reference_patterns>
-    <internal_link>
-      <format>[Link Text](#section-anchor)</format>
-      <example>[See Configuration Guide](#configuration)</example>
-    </internal_link>
-
-    <external_link>
-      <format>[Link Text](https://external.url)</format>
-      <example>[Official Documentation](https://docs.example.com)</example>
-    </external_link>
-
-    <related_feature>
-      <template>
-> 📌 **Related Features**
-> - [Feature A](../feature-a/README.md): [How it relates]
-> - [Feature B](../feature-b/README.md): [How it relates]
-      </template>
-    </related_feature>
-
-    <see_also>
-      <template>
-> 👉 **See Also**
-> - [Related Topic 1](#anchor1)
-> - [Related Topic 2](#anchor2)
-> - [External Resource](https://example.com)
-      </template>
-    </see_also>
-  </cross_reference_patterns>
-</documentation_patterns>

.roo/rules-docs-extractor/2_verification_workflow.xml

@@ -0,0 +1,85 @@
+<verification_workflow>
+  <overview>
+    Compare provided documentation against actual codebase implementation.
+    Output is a structured diff of claims vs reality.
+    Do NOT rewrite the docs. Do NOT suggest wording. Just report discrepancies.
+  </overview>
+
+  <process>
+    <step number="1">
+      <title>Receive Documentation</title>
+      <actions>
+        <action>User provides documentation to verify (text, file, or URL)</action>
+        <action>Identify the feature/aspect being documented</action>
+      </actions>
+    </step>
+
+    <step number="2">
+      <title>Extract Claims</title>
+      <actions>
+        <action>Parse the documentation into discrete claims</action>
+        <action>Tag each claim with a category (behavior, config, constraint, etc.)</action>
+        <action>Record the exact quote from the documentation</action>
+      </actions>
+    </step>
+
+    <step number="3">
+      <title>Verify Against Code</title>
+      <actions>
+        <action>For each claim, find the relevant code</action>
+        <action>Compare claim to actual implementation</action>
+        <action>Record: ACCURATE, INACCURATE, OUTDATED, MISSING_CONTEXT, or UNVERIFIABLE</action>
+        <action>For inaccuracies, record what the code actually does</action>
+      </actions>
+    </step>
+
+    <step number="4">
+      <title>Output Verification Report</title>
+      <actions>
+        <action>Write verification to .roo/extraction/VERIFY-[feature].yaml</action>
+        <action>Use the output schema (see output_format.xml)</action>
+      </actions>
+    </step>
+  </process>
+
+  <verification_statuses>
+    <status name="ACCURATE">
+      <meaning>Claim matches implementation</meaning>
+    </status>
+    <status name="INACCURATE">
+      <meaning>Claim contradicts implementation</meaning>
+      <requires>What the code actually does</requires>
+    </status>
+    <status name="OUTDATED">
+      <meaning>Claim was once true but code has changed</meaning>
+      <requires>Current behavior</requires>
+    </status>
+    <status name="MISSING_CONTEXT">
+      <meaning>Claim is true but omits important information</meaning>
+      <requires>The missing context</requires>
+    </status>
+    <status name="UNVERIFIABLE">
+      <meaning>Cannot find code to verify this claim</meaning>
+      <requires>Search paths attempted</requires>
+    </status>
+  </verification_statuses>
+
+  <claim_categories>
+    <category>behavior</category>
+    <category>configuration</category>
+    <category>constraint</category>
+    <category>error_handling</category>
+    <category>ui</category>
+    <category>integration</category>
+    <category>prerequisite</category>
+  </claim_categories>
+
+  <rules>
+    <rule>Verify facts, not writing quality</rule>
+    <rule>Report what code does, not what docs should say</rule>
+    <rule>Include source file paths as evidence</rule>
+    <rule>Do NOT suggest documentation rewrites</rule>
+    <rule>Do NOT evaluate if docs are "good" - only if they're accurate</rule>
+    <rule>Quote exact code when showing discrepancies</rule>
+  </rules>
+</verification_workflow>

.roo/rules-docs-extractor/3_analysis_techniques.xml

@@ -1,349 +0,0 @@
-<analysis_techniques>
-  <overview>
-    Heuristics for analyzing a codebase to extract reliable, user-facing documentation.
-    This file contains technique checklists only—no tool instructions or invocations.
-  </overview>
-
-  <ui_ux_analysis_techniques>
-    <technique name="component_discovery">
-      <description>Find and analyze UI components and their interactions</description>
-      <heuristics>
-        <rule>Start from feature or route directories and enumerate components related to the requested topic.</rule>
-        <rule>Differentiate container vs presentational components; note composition patterns.</rule>
-        <rule>Trace inputs/outputs: props, state, context, events, and side effects.</rule>
-        <rule>Record conditional rendering that affects user-visible states.</rule>
-      </heuristics>
-      <evidence_to_collect>
-        <item>Primary components and responsibilities.</item>
-        <item>Props/state/context that change behavior.</item>
-        <item>High-level dependency/composition map.</item>
-      </evidence_to_collect>
-    </technique>
-
-    <technique name="style_analysis">
-      <description>Analyze styling and visual elements</description>
-      <heuristics>
-        <rule>Identify design tokens and utility classes used to drive layout and state.</rule>
-        <rule>Capture responsive behavior and breakpoint rules that materially change UX.</rule>
-        <rule>Document visual affordances tied to state (loading, error, disabled).</rule>
-      </heuristics>
-      <evidence_to_collect>
-        <item>Key classes/selectors influencing layout/state.</item>
-        <item>Responsive behavior summary and breakpoints.</item>
-      </evidence_to_collect>
-    </technique>
-
-    <technique name="user_flow_mapping">
-      <description>Map user interactions and navigation flows</description>
-      <analysis_areas>
-        <area>Route definitions and navigation</area>
-        <area>Form submissions and validations</area>
-        <area>Button clicks and event handlers</area>
-        <area>State changes and UI updates</area>
-        <area>Loading and error states</area>
-      </analysis_areas>
-      <heuristics>
-        <rule>Outline entry points and expected outcomes for each primary flow.</rule>
-        <rule>Summarize validation rules and failure states the user can encounter.</rule>
-        <rule>Record redirects and deep-link behavior relevant to the feature.</rule>
-      </heuristics>
-      <evidence_to_collect>
-        <item>Flow diagrams or bullet sequences for main tasks.</item>
-        <item>Validation conditions and error messages.</item>
-        <item>Navigation transitions and guards.</item>
-      </evidence_to_collect>
-    </technique>
-
-    <technique name="user_feedback_analysis">
-      <description>Analyze how the system communicates with users</description>
-      <elements_to_find>
-        <element>Error messages and alerts</element>
-        <element>Success notifications</element>
-        <element>Loading indicators</element>
-        <element>Tooltips and help text</element>
-        <element>Confirmation dialogs</element>
-        <element>Progress indicators</element>
-      </elements_to_find>
-      <heuristics>
-        <rule>Map message triggers to the user actions that cause them.</rule>
-        <rule>Capture severity, persistence, and dismissal behavior.</rule>
-        <rule>Note localization or accessibility considerations in messages.</rule>
-      </heuristics>
-      <evidence_to_collect>
-        <item>Catalog of messages with purpose and conditions.</item>
-        <item>Loading/progress patterns and timeouts.</item>
-      </evidence_to_collect>
-    </technique>
-
-    <technique name="accessibility_analysis">
-      <description>Check for accessibility features and compliance</description>
-      <accessibility_checks>
-        <check>ARIA labels and roles</check>
-        <check>Keyboard navigation support</check>
-        <check>Screen reader compatibility</check>
-        <check>Focus management</check>
-        <check>Color contrast considerations</check>
-      </accessibility_checks>
-      <heuristics>
-        <rule>Confirm interactive elements have clear focus and labels.</rule>
-        <rule>Describe keyboard-only navigation paths for core flows.</rule>
-      </heuristics>
-      <evidence_to_collect>
-        <item>Accessibility gaps affecting task completion.</item>
-      </evidence_to_collect>
-    </technique>
-
-    <technique name="responsive_design_analysis">
-      <description>Analyze responsive design and mobile experience</description>
-      <analysis_points>
-        <point>Breakpoint definitions</point>
-        <point>Mobile-specific components</point>
-        <point>Touch event handlers</point>
-        <point>Viewport configurations</point>
-        <point>Media queries</point>
-      </analysis_points>
-      <heuristics>
-        <rule>Summarize layout changes across breakpoints that alter workflow.</rule>
-        <rule>Note touch targets and gestures required on mobile.</rule>
-      </heuristics>
-      <evidence_to_collect>
-        <item>Table of key differences per breakpoint.</item>
-      </evidence_to_collect>
-    </technique>
-  </ui_ux_analysis_techniques>
-
-  <code_analysis_techniques>
-    <technique name="entry_point_analysis">
-      <description>Understand feature entry points and control flow</description>
-      <steps>
-        <step>Identify main functions, controllers, or route handlers.</step>
-        <step>Trace execution and decision branches.</step>
-        <step>Document input validation and preconditions.</step>
-      </steps>
-      <evidence_to_collect>
-        <item>Entry points list and short purpose statements.</item>
-        <item>Decision matrix or flow sketch.</item>
-      </evidence_to_collect>
-    </technique>
-
-    <technique name="api_extraction">
-      <description>Extract API specifications from code</description>
-      <patterns>
-        <pattern type="rest">
-          <extraction>
-            <item>HTTP method and route path</item>
-            <item>Path/query parameters</item>
-            <item>Request/response schemas</item>
-            <item>Status codes and error bodies</item>
-          </extraction>
-        </pattern>
-        <pattern type="graphql">
-          <extraction>
-            <item>Schema and input types</item>
-            <item>Resolvers and return types</item>
-            <item>Field arguments and constraints</item>
-          </extraction>
-        </pattern>
-      </patterns>
-    </technique>
-
-    <technique name="dependency_mapping">
-      <description>Map dependencies and integration points</description>
-      <analysis_points>
-        <point>Imports and module boundaries</point>
-        <point>Package and runtime dependencies</point>
-        <point>External API/SDK usage</point>
-        <point>DB connections and migrations</point>
-        <point>Messaging/queue/event streams</point>
-        <point>Filesystem or network side effects</point>
-      </analysis_points>
-      <evidence_to_collect>
-        <item>Dependency graph summary and hot spots.</item>
-        <item>List of external integrations and auth methods.</item>
-      </evidence_to_collect>
-    </technique>
-
-    <technique name="data_model_extraction">
-      <description>Extract data models, schemas, and type definitions</description>
-      <sources>
-        <source type="typescript">
-          <patterns>- interfaces, types, classes, enums</patterns>
-        </source>
-        <source type="database">
-          <patterns>- Schema definitions, migration files, ORM models</patterns>
-        </source>
-        <source type="validation">
-          <patterns>- JSON Schema, Joi/Yup/Zod schemas, validation decorators</patterns>
-        </source>
-      </sources>
-      <evidence_to_collect>
-        <item>Canonical definitions and field constraints.</item>
-        <item>Entity relationships and ownership.</item>
-      </evidence_to_collect>
-    </technique>
-
-    <technique name="business_logic_extraction">
-      <description>Identify and document business rules</description>
-      <indicators>
-        <indicator>Complex conditionals</indicator>
-        <indicator>Calculation functions</indicator>
-        <indicator>Validation rules</indicator>
-        <indicator>State machines</indicator>
-        <indicator>Domain-specific constants and algorithms</indicator>
-      </indicators>
-      <documentation_focus>
-        <focus>Why the logic exists (business need)</focus>
-        <focus>When the logic applies (conditions)</focus>
-        <focus>What the logic does (transformation)</focus>
-        <focus>Edge cases and invariants</focus>
-        <focus>Impact of changes</focus>
-      </documentation_focus>
-    </technique>
-
-    <technique name="error_handling_analysis">
-      <description>Document error handling and recovery</description>
-      <analysis_areas>
-        <area>try/catch blocks and error boundaries</area>
-        <area>Custom error classes and codes</area>
-        <area>Logging, fallbacks, retries, circuit breakers</area>
-      </analysis_areas>
-      <evidence_to_collect>
-        <item>Error taxonomy and user-facing messages.</item>
-        <item>Recovery/rollback strategies and timeouts.</item>
-      </evidence_to_collect>
-    </technique>
-
-    <technique name="security_analysis">
-      <description>Identify security measures and vulnerabilities</description>
-      <security_checks>
-        <check category="authentication">JWT, sessions, OAuth, API keys</check>
-        <check category="authorization">RBAC, permission checks, ownership validation</check>
-        <check category="data_protection">Encryption, hashing, sensitive data handling</check>
-        <check category="input_validation">Sanitization and injection prevention</check>
-      </security_checks>
-      <evidence_to_collect>
-        <item>Threat surfaces and mitigations relevant to the feature.</item>
-      </evidence_to_collect>
-    </technique>
-
-    <technique name="performance_analysis">
-      <description>Identify performance factors and optimization opportunities</description>
-      <analysis_points>
-        <point>Expensive loops/algorithms</point>
-        <point>DB query patterns (e.g., N+1)</point>
-        <point>Caching strategies</point>
-        <point>Concurrency and async usage</point>
-        <point>Batching and resource pooling</point>
-        <point>Memory management and object lifetimes</point>
-      </analysis_points>
-      <metrics_to_document>
-        <metric>Time/space complexity</metric>
-        <metric>DB query counts</metric>
-        <metric>API response times</metric>
-        <metric>Memory usage</metric>
-        <metric>Concurrency handling</metric>
-      </metrics_to_document>
-    </technique>
-
-    <technique name="test_coverage_analysis">
-      <description>Assess test coverage at a useful granularity</description>
-      <test_types>
-        <type name="unit">
-          <analysis>Function-level coverage and edge cases</analysis>
-        </type>
-        <type name="integration">
-          <analysis>Workflow coverage and contract boundaries</analysis>
-        </type>
-        <type name="api">
-          <analysis>Endpoint success/failure paths and schemas</analysis>
-        </type>
-      </test_types>
-      <evidence_to_collect>
-        <item>List of critical behaviors missing tests.</item>
-      </evidence_to_collect>
-    </technique>
-
-    <technique name="configuration_extraction">
-      <description>Extract configuration options and their impacts</description>
-      <configuration_sources>
-        <source>.env files, config files, CLI args, feature flags</source>
-      </configuration_sources>
-      <documentation_requirements>
-        <requirement>Default values and valid ranges</requirement>
-        <requirement>Behavioral impact of each option</requirement>
-        <requirement>Dependencies between options</requirement>
-        <requirement>Security implications</requirement>
-      </documentation_requirements>
-    </technique>
-  </code_analysis_techniques>
-
-  <workflow_analysis>
-    <technique name="user_journey_mapping">
-      <description>Map user workflows through the feature</description>
-      <steps>
-        <step>Identify entry points (UI, API, CLI)</step>
-        <step>Trace user actions and decision points</step>
-        <step>Map data transformations</step>
-        <step>Identify outcomes and completion criteria</step>
-      </steps>
-      <deliverables>
-        <deliverable>Flow diagrams, procedures, decision trees, state diagrams</deliverable>
-      </deliverables>
-    </technique>
-
-    <technique name="integration_flow_analysis">
-      <description>Document integration with other systems</description>
-      <integration_types>
-        <type>Sync API calls, async messaging, events, batch processing, streaming</type>
-      </integration_types>
-      <documentation_focus>
-        <focus>Protocols, auth, error handling, data transforms, SLAs</focus>
-      </documentation_focus>
-    </technique>
-  </workflow_analysis>
-
-  <metadata_extraction>
-    <technique name="version_compatibility">
-      <description>Summarize version constraints and compatibility</description>
-      <sources>
-        <source>package manifests, READMEs, migration guides, breaking changes docs</source>
-      </sources>
-      <evidence_to_collect>
-        <item>Minimum/recommended versions and notable constraints.</item>
-      </evidence_to_collect>
-    </technique>
-
-    <technique name="deprecation_tracking">
-      <description>Track deprecations and migrations</description>
-      <indicators>
-        <indicator>Explicit deprecation notices and TODO markers</indicator>
-        <indicator>Legacy code paths and adapters</indicator>
-      </indicators>
-      <documentation_requirements>
-        <requirement>Deprecation date and removal timeline</requirement>
-        <requirement>Migration path and alternatives</requirement>
-      </documentation_requirements>
-    </technique>
-  </metadata_extraction>
-
-  <quality_indicators>
-    <indicator name="documentation_completeness">
-      <checks>
-        <check>Public APIs documented with inputs/outputs and errors</check>
-        <check>Examples for complex features</check>
-        <check>Error scenarios covered with recovery guidance</check>
-        <check>Config options explained with defaults and impacts</check>
-        <check>Security considerations addressed</check>
-      </checks>
-    </indicator>
-    <indicator name="code_quality_metrics">
-      <metrics>
-        <metric>Cyclomatic complexity</metric>
-        <metric>Code duplication</metric>
-        <metric>Test coverage and gaps</metric>
-        <metric>Documentation coverage for user-visible behaviors</metric>
-        <metric>Known technical debt affecting UX</metric>
-      </metrics>
-    </indicator>
-  </quality_indicators>
-</analysis_techniques>

.roo/rules-docs-extractor/3_output_format.xml

@@ -0,0 +1,133 @@
+<output_format>
+  <overview>
+    Structured data output formats for extraction and verification.
+    All output is YAML. No prose. No markdown formatting.
+    This data feeds into documentation-writer mode.
+  </overview>
+
+  <extraction_schema>
+    <description>Schema for EXTRACT-[feature].yaml files</description>
+    <template>
+feature:
+  name: [feature name from code]
+  slug: [lowercase-hyphenated identifier]
+  extracted_at: [ISO timestamp]
+  source_files:
+    - [list of primary files]
+
+identity:
+  entry_points:
+    - type: [command|ui|api|event]
+      name: [identifier]
+      location: [file:line]
+  components:
+    - name: [component name]
+      file: [path]
+      purpose: [one line from code comments or inferred]
+
+behavior:
+  primary_action: [what it does - from code]
+  inputs:
+    - name: [input name]
+      type: [data type]
+      required: [true|false]
+      source: [file:line]
+  outputs:
+    - name: [output name]
+      type: [data type]
+      source: [file:line]
+  side_effects:
+    - description: [what changes]
+      source: [file:line]
+
+configuration:
+  - name: [setting name]
+    key: [config key path]
+    type: [data type]
+    default: [default value]
+    valid_values: [list or range]
+    effect: [what it changes]
+    source: [file:line]
+
+constraints:
+  prerequisites:
+    - description: [requirement]
+      source: [file:line]
+  limitations:
+    - description: [what cannot be done]
+      source: [file:line]
+  permissions:
+    - description: [permission needed]
+      source: [file:line]
+
+errors:
+  - condition: [when this error occurs]
+    message: "[exact error message text]"
+    code: [error code if any]
+    source: [file:line]
+
+ui:
+  components:
+    - name: [component name]
+      type: [button|panel|input|etc]
+      label: "[visible text]"
+      source: [file:line]
+  interactions:
+    - trigger: [user action]
+      result: [what happens]
+      source: [file:line]
+
+integration:
+  internal:
+    - feature: [other feature name]
+      relationship: [how they interact]
+      source: [file:line]
+  external:
+    - service: [external service]
+      api: [endpoint or method]
+      source: [file:line]
+    </template>
+  </extraction_schema>
+
+  <verification_schema>
+    <description>Schema for VERIFY-[feature].yaml files</description>
+    <template>
+verification:
+  feature: [feature name]
+  doc_source: [where the docs came from]
+  verified_at: [ISO timestamp]
+  summary:
+    total_claims: [count]
+    accurate: [count]
+    inaccurate: [count]
+    outdated: [count]
+    missing_context: [count]
+    unverifiable: [count]
+
+claims:
+  - id: [claim-1]
+    quote: "[exact text from documentation]"
+    category: [behavior|configuration|constraint|error_handling|ui|integration|prerequisite]
+    status: [ACCURATE|INACCURATE|OUTDATED|MISSING_CONTEXT|UNVERIFIABLE]
+    evidence:
+      code_file: [file:line]
+      actual_behavior: [what code does - only if status is not ACCURATE]
+      code_quote: "[relevant code snippet]"
+    </template>
+  </verification_schema>
+
+  <output_rules>
+    <rule>Use YAML, not JSON or markdown</rule>
+    <rule>Include source file:line for every fact</rule>
+    <rule>Quote exact strings from code using double quotes</rule>
+    <rule>Use null for unknown/missing values, not empty strings</rule>
+    <rule>Keep descriptions factual and brief - one line max</rule>
+    <rule>Do NOT add commentary, suggestions, or explanations</rule>
+  </output_rules>
+
+  <file_naming>
+    <extraction>EXTRACT-[feature-slug].yaml</extraction>
+    <verification>VERIFY-[feature-slug].yaml</verification>
+    <location>.roo/extraction/</location>
+  </file_naming>
+</output_format>

.roo/rules-docs-extractor/4_communication_guidelines.xml

@@ -1,298 +0,0 @@
-<communication_guidelines>
-  <overview>
-    Guidelines for user communication and output formatting.
-  </overview>
-
-  <user_interaction>
-    <initial_contact>
-      <principle>Act on the user's request immediately.</principle>
-      <principle>Only ask for clarification if the request is ambiguous.</principle>
-    </initial_contact>
-
-    <clarification>
-      <when_to_ask>
-        <scenario>Multiple features with similar names are found.</scenario>
-        <scenario>The request is ambiguous.</scenario>
-        <scenario>The user explicitly asks for options.</scenario>
-      </when_to_ask>
-      
-    </clarification>
-
-    <progress_updates>
-      <when_to_update>
-        <trigger>Starting a major analysis phase.</trigger>
-        <trigger>Extraction is complete.</trigger>
-        <trigger>Unexpected complexity is found.</trigger>
-      </when_to_update>
-      
-      <update_format>
-        <template>
-          Analyzing [component]...
-          - Found [X] related files.
-          - Identified [Y] API endpoints.
-          - Found [Z] config options.
-        </template>
-      </update_format>
-    </progress_updates>
-
-    <findings_communication>
-      <important_findings>
-        <discovery type="security_issue">
-          Alert user to security concerns found during analysis.
-        </discovery>
-        <discovery type="deprecated_code">
-          Note deprecated features needing migration docs.
-        </discovery>
-        <discovery type="missing_docs">
-          Highlight code that lacks inline documentation.
-        </discovery>
-        <discovery type="complex_dependencies">
-          Warn about complex dependency chains.
-        </discovery>
-      </important_findings>
-      <extraction_findings>
-        <template>
-Feature extraction complete for [feature name].
-
-**Extraction Report**: `EXTRACTION-[feature].md`
-
-**Key Findings**:
-- Technical Components: [X] classes, [Y] APIs, [Z] configurations
-- User Workflows: [number] primary use cases identified
-- Business Logic: [summary of core functionality]
-- Integration Points: [list of external dependencies]
-
-**Documentation Considerations**:
-- [Important aspect that needs clear explanation]
-- [Complex area that may need diagrams]
-- [Edge cases that should be documented]
-
-The extraction report provides comprehensive details for your documentation team.
-        </template>
-      </extraction_findings>
-      <verification_findings>
-        <template>
-Documentation verification complete.
-
-**Verification Report**: `VERIFICATION-[feature].md`
-
-**Overall Assessment**: [Accurate/Needs Updates/Contains Critical Errors]
-
-**Summary of Findings**:
-- Critical Inaccuracies: [number]
-- Technical Corrections Needed: [number]
-- Missing Information: [number]
-- Clarity Improvements: [number]
-
-**Most Important Issues**:
-1. [Critical issue that could mislead users]
-2. [Important technical inaccuracy]
-3. [Key missing information]
-
-See the full verification report for detailed corrections and suggestions.
-        </template>
-      </verification_findings>
-    </findings_communication>
-  </user_interaction>
-
-  <output_formatting>
-    <markdown_standards>
-      <headings>
-        <rule>Use # for main title, ## for major sections, ### for subsections.</rule>
-        <rule>Never skip heading levels.</rule>
-      </headings>
-
-      <code_blocks>
-        <rule>Always specify language for syntax highlighting (e.g., typescript, json, bash).</rule>
-        <rule>Include file paths as comments where relevant.</rule>
-        <example>
-```typescript
-// src/auth/auth.service.ts
-export class AuthService {
-  async validateUser(email: string, password: string): Promise<User> {
-    // Implementation
-  }
-}
-```
-        </example>
-      </code_blocks>
-
-      <tables>
-        <rule>Use tables for structured data like configs.</rule>
-        <rule>Include headers and align columns.</rule>
-        <rule>Keep cell content brief.</rule>
-        <example>
-| Variable | Type | Default | Description |
-|----------|------|---------|-------------|
-| `JWT_SECRET` | string | - | Secret key for JWT signing |
-| `JWT_EXPIRATION` | string | '15m' | Token expiration time |
-        </example>
-      </tables>
-
-      <lists>
-        <rule>Use bullets for unordered lists, numbers for sequential steps.</rule>
-        <rule>Keep list items parallel in structure.</rule>
-      </lists>
-    </markdown_standards>
-
-    <cross_references>
-      <internal_links>
-        <format>[Link text](#section-anchor)</format>
-        <rule>Use lowercase, hyphenated anchors. Test all links.</rule>
-      </internal_links>
-
-      <external_links>
-        <format>[Link text](https://example.com)</format>
-        <rule>Use HTTPS. Link to official docs.</rule>
-      </external_links>
-
-      <file_references>
-        <format>`path/to/file.ts`</format>
-        <rule>Use relative paths from project root, in backticks.</rule>
-      </file_references>
-    </cross_references>
-
-    <special_sections>
-      <alerts>
-        <type name="warning">
-          <format>> ⚠️ **Warning**: [message]</format>
-          <use_for>Security, breaking changes, deprecations.</use_for>
-        </type>
-        <type name="note">
-          <format>> 📝 **Note**: [message]</format>
-          <use_for>Important info, clarifications.</use_for>
-        </type>
-        <type name="tip">
-          <format>> 💡 **Tip**: [message]</format>
-          <use_for>Best practices, optimizations.</use_for>
-        </type>
-      </alerts>
-
-      <metadata_blocks>
-        <version_info>
----
-Feature: Authentication System
-Version: 2.1.0
-Last Updated: 2024-01-15
-Status: Stable
----
-        </version_info>
-      </metadata_blocks>
-    </special_sections>
-  </output_formatting>
-
-  <documentation_tone>
-    <general>
-      <principle>Be direct, not conversational.</principle>
-      <principle>Use active voice.</principle>
-      <principle>Lead with benefits.</principle>
-      <principle>Use concrete examples.</principle>
-      <principle>Keep paragraphs short.</principle>
-      <principle>Avoid unnecessary technical details.</principle>
-    </general>
-
-    <audience_tone>
-      <audience type="developer">
-        <tone>Technical and direct.</tone>
-        <vocabulary>Standard programming terms.</vocabulary>
-        <examples>Code snippets, implementation details.</examples>
-      </audience>
-      <audience type="user">
-        <tone>Instructional, step-by-step.</tone>
-        <vocabulary>Simple language, no jargon.</vocabulary>
-        <examples>Screenshots, real-world scenarios.</examples>
-      </audience>
-    </audience_tone>
-  </documentation_tone>
-
-  <completion_message>
-    <structure>
-      <element>Summary of analysis performed.</element>
-      <element>Key findings or issues identified.</element>
-      <element>Report file location.</element>
-      <element>Recommended next steps.</element>
-    </structure>
-
-    <extraction_example>
-Feature extraction complete for the authentication system.
-
-**Extraction Report**: `EXTRACTION-authentication-system.md`
-
-**Technical Summary**:
-- JWT-based authentication with refresh tokens
-- 5 API endpoints (login, logout, refresh, register, profile)
-- 12 configuration options
-- bcrypt password hashing, rate limiting
-
-**Non-Technical Summary**:
-- Users can register, login, and manage sessions
-- Supports "remember me" functionality
-- Automatic session refresh for seamless experience
-- Account lockout after failed attempts
-
-**Documentation Considerations**:
-- Token expiration times need clear explanation
-- Password requirements should be prominently displayed
-- Error messages need user-friendly translations
-
-The extraction report contains all details needed for comprehensive documentation.
-    </extraction_example>
-
-    <verification_example>
-Documentation verification complete for the authentication system.
-
-**Verification Report**: `VERIFICATION-authentication-system.md`
-
-**Overall Assessment**: Needs Updates
-
-**Critical Issues Found**:
-1. JWT_SECRET documented as optional, but it's required
-2. Token expiration listed as 30m, actual is 15m
-3. Missing documentation for rate limiting feature
-
-**Technical Corrections**: 7 items
-**Missing Information**: 4 sections
-**Clarity Improvements**: 3 suggestions
-
-Please review the verification report for specific corrections needed.
-    </verification_example>
-  </completion_message>
-
-  <error_handling>
-    <scenarios>
-      <scenario type="feature_not_found">
-        <response>
-          Could not find a feature matching "[feature name]". Similar features found:
-          - [List similar features]
-          Document one of these instead?
-        </response>
-      </scenario>
-
-      <scenario type="insufficient_docs">
-        <response>
-          Code for [feature] has limited inline documentation. Extracting from code structure, tests, and usage patterns.
-        </response>
-      </scenario>
-
-      <scenario type="complex_feature">
-        <response>
-          This feature is complex. Choose documentation scope:
-          - Document comprehensively
-          - Focus on core functionality
-          - Split into multiple documents
-        </response>
-      </scenario>
-    </scenarios>
-  </error_handling>
-
-  <quality_checks>
-    <before_completion>
-      <check>No placeholder content remains.</check>
-      <check>Code examples are correct.</check>
-      <check>Links and cross-references work.</check>
-      <check>Tables are formatted correctly.</check>
-      <check>Version info is included.</check>
-      <check>Filename follows conventions.</check>
-    </before_completion>
-  </quality_checks>
-</communication_guidelines>

.roo/rules-integration-tester/1_workflow.xml

@@ -1,198 +0,0 @@
-<workflow>
-  <step number="1">
-    <name>Understand Test Requirements</name>
-    <instructions>
-      Use ask_followup_question to determine what type of integration test is needed:
-      
-      <ask_followup_question>
-      <question>What type of integration test would you like me to create or work on?</question>
-      <follow_up>
-      <suggest>New E2E test for a specific feature or workflow</suggest>
-      <suggest>Fix or update an existing integration test</suggest>
-      <suggest>Create test utilities or helpers for common patterns</suggest>
-      <suggest>Debug failing integration tests</suggest>
-      </follow_up>
-      </ask_followup_question>
-    </instructions>
-  </step>
-
-  <step number="2">
-    <name>Gather Test Specifications</name>
-    <instructions>
-      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.
-    </instructions>
-  </step>
-
-  <step number="3">
-    <name>Explore Existing Test Patterns</name>
-    <instructions>
-      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
-    </instructions>
-  </step>
-
-  <step number="4">
-    <name>Analyze Test Environment and Setup</name>
-    <instructions>
-      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
-    </instructions>
-  </step>
-
-  <step number="5">
-    <name>Design Test Structure</name>
-    <instructions>
-      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
-    </instructions>
-  </step>
-
-  <step number="6">
-    <name>Implement Test Code</name>
-    <instructions>
-      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
-    </instructions>
-  </step>
-
-  <step number="7">
-    <name>Run and Validate Tests</name>
-    <instructions>
-      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
-    </instructions>
-  </step>
-
-  <step number="8">
-    <name>Document and Complete</name>
-    <instructions>
-      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
-    </instructions>
-  </step>
-</workflow>

.roo/rules-integration-tester/2_test_patterns.xml

@@ -1,303 +0,0 @@
-<test_patterns>
-  <mocha_tdd_structure>
-    <description>Standard Mocha TDD structure for integration tests</description>
-    <pattern>
-      <name>Basic Test Suite Structure</name>
-      <example>
-        ```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
-          });
-        });
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>Event Listening Pattern</name>
-      <example>
-        ```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(() => {});
-          }
-        });
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>File Creation Test Pattern</name>
-      <example>
-        ```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);
-        });
-        ```
-      </example>
-    </pattern>
-  </mocha_tdd_structure>
-
-  <api_interaction_patterns>
-    <pattern>
-      <name>Basic Task Execution</name>
-      <example>
-        ```typescript
-        // Start a task and wait for completion
-        await api.startTask('Your prompt here');
-        await waitUntilCompleted();
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>Task with Auto-Approval Settings</name>
-      <example>
-        ```typescript
-        // Enable auto-approval for specific actions
-        await api.updateSettings({
-          alwaysAllowWrite: true,
-          alwaysAllowExecute: true
-        });
-        
-        await api.startTask('Create and execute a script');
-        await waitUntilCompleted();
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>Message Validation</name>
-      <example>
-        ```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');
-        ```
-      </example>
-    </pattern>
-  </api_interaction_patterns>
-
-  <error_handling_patterns>
-    <pattern>
-      <name>Task Abortion Handling</name>
-      <example>
-        ```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');
-        });
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>Error Message Validation</name>
-      <example>
-        ```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');
-        });
-        ```
-      </example>
-    </pattern>
-  </error_handling_patterns>
-
-  <utility_patterns>
-    <pattern>
-      <name>File Location Helper</name>
-      <example>
-        ```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;
-        }
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>Event Collection Helper</name>
-      <example>
-        ```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 = [];
-          }
-        }
-        ```
-      </example>
-    </pattern>
-  </utility_patterns>
-
-  <debugging_patterns>
-    <pattern>
-      <name>Comprehensive Logging</name>
-      <example>
-        ```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));
-        });
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>State Validation</name>
-      <example>
-        ```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('========================');
-        }
-        ```
-      </example>
-    </pattern>
-  </debugging_patterns>
-</test_patterns>

.roo/rules-integration-tester/3_best_practices.xml

@@ -1,104 +0,0 @@
-<best_practices>
-  <test_structure>
-    - 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
-  </test_structure>
-
-  <api_interactions>
-    - 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
-  </api_interactions>
-
-  <file_system_handling>
-    - 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
-  </file_system_handling>
-
-  <event_handling>
-    - 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
-  </event_handling>
-
-  <error_scenarios>
-    - 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
-  </error_scenarios>
-
-  <test_reliability>
-    - 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
-  </test_reliability>
-
-  <debugging_and_troubleshooting>
-    - 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
-  </debugging_and_troubleshooting>
-
-  <test_utilities>
-    - 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
-  </test_utilities>
-
-  <ai_interaction_considerations>
-    - 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
-  </ai_interaction_considerations>
-
-  <test_execution>
-    - 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
-  </test_execution>
-
-  <code_organization>
-    - 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
-  </code_organization>
-</best_practices>

.roo/rules-integration-tester/4_common_mistakes.xml

@@ -1,109 +0,0 @@
-<common_mistakes_to_avoid>
-  <test_structure_mistakes>
-    - 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
-  </test_structure_mistakes>
-
-  <api_interaction_mistakes>
-    - 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
-  </api_interaction_mistakes>
-
-  <file_system_mistakes>
-    - 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
-  </file_system_mistakes>
-
-  <event_handling_mistakes>
-    - 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
-  </event_handling_mistakes>
-
-  <test_execution_mistakes>
-    - 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
-  </test_execution_mistakes>
-
-  <debugging_mistakes>
-    - 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
-  </debugging_mistakes>
-
-  <ai_interaction_mistakes>
-    - 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
-  </ai_interaction_mistakes>
-
-  <reliability_mistakes>
-    - 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
-  </reliability_mistakes>
-
-  <workspace_mistakes>
-    - 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()
-  </workspace_mistakes>
-
-  <message_handling_mistakes>
-    - 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
-  </message_handling_mistakes>
-
-  <timeout_and_timing_mistakes>
-    - 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
-  </timeout_and_timing_mistakes>
-
-  <test_data_mistakes>
-    - 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
-  </test_data_mistakes>
-</common_mistakes_to_avoid>

.roo/rules-integration-tester/5_test_environment.xml

@@ -1,209 +0,0 @@
-<test_environment_and_tools>
-  <test_framework>
-    <description>VSCode E2E testing framework using Mocha and VSCode Test</description>
-    <key_components>
-      - 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
-    </key_components>
-  </test_framework>
-
-  <directory_structure>
-    <test_files_location>apps/vscode-e2e/src/suite/</test_files_location>
-    <test_utilities>apps/vscode-e2e/src/utils/</test_utilities>
-    <test_runner>apps/vscode-e2e/src/runTest.ts</test_runner>
-    <package_config>apps/vscode-e2e/package.json</package_config>
-    <type_definitions>packages/types/</type_definitions>
-  </directory_structure>
-
-  <test_execution_commands>
-    <working_directory>apps/vscode-e2e</working_directory>
-    <commands>
-      <run_all_tests>npm run test:run</run_all_tests>
-      <run_specific_test>TEST_FILE="filename.test" npm run test:run</run_specific_test>
-      <example>cd apps/vscode-e2e && TEST_FILE="apply-diff.test" npm run test:run</example>
-      <check_scripts>npm run</check_scripts>
-    </commands>
-    <important_notes>
-      - 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
-    </important_notes>
-  </test_execution_commands>
-
-  <api_object>
-    <description>Global api object for extension interactions</description>
-    <key_methods>
-      <task_management>
-        - 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
-      </task_management>
-      <event_listeners>
-        - 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
-      </event_listeners>
-      <settings>
-        - api.updateSettings(settings): Update extension settings
-        - api.getSettings(): Get current settings
-      </settings>
-    </key_methods>
-  </api_object>
-
-  <test_utilities>
-    <wait_functions>
-      <waitFor>
-        <description>Wait for a condition to be true</description>
-        <usage>await waitFor(() => condition, timeout)</usage>
-        <example>await waitFor(() => fs.existsSync(filePath), 5000)</example>
-      </waitFor>
-      <waitUntilCompleted>
-        <description>Wait until current task is completed</description>
-        <usage>await waitUntilCompleted()</usage>
-        <timeout>Default timeout for task completion</timeout>
-      </waitUntilCompleted>
-      <waitUntilAborted>
-        <description>Wait until current task is aborted</description>
-        <usage>await waitUntilAborted()</usage>
-        <timeout>Default timeout for task abortion</timeout>
-      </waitUntilAborted>
-    </wait_functions>
-    
-    <helper_patterns>
-      <file_location_helper>
-        <description>Helper to find files in multiple possible locations</description>
-        <usage>Use when files might be created in different workspace directories</usage>
-      </file_location_helper>
-      <event_collector>
-        <description>Utility to collect and analyze events during test execution</description>
-        <usage>Use for comprehensive event tracking and validation</usage>
-      </event_collector>
-      <assertion_helpers>
-        <description>Custom assertion functions for common test patterns</description>
-        <usage>Use for consistent validation across tests</usage>
-      </assertion_helpers>
-    </helper_patterns>
-  </test_utilities>
-
-  <workspace_management>
-    <workspace_creation>
-      <description>Test workspaces are created by runTest.ts</description>
-      <location>/tmp/roo-test-workspace-*</location>
-      <access>vscode.workspace.workspaceFolders![0].uri.fsPath</access>
-    </workspace_creation>
-    
-    <file_creation_strategy>
-      <setup_phase>Create all test files in suiteSetup() before any tests run</setup_phase>
-      <location>Always create files in the VSCode workspace directory</location>
-      <verification>Verify files exist after creation to catch setup issues early</verification>
-      <cleanup>Clean up all test files in suiteTeardown() to avoid test pollution</cleanup>
-      <storage>Store file paths in a test-scoped object for easy reference</storage>
-    </file_creation_strategy>
-
-    <ai_visibility>
-      <important_note>The AI will not see the files in the workspace directory</important_note>
-      <solution>Tell the AI to assume files exist and proceed as if they do</solution>
-      <verification>Always verify outcomes rather than relying on AI file visibility</verification>
-    </ai_visibility>
-  </workspace_management>
-
-  <message_types>
-    <description>Understanding message types for proper event handling</description>
-    <reference>Check packages/types/src/message.ts for valid message types</reference>
-    
-    <key_message_types>
-      <api_req_started>
-        <type>say</type>
-        <say>api_req_started</say>
-        <description>Indicates tool execution started</description>
-        <text_content>JSON with tool name and execution details</text_content>
-        <usage>Most reliable way to verify tool execution</usage>
-      </api_req_started>
-      
-      <completion_result>
-        <description>Contains tool execution results</description>
-        <usage>Tool results appear here, not in "tool_result" type</usage>
-      </completion_result>
-      
-      <text_messages>
-        <description>General AI conversation messages</description>
-        <caution>Format may vary, don't rely on parsing these for tool detection</caution>
-      </text_messages>
-    </key_message_types>
-  </message_types>
-
-  <auto_approval_settings>
-    <description>Settings to enable automatic approval of AI actions</description>
-    <critical_settings>
-      <alwaysAllowWrite>Enable for file creation/modification tests</alwaysAllowWrite>
-      <alwaysAllowExecute>Enable for command execution tests</alwaysAllowExecute>
-      <alwaysAllowBrowser>Enable for browser-related tests</alwaysAllowBrowser>
-    </critical_settings>
-    <usage>
-      ```typescript
-      await api.updateSettings({
-        alwaysAllowWrite: true,
-        alwaysAllowExecute: true
-      });
-      ```
-    </usage>
-    <importance>Without proper auto-approval settings, the AI won't be able to perform actions without user approval</importance>
-  </auto_approval_settings>
-
-  <debugging_tools>
-    <console_logging>
-      <description>Use console.log for tracking test execution flow</description>
-      <best_practices>
-        - Log test phase transitions
-        - Log important events and data
-        - Log file paths and workspace state
-        - Log expected vs actual outcomes
-      </best_practices>
-    </console_logging>
-    
-    <state_validation>
-      <description>Helper functions to validate test state at critical points</description>
-      <includes>
-        - Workspace file listing
-        - Current working directory
-        - Task status
-        - Event counts
-      </includes>
-    </state_validation>
-    
-    <error_analysis>
-      <description>Tools for analyzing test failures</description>
-      <techniques>
-        - Stack trace analysis
-        - Event timeline reconstruction
-        - File system state comparison
-        - Message flow analysis
-      </techniques>
-    </error_analysis>
-  </debugging_tools>
-
-  <performance_considerations>
-    <timeouts>
-      <description>Appropriate timeout values for different operations</description>
-      <task_completion>Use generous timeouts for task completion (30+ seconds)</task_completion>
-      <file_operations>Shorter timeouts for file system operations (5-10 seconds)</file_operations>
-      <event_waiting>Medium timeouts for event waiting (10-15 seconds)</event_waiting>
-    </timeouts>
-    
-    <resource_management>
-      <description>Proper cleanup to avoid resource leaks</description>
-      <event_listeners>Always clean up event listeners after tests</event_listeners>
-      <tasks>Cancel or clear tasks in teardown</tasks>
-      <files>Remove test files to avoid disk space issues</files>
-    </resource_management>
-  </performance_considerations>
-</test_environment_and_tools>

.roo/rules-issue-investigator/1_workflow.xml

@@ -70,7 +70,7 @@
         </step>
         <step>
             <title>Draft Comment</title>
-            <description>Draft a comment for the GitHub issue that explains your findings and suggested solution in a conversational, human-like tone.</description>
+            <description>Draft a comment for the GitHub issue that explains your findings and suggested solution in a conversational, human-like tone. Start the comment with "Hey @roomote-agent,".</description>
         </step>
       </steps>
     </phase>

.roo/rules-issue-investigator/2_best_practices.xml

@@ -52,6 +52,7 @@
     </category>
     <category name="communication">
       <item>Does the draft comment sound conversational and human?</item>
+      <item>Does the draft comment start with "Hey @roomote-agent,"?</item>
       <item>Have I avoided technical jargon where possible?</item>
       <item>Is the tone helpful and not condescending?</item>
     </category>

.roo/rules-issue-investigator/4_tool_usage.xml

@@ -23,10 +23,16 @@
         <practice>Use `gh issue view [URL] --json title,body,labels,comments` to fetch initial details.</practice>
         <practice>Use `gh issue comment [URL] --body "..."` to add comments, but only after explicit user approval.</practice>
         <practice>Always wrap the comment body in quotes to handle special characters.</practice>
+        <practice>When posting a comment, the body must start with "Hey @roomote-agent," exactly.</practice>
       </best_practices>
       <example><![CDATA[
 <execute_command>
 <command>gh issue view https://github.com/RooCodeInc/Roo-Code/issues/123 --json title,body</command>
+</execute_command>
+      ]]></example>
+      <example><![CDATA[
+<execute_command>
+<command>gh issue comment https://github.com/RooCodeInc/Roo-Code/issues/123 --body "Hey @roomote-agent, I've investigated and proposed a theoretical fix above."</command>
 </execute_command>
       ]]></example>
     </tool>

.roo/rules-issue-investigator/5_examples.xml

@@ -70,7 +70,7 @@
       <step number="6">
           <description>Formulate a solution and draft a comment.</description>
           <draft>
-"Hey, I took a look at this issue and it seems like the problem is in the `handleLogin` function in `src/auth/login.ts`. There's an empty `try...catch` block that is likely catching the login error and preventing any message from being shown to the user.
+"Hey @roomote-agent, I took a look at this issue and it seems like the problem is in the `handleLogin` function in `src/auth/login.ts`. There's an empty `try...catch` block that is likely catching the login error and preventing any message from being shown to the user.
 
 A good first step to fixing this would be to add some logging to the `catch` block to see what error is actually happening. Then, we should probably implement proper error feedback to the user on the login page. This should solve the issue of the silent failure."
           </draft>

.roo/rules-issue-investigator/6_communication.xml

@@ -2,18 +2,20 @@
   <tone_and_style>
     <principle>Be conversational and helpful, not robotic.</principle>
     <principle>Write comments as if you are a human developer collaborating on the project.</principle>
+    <principle>Always start any GitHub issue comment body with "Hey @roomote-agent,".</principle>
     <avoid>
       <phrase>Analysis complete.</phrase>
       <phrase>The investigation has yielded the following result.</phrase>
+      <phrase>Starting comments with "Hey," instead of "Hey @roomote-agent,".</phrase>
     </avoid>
     <prefer>
-      <phrase>Hey, I took a look at this and found something interesting...</phrase>
-      <phrase>I've been digging into this issue, and I think I've found a possible cause.</phrase>
+      <phrase>Hey @roomote-agent, I took a look at this and found something interesting...</phrase>
+      <phrase>Hey @roomote-agent, I've been digging into this issue, and I think I've found a possible cause.</phrase>
     </prefer>
   </tone_and_style>
 
   <comment_structure>
-      <element>Start with a friendly opening.</element>
+      <element>Start every GitHub issue comment with "Hey @roomote-agent,".</element>
       <element>State your main finding or hypothesis clearly but not definitively.</element>
       <element>Provide context, like file paths and function names.</element>
       <element>Propose a next step or a theoretical solution.</element>

.roo/rules-issue-writer/2_github_issue_templates.xml

@@ -1,190 +0,0 @@
-<github_issue_templates>
-  <overview>
-    This mode prioritizes using repository-specific issue templates over hardcoded ones.
-    If no templates exist in the repository, simple generic templates are created on the fly.
-  </overview>
-
-  <template_detection>
-    <locations>
-      <location priority="1">.github/ISSUE_TEMPLATE/*.yml</location>
-      <location priority="2">.github/ISSUE_TEMPLATE/*.yaml</location>
-      <location priority="3">.github/ISSUE_TEMPLATE/*.md</location>
-      <location priority="4">.github/issue_template.md</location>
-      <location priority="5">.github/ISSUE_TEMPLATE.md</location>
-    </locations>
-    
-    <yaml_template_structure>
-      <field name="name">Display name of the template</field>
-      <field name="description">Brief description of when to use this template</field>
-      <field name="title">Default issue title (optional)</field>
-      <field name="labels">Array of labels to apply</field>
-      <field name="assignees">Array of default assignees</field>
-      <field name="body">Array of form elements or markdown content</field>
-    </yaml_template_structure>
-    
-    <yaml_form_elements>
-      <element type="markdown">
-        <description>Static markdown content</description>
-        <attributes>
-          <attr name="value">The markdown content to display</attr>
-        </attributes>
-      </element>
-      
-      <element type="input">
-        <description>Single-line text input</description>
-        <attributes>
-          <attr name="id">Unique identifier</attr>
-          <attr name="label">Display label</attr>
-          <attr name="description">Help text</attr>
-          <attr name="placeholder">Placeholder text</attr>
-          <attr name="value">Default value</attr>
-          <attr name="required">Boolean</attr>
-        </attributes>
-      </element>
-      
-      <element type="textarea">
-        <description>Multi-line text input</description>
-        <attributes>
-          <attr name="id">Unique identifier</attr>
-          <attr name="label">Display label</attr>
-          <attr name="description">Help text</attr>
-          <attr name="placeholder">Placeholder text</attr>
-          <attr name="value">Default value</attr>
-          <attr name="required">Boolean</attr>
-          <attr name="render">Language for syntax highlighting</attr>
-        </attributes>
-      </element>
-      
-      <element type="dropdown">
-        <description>Dropdown selection</description>
-        <attributes>
-          <attr name="id">Unique identifier</attr>
-          <attr name="label">Display label</attr>
-          <attr name="description">Help text</attr>
-          <attr name="options">Array of options</attr>
-          <attr name="required">Boolean</attr>
-        </attributes>
-      </element>
-      
-      <element type="checkboxes">
-        <description>Multiple checkbox options</description>
-        <attributes>
-          <attr name="id">Unique identifier</attr>
-          <attr name="label">Display label</attr>
-          <attr name="description">Help text</attr>
-          <attr name="options">Array of checkbox items</attr>
-        </attributes>
-      </element>
-    </yaml_form_elements>
-    
-    <markdown_template_structure>
-      <front_matter>
-        Optional YAML front matter with:
-        - name: Template name
-        - about: Template description
-        - title: Default title
-        - labels: Comma-separated or array
-        - assignees: Comma-separated or array
-      </front_matter>
-      <body>
-        Markdown content with sections and placeholders
-        Common patterns:
-        - Headers with ##
-        - Placeholder text in brackets or as comments
-        - Checklists with - [ ]
-        - Code blocks with ```
-      </body>
-    </markdown_template_structure>
-  </template_detection>
-
-  <generic_templates>
-    <description>
-      When no repository templates exist, create simple templates based on issue type.
-      These should be minimal and focused on gathering essential information.
-    </description>
-    
-    <bug_template>
-      <structure>
-        - Description: Clear explanation of the bug
-        - Steps to Reproduce: Numbered list
-        - Expected Behavior: What should happen
-        - Actual Behavior: What actually happens
-        - Additional Context: Version, environment, logs
-        - Code Investigation: Findings from exploration (if any)
-      </structure>
-      <labels>["bug"]</labels>
-    </bug_template>
-    
-    <feature_template>
-      <structure>
-        - Problem Description: What problem this solves
-        - Current Behavior: How it works now
-        - Proposed Solution: What should change
-        - Impact: Who benefits and how
-        - Technical Context: Code findings (if any)
-      </structure>
-      <labels>["enhancement", "proposal"]</labels>
-    </feature_template>
-  </generic_templates>
-
-  <template_parsing_guidelines>
-    <guideline>
-      When parsing YAML templates:
-      1. Use a YAML parser to extract the structure
-      2. Convert form elements to markdown sections
-      3. Preserve required field indicators
-      4. Include descriptions as help text
-      5. Maintain the intended flow of the template
-    </guideline>
-    
-    <guideline>
-      When parsing Markdown templates:
-      1. Extract front matter if present
-      2. Identify section headers
-      3. Look for placeholder patterns
-      4. Preserve formatting and structure
-      5. Replace generic placeholders with user's information
-    </guideline>
-    
-    <guideline>
-      For template selection:
-      1. If only one template exists, use it automatically
-      2. If multiple exist, let user choose based on name/description
-      3. Match template to issue type when possible (bug vs feature)
-      4. Respect template metadata (labels, assignees, etc.)
-    </guideline>
-  </template_parsing_guidelines>
-
-  <filling_templates>
-    <principle>
-      Fill templates intelligently using gathered information:
-      - Map user's description to appropriate sections
-      - Include code investigation findings where relevant
-      - Preserve template structure and formatting
-      - Don't leave placeholder text unfilled
-      - Add contributor scoping if user is contributing
-    </principle>
-    
-    <mapping_examples>
-      <example from="Steps to Reproduce" to="User's reproduction steps + code paths"/>
-      <example from="Expected behavior" to="What user expects + code logic verification"/>
-      <example from="System information" to="Detected versions + environment"/>
-      <example from="Additional context" to="Code findings + architecture insights"/>
-    </mapping_examples>
-  </filling_templates>
-
-  <no_template_behavior>
-    <description>
-      When no templates exist, create appropriate generic templates on the fly.
-      Keep them simple and focused on essential information.
-    </description>
-    
-    <guidelines>
-      - Don't overwhelm with too many fields
-      - Focus on problem description first
-      - Include technical details only if user is contributing
-      - Use clear, simple section headers
-      - Adapt based on issue type (bug vs feature)
-    </guidelines>
-  </no_template_behavior>
-</github_issue_templates>

.roo/rules-issue-writer/3_best_practices.xml

@@ -1,172 +1,147 @@
 <best_practices>
+  <mode_scope>
+    This mode assembles a template-free issue body grounded by codebase exploration and can submit it via GitHub CLI after explicit confirmation.
+    Submission uses Title and Body only and targets the detected repository after the merged Review and Submit step.
+  </mode_scope>
+
   <mode_behavior>
-    - CRITICAL: This mode assumes the user's FIRST message is already an issue description
-    - Do NOT ask "What would you like to do?" or "Do you want to create an issue?"
-    - Immediately start the issue creation workflow when the user begins talking
-    - Treat their initial message as the problem/feature description
-    - Begin with repository detection and codebase discovery right away
-    - The user is already in "issue creation mode" by choosing this mode
+    - Treat the user's FIRST message as the issue description; do not ask if they want to create an issue.
+    - Start with repository detection (verify git repo; resolve OWNER/REPO from origin), then determine repository structure (monorepo/standard).
+    - After detection, begin codebase discovery scoped to the repository root or the selected package (in monorepos).
+    - Keep final output non-technical; implementation details remain internal.
   </mode_behavior>
-  
-  <template_usage>
-    - ALWAYS check for repository-specific issue templates before creating issues
-    - Use templates from .github/ISSUE_TEMPLATE/ directory if they exist
-    - Parse both YAML (.yml/.yaml) and Markdown (.md) template formats
-    - If multiple templates exist, let the user choose the appropriate one
-    - If no templates exist, create a simple generic template on the fly
-    - NEVER fall back to hardcoded templates - always use repo templates or generate minimal ones
-    - Respect template metadata like labels, assignees, and title patterns
-    - Fill templates intelligently using gathered information from codebase exploration
-  </template_usage>
-  
-  <problem_reporting_focus>
-    - Focus on helping users describe problems clearly, not solutions
-    - The project 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
-    
-    CRITICAL: Lead with user impact:
-    - Always explain WHO is affected and WHEN the problem occurs
-    - Use concrete examples with actual values, not abstractions
-    - Show before/after scenarios with specific data
-    - Example: "Users trying to [action] see [actual result] instead of [expected result]"
-  </problem_reporting_focus>
-  
-  <fact_driven_verification>
-    - ALWAYS verify user claims against actual code implementation
-    - For feature requests, aggressively check if current behavior matches user's description
-    - If code shows different intent than user describes, it might be a bug not a feature
-    - Present code evidence when challenging user assumptions
-    - Do not be agreeable - be fact-driven and question discrepancies
-    - Continue verification until facts are established
-    - A "feature request" where code shows the feature should already work is likely a bug
-    
-    CRITICAL additions for thorough analysis:
-    - Trace data flow from where values are created to where they're used
-    - Look for existing variables/functions that already contain needed data
-    - Check if the issue is just missing usage of existing code
-    - Follow imports and exports to understand data availability
-    - Identify patterns in similar features that work correctly
-  </fact_driven_verification>
-  
-  <general_practices>
-    - Always search for existing similar issues before creating a new one
-    - Check for and use repository issue templates before creating content
-    - 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
-    
-    CRITICAL: Use concrete examples throughout:
-    - Show actual data values, not just descriptions
-    - Include specific file paths and line numbers
-    - Demonstrate the data flow with real examples
-    - Bad: "The value is incorrect"
-    - Good: "The function returns '123' when it should return '456'"
-  </general_practices>
-  
-  <contributor_specific>
-    - Only perform issue scoping 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 issue scoping
-    - Provide clear acceptance criteria in Given/When/Then format
-    - Consider trade-offs and alternative approaches
-    
-    CRITICAL: Prioritize simple solutions:
-    - ALWAYS check if needed functionality already exists before proposing new code
-    - Look for existing variables that just need to be passed/used differently
-    - Prefer using existing patterns over creating new ones
-    - The best fix often involves minimal code changes
-    - Example: "Use existing `modeInfo` from line 234 in export" vs "Create new mode tracking system"
-  </contributor_specific>
-  
-  <backwards_compatibility_focus>
-    ALWAYS consider backwards compatibility:
-    - Think about existing data/configurations already in use
-    - Propose solutions that handle both old and new formats gracefully
-    - Consider migration paths for existing users
-    - Document any breaking changes clearly
-    - Prefer additive changes over breaking changes when possible
-  </backwards_compatibility_focus>
-  
+
+  <value_framing>
+    <principles>
+      - Always pair the problem with user-facing value: who is impacted, when it occurs, and why it matters.
+      - Keep value non-technical (clarity, time saved, fewer errors, better UX, improved accessibility, reduced confusion).
+    </principles>
+    <lightweight_impact_options>
+      - Severity: Blocker | High | Medium | Low (optional)
+      - Reach: Few | Some | Many (optional)
+    </lightweight_impact_options>
+  </value_framing>
+
+  <sourcing_and_provenance>
+    <direct_from_user_only>
+      - Reproduction steps
+      - Variations tried
+      - Environment details
+    </direct_from_user_only>
+    <inference_allowed_with_care>
+      - Problem/Value statement (plain-language synthesis from user wording)
+      - Context (who/when) based on user input; keep code-based signals internal
+    </inference_allowed_with_care>
+    <hallucination_guards>
+      - Never fabricate “Variations tried.” If not provided, omit.
+      - If critical details are missing, ask targeted questions; otherwise proceed with omissions.
+    </hallucination_guards>
+  </sourcing_and_provenance>
+
+  <cli_submission>
+    <confirmation>
+      Use a single merged "Review and Submit" step with options:
+      - Submit now
+      - Submit now and assign to me
+      Any other response is treated as a change request and the step is rerun after applying edits.
+    </confirmation>
+    <repo_detection>
+      Submission requires repository detection (git present, origin configured). Capture normalized OWNER/REPO (e.g., owner/repo) and store as [OWNER_REPO] for submission.
+    </repo_detection>
+    <target_repo>
+      Always specify the target using --repo "[OWNER_REPO]" to avoid ambiguity and ensure the correct repository is used.
+    </target_repo>
+    <assignment>
+      When "Submit now and assign to me" is chosen, create using: --assignee "@me".
+      If creation with --assignee fails (e.g., permissions), create the issue without an assignee and immediately run:
+      gh issue edit <issue-url-or-number> --add-assignee "@me".
+    </assignment>
+    <command_safety>
+      Use --body with robust quoting (for example: --body "$(printf '%s\n' "[ISSUE_BODY]")") or a heredoc; do not create temporary files or reference file paths. Always include --repo "[OWNER_REPO]" and echo the resulting issue URL.
+      In execute_command calls, output only the command string; never include XML tags, CDATA markers, code fences, or backticks in the command payload.
+    </command_safety>
+    <error_handling>
+      On gh errors (installation/auth), present the error and offer to retry after fixing gh setup. Surface the computed Title and Body inline
+      so the user can submit manually if needed.
+    </error_handling>
+  </cli_submission>
+
+  <codebase_exploration>
+    <principles>
+      - Use semantic search first to find relevant areas.
+      - Refine with targeted regex for exact strings (errors, component names, flags).
+      - Read key files to verify behavior; keep evidence internal.
+      - Early-stop when hits converge (~70%) or you can name the exact feature/component.
+      - Escalate-once if signals conflict; run one refined batch, then proceed.
+    </principles>
+    <tool_sequence>
+      1) codebase_search → 2) search_files → 3) read_file (as needed)
+    </tool_sequence>
+    <scoping>
+      In monorepos, scope searches to the selected package when the context is clear; otherwise ask for the relevant package/app if ambiguous.
+    </scoping>
+    <internal_only>
+      Keep language plain and exclude technical artifacts (paths, line numbers, stack traces, diffs) from the final issue body.
+    </internal_only>
+  </codebase_exploration>
+
+  <questioning>
+    <guidelines>
+      - Ask minimal, targeted questions based on what you found in code.
+      - For bugs: request a minimal reproduction (environment, steps, expected, actual, variations).
+      - For enhancements: capture user goal, desired behavior in plain language, and any constraints.
+      - Present discrepancies in plain language (no code) and confirm understanding.
+    </guidelines>
+  </questioning>
+
+  <issue_output_rules>
+    <format>
+      <![CDATA[
+## Type
+Bug | Enhancement
+
+## Problem / Value
+[One or two sentences that capture the problem and why it matters in plain language]
+
+## Context
+[Who is affected and when it happens]
+[Enhancement: desired behavior conceptually, in the user's words]
+[Bug: current observed behavior in plain language]
+
+## Reproduction (Bug only, if available)
+1) Steps (each action/command)
+2) Expected result
+3) Actual result
+4) Variations tried (only if explicitly provided)
+
+## Constraints/Preferences
+[Performance, accessibility, UX, or other considerations]
+      ]]>
+    </format>
+    <rules>
+      - Omit sections that would be empty.
+      - Do not include "Variations tried" unless explicitly provided by the user.
+      - Keep language plain and user-centric.
+      - Exclude technical artifacts (paths, lines, stacks, diffs).
+    </rules>
+  </issue_output_rules>
+
+  <review_stage_presentation>
+    - At each review stage, present the full current issue details (Title + Body) in a markdown code block.
+    - Offer "Submit now" or "Submit now and assign to me" suggestions; treat any other response as a change request and rerun the step after applying edits.
+  </review_stage_presentation>
+
+  <autonomy_and_budgets>
+    - Tool preambles: restate goal briefly, outline a short plan, narrate progress succinctly, summarize final delta.
+    - One-tool-per-message: await results before continuing.
+    - Discovery budget: default max 3 searches before escalate-once; stop when sufficient.
+    - Early-stop: when top hits converge or target is identifiable.
+    - Verbosity: low narrative; detail appears only in structured outputs.
+  </autonomy_and_budgets>
+
   <communication_guidelines>
-    - 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
-    - When presenting template choices, include template descriptions to help users choose
-    - Explain that you're using the repository's own templates for consistency
+    - Be direct and concise; avoid jargon in the final issue body.
+    - Keep questions optional and easy to answer with suggested options.
+    - Emphasize WHO is affected and WHEN it happens.
   </communication_guidelines>
-  
-  <template_best_practices>
-    <practice name="template_detection">
-      Always check these locations in order:
-      1. .github/ISSUE_TEMPLATE/*.yml or *.yaml (GitHub form syntax)
-      2. .github/ISSUE_TEMPLATE/*.md (Markdown templates)
-      3. .github/issue_template.md (single template)
-      4. .github/ISSUE_TEMPLATE.md (alternate naming)
-    </practice>
-    
-    <practice name="template_parsing">
-      For YAML templates:
-      - Extract form elements and convert to appropriate markdown sections
-      - Preserve required field indicators
-      - Include field descriptions as context
-      - Respect dropdown options and checkbox lists
-      
-      For Markdown templates:
-      - Parse front matter for metadata
-      - Identify section headers and structure
-      - Replace placeholder text with actual information
-      - Maintain formatting and hierarchy
-    </practice>
-    
-    <practice name="template_filling">
-      - Map gathered information to template sections intelligently
-      - Don't leave placeholder text in the final issue
-      - Add code investigation findings to relevant sections
-      - Include contributor scoping in appropriate section if applicable
-      - Preserve the template's intended structure and flow
-    </practice>
-    
-    <practice name="no_template_handling">
-      When no templates exist:
-      - Create minimal, focused templates
-      - Use simple section headers
-      - Focus on essential information only
-      - Adapt structure based on issue type
-      - Don't overwhelm with unnecessary fields
-    </practice>
-  </template_best_practices>
-  <technical_accuracy_guidelines>
-    <guideline name="thorough_code_analysis">
-      Before proposing ANY solution:
-      1. Use codebase_search extensively to find all related code
-      2. Read multiple files to understand the full context
-      3. Trace variable usage from creation to consumption
-      4. Look for similar working features to understand patterns
-      5. Identify what already exists vs what's actually missing
-    </guideline>
-    
-    <guideline name="simplicity_first">
-      When designing solutions:
-      1. Check if the data/function already exists somewhere
-      2. Look for configuration options before code changes
-      3. Prefer passing existing variables over creating new ones
-      4. Use established patterns from similar features
-      5. Aim for minimal diff size
-    </guideline>
-    
-    <guideline name="precise_technical_details">
-      Always include:
-      - Exact file paths and line numbers
-      - Variable/function names as they appear in code
-      - Before/after code snippets showing minimal changes
-      - Clear explanation of why the simple fix works
-    </guideline>
-  </technical_accuracy_guidelines>
 </best_practices>

.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml

@@ -1,126 +1,109 @@
 <common_mistakes_to_avoid>
   <mode_initialization_mistakes>
-    - CRITICAL: Asking "What would you like to do?" when mode starts
-    - Waiting for user to say "create an issue" or "make me an issue"
-    - Not treating the first user message as the issue description
-    - Delaying the workflow start with unnecessary questions
-    - Asking if they want to create an issue when they've already chosen this mode
-    - Not immediately beginning repository detection and codebase discovery
+    - Asking "What would you like to do?" at start instead of treating the first message as the issue description
+    - Delaying the workflow with unnecessary questions before discovery
+    - Not immediately beginning codebase-aware discovery (semantic search → regex refine → read key files)
+    - Skipping repository detection (git + origin) before discovery or submission
+    - Not validating repository context before gh commands
   </mode_initialization_mistakes>
-  
+
+  <scope_mistakes>
+    - Submitting without explicit user confirmation ("Submit now")
+    - Targeting the wrong repository by relying on current directory defaults; always pass --repo OWNER/REPO detected in Step 2
+    - Performing PR prep, complexity estimates, or technical scoping
+  </scope_mistakes>
+
+  <submission_mistakes>
+    <mistake_block>
+      <mistake>Splitting final review and submission into multiple steps</mistake>
+      <impact>Creates redundant prompts and inconsistent state; leads to janky UX</impact>
+      <correct_approach>Use a single merged "Review and Submit" step offering only: Submit now, Submit now and assign to me; treat any other response as a change request</correct_approach>
+    </mistake_block>
+    <mistake_block>
+      <mistake>Not offering "Submit now and assign to me"</mistake>
+      <impact>Forces manual assignment later; reduces efficiency</impact>
+      <correct_approach>Provide the assignment option and use gh issue create --assignee "@me"; if that fails, immediately run gh issue edit <issue-url-or-number> --add-assignee "@me"</correct_approach>
+    </mistake_block>
+    <mistake_block>
+      <mistake>Using temporary files or --body-file for issue body submission</mistake>
+      <impact>Introduces filesystem dependencies and leaks paths; contradicts single-command policy</impact>
+      <correct_approach>Use inline --body with robust quoting, e.g., --body "$(printf '%s\n' "[ISSUE_BODY]")"; do not reference any file paths</correct_approach>
+    </mistake_block>
+    <mistake_block>
+      <mistake>Omitting --repo or relying on current directory defaults</mistake>
+      <impact>May submit to the wrong repository in multi-repo or worktree contexts</impact>
+      <correct_approach>Always pass --repo [OWNER_REPO] detected in Step 2</correct_approach>
+    </mistake_block>
+    <mistake_block>
+      <mistake>Attempting submission without prior repository detection</mistake>
+      <impact>Commands may target the wrong repo or fail</impact>
+      <correct_approach>Detect git repo and ensure origin is configured before any gh commands</correct_approach>
+    </mistake_block>
+  </submission_mistakes>
+
+  <sourcing_mistakes>
+    <mistake_block>
+      <mistake>Inventing or inferring “Variations tried” when the user didn’t provide any</mistake>
+      <impact>Misleads triage and wastes time reproducing non-existent attempts</impact>
+      <correct_approach>Omit the “Variations tried” line entirely unless explicitly provided; if needed, ask a targeted question first</correct_approach>
+    </mistake_block>
+    <mistake_block>
+      <mistake>Framing only the problem without the value/impact</mistake>
+      <impact>Makes prioritization harder; obscures who benefits and why it matters</impact>
+      <correct_approach>Pair the problem with a plain-language value statement (who, when, why it matters)</correct_approach>
+    </mistake_block>
+    <mistake_block>
+      <mistake>Overstating impact without user signal</mistake>
+      <impact>Damages credibility and misguides prioritization</impact>
+      <correct_approach>Use conservative, plain language; if unsure, omit severity/reach or ask a single targeted question</correct_approach>
+    </mistake_block>
+  </sourcing_mistakes>
+
   <problem_reporting_mistakes>
-    - 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
+    - Vague descriptions like "doesn't work" without who/when impact
+    - Missing minimal reproduction for bugs (environment, steps, expected, actual, variations)
+    - Enhancement requests that skip the user goal or desired behavior in plain language
+    - Titles/summaries that don't quickly communicate the issue
   </problem_reporting_mistakes>
-  
-  <workflow_mistakes>
-    - Asking for technical details from non-contributing users
-    - Performing issue scoping 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
-    - Using hardcoded templates instead of repository templates
-    - Not checking for issue templates before creating content
-    - Ignoring template metadata like labels and assignees
-  </workflow_mistakes>
-  
-  <contributor_mistakes>
-    - Starting implementation before approval
-    - Not providing detailed issue scoping 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
-  </contributor_mistakes>
-  
-  <technical_analysis_mistakes>
-    <mistake>Not tracing data flow completely through the system</mistake>
-    <impact>Missing that data already exists leads to proposing unnecessary new code</impact>
+
+  <output_mistakes>
+    - Including code paths, line numbers, stack traces, or diffs in the final issue body
+    - Adding labels, metadata, or repository details to the body
+    - Leaving empty section placeholders instead of omitting the section
+    - Using technical jargon instead of plain, user-centric language
+  </output_mistakes>
+
+  <code_exploration_mistakes>
+    <mistake>Skipping semantic search and jumping straight to assumptions</mistake>
+    <impact>Leads to misclassification and inaccurate context</impact>
     <correct_approach>
-      - Use codebase_search extensively to find ALL related code
-      - Trace variables from creation to consumption
-      - Check if needed data is already calculated but not used
-      - Look for similar working features as patterns
+      - Start with codebase_search on extracted keywords
+      - Refine with search_files for exact strings (errors, component names, flags)
+      - read_file only as needed to verify behavior; keep evidence internal
+      - Early-stop when hits converge or you can name the exact feature/component
+      - Escalate-once if signals conflict (one refined pass), then proceed
     </correct_approach>
-    <example>
-      Bad: "Add mode tracking to import function"
-      Good: "The export already includes mode info at line 234, just use it in import at line 567"
-    </example>
-  </technical_analysis_mistakes>
-  
-  <solution_design_mistakes>
-    <mistake>Proposing complex new systems when simple fixes exist</mistake>
-    <impact>Creates unnecessary complexity, maintenance burden, and potential bugs</impact>
+  </code_exploration_mistakes>
+
+  <discrepancy_handling_mistakes>
+    <mistake>Accepting user claims that contradict the codebase without verification</mistake>
+    <impact>Produces misleading or incorrect issue framing</impact>
     <correct_approach>
-      - ALWAYS check if functionality already exists first
-      - Look for minimal changes that solve the problem
-      - Prefer using existing variables/functions differently
-      - Aim for the smallest possible diff
+      - Verify claims against the implementation; trace data from creation → usage
+      - Compare with similar working features to ground expectations
+      - If discrepancies arise, present concrete, plain-language examples (no code) and confirm
     </correct_approach>
-    <example>
-      Bad: "Create new state management system for mode tracking"
-      Good: "Pass existing modeInfo variable from line 45 to the function at line 78"
-    </example>
-  </solution_design_mistakes>
-  
-  <code_verification_mistakes>
-    <mistake>Not reading actual code before proposing solutions</mistake>
-    <impact>Solutions don't match the actual codebase structure</impact>
-    <correct_approach>
-      - Always read the relevant files first
-      - Verify exact line numbers and content
-      - Check imports/exports to understand data availability
-      - Look at similar features that work correctly
-    </correct_approach>
-  </code_verification_mistakes>
-  
-  <pattern_recognition_mistakes>
-    <mistake>Creating new patterns instead of following existing ones</mistake>
-    <impact>Inconsistent codebase, harder to maintain</impact>
-    <correct_approach>
-      - Find similar features that work correctly
-      - Follow the same patterns and structures
-      - Reuse existing utilities and helpers
-      - Maintain consistency with the codebase style
-    </correct_approach>
-  </pattern_recognition_mistakes>
-  
-  <template_usage_mistakes>
-    <mistake>Using hardcoded templates when repository templates exist</mistake>
-    <impact>Issues don't follow repository conventions, may be rejected or need reformatting</impact>
-    <correct_approach>
-      - Always check .github/ISSUE_TEMPLATE/ directory first
-      - Parse and use repository templates when available
-      - Only create generic templates when none exist
-    </correct_approach>
-  </template_usage_mistakes>
-  
-  <template_parsing_mistakes>
-    <mistake>Not properly parsing YAML template structure</mistake>
-    <impact>Missing required fields, incorrect formatting, lost metadata</impact>
-    <correct_approach>
-      - Parse YAML templates to extract all form elements
-      - Convert form elements to appropriate markdown sections
-      - Preserve field requirements and descriptions
-      - Maintain dropdown options and checkbox lists
-    </correct_approach>
-  </template_parsing_mistakes>
-  
-  <template_filling_mistakes>
-    <mistake>Leaving placeholder text in final issue</mistake>
-    <impact>Unprofessional appearance, confusion about what information is needed</impact>
-    <correct_approach>
-      - Replace all placeholders with actual information
-      - Remove instruction text meant for template users
-      - Fill every section with relevant content
-      - Add "N/A" for truly inapplicable sections
-    </correct_approach>
-  </template_filling_mistakes>
+  </discrepancy_handling_mistakes>
+
+  <questioning_mistakes>
+    - Asking broad, unfocused questions instead of targeted ones based on findings
+    - Demanding technical details from non-technical users
+    - Failing to provide easy, suggested answer formats (repro scaffold, goal statement)
+  </questioning_mistakes>
+
+  <consistency_mistakes>
+    - Mixing internal technical evidence into the final body
+    - Ignoring the issue format or adding extra sections
+    - Using inconsistent tone or switching between technical and non-technical language
+  </consistency_mistakes>
 </common_mistakes_to_avoid>

.roo/rules-issue-writer/5_examples.xml

@@ -0,0 +1,134 @@
+<issue_examples>
+  <overview>
+    Examples of assembling template-free issue prompts grounded by codebase exploration, with optional CLI submission after explicit confirmation.
+    Repository detection precedes submission; review and submission occur in a single merged step offering "Submit now" or "Submit now and assign to me". Any other response is treated as a change request.
+  </overview>
+
+  <example name="bug_dark_theme_button_invisible">
+    <user_input>
+      In dark theme the Submit button is almost invisible on the New Run page.
+    </user_input>
+    <discovery>
+      <tool_calls>
+        <![CDATA[
+<codebase_search>
+<query>dark theme submit button visibility</query>
+</codebase_search>
+
+<search_files>
+<path>.</path>
+<regex>Submit|button|dark|theme</regex>
+</search_files>
+        ]]>
+      </tool_calls>
+      <notes>
+        Internal: matches found in UI components related to theme; wording grounded to user impact.
+      </notes>
+    </discovery>
+    <final_issue_body><![CDATA[
+## Type
+Bug
+
+## Problem / Value
+In dark theme, the Submit button is hard to see on the new run form, making it difficult for users to complete new runs.
+
+## Context
+Affects users creating new runs with dark theme enabled; the button appears low-contrast and is difficult to locate.
+
+## Reproduction
+1) Steps: Open "New Run" -> Scroll to bottom -> Look for Submit
+2) Expected result: Clearly visible, high-contrast Submit button
+3) Actual result: Button appears nearly invisible in dark theme
+4) Variations tried: Different browsers (Chrome/Firefox) show same result
+    ]]></final_issue_body>
+  </example>
+
+  <example name="enhancement_copy_run_confirmation">
+    <user_input>
+      I accidentally click "Copy Run" sometimes; would be great to have a simple confirmation.
+    </user_input>
+    <discovery>
+      <tool_calls>
+        <![CDATA[
+<codebase_search>
+<query>Copy Run confirmation</query>
+</codebase_search>
+        ]]>
+      </tool_calls>
+      <notes>
+        Internal: feature entry point identified; keep final output non-technical and user-centric.
+      </notes>
+    </discovery>
+    <final_issue_body><![CDATA[
+## Type
+Enhancement
+
+## Problem / Value
+Add a confirmation dialog before copying an existing run to prevent accidental duplication.
+
+## Context
+Users sometimes click "Copy Run" by mistake when browsing runs; a simple confirmation would prevent accidental duplication.
+
+## Constraints/Preferences
+Keep the flow lightweight and unobtrusive; avoid slowing down intentional copies.
+    ]]></final_issue_body>
+  </example>
+
+  <example name="bug_submission_review_and_assign">
+    <user_input>
+      Dark theme Submit button is invisible; I'd like to file this.
+    </user_input>
+    <final_issue_body><![CDATA[
+## Type
+Bug
+
+## Problem / Value
+In dark theme, the Submit button is hard to see on the new run form, making it difficult for users to complete new runs.
+
+## Context
+Affects users creating new runs with dark theme enabled; the button appears low-contrast and is difficult to locate.
+
+## Reproduction
+1) Steps: Open "New Run" -> Scroll to bottom -> Look for Submit
+2) Expected result: Clearly visible, high-contrast Submit button
+3) Actual result: Button appears nearly invisible in dark theme
+    ]]></final_issue_body>
+    <review_and_submit>
+      <ask_followup_question>
+        <question>Review the current issue details. Select one of the options below or specify any changes or other workflow you would like me to perform:
+
+```md
+Title: [ISSUE_TITLE]
+
+[ISSUE_BODY]
+```</question>
+        <follow_up>
+          <suggest>Submit now</suggest>
+          <suggest>Submit now and assign to me</suggest>
+        </follow_up>
+      </ask_followup_question>
+
+      <execute_command for="submit_now">
+        <command>gh issue create --repo "[OWNER_REPO]" --title "[ISSUE_TITLE]" --body "$(printf '%s\n' "[ISSUE_BODY]")"</command>
+      </execute_command>
+
+      <execute_command for="submit_now_and_assign_to_me">
+        <command>ISSUE_URL=$(gh issue create --repo "[OWNER_REPO]" --title "[ISSUE_TITLE]" --body "$(printf '%s\n' "[ISSUE_BODY]")" --assignee "@me") || true; if [ -z "$ISSUE_URL" ]; then ISSUE_URL=$(gh issue create --repo "[OWNER_REPO]" --title "[ISSUE_TITLE]" --body "$(printf '%s\n' "[ISSUE_BODY]")"); gh issue edit "$ISSUE_URL" --add-assignee "@me"; fi; echo "$ISSUE_URL"</command>
+      </execute_command>
+
+      <loopback_note>
+        If a change request is provided, collect the requested edits, update the draft (re-run discovery if new info affects context), then rerun this merged step.
+      </loopback_note>
+
+      <expected_output>https://github.com/OWNER/REPO/issues/123</expected_output>
+    </review_and_submit>
+  </example>
+
+  <policies>
+    <policy>Issues are template-free (Title + Body only).</policy>
+    <policy>Repository detection (git + origin → OWNER/REPO) occurs before submission and is passed explicitly via --repo [OWNER_REPO].</policy>
+    <policy>Never use --body-file or temporary files; submit with inline --body only (no file paths).</policy>
+    <policy>Review and submission happen in one merged step offering "Submit now" or "Submit now and assign to me"; any other response is treated as a change request.</policy>
+    <policy>All discovery is internal; keep final output plain-language.</policy>
+  </policies>
+</issue_examples>

.roo/rules-issue-writer/5_github_cli_usage.xml

@@ -1,342 +0,0 @@
-<github_cli_usage>
-  <overview>
-    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: This mode prioritizes using repository-specific issue templates over
-    hardcoded ones. Templates are detected and used dynamically from the repository.
-  </overview>
-
-  <pre_creation_commands>
-    <command name="gh issue list">
-      <when_to_use>
-        ALWAYS use this FIRST before creating any issue to check for duplicates.
-        Search for keywords from the user's problem description.
-      </when_to_use>
-      <example>
-        <execute_command>
-        <command>gh issue list --repo $REPO_FULL_NAME --search "dark theme button visibility" --state all --limit 20</command>
-        </execute_command>
-      </example>
-      <options>
-        --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
-      </options>
-    </command>
-
-    <command name="gh search issues">
-      <when_to_use>
-        Use for more advanced searches across issues and pull requests.
-        Supports GitHub's advanced search syntax.
-      </when_to_use>
-      <example>
-        <execute_command>
-        <command>gh search issues --repo $REPO_FULL_NAME "dark theme button" --limit 10</command>
-        </execute_command>
-      </example>
-    </command>
-
-    <command name="gh issue view">
-      <when_to_use>
-        Use when you find a potentially related issue and need full details.
-        Check if the user's issue is already reported or related.
-      </when_to_use>
-      <example>
-        <execute_command>
-        <command>gh issue view 123 --repo $REPO_FULL_NAME --comments</command>
-        </execute_command>
-      </example>
-      <options>
-        --comments: Include issue comments
-        --json: Get structured data
-        --web: Open in browser
-      </options>
-    </command>
-  </pre_creation_commands>
-
-  <template_detection_commands>
-    <command name="list_files">
-      <when_to_use>
-        Use to check for issue templates in the repository before creating issues.
-        This is not a gh command but necessary for template detection.
-      </when_to_use>
-      <examples>
-        Check for templates in standard location:
-        <list_files>
-        <path>.github/ISSUE_TEMPLATE</path>
-        <recursive>true</recursive>
-        </list_files>
-        
-        Check for single template file:
-        <list_files>
-        <path>.github</path>
-        <recursive>false</recursive>
-        </list_files>
-      </examples>
-    </command>
-
-    <command name="read_file">
-      <when_to_use>
-        Read template files to parse their structure and content.
-        Used after detecting template files.
-      </when_to_use>
-      <examples>
-        Read YAML template:
-        <read_file>
-        <path>.github/ISSUE_TEMPLATE/bug_report.yml</path>
-        </read_file>
-        
-        Read Markdown template:
-        <read_file>
-        <path>.github/ISSUE_TEMPLATE/feature_request.md</path>
-        </read_file>
-      </examples>
-    </command>
-  </template_detection_commands>
-
-  <contributor_only_commands>
-    <note>
-      These commands should ONLY be used if the user has indicated they want to
-      contribute the implementation. Skip these for problem reporters.
-    </note>
-    
-    <command name="gh repo view">
-      <when_to_use>
-        Get repository information and recent activity.
-      </when_to_use>
-      <example>
-        <execute_command>
-        <command>gh repo view $REPO_FULL_NAME --json defaultBranchRef,description,updatedAt</command>
-        </execute_command>
-      </example>
-    </command>
-
-    <command name="gh search prs">
-      <when_to_use>
-        Check recent PRs that might be related to the issue.
-        Look for PRs that modified relevant code.
-      </when_to_use>
-      <example>
-        <execute_command>
-        <command>gh search prs --repo $REPO_FULL_NAME "dark theme" --limit 10 --state all</command>
-        </execute_command>
-      </example>
-    </command>
-
-    <command name="git log">
-      <when_to_use>
-        For bug reports from contributors, check recent commits that might have introduced the issue.
-        Use after cloning the repository locally.
-      </when_to_use>
-      <example>
-        <execute_command>
-        <command>git log --oneline --grep="theme" -n 20</command>
-        </execute_command>
-      </example>
-    </command>
-  </contributor_only_commands>
-
-  <issue_creation_command>
-    <command name="gh issue create">
-      <when_to_use>
-        Only use after:
-        1. Confirming no duplicates exist
-        2. Checking for and using repository templates
-        3. Gathering all required information
-        4. Determining if user is contributing or just reporting
-        5. Getting user confirmation
-      </when_to_use>
-      <bug_report_example>
-        <execute_command>
-        <command>gh issue create --repo $REPO_FULL_NAME --title "[Descriptive title of the bug]" --body-file /tmp/issue_body.md --label "bug"</command>
-        </execute_command>
-      </bug_report_example>
-      <feature_request_example>
-        <execute_command>
-        <command>gh issue create --repo $REPO_FULL_NAME --title "[Problem-focused title]" --body-file /tmp/issue_body.md --label "proposal" --label "enhancement"</command>
-        </execute_command>
-      </feature_request_example>
-      <options>
-        --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
-      </options>
-    </command>
-  </issue_creation_command>
-
-  <post_creation_commands>
-    <command name="gh issue comment">
-      <when_to_use>
-        ONLY use if user wants to add additional information after creation.
-      </when_to_use>
-      <example>
-        <execute_command>
-        <command>gh issue comment 456 --repo $REPO_FULL_NAME --body "Additional context or comments."</command>
-        </execute_command>
-      </example>
-    </command>
-
-    <command name="gh issue edit">
-      <when_to_use>
-        Use if user realizes they need to update the issue after creation.
-        Can update title, body, or labels.
-      </when_to_use>
-      <example>
-        <execute_command>
-        <command>gh issue edit 456 --repo $REPO_FULL_NAME --title "[Updated title]" --body "[Updated body]"</command>
-        </execute_command>
-      </example>
-    </command>
-  </post_creation_commands>
-
-  <workflow_integration>
-    <step_1_integration>
-      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
-    </step_1_integration>
-
-    <step_2_integration>
-      Template detection (NEW):
-      1. Use list_files to check .github/ISSUE_TEMPLATE/ directory
-      2. Read any template files found (YAML or Markdown)
-      3. Parse template structure and metadata
-      4. If multiple templates, let user choose
-      5. If no templates, prepare to create generic one
-    </step_2_integration>
-
-    <step_3_integration>
-      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
-    </step_3_integration>
-
-    <step_4_integration>
-      During codebase exploration (CONTRIBUTORS ONLY):
-      1. Clone repo locally if needed: `gh repo clone $REPO_FULL_NAME`
-      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
-    </step_4_integration>
-
-    <step_5_integration>
-      When creating the issue:
-      1. Use repository template if found, or generic template if not
-      2. Fill template with gathered information
-      3. Format differently based on contributor vs problem reporter
-      4. Save formatted body to temporary file
-      5. Use `gh issue create` with appropriate labels from template
-      6. Capture the returned issue URL
-      7. Show user the created issue URL
-    </step_5_integration>
-  </workflow_integration>
-
-  <best_practices>
-    <practice name="file_handling">
-      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`
-    </practice>
-
-    <practice name="search_efficiency">
-      Use specific search terms:
-      - Include error messages in quotes
-      - Use label filters when appropriate
-      - Limit results to avoid overwhelming output
-    </practice>
-
-    <practice name="json_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`
-    </practice>
-  </best_practices>
-
-  <error_handling>
-    <duplicate_found>
-      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
-    </duplicate_found>
-
-    <creation_failed>
-      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
-    </creation_failed>
-
-    <authentication>
-      Ensure GitHub CLI is authenticated:
-      - Check status: `gh auth status`
-      - Login if needed: `gh auth login`
-      - Select appropriate scopes for issue creation
-    </authentication>
-  </error_handling>
-
-  <command_reference>
-    <issues>
-      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
-    </issues>
-
-    <search>
-      gh search issues   - Search issues and PRs
-      gh search prs      - Search pull requests
-      gh search repos    - Search repositories
-    </search>
-
-    <repository>
-      gh repo view       - View repository info
-      gh repo clone      - Clone repository
-    </repository>
-  </command_reference>
-
-  <template_handling_reference>
-    <yaml_template_parsing>
-      When parsing YAML templates:
-      - Extract 'name' for template identification
-      - Get 'labels' array for automatic labeling
-      - Parse 'body' array for form elements
-      - Convert form elements to markdown sections
-      - Preserve 'required' field indicators
-    </yaml_template_parsing>
-    
-    <markdown_template_parsing>
-      When parsing Markdown templates:
-      - Check for YAML front matter
-      - Extract metadata (labels, assignees)
-      - Identify section headers
-      - Replace placeholder text
-      - Maintain formatting structure
-    </markdown_template_parsing>
-    
-    <template_usage_flow>
-      1. Detect templates with list_files
-      2. Read templates with read_file
-      3. Parse structure and metadata
-      4. Let user choose if multiple exist
-      5. Fill template with information
-      6. Create issue with template content
-    </template_usage_flow>
-  </template_handling_reference>
-</github_cli_usage>

.roo/rules-mode-writer/1_mode_creation_workflow.xml

@@ -1,301 +0,0 @@
-<mode_management_workflow>
-  <overview>
-    This workflow guides you through creating new custom modes or editing existing modes
-    for the Roo Code Software, ensuring comprehensive understanding and cohesive implementation.
-  </overview>
-
-  <initial_determination>
-    <step number="1">
-      <title>Determine User Intent</title>
-      <description>
-        Identify whether the user wants to create a new mode or edit an existing one
-      </description>
-      <detection_patterns>
-        <pattern type="edit_existing">
-          <indicators>
-            <indicator>User mentions a specific mode by name or slug</indicator>
-            <indicator>User references a mode directory path (e.g., .roo/rules-[mode-slug])</indicator>
-            <indicator>User asks to modify, update, enhance, or fix an existing mode</indicator>
-            <indicator>User says "edit this mode" or "change this mode"</indicator>
-          </indicators>
-        </pattern>
-        <pattern type="create_new">
-          <indicators>
-            <indicator>User asks to create a new mode</indicator>
-            <indicator>User describes a new capability not covered by existing modes</indicator>
-            <indicator>User says "make a mode for" or "create a mode that"</indicator>
-          </indicators>
-        </pattern>
-      </detection_patterns>
-      <clarification_question>
-        <ask_followup_question>
-          <question>I want to make sure I understand correctly. Are you looking to create a brand new mode or modify an existing one?</question>
-          <follow_up>
-            <suggest>Create a new mode for a specific purpose</suggest>
-            <suggest>Edit an existing mode to add new capabilities</suggest>
-            <suggest>Fix issues in an existing mode</suggest>
-            <suggest>Enhance an existing mode with better workflows</suggest>
-          </follow_up>
-        </ask_followup_question>
-      </clarification_question>
-    </step>
-  </initial_determination>
-
-  <workflow_branches>
-    <branch name="create_new_mode">
-      <step number="2a">
-        <title>Gather Requirements for New Mode</title>
-        <description>
-          Understand what the user wants the new mode to accomplish
-        </description>
-        <actions>
-          <action>Ask about the mode's primary purpose and use cases</action>
-          <action>Identify what types of tasks the mode should handle</action>
-          <action>Determine what tools and file access the mode needs</action>
-          <action>Clarify any special behaviors or restrictions</action>
-        </actions>
-        <example>
-          <ask_followup_question>
-            <question>What is the primary purpose of this new mode? What types of tasks should it handle?</question>
-            <follow_up>
-              <suggest>A mode for writing and maintaining documentation</suggest>
-              <suggest>A mode for database schema design and migrations</suggest>
-              <suggest>A mode for API endpoint development and testing</suggest>
-              <suggest>A mode for performance optimization and profiling</suggest>
-            </follow_up>
-          </ask_followup_question>
-        </example>
-      </step>
-
-      <step number="3a">
-        <title>Design Mode Configuration</title>
-        <description>
-          Create the mode definition with all required fields
-        </description>
-        <required_fields>
-          <field name="slug">
-            <description>Unique identifier (lowercase, hyphens allowed)</description>
-            <best_practice>Keep it short and descriptive (e.g., "api-dev", "docs-writer")</best_practice>
-          </field>
-          <field name="name">
-            <description>Display name with optional emoji</description>
-            <best_practice>Use an emoji that represents the mode's purpose</best_practice>
-          </field>
-          <field name="roleDefinition">
-            <description>Detailed description of the mode's role and expertise</description>
-            <best_practice>
-              Start with "You are Roo Code, a [specialist type]..."
-              List specific areas of expertise
-              Mention key technologies or methodologies
-            </best_practice>
-          </field>
-          <field name="groups">
-            <description>Tool groups the mode can access</description>
-            <options>
-              <option name="read">File reading and searching tools</option>
-              <option name="edit">File editing tools (can be restricted by regex)</option>
-              <option name="command">Command execution tools</option>
-              <option name="browser">Browser interaction tools</option>
-              <option name="mcp">MCP server tools</option>
-            </options>
-          </field>
-        </required_fields>
-        <recommended_fields>
-          <field name="whenToUse">
-            <description>Clear description for the Orchestrator</description>
-            <best_practice>Explain specific scenarios and task types</best_practice>
-          </field>
-        </recommended_fields>
-        <important_note>
-          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.
-        </important_note>
-      </step>
-
-      <step number="4a">
-        <title>Implement File Restrictions</title>
-        <description>
-          Configure appropriate file access permissions
-        </description>
-        <example>
-          <comment>Restrict edit access to specific file types</comment>
-          <code>
-groups:
-  - read
-  - - edit
-    - fileRegex: \.(md|txt|rst)$
-      description: Documentation files only
-  - command
-          </code>
-        </example>
-        <guidelines>
-          <guideline>Use regex patterns to limit file editing scope</guideline>
-          <guideline>Provide clear descriptions for restrictions</guideline>
-          <guideline>Consider the principle of least privilege</guideline>
-        </guidelines>
-      </step>
-
-      <step number="5a">
-        <title>Create XML Instruction Files</title>
-        <description>
-          Design structured instruction files in .roo/rules-[mode-slug]/
-        </description>
-        <file_structure>
-          <file name="1_workflow.xml">Main workflow and step-by-step processes</file>
-          <file name="2_best_practices.xml">Guidelines and conventions</file>
-          <file name="3_common_patterns.xml">Reusable code patterns and examples</file>
-          <file name="4_tool_usage.xml">Specific tool usage instructions</file>
-          <file name="5_examples.xml">Complete workflow examples</file>
-        </file_structure>
-        <xml_best_practices>
-          <practice>Use semantic tag names that describe content</practice>
-          <practice>Nest tags hierarchically for better organization</practice>
-          <practice>Include code examples in CDATA sections when needed</practice>
-          <practice>Add comments to explain complex sections</practice>
-        </xml_best_practices>
-      </step>
-    </branch>
-
-    <branch name="edit_existing_mode">
-      <step number="2b">
-        <title>Immerse in Existing Mode</title>
-        <description>
-          Fully understand the existing mode before making any changes
-        </description>
-        <actions>
-          <action>Locate and read the mode configuration in .roomodes</action>
-          <action>Read all XML instruction files in .roo/rules-[mode-slug]/</action>
-          <action>Analyze the mode's current capabilities and limitations</action>
-          <action>Understand the mode's role in the broader ecosystem</action>
-        </actions>
-        <questions_to_ask>
-          <ask_followup_question>
-            <question>What specific aspects of the mode would you like to change or enhance?</question>
-            <follow_up>
-              <suggest>Add new capabilities or tool permissions</suggest>
-              <suggest>Fix issues with current workflows or instructions</suggest>
-              <suggest>Improve the mode's roleDefinition or whenToUse description</suggest>
-              <suggest>Enhance XML instructions for better clarity</suggest>
-            </follow_up>
-          </ask_followup_question>
-        </questions_to_ask>
-      </step>
-
-      <step number="3b">
-        <title>Analyze Change Impact</title>
-        <description>
-          Understand how proposed changes will affect the mode
-        </description>
-        <analysis_areas>
-          <area>Compatibility with existing workflows</area>
-          <area>Impact on file permissions and tool access</area>
-          <area>Consistency with mode's core purpose</area>
-          <area>Integration with other modes</area>
-        </analysis_areas>
-        <validation_questions>
-          <ask_followup_question>
-            <question>I've analyzed the existing mode. Here's what I understand about your requested changes. Is this correct?</question>
-            <follow_up>
-              <suggest>Yes, that's exactly what I want to change</suggest>
-              <suggest>Mostly correct, but let me clarify some details</suggest>
-              <suggest>No, I meant something different</suggest>
-              <suggest>I'd like to add additional changes</suggest>
-            </follow_up>
-          </ask_followup_question>
-        </validation_questions>
-      </step>
-
-      <step number="4b">
-        <title>Plan Modifications</title>
-        <description>
-          Create a detailed plan for modifying the mode
-        </description>
-        <planning_steps>
-          <step>Identify which files need to be modified</step>
-          <step>Determine if new XML instruction files are needed</step>
-          <step>Check for potential conflicts or contradictions</step>
-          <step>Plan the order of changes for minimal disruption</step>
-        </planning_steps>
-      </step>
-
-      <step number="5b">
-        <title>Implement Changes</title>
-        <description>
-          Apply the planned modifications to the mode
-        </description>
-        <implementation_order>
-          <change>Update .roomodes configuration if needed</change>
-          <change>Modify existing XML instruction files</change>
-          <change>Create new XML instruction files if required</change>
-          <change>Update examples and documentation</change>
-        </implementation_order>
-      </step>
-    </branch>
-  </workflow_branches>
-
-  <validation_and_cohesion>
-    <step number="6">
-      <title>Validate Cohesion and Consistency</title>
-      <description>
-        Ensure all changes are cohesive and don't contradict each other
-      </description>
-      <validation_checks>
-        <check type="configuration">
-          <item>Mode slug follows naming conventions</item>
-          <item>File restrictions align with mode purpose</item>
-          <item>Tool permissions are appropriate</item>
-          <item>whenToUse clearly differentiates from other modes</item>
-        </check>
-        <check type="instructions">
-          <item>All XML files follow consistent structure</item>
-          <item>No contradicting instructions between files</item>
-          <item>Examples align with stated workflows</item>
-          <item>Tool usage matches granted permissions</item>
-        </check>
-        <check type="integration">
-          <item>Mode integrates well with Orchestrator</item>
-          <item>Clear boundaries with other modes</item>
-          <item>Handoff points are well-defined</item>
-        </check>
-      </validation_checks>
-      <cohesion_questions>
-        <ask_followup_question>
-          <question>I've completed the validation checks. Would you like me to review any specific aspect in more detail?</question>
-          <follow_up>
-            <suggest>Review the file permission patterns</suggest>
-            <suggest>Check for workflow contradictions</suggest>
-            <suggest>Verify integration with other modes</suggest>
-            <suggest>Everything looks good, proceed to testing</suggest>
-          </follow_up>
-        </ask_followup_question>
-      </cohesion_questions>
-    </step>
-
-    <step number="7">
-      <title>Test and Refine</title>
-      <description>
-        Verify the mode works as intended
-      </description>
-      <checklist>
-        <item>Mode appears in the mode list</item>
-        <item>File restrictions work correctly</item>
-        <item>Instructions are clear and actionable</item>
-        <item>Mode integrates well with Orchestrator</item>
-        <item>All examples are accurate and helpful</item>
-        <item>Changes don't break existing functionality (for edits)</item>
-        <item>New capabilities work as expected</item>
-      </checklist>
-    </step>
-  </validation_and_cohesion>
-
-  <quick_reference>
-    <command>Create mode in .roomodes for project-specific modes</command>
-    <command>Create mode in global custom_modes.yaml for system-wide modes</command>
-    <command>Use list_files to verify .roo folder structure</command>
-    <command>Test file regex patterns with search_files</command>
-    <command>Use codebase_search to find existing mode implementations</command>
-    <command>Read all XML files in a mode directory to understand its structure</command>
-    <command>Always validate changes for cohesion and consistency</command>
-  </quick_reference>
-</mode_management_workflow>

.roo/rules-mode-writer/2_xml_structuring_best_practices.xml

@@ -1,220 +0,0 @@
-<xml_structuring_best_practices>
-  <overview>
-    XML tags help Claude parse prompts more accurately, leading to higher-quality outputs.
-    This guide covers best practices for structuring mode instructions using XML.
-  </overview>
-
-  <why_use_xml_tags>
-    <benefit type="clarity">
-      Clearly separate different parts of your instructions and ensure well-structured content
-    </benefit>
-    <benefit type="accuracy">
-      Reduce errors caused by Claude misinterpreting parts of your instructions
-    </benefit>
-    <benefit type="flexibility">
-      Easily find, add, remove, or modify parts of instructions without rewriting everything
-    </benefit>
-    <benefit type="parseability">
-      Having Claude use XML tags in its output makes it easier to extract specific parts of responses
-    </benefit>
-  </why_use_xml_tags>
-
-  <core_principles>
-    <principle name="consistency">
-      <description>Use the same tag names throughout your instructions</description>
-      <example>
-        Always use <step> for workflow steps, not sometimes <action> or <task>
-      </example>
-    </principle>
-    
-    <principle name="semantic_naming">
-      <description>Tag names should clearly describe their content</description>
-      <good_examples>
-        <tag>detailed_steps</tag>
-        <tag>error_handling</tag>
-        <tag>validation_rules</tag>
-      </good_examples>
-      <bad_examples>
-        <tag>stuff</tag>
-        <tag>misc</tag>
-        <tag>data1</tag>
-      </bad_examples>
-    </principle>
-
-    <principle name="hierarchical_nesting">
-      <description>Nest tags to show relationships and structure</description>
-      <example>
-        <workflow>
-          <phase name="preparation">
-            <step>Gather requirements</step>
-            <step>Validate inputs</step>
-          </phase>
-          <phase name="execution">
-            <step>Process data</step>
-            <step>Generate output</step>
-          </phase>
-        </workflow>
-      </example>
-    </principle>
-  </core_principles>
-
-  <common_tag_patterns>
-    <pattern name="workflow_structure">
-      <usage>For step-by-step processes</usage>
-      <template><![CDATA[
-<workflow>
-  <overview>High-level description</overview>
-  <prerequisites>
-    <prerequisite>Required condition 1</prerequisite>
-    <prerequisite>Required condition 2</prerequisite>
-  </prerequisites>
-  <steps>
-    <step number="1">
-      <title>Step Title</title>
-      <description>What this step accomplishes</description>
-      <actions>
-        <action>Specific action to take</action>
-      </actions>
-      <validation>How to verify success</validation>
-    </step>
-  </steps>
-</workflow>
-      ]]></template>
-    </pattern>
-
-    <pattern name="examples_structure">
-      <usage>For providing code examples and demonstrations</usage>
-      <template><![CDATA[
-<examples>
-  <example name="descriptive_name">
-    <description>What this example demonstrates</description>
-    <context>When to use this approach</context>
-    <code language="typescript">
-      // Your code example here
-    </code>
-    <explanation>
-      Key points about the implementation
-    </explanation>
-  </example>
-</examples>
-      ]]></template>
-    </pattern>
-
-    <pattern name="guidelines_structure">
-      <usage>For rules and best practices</usage>
-      <template><![CDATA[
-<guidelines category="category_name">
-  <guideline priority="high">
-    <rule>The specific rule or guideline</rule>
-    <rationale>Why this is important</rationale>
-    <exceptions>When this doesn't apply</exceptions>
-  </guideline>
-</guidelines>
-      ]]></template>
-    </pattern>
-
-    <pattern name="tool_usage_structure">
-      <usage>For documenting how to use specific tools</usage>
-      <template><![CDATA[
-<tool_usage tool="tool_name">
-  <purpose>What this tool accomplishes</purpose>
-  <when_to_use>Specific scenarios for this tool</when_to_use>
-  <syntax>
-    <command>The exact command format</command>
-    <parameters>
-      <parameter name="param1" required="true">
-        <description>What this parameter does</description>
-        <type>string|number|boolean</type>
-        <example>example_value</example>
-      </parameter>
-    </parameters>
-  </syntax>
-  <examples>
-    <example scenario="common_use_case">
-      <code>Actual usage example</code>
-      <output>Expected output</output>
-    </example>
-  </examples>
-</tool_usage>
-      ]]></template>
-    </pattern>
-  </common_tag_patterns>
-
-  <formatting_guidelines>
-    <guideline name="indentation">
-      Use consistent indentation (2 or 4 spaces) for nested elements
-    </guideline>
-    <guideline name="line_breaks">
-      Add line breaks between major sections for readability
-    </guideline>
-    <guideline name="comments">
-      Use XML comments <!-- like this --> to explain complex sections
-    </guideline>
-    <guideline name="cdata_sections">
-      Use CDATA for code blocks or content with special characters:
-      <![CDATA[<code><![CDATA[your code here]]></code>]]>
-    </guideline>
-    <guideline name="attributes_vs_elements">
-      Use attributes for metadata, elements for content:
-      <example type="good">
-        <step number="1" priority="high">
-          <description>The actual step content</description>
-        </step>
-      </example>
-    </guideline>
-  </formatting_guidelines>
-
-  <anti_patterns>
-    <anti_pattern name="flat_structure">
-      <description>Avoid completely flat structures without hierarchy</description>
-      <bad><![CDATA[
-<instructions>
-<item1>Do this</item1>
-<item2>Then this</item2>
-<item3>Finally this</item3>
-</instructions>
-      ]]></bad>
-      <good><![CDATA[
-<instructions>
-  <steps>
-    <step order="1">Do this</step>
-    <step order="2">Then this</step>
-    <step order="3">Finally this</step>
-  </steps>
-</instructions>
-      ]]></good>
-    </anti_pattern>
-
-    <anti_pattern name="inconsistent_naming">
-      <description>Don't mix naming conventions</description>
-      <bad>
-        Mixing camelCase, snake_case, and kebab-case in tag names
-      </bad>
-      <good>
-        Pick one convention (preferably snake_case for XML) and stick to it
-      </good>
-    </anti_pattern>
-
-    <anti_pattern name="overly_generic_tags">
-      <description>Avoid tags that don't convey meaning</description>
-      <bad>data, info, stuff, thing, item</bad>
-      <good>user_input, validation_result, error_message, configuration</good>
-    </anti_pattern>
-  </anti_patterns>
-
-  <integration_tips>
-    <tip>
-      Reference XML content in instructions:
-      "Using the workflow defined in &lt;workflow&gt; tags..."
-    </tip>
-    <tip>
-      Combine XML structure with other techniques like multishot prompting
-    </tip>
-    <tip>
-      Use XML tags in expected outputs to make parsing easier
-    </tip>
-    <tip>
-      Create reusable XML templates for common patterns
-    </tip>
-  </integration_tips>
-</xml_structuring_best_practices>

.roo/rules-mode-writer/3_mode_configuration_patterns.xml

@@ -1,261 +0,0 @@
-<mode_configuration_patterns>
-  <overview>
-    Common patterns and templates for creating different types of modes, with examples from existing modes in the Roo-Code software.
-  </overview>
-
-  <mode_types>
-    <type name="specialist_mode">
-      <description>
-        Modes focused on specific technical domains or tasks
-      </description>
-      <characteristics>
-        <characteristic>Deep expertise in a particular area</characteristic>
-        <characteristic>Restricted file access based on domain</characteristic>
-        <characteristic>Specialized tool usage patterns</characteristic>
-      </characteristics>
-      <example_template><![CDATA[
-- slug: api-specialist
-  name: 🔌 API Specialist
-  roleDefinition: >-
-    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
-      ]]></example_template>
-    </type>
-
-    <type name="workflow_mode">
-      <description>
-        Modes that guide users through multi-step processes
-      </description>
-      <characteristics>
-        <characteristic>Step-by-step workflow guidance</characteristic>
-        <characteristic>Heavy use of ask_followup_question</characteristic>
-        <characteristic>Process validation at each step</characteristic>
-      </characteristics>
-      <example_template><![CDATA[
-- slug: migration-guide
-  name: 🔄 Migration Guide
-  roleDefinition: >-
-    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
-      ]]></example_template>
-    </type>
-
-    <type name="analysis_mode">
-      <description>
-        Modes focused on code analysis and reporting
-      </description>
-      <characteristics>
-        <characteristic>Read-heavy operations</characteristic>
-        <characteristic>Limited or no edit permissions</characteristic>
-        <characteristic>Comprehensive reporting outputs</characteristic>
-      </characteristics>
-      <example_template><![CDATA[
-- slug: security-auditor
-  name: 🔒 Security Auditor
-  roleDefinition: >-
-    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
-      ]]></example_template>
-    </type>
-
-    <type name="creative_mode">
-      <description>
-        Modes for generating new content or features
-      </description>
-      <characteristics>
-        <characteristic>Broad file creation permissions</characteristic>
-        <characteristic>Template and boilerplate generation</characteristic>
-        <characteristic>Interactive design process</characteristic>
-      </characteristics>
-      <example_template><![CDATA[
-- slug: component-designer
-  name: 🎨 Component Designer
-  roleDefinition: >-
-    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
-      ]]></example_template>
-    </type>
-  </mode_types>
-
-  <permission_patterns>
-    <pattern name="documentation_only">
-      <description>For modes that only work with documentation</description>
-      <configuration><![CDATA[
-groups:
-  - read
-  - - edit
-    - fileRegex: \.(md|mdx|rst|txt)$
-      description: Documentation files only
-      ]]></configuration>
-    </pattern>
-
-    <pattern name="test_focused">
-      <description>For modes that work with test files</description>
-      <configuration><![CDATA[
-groups:
-  - read
-  - command
-  - - edit
-    - fileRegex: (__tests__/.*|__mocks__/.*|.*\.test\.(ts|tsx|js|jsx)$|.*\.spec\.(ts|tsx|js|jsx)$)
-      description: Test files and mocks
-      ]]></configuration>
-    </pattern>
-
-    <pattern name="config_management">
-      <description>For modes that manage configuration</description>
-      <configuration><![CDATA[
-groups:
-  - read
-  - - edit
-    - fileRegex: (.*\.config\.(js|ts|json)|.*rc\.json|.*\.yaml|.*\.yml|\.env\.example)$
-      description: Configuration files (not .env)
-      ]]></configuration>
-    </pattern>
-
-    <pattern name="full_stack">
-      <description>For modes that need broad access</description>
-      <configuration><![CDATA[
-groups:
-  - read
-  - edit  # No restrictions
-  - command
-  - browser
-  - mcp
-      ]]></configuration>
-    </pattern>
-  </permission_patterns>
-
-  <naming_conventions>
-    <convention category="slug">
-      <rule>Use lowercase with hyphens</rule>
-      <good>api-dev, test-writer, docs-manager</good>
-      <bad>apiDev, test_writer, DocsManager</bad>
-    </convention>
-    
-    <convention category="name">
-      <rule>Use title case with descriptive emoji</rule>
-      <good>🔧 API Developer, 📝 Documentation Writer</good>
-      <bad>api developer, DOCUMENTATION WRITER</bad>
-    </convention>
-
-    <convention category="emoji_selection">
-      <common_emojis>
-        <emoji meaning="testing">🧪</emoji>
-        <emoji meaning="documentation">📝</emoji>
-        <emoji meaning="design">🎨</emoji>
-        <emoji meaning="debugging">🪲</emoji>
-        <emoji meaning="building">🏗️</emoji>
-        <emoji meaning="security">🔒</emoji>
-        <emoji meaning="api">🔌</emoji>
-        <emoji meaning="database">🗄️</emoji>
-        <emoji meaning="performance">⚡</emoji>
-        <emoji meaning="configuration">⚙️</emoji>
-      </common_emojis>
-    </convention>
-  </naming_conventions>
-
-  <integration_guidelines>
-    <guideline name="orchestrator_compatibility">
-      <description>Ensure whenToUse is clear for Orchestrator mode</description>
-      <checklist>
-        <item>Specify concrete task types the mode handles</item>
-        <item>Include trigger keywords or phrases</item>
-        <item>Differentiate from similar modes</item>
-        <item>Mention specific file types or areas</item>
-      </checklist>
-    </guideline>
-
-    <guideline name="mode_boundaries">
-      <description>Define clear boundaries between modes</description>
-      <checklist>
-        <item>Avoid overlapping responsibilities</item>
-        <item>Make handoff points explicit</item>
-        <item>Use switch_mode when appropriate</item>
-        <item>Document mode interactions</item>
-      </checklist>
-    </guideline>
-  </integration_guidelines>
-</mode_configuration_patterns>

.roo/rules-mode-writer/4_instruction_file_templates.xml

@@ -1,367 +0,0 @@
-<instruction_file_templates>
-  <overview>
-    Templates and examples for creating XML instruction files that provide
-    detailed guidance for each mode's behavior and workflows.
-  </overview>
-
-  <file_organization>
-    <principle>Number files to indicate execution order</principle>
-    <principle>Use descriptive names that indicate content</principle>
-    <principle>Keep related instructions together</principle>
-    <standard_structure>
-      <file>1_workflow.xml - Main workflow and processes</file>
-      <file>2_best_practices.xml - Guidelines and conventions</file>
-      <file>3_common_patterns.xml - Reusable code patterns</file>
-      <file>4_tool_usage.xml - Specific tool instructions</file>
-      <file>5_examples.xml - Complete workflow examples</file>
-      <file>6_error_handling.xml - Error scenarios and recovery</file>
-      <file>7_communication.xml - User interaction guidelines</file>
-    </standard_structure>
-  </file_organization>
-
-  <workflow_file_template>
-    <description>Template for main workflow files (1_workflow.xml)</description>
-    <template><![CDATA[
-<workflow_instructions>
-  <mode_overview>
-    Brief description of what this mode does and its primary purpose
-  </mode_overview>
-
-  <initialization_steps>
-    <step number="1">
-      <action>Understand the user's request</action>
-      <details>
-        Parse the user's input to identify:
-        - Primary objective
-        - Specific requirements
-        - Constraints or limitations
-      </details>
-    </step>
-    
-    <step number="2">
-      <action>Gather necessary context</action>
-      <tools>
-        <tool>codebase_search - Find relevant existing code</tool>
-        <tool>list_files - Understand project structure</tool>
-        <tool>read_file - Examine specific implementations</tool>
-      </tools>
-    </step>
-  </initialization_steps>
-
-  <main_workflow>
-    <phase name="analysis">
-      <description>Analyze the current state and requirements</description>
-      <steps>
-        <step>Identify affected components</step>
-        <step>Assess impact of changes</step>
-        <step>Plan implementation approach</step>
-      </steps>
-    </phase>
-
-    <phase name="implementation">
-      <description>Execute the planned changes</description>
-      <steps>
-        <step>Create/modify necessary files</step>
-        <step>Ensure consistency across codebase</step>
-        <step>Add appropriate documentation</step>
-      </steps>
-    </phase>
-
-    <phase name="validation">
-      <description>Verify the implementation</description>
-      <steps>
-        <step>Check for errors or inconsistencies</step>
-        <step>Validate against requirements</step>
-        <step>Ensure no regressions</step>
-      </steps>
-    </phase>
-  </main_workflow>
-
-  <completion_criteria>
-    <criterion>All requirements have been addressed</criterion>
-    <criterion>Code follows project conventions</criterion>
-    <criterion>Changes are properly documented</criterion>
-    <criterion>No breaking changes introduced</criterion>
-  </completion_criteria>
-</workflow_instructions>
-    ]]></template>
-  </workflow_file_template>
-
-  <best_practices_template>
-    <description>Template for best practices files (2_best_practices.xml)</description>
-    <template><![CDATA[
-<best_practices>
-  <general_principles>
-    <principle priority="high">
-      <name>Principle Name</name>
-      <description>Detailed explanation of the principle</description>
-      <rationale>Why this principle is important</rationale>
-      <example>
-        <scenario>When this applies</scenario>
-        <good>Correct approach</good>
-        <bad>What to avoid</bad>
-      </example>
-    </principle>
-  </general_principles>
-
-  <code_conventions>
-    <convention category="naming">
-      <rule>Specific naming convention</rule>
-      <examples>
-        <good>goodExampleName</good>
-        <bad>bad_example-name</bad>
-      </examples>
-    </convention>
-    
-    <convention category="structure">
-      <rule>How to structure code/files</rule>
-      <template>
-        // Example structure
-      </template>
-    </convention>
-  </code_conventions>
-
-  <common_pitfalls>
-    <pitfall>
-      <description>Common mistake to avoid</description>
-      <why_problematic>Explanation of issues it causes</why_problematic>
-      <correct_approach>How to do it properly</correct_approach>
-    </pitfall>
-  </common_pitfalls>
-
-  <quality_checklist>
-    <category name="before_starting">
-      <item>Understand requirements fully</item>
-      <item>Check existing implementations</item>
-    </category>
-    <category name="during_implementation">
-      <item>Follow established patterns</item>
-      <item>Write clear documentation</item>
-    </category>
-    <category name="before_completion">
-      <item>Review all changes</item>
-      <item>Verify requirements met</item>
-    </category>
-  </quality_checklist>
-</best_practices>
-    ]]></template>
-  </best_practices_template>
-
-  <tool_usage_template>
-    <description>Template for tool usage files (4_tool_usage.xml)</description>
-    <template><![CDATA[
-<tool_usage_guide>
-  <tool_priorities>
-    <priority level="1">
-      <tool>codebase_search</tool>
-      <when>Always use first to find relevant code</when>
-      <why>Semantic search finds functionality better than keywords</why>
-    </priority>
-    <priority level="2">
-      <tool>read_file</tool>
-      <when>After identifying files with codebase_search</when>
-      <why>Get full context of implementations</why>
-    </priority>
-  </tool_priorities>
-
-  <tool_specific_guidance>
-    <tool name="apply_diff">
-      <best_practices>
-        <practice>Always read file first to ensure exact content match</practice>
-        <practice>Make multiple changes in one diff when possible</practice>
-        <practice>Include line numbers for accuracy</practice>
-      </best_practices>
-      <example><![CDATA[
-<apply_diff>
-<path>src/config.ts</path>
-<diff>
-<<<<<<< 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
-</diff>
-</apply_diff>
-      ]]></example>
-    </tool>
-
-    <tool name="ask_followup_question">
-      <best_practices>
-        <practice>Provide 2-4 specific, actionable suggestions</practice>
-        <practice>Order suggestions by likelihood or importance</practice>
-        <practice>Make suggestions complete (no placeholders)</practice>
-      </best_practices>
-      <example><![CDATA[
-<ask_followup_question>
-<question>Which database system should I configure for this project?</question>
-<follow_up>
-<suggest>PostgreSQL with the default configuration</suggest>
-<suggest>MySQL 8.0 with InnoDB storage engine</suggest>
-<suggest>SQLite for local development only</suggest>
-<suggest>MongoDB for document-based storage</suggest>
-</follow_up>
-</ask_followup_question>
-      ]]></example>
-    </tool>
-  </tool_specific_guidance>
-
-  <tool_combination_patterns>
-    <pattern name="explore_then_modify">
-      <sequence>
-        <step>codebase_search - Find relevant files</step>
-        <step>list_code_definition_names - Understand structure</step>
-        <step>read_file - Get full context</step>
-        <step>apply_diff or write_to_file - Make changes</step>
-      </sequence>
-    </pattern>
-    
-    <pattern name="verify_then_proceed">
-      <sequence>
-        <step>list_files - Check file exists</step>
-        <step>read_file - Verify current content</step>
-        <step>ask_followup_question - Confirm approach</step>
-        <step>apply_diff - Implement changes</step>
-      </sequence>
-    </pattern>
-  </tool_combination_patterns>
-</tool_usage_guide>
-    ]]></template>
-  </tool_usage_template>
-
-  <examples_file_template>
-    <description>Template for example files (5_examples.xml)</description>
-    <template><![CDATA[
-<complete_examples>
-  <example name="descriptive_example_name">
-    <scenario>
-      Detailed description of the use case this example covers
-    </scenario>
-    
-    <user_request>
-      The initial request from the user
-    </user_request>
-
-    <workflow>
-      <step number="1">
-        <description>First step description</description>
-        <tool_use><![CDATA[
-<codebase_search>
-<query>search query here</query>
-</codebase_search>
-        ]]></tool_use>
-        <expected_outcome>What we learn from this step</expected_outcome>
-      </step>
-
-      <step number="2">
-        <description>Second step description</description>
-        <tool_use><![CDATA[
-<read_file>
-<path>path/to/file.ts</path>
-</read_file>
-        ]]></tool_use>
-        <analysis>How we interpret the results</analysis>
-      </step>
-
-      <step number="3">
-        <description>Implementation step</description>
-        <tool_use><![CDATA[
-<apply_diff>
-<path>path/to/file.ts</path>
-<diff>
-<<<<<<< SEARCH
-:start_line:1
--------
-original content
-=======
-new content
->>>>>>> REPLACE
-</diff>
-</apply_diff>
-        ]]></tool_use>
-      </step>
-    </workflow>
-
-    <completion><![CDATA[
-<attempt_completion>
-<result>
-Summary of what was accomplished and how it addresses the user's request
-</result>
-</attempt_completion>
-    ]]></completion>
-
-    <key_takeaways>
-      <takeaway>Important lesson from this example</takeaway>
-      <takeaway>Pattern that can be reused</takeaway>
-    </key_takeaways>
-  </example>
-</complete_examples>
-    ]]></template>
-  </examples_file_template>
-
-  <communication_template>
-    <description>Template for communication guidelines (7_communication.xml)</description>
-    <template><![CDATA[
-<communication_guidelines>
-  <tone_and_style>
-    <principle>Be direct and technical, not conversational</principle>
-    <principle>Focus on actions taken and results achieved</principle>
-    <avoid>
-      <phrase>Great! I'll help you with that...</phrase>
-      <phrase>Certainly! Let me...</phrase>
-      <phrase>Sure thing!</phrase>
-    </avoid>
-    <prefer>
-      <phrase>I'll analyze the codebase to...</phrase>
-      <phrase>Implementing the requested changes...</phrase>
-      <phrase>The analysis shows...</phrase>
-    </prefer>
-  </tone_and_style>
-
-  <user_interaction>
-    <when_to_ask_questions>
-      <scenario>Missing critical information</scenario>
-      <scenario>Multiple valid approaches exist</scenario>
-      <scenario>Potential breaking changes</scenario>
-    </when_to_ask_questions>
-    
-    <question_format>
-      <guideline>Be specific about what you need</guideline>
-      <guideline>Provide actionable options</guideline>
-      <guideline>Explain implications of choices</guideline>
-    </question_format>
-  </user_interaction>
-
-  <progress_updates>
-    <when>During long-running operations</when>
-    <format>
-      <update>Analyzing [X] files for [purpose]...</update>
-      <update>Implementing [feature] in [location]...</update>
-      <update>Validating changes against [criteria]...</update>
-    </format>
-  </progress_updates>
-
-  <completion_messages>
-    <structure>
-      <element>What was accomplished</element>
-      <element>Key changes made</element>
-      <element>Any important notes or warnings</element>
-    </structure>
-    <avoid>
-      <element>Questions at the end</element>
-      <element>Offers for further assistance</element>
-      <element>Conversational closings</element>
-    </avoid>
-  </completion_messages>
-</communication_guidelines>
-    ]]></template>
-  </communication_template>
-</instruction_file_templates>

.roo/rules-mode-writer/5_complete_mode_examples.xml

@@ -1,214 +0,0 @@
-<complete_examples>
-  <example name="mode_editing_enhancement">
-    <scenario>
-      Edit the test mode to add support for performance testing and benchmarking
-    </scenario>
-    
-    <user_request>
-      I want to edit the test mode to add benchmark testing capabilities
-    </user_request>
-
-    <workflow>
-      <step number="1">
-        <description>Determine user intent and clarify scope</description>
-        <tool_use><![CDATA[
-<ask_followup_question>
-<question>I understand you want to edit the test mode to add performance testing capabilities. Before we proceed, let me confirm the scope of changes. What specific performance testing features do you need?</question>
-<follow_up>
-<suggest>Add benchmark testing with Vitest's bench API</suggest>
-<suggest>Include performance profiling and memory usage tracking</suggest>
-<suggest>Add load testing capabilities for API endpoints</suggest>
-<suggest>All of the above - comprehensive performance testing suite</suggest>
-</follow_up>
-</ask_followup_question>
-        ]]></tool_use>
-        <expected_outcome>User selected: Add benchmark testing with Vitest's bench API</expected_outcome>
-      </step>
-
-      <step number="2">
-        <description>Immerse in existing test mode configuration</description>
-        <tool_use><![CDATA[
-<read_file>
-<path>.roomodes</path>
-</read_file>
-        ]]></tool_use>
-        <analysis>Found test mode configuration with current roleDefinition and file restrictions</analysis>
-      </step>
-
-      <step number="3">
-        <description>Explore existing test mode instructions</description>
-        <tool_use><![CDATA[
-<list_files>
-<path>.roo/rules-test</path>
-<recursive>true</recursive>
-</list_files>
-        ]]></tool_use>
-        <tool_use><![CDATA[
-<read_file>
-<path>.roo/rules-test/1_workflow.xml</path>
-</read_file>
-        ]]></tool_use>
-        <analysis>Understood current test workflows and patterns</analysis>
-      </step>
-
-      <step number="4">
-        <description>Validate changes for cohesion</description>
-        <tool_use><![CDATA[
-<ask_followup_question>
-<question>I've analyzed the test mode. Adding benchmark testing would require:
-1. Updating the roleDefinition to include performance testing expertise
-2. Modifying file restrictions to include .bench.ts files
-3. Adding new workflow instructions for benchmark creation
-4. Including Vitest bench API examples
-
-This aligns well with the existing testing focus. Should I proceed with all these changes?</question>
-<follow_up>
-<suggest>Yes, implement all the changes as described</suggest>
-<suggest>Start with just the roleDefinition and file restrictions</suggest>
-<suggest>Focus only on the workflow instructions first</suggest>
-<suggest>Let me review the specific changes before proceeding</suggest>
-</follow_up>
-</ask_followup_question>
-        ]]></tool_use>
-        <expected_outcome>User selected: Yes, implement all the changes as described</expected_outcome>
-      </step>
-
-      <step number="5">
-        <description>Update mode configuration in .roomodes</description>
-        <tool_use><![CDATA[
-<apply_diff>
-<path>.roomodes</path>
-<diff>
-<<<<<<< SEARCH
-    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
-=======
-    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 - Benchmark testing with Vitest bench API - Performance profiling and optimization - Memory usage analysis in tests
->>>>>>> REPLACE
-</diff>
-</apply_diff>
-        ]]></tool_use>
-      </step>
-
-      <step number="6">
-        <description>Update file restrictions to include benchmark files</description>
-        <tool_use><![CDATA[
-<apply_diff>
-<path>.roomodes</path>
-<diff>
-<<<<<<< SEARCH
-        - 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
-=======
-        - fileRegex: (__tests__/.*|__mocks__/.*|\.test\.(ts|tsx|js|jsx)$|\.spec\.(ts|tsx|js|jsx)$|\.bench\.(ts|tsx|js|jsx)$|/test/.*|vitest\.config\.(js|ts)$|vitest\.setup\.(js|ts)$)
-          description: Test files, benchmarks, mocks, and Vitest configuration
->>>>>>> REPLACE
-</diff>
-</apply_diff>
-        ]]></tool_use>
-      </step>
-
-      <step number="7">
-        <description>Create new benchmark workflow instructions</description>
-        <tool_use><![CDATA[
-<write_to_file>
-<path>.roo/rules-test/5_benchmark_testing.xml</path>
-<content>
-<benchmark_testing_guide>
-  <overview>
-    Guidelines for creating and maintaining performance benchmarks using Vitest bench API
-  </overview>
-
-  <benchmark_patterns>
-    <pattern name="basic_benchmark">
-      <description>Basic benchmark structure</description>
-      <example><![CDATA[
-import { bench, describe } from 'vitest';
-
-describe('Array operations', () => {
-  bench('Array.push', () => {
-    const arr = [];
-    for (let i = 0; i < 1000; i++) {
-      arr.push(i);
-    }
-  });
-
-  bench('Array spread', () => {
-    let arr = [];
-    for (let i = 0; i < 1000; i++) {
-      arr = [...arr, i];
-    }
-  });
-});
-      ]]></example>
-    </pattern>
-  </benchmark_patterns>
-
-  <best_practices>
-    <practice>Use meaningful benchmark names that describe what's being measured</practice>
-    <practice>Include baseline comparisons when optimizing code</practice>
-    <practice>Run benchmarks in isolation to avoid interference</practice>
-    <practice>Document performance expectations and thresholds</practice>
-  </best_practices>
-</benchmark_testing_guide>
-</content>
-<line_count>38</line_count>
-</write_to_file>
-        ]]></tool_use>
-      </step>
-
-      <step number="8">
-        <description>Validate all changes for consistency</description>
-        <tool_use><![CDATA[
-<ask_followup_question>
-<question>I've completed all the changes to add benchmark testing capabilities to the test mode:
-
-1. ✓ Updated roleDefinition to include benchmark expertise
-2. ✓ Modified file restrictions to include .bench.ts files
-3. ✓ Created new benchmark workflow instructions
-4. ✓ Added Vitest bench API examples
-
-All changes are cohesive and align with the existing test mode structure. Would you like me to test any specific aspect of these changes?</question>
-<follow_up>
-<suggest>Test creating a new benchmark file to verify file permissions</suggest>
-<suggest>Review the complete changes one more time</suggest>
-<suggest>Everything looks good, the mode is ready</suggest>
-<suggest>Create a simple benchmark example to test</suggest>
-</follow_up>
-</ask_followup_question>
-        ]]></tool_use>
-      </step>
-    </workflow>
-
-    <completion><![CDATA[
-<attempt_completion>
-<result>
-I've successfully enhanced the test mode with benchmark testing capabilities:
-
-1. Updated the roleDefinition to include:
-   - Benchmark testing with Vitest bench API
-   - Performance profiling and optimization
-   - Memory usage analysis in tests
-
-2. Modified file restrictions to include .bench.ts files, allowing the mode to create and edit benchmark files
-
-3. Created new workflow instructions at .roo/rules-test/5_benchmark_testing.xml with:
-   - Basic benchmark patterns
-   - Best practices for performance testing
-   - Example code using Vitest's bench API
-
-All changes have been validated for cohesion and consistency with the existing test mode structure. The mode now supports comprehensive performance testing alongside its existing unit and integration testing capabilities.
-</result>
-</attempt_completion>
-    ]]></completion>
-
-    <key_takeaways>
-      <takeaway>Always immerse yourself in the existing mode before making changes</takeaway>
-      <takeaway>Use ask_followup_question aggressively to clarify scope and validate changes</takeaway>
-      <takeaway>Validate all changes for cohesion and consistency</takeaway>
-      <takeaway>Update all relevant parts: configuration, file restrictions, and instructions</takeaway>
-      <takeaway>Test changes to ensure they work as expected</takeaway>
-    </key_takeaways>
-  </example>
-</complete_examples>

.roo/rules-mode-writer/6_mode_testing_validation.xml

@@ -1,207 +0,0 @@
-<mode_testing_validation>
-  <overview>
-    Guidelines for testing and validating newly created modes to ensure they function correctly and integrate well with the Roo Code ecosystem.
-  </overview>
-
-  <validation_checklist>
-    <category name="configuration_validation">
-      <item priority="critical">
-        <check>Mode slug is unique and follows naming conventions</check>
-        <validation>No spaces, lowercase, hyphens only</validation>
-      </item>
-      <item priority="critical">
-        <check>All required fields are present and non-empty</check>
-        <fields>slug, name, roleDefinition, groups</fields>
-      </item>
-      <item priority="critical">
-        <check>No customInstructions field in .roomodes</check>
-        <validation>All instructions must be in XML files in .roo/rules-[slug]/</validation>
-      </item>
-      <item priority="high">
-        <check>File restrictions use valid regex patterns</check>
-        <test_method><![CDATA[
-<search_files>
-<path>.</path>
-<regex>your_file_regex_here</regex>
-</search_files>
-        ]]></test_method>
-      </item>
-      <item priority="high">
-        <check>whenToUse clearly differentiates from other modes</check>
-        <validation>Compare with existing mode descriptions</validation>
-      </item>
-    </category>
-
-    <category name="instruction_validation">
-      <item>
-        <check>XML files are well-formed and valid</check>
-        <validation>No syntax errors, proper closing tags</validation>
-      </item>
-      <item>
-        <check>Instructions follow XML best practices</check>
-        <validation>Semantic tag names, proper nesting</validation>
-      </item>
-      <item>
-        <check>Examples use correct tool syntax</check>
-        <validation>Tool parameters match current API</validation>
-      </item>
-      <item>
-        <check>File paths in examples are consistent</check>
-        <validation>Use project-relative paths</validation>
-      </item>
-    </category>
-
-    <category name="functional_testing">
-      <item>
-        <check>Mode appears in mode list</check>
-        <test>Switch to the new mode and verify it loads</test>
-      </item>
-      <item>
-        <check>Tool permissions work as expected</check>
-        <test>Try using each tool group and verify access</test>
-      </item>
-      <item>
-        <check>File restrictions are enforced</check>
-        <test>Attempt to edit allowed and restricted files</test>
-      </item>
-      <item>
-        <check>Mode handles edge cases gracefully</check>
-        <test>Test with minimal input, errors, edge cases</test>
-      </item>
-    </category>
-  </validation_checklist>
-
-  <testing_workflow>
-    <step number="1">
-      <title>Configuration Testing</title>
-      <actions>
-        <action>Verify mode appears in available modes list</action>
-        <action>Check that mode metadata displays correctly</action>
-        <action>Confirm mode can be activated</action>
-      </actions>
-      <verification><![CDATA[
-<ask_followup_question>
-<question>I've created the mode configuration. Can you see the new mode in your mode list?</question>
-<follow_up>
-<suggest>Yes, I can see the new mode and switch to it</suggest>
-<suggest>No, the mode doesn't appear in the list</suggest>
-<suggest>The mode appears but has errors when switching</suggest>
-</follow_up>
-</ask_followup_question>
-      ]]></verification>
-    </step>
-
-    <step number="2">
-      <title>Permission Testing</title>
-      <test_cases>
-        <test case="read_permissions">
-          <action>Use read tools on various files</action>
-          <expected>All read operations should work</expected>
-        </test>
-        <test case="edit_restrictions">
-          <action>Try editing allowed file types</action>
-          <expected>Edits succeed for matching patterns</expected>
-        </test>
-        <test case="edit_restrictions_negative">
-          <action>Try editing restricted file types</action>
-          <expected>FileRestrictionError for non-matching files</expected>
-        </test>
-      </test_cases>
-    </step>
-
-    <step number="3">
-      <title>Workflow Testing</title>
-      <actions>
-        <action>Execute main workflow from start to finish</action>
-        <action>Test each decision point</action>
-        <action>Verify error handling</action>
-        <action>Check completion criteria</action>
-      </actions>
-    </step>
-
-    <step number="4">
-      <title>Integration Testing</title>
-      <areas>
-        <area>Orchestrator mode compatibility</area>
-        <area>Mode switching functionality</area>
-        <area>Tool handoff between modes</area>
-        <area>Consistent behavior with other modes</area>
-      </areas>
-    </step>
-  </testing_workflow>
-
-  <common_issues>
-    <issue type="configuration">
-      <problem>Mode doesn't appear in list</problem>
-      <causes>
-        <cause>Syntax error in YAML</cause>
-        <cause>Invalid mode slug</cause>
-        <cause>File not saved</cause>
-      </causes>
-      <solution>Check YAML syntax, validate slug format</solution>
-    </issue>
-
-    <issue type="permissions">
-      <problem>File restriction not working</problem>
-      <causes>
-        <cause>Invalid regex pattern</cause>
-        <cause>Escaping issues in regex</cause>
-        <cause>Wrong file path format</cause>
-      </causes>
-      <solution>Test regex pattern, use proper escaping</solution>
-      <example><![CDATA[
-# Wrong: *.ts (glob pattern)
-# Right: .*\.ts$ (regex pattern)
-      ]]></example>
-    </issue>
-
-    <issue type="behavior">
-      <problem>Mode not following instructions</problem>
-      <causes>
-        <cause>Instructions not in .roo/rules-[slug]/ folder</cause>
-        <cause>XML parsing errors</cause>
-        <cause>Conflicting instructions</cause>
-      </causes>
-      <solution>Verify file locations and XML validity</solution>
-    </issue>
-  </common_issues>
-
-  <debugging_tools>
-    <tool name="list_files">
-      <usage>Verify instruction files exist in correct location</usage>
-      <command><![CDATA[
-<list_files>
-<path>.roo</path>
-<recursive>true</recursive>
-</list_files>
-      ]]></command>
-    </tool>
-
-    <tool name="read_file">
-      <usage>Check mode configuration syntax</usage>
-      <command><![CDATA[
-<read_file>
-<path>.roomodes</path>
-</read_file>
-      ]]></command>
-    </tool>
-
-    <tool name="search_files">
-      <usage>Test file restriction patterns</usage>
-      <command><![CDATA[
-<search_files>
-<path>.</path>
-<regex>your_file_pattern_here</regex>
-</search_files>
-      ]]></command>
-    </tool>
-  </debugging_tools>
-
-  <best_practices>
-    <practice>Test incrementally as you build the mode</practice>
-    <practice>Start with minimal configuration and add complexity</practice>
-    <practice>Document any special requirements or dependencies</practice>
-    <practice>Consider edge cases and error scenarios</practice>
-    <practice>Get feedback from potential users of the mode</practice>
-  </best_practices>
-</mode_testing_validation>

.roo/rules-mode-writer/7_validation_cohesion_checking.xml

@@ -1,201 +0,0 @@
-<validation_cohesion_checking>
-  <overview>
-    Guidelines for thoroughly validating mode changes to ensure cohesion,
-    consistency, and prevent contradictions across all mode components.
-  </overview>
-
-  <validation_principles>
-    <principle name="comprehensive_review">
-      <description>
-        Every change must be reviewed in context of the entire mode
-      </description>
-      <checklist>
-        <item>Read all existing XML instruction files</item>
-        <item>Verify new changes align with existing patterns</item>
-        <item>Check for duplicate or conflicting instructions</item>
-        <item>Ensure terminology is consistent throughout</item>
-      </checklist>
-    </principle>
-
-    <principle name="aggressive_questioning">
-      <description>
-        Use ask_followup_question extensively to clarify ambiguities
-      </description>
-      <when_to_ask>
-        <scenario>User's intent is unclear</scenario>
-        <scenario>Multiple interpretations are possible</scenario>
-        <scenario>Changes might conflict with existing functionality</scenario>
-        <scenario>Impact on other modes needs clarification</scenario>
-      </when_to_ask>
-      <example><![CDATA[
-<ask_followup_question>
-<question>I notice this change might affect how the mode interacts with file permissions. Should we also update the file regex patterns to match?</question>
-<follow_up>
-<suggest>Yes, update the file regex to include the new file types</suggest>
-<suggest>No, keep the current file restrictions as they are</suggest>
-<suggest>Let me explain what file types I need to work with</suggest>
-<suggest>Show me the current file restrictions first</suggest>
-</follow_up>
-</ask_followup_question>
-      ]]></example>
-    </principle>
-
-    <principle name="contradiction_detection">
-      <description>
-        Actively search for and resolve contradictions
-      </description>
-      <common_contradictions>
-        <contradiction>
-          <type>Permission Mismatch</type>
-          <description>Instructions reference tools the mode doesn't have access to</description>
-          <resolution>Either grant the tool permission or update the instructions</resolution>
-        </contradiction>
-        <contradiction>
-          <type>Workflow Conflicts</type>
-          <description>Different XML files describe conflicting workflows</description>
-          <resolution>Consolidate workflows and ensure single source of truth</resolution>
-        </contradiction>
-        <contradiction>
-          <type>Role Confusion</type>
-          <description>Mode's roleDefinition doesn't match its actual capabilities</description>
-          <resolution>Update roleDefinition to accurately reflect the mode's purpose</resolution>
-        </contradiction>
-      </common_contradictions>
-    </principle>
-  </validation_principles>
-
-  <validation_workflow>
-    <phase name="pre_change_analysis">
-      <description>Before making any changes</description>
-      <steps>
-        <step>Read and understand all existing mode files</step>
-        <step>Create a mental model of current mode behavior</step>
-        <step>Identify potential impact areas</step>
-        <step>Ask clarifying questions about intended changes</step>
-      </steps>
-    </phase>
-
-    <phase name="change_implementation">
-      <description>While making changes</description>
-      <steps>
-        <step>Document each change and its rationale</step>
-        <step>Cross-reference with other files after each change</step>
-        <step>Verify examples still work with new changes</step>
-        <step>Update related documentation immediately</step>
-      </steps>
-    </phase>
-
-    <phase name="post_change_validation">
-      <description>After changes are complete</description>
-      <validation_checklist>
-        <category name="structural_validation">
-          <check>All XML files are well-formed and valid</check>
-          <check>File naming follows established patterns</check>
-          <check>Tag names are consistent across files</check>
-          <check>No orphaned or unused instructions</check>
-        </category>
-
-        <category name="content_validation">
-          <check>roleDefinition accurately describes the mode</check>
-          <check>whenToUse is clear and distinguishable</check>
-          <check>Tool permissions match instruction requirements</check>
-          <check>File restrictions align with mode purpose</check>
-          <check>Examples are accurate and functional</check>
-        </category>
-
-        <category name="integration_validation">
-          <check>Mode boundaries are well-defined</check>
-          <check>Handoff points to other modes are clear</check>
-          <check>No overlap with other modes' responsibilities</check>
-          <check>Orchestrator can correctly route to this mode</check>
-        </category>
-      </validation_checklist>
-    </phase>
-  </validation_workflow>
-
-  <cohesion_patterns>
-    <pattern name="consistent_voice">
-      <description>Maintain consistent tone and terminology</description>
-      <guidelines>
-        <guideline>Use the same terms for the same concepts throughout</guideline>
-        <guideline>Keep instruction style consistent across files</guideline>
-        <guideline>Maintain the same level of detail in similar sections</guideline>
-      </guidelines>
-    </pattern>
-
-    <pattern name="logical_flow">
-      <description>Ensure instructions flow logically</description>
-      <guidelines>
-        <guideline>Prerequisites come before dependent steps</guideline>
-        <guideline>Complex concepts build on simpler ones</guideline>
-        <guideline>Examples follow the explained patterns</guideline>
-      </guidelines>
-    </pattern>
-
-    <pattern name="complete_coverage">
-      <description>Ensure all aspects are covered without gaps</description>
-      <guidelines>
-        <guideline>Every mentioned tool has usage instructions</guideline>
-        <guideline>All workflows have complete examples</guideline>
-        <guideline>Error scenarios are addressed</guideline>
-      </guidelines>
-    </pattern>
-  </cohesion_patterns>
-
-  <validation_questions>
-    <question_set name="before_changes">
-      <ask_followup_question>
-        <question>Before we proceed with changes, I want to ensure I understand the full scope. What is the main goal of these modifications?</question>
-        <follow_up>
-          <suggest>Add new functionality while keeping existing features</suggest>
-          <suggest>Fix issues with current implementation</suggest>
-          <suggest>Refactor for better organization</suggest>
-          <suggest>Expand the mode's capabilities into new areas</suggest>
-        </follow_up>
-      </ask_followup_question>
-    </question_set>
-
-    <question_set name="during_changes">
-      <ask_followup_question>
-        <question>This change might affect other parts of the mode. How should we handle the impact on [specific area]?</question>
-        <follow_up>
-          <suggest>Update all affected areas to maintain consistency</suggest>
-          <suggest>Keep the existing behavior for backward compatibility</suggest>
-          <suggest>Create a migration path from old to new behavior</suggest>
-          <suggest>Let me review the impact first</suggest>
-        </follow_up>
-      </ask_followup_question>
-    </question_set>
-
-    <question_set name="after_changes">
-      <ask_followup_question>
-        <question>I've completed the changes and validation. Which aspect would you like me to test more thoroughly?</question>
-        <follow_up>
-          <suggest>Test the new workflow end-to-end</suggest>
-          <suggest>Verify file permissions work correctly</suggest>
-          <suggest>Check integration with other modes</suggest>
-          <suggest>Review all changes one more time</suggest>
-        </follow_up>
-      </ask_followup_question>
-    </question_set>
-  </validation_questions>
-
-  <red_flags>
-    <flag priority="high">
-      <description>Instructions reference tools not in the mode's groups</description>
-      <action>Either add the tool group or remove the instruction</action>
-    </flag>
-    <flag priority="high">
-      <description>File regex doesn't match described file types</description>
-      <action>Update regex pattern to match intended files</action>
-    </flag>
-    <flag priority="medium">
-      <description>Examples don't follow stated best practices</description>
-      <action>Update examples to demonstrate best practices</action>
-    </flag>
-    <flag priority="medium">
-      <description>Duplicate instructions in different files</description>
-      <action>Consolidate to single location and reference</action>
-    </flag>
-  </red_flags>
-</validation_cohesion_checking>

.roo/rules-translate/instructions-zh-cn.md

@@ -16,7 +16,6 @@
 | Auto-approve          | 自动批准          | 始终批准     | 权限相关术语  |
 | Checkpoint            | 存档点            | 检查点/快照  | 技术概念统一  |
 | MCP Server            | MCP 服务          | MCP 服务器   | 技术组件      |
-| Human Relay           | 人工辅助模式      | 人工中继     | 功能描述清晰  |
 | Network Timeout       | 请求超时          | 网络超时     | 更准确描述    |
 | Terminal              | 终端              | 命令行       | 技术术语统一  |
 | diff                  | 差异更新          | 差分/补丁    | 代码变更      |

.roo/skills/evals-context/SKILL.md

@@ -0,0 +1,188 @@
+---
+name: evals-context
+description: Provides context about the Roo Code evals system structure in this monorepo. Use when tasks mention "evals", "evaluation", "eval runs", "eval exercises", or working with the evals infrastructure. Helps distinguish between the evals execution system (packages/evals, apps/web-evals) and the public website evals display page (apps/web-roo-code/src/app/evals).
+---
+
+# Evals Codebase Context
+
+## When to Use This Skill
+
+Use this skill when the task involves:
+
+- Modifying or debugging the evals execution infrastructure
+- Adding new eval exercises or languages
+- Working with the evals web interface (apps/web-evals)
+- Modifying the public evals display page on roocode.com
+- Understanding where evals code lives in this monorepo
+
+## When NOT to Use This Skill
+
+Do NOT use this skill when:
+
+- Working on unrelated parts of the codebase (extension, webview-ui, etc.)
+- The task is purely about the VS Code extension's core functionality
+- Working on the main website pages that don't involve evals
+
+## Key Disambiguation: Two "Evals" Locations
+
+This monorepo has **two distinct evals-related locations** that can cause confusion:
+
+| Component                   | Path                                                           | Purpose                                                        |
+| --------------------------- | -------------------------------------------------------------- | -------------------------------------------------------------- |
+| **Evals Execution System**  | `packages/evals/`                                              | Core eval infrastructure: CLI, DB schema, Docker configs       |
+| **Evals Management UI**     | `apps/web-evals/`                                              | Next.js app for creating/monitoring eval runs (localhost:3446) |
+| **Website Evals Page**      | `apps/web-roo-code/src/app/evals/`                             | Public roocode.com page displaying eval results                |
+| **External Exercises Repo** | [Roo-Code-Evals](https://github.com/RooCodeInc/Roo-Code-Evals) | Actual coding exercises (NOT in this monorepo)                 |
+
+## Directory Structure Reference
+
+### `packages/evals/` - Core Evals Package
+
+```
+packages/evals/
+├── ARCHITECTURE.md          # Detailed architecture documentation
+├── ADDING-EVALS.md          # Guide for adding new exercises/languages
+├── README.md                # Setup and running instructions
+├── docker-compose.yml       # Container orchestration
+├── Dockerfile.runner        # Runner container definition
+├── Dockerfile.web           # Web app container
+├── drizzle.config.ts        # Database ORM config
+├── src/
+│   ├── index.ts             # Package exports
+│   ├── cli/                 # CLI commands for running evals
+│   │   ├── runEvals.ts      # Orchestrates complete eval runs
+│   │   ├── runTask.ts       # Executes individual tasks in containers
+│   │   ├── runUnitTest.ts   # Validates task completion via tests
+│   │   └── redis.ts         # Redis pub/sub integration
+│   ├── db/
+│   │   ├── schema.ts        # Database schema (runs, tasks)
+│   │   ├── queries/         # Database query functions
+│   │   └── migrations/      # SQL migrations
+│   └── exercises/
+│       └── index.ts         # Exercise loading utilities
+└── scripts/
+    └── setup.sh             # Local macOS setup script
+```
+
+### `apps/web-evals/` - Evals Management Web App
+
+```
+apps/web-evals/
+├── src/
+│   ├── app/
+│   │   ├── page.tsx         # Home page (runs list)
+│   │   ├── runs/
+│   │   │   ├── new/         # Create new eval run
+│   │   │   └── [id]/        # View specific run status
+│   │   └── api/runs/        # SSE streaming endpoint
+│   ├── actions/             # Server actions
+│   │   ├── runs.ts          # Run CRUD operations
+│   │   ├── tasks.ts         # Task queries
+│   │   ├── exercises.ts     # Exercise listing
+│   │   └── heartbeat.ts     # Controller health checks
+│   ├── hooks/               # React hooks (SSE, models, etc.)
+│   └── lib/                 # Utilities and schemas
+```
+
+### `apps/web-roo-code/src/app/evals/` - Public Website Evals Page
+
+```
+apps/web-roo-code/src/app/evals/
+├── page.tsx      # Fetches and displays public eval results
+├── evals.tsx     # Main evals display component
+├── plot.tsx      # Visualization component
+└── types.ts      # EvalRun type (extends packages/evals types)
+```
+
+This page **displays** eval results on the public roocode.com website. It imports types from `@roo-code/evals` but does NOT run evals.
+
+## Architecture Overview
+
+The evals system is a distributed evaluation platform that runs AI coding tasks in isolated VS Code environments:
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│  Web App (apps/web-evals)  ──────────────────────────────── │
+│        │                                                    │
+│        ▼                                                    │
+│  PostgreSQL ◄────► Controller Container                     │
+│        │               │                                    │
+│        ▼               ▼                                    │
+│     Redis ◄───► Runner Containers (1-25 parallel)           │
+└─────────────────────────────────────────────────────────────┘
+```
+
+**Key components:**
+
+- **Controller**: Orchestrates eval runs, spawns runners, manages task queue (p-queue)
+- **Runner**: Isolated Docker container with VS Code + Roo Code extension + language runtimes
+- **Redis**: Pub/sub for real-time events (NOT task queuing)
+- **PostgreSQL**: Stores runs, tasks, metrics
+
+## Common Tasks Quick Reference
+
+### Adding a New Eval Exercise
+
+1. Add exercise to [Roo-Code-Evals](https://github.com/RooCodeInc/Roo-Code-Evals) repo (external)
+2. See [`packages/evals/ADDING-EVALS.md`](packages/evals/ADDING-EVALS.md) for structure
+
+### Modifying Eval CLI Behavior
+
+Edit files in [`packages/evals/src/cli/`](packages/evals/src/cli/):
+
+- [`runEvals.ts`](packages/evals/src/cli/runEvals.ts) - Run orchestration
+- [`runTask.ts`](packages/evals/src/cli/runTask.ts) - Task execution
+- [`runUnitTest.ts`](packages/evals/src/cli/runUnitTest.ts) - Test validation
+
+### Modifying the Evals Web Interface
+
+Edit files in [`apps/web-evals/src/`](apps/web-evals/src/):
+
+- [`app/runs/new/new-run.tsx`](apps/web-evals/src/app/runs/new/new-run.tsx) - New run form
+- [`actions/runs.ts`](apps/web-evals/src/actions/runs.ts) - Run server actions
+
+### Modifying the Public Evals Display Page
+
+Edit files in [`apps/web-roo-code/src/app/evals/`](apps/web-roo-code/src/app/evals/):
+
+- [`evals.tsx`](apps/web-roo-code/src/app/evals/evals.tsx) - Display component
+- [`plot.tsx`](apps/web-roo-code/src/app/evals/plot.tsx) - Charts
+
+### Database Schema Changes
+
+1. Edit [`packages/evals/src/db/schema.ts`](packages/evals/src/db/schema.ts)
+2. Generate migration: `cd packages/evals && pnpm drizzle-kit generate`
+3. Apply migration: `pnpm drizzle-kit migrate`
+
+## Running Evals Locally
+
+```bash
+# From repo root
+pnpm evals
+
+# Opens web UI at http://localhost:3446
+```
+
+**Ports (defaults):**
+
+- PostgreSQL: 5433
+- Redis: 6380
+- Web: 3446
+
+## Testing
+
+```bash
+# packages/evals tests
+cd packages/evals && npx vitest run
+
+# apps/web-evals tests
+cd apps/web-evals && npx vitest run
+```
+
+## Key Types/Exports from `@roo-code/evals`
+
+The package exports are defined in [`packages/evals/src/index.ts`](packages/evals/src/index.ts):
+
+- Database queries: `getRuns`, `getTasks`, `getTaskMetrics`, etc.
+- Schema types: `Run`, `Task`, `TaskMetrics`
+- Used by both `apps/web-evals` and `apps/web-roo-code`

.roo/skills/roo-conflict-resolution/SKILL.md

@@ -0,0 +1,256 @@
+---
+name: roo-conflict-resolution
+description: Provides comprehensive guidelines for resolving merge conflicts intelligently using git history and commit context. Use when tasks involve merge conflicts, rebasing, PR conflicts, or git conflict resolution. This skill analyzes commit messages, git blame, and code intent to make intelligent resolution decisions.
+---
+
+# Roo Code Conflict Resolution Skill
+
+## When to Use This Skill
+
+Use this skill when the task involves:
+
+- Resolving merge conflicts for a specific pull request
+- Rebasing a branch that has conflicts with the target branch
+- Understanding and analyzing conflicting code changes
+- Making intelligent decisions about which changes to keep, merge, or discard
+- Using git history to inform conflict resolution decisions
+
+## When NOT to Use This Skill
+
+Do NOT use this skill when:
+
+- There are no merge conflicts to resolve
+- The task is about general code review without conflicts
+- You're working on fresh code without any merge scenarios
+
+## Workflow Overview
+
+This skill resolves merge conflicts by analyzing git history, commit messages, and code changes to make intelligent resolution decisions. Given a PR number (e.g., "#123"), it handles the entire conflict resolution process.
+
+## Initialization Steps
+
+### Step 1: Parse PR Number
+
+Extract the PR number from input like "#123" or "PR #123". Validate that a PR number was provided.
+
+### Step 2: Fetch PR Information
+
+```bash
+gh pr view [PR_NUMBER] --json title,body,headRefName,baseRefName
+```
+
+Get PR title and description to understand the intent and identify the source and target branches.
+
+### Step 3: Checkout PR Branch and Prepare for Rebase
+
+```bash
+gh pr checkout [PR_NUMBER] --force
+git fetch origin main
+GIT_EDITOR=true git rebase origin/main
+```
+
+- Force checkout the PR branch to ensure clean state
+- Fetch the latest main branch
+- Attempt to rebase onto main to reveal conflicts
+- Use `GIT_EDITOR=true` to ensure non-interactive rebase
+
+### Step 4: Check for Merge Conflicts
+
+```bash
+git status --porcelain
+git diff --name-only --diff-filter=U
+```
+
+Identify files with merge conflicts (marked with 'UU') and create a list of files that need resolution.
+
+## Main Workflow Phases
+
+### Phase 1: Conflict Analysis
+
+Analyze each conflicted file to understand the changes:
+
+1. Read the conflicted file to identify conflict markers
+2. Extract the conflicting sections between `<<<<<<<` and `>>>>>>>`
+3. Run git blame on both sides of the conflict
+4. Fetch commit messages and diffs for relevant commits
+5. Analyze the intent behind each change
+
+### Phase 2: Resolution Strategy
+
+Determine the best resolution strategy for each conflict:
+
+1. Categorize changes by intent (bugfix, feature, refactor, etc.)
+2. Evaluate recency and relevance of changes
+3. Check for structural overlap vs formatting differences
+4. Identify if changes can be combined or if one should override
+5. Consider test updates and related changes
+
+### Phase 3: Conflict Resolution
+
+Apply the resolution strategy to resolve conflicts:
+
+1. For each conflict, apply the chosen resolution
+2. Ensure proper escaping of conflict markers in diffs
+3. Validate that resolved code is syntactically correct
+4. Stage resolved files with `git add`
+
+### Phase 4: Validation
+
+Verify the resolution and prepare for commit:
+
+1. Run `git status` to confirm all conflicts are resolved
+2. Check for any compilation or syntax errors
+3. Review the final diff to ensure sensible resolutions
+4. Prepare a summary of resolution decisions
+
+## Git Commands Reference
+
+| Command | Purpose |
+|---------|---------|
+| `gh pr checkout [PR_NUMBER] --force` | Force checkout the PR branch |
+| `git fetch origin main` | Get the latest main branch |
+| `GIT_EDITOR=true git rebase origin/main` | Rebase current branch onto main (non-interactive) |
+| `git blame -L [start],[end] [commit] -- [file]` | Get commit information for specific lines |
+| `git show --format="%H%n%an%n%ae%n%ad%n%s%n%b" --no-patch [sha]` | Get commit metadata |
+| `git show [sha] -- [file]` | Get the actual changes made in a commit |
+| `git ls-files -u` | List unmerged files with stage information |
+| `GIT_EDITOR=true git rebase --continue` | Continue rebase after resolving conflicts |
+
+## Best Practices
+
+### Intent-Based Resolution (High Priority)
+
+Always prioritize understanding the intent behind changes rather than just looking at the code differences. Commit messages, PR descriptions, and issue references provide crucial context.
+
+**Example:** When there's a conflict between a bugfix and a refactor, apply the bugfix logic within the refactored structure rather than simply choosing one side.
+
+### Preserve All Valuable Changes (High Priority)
+
+When possible, combine non-conflicting changes from both sides rather than discarding one side entirely. Both sides of a conflict often contain valuable changes that can coexist if properly integrated.
+
+### Escape Conflict Markers (High Priority)
+
+When using `apply_diff`, always escape merge conflict markers with backslashes to prevent parsing errors:
+
+- Correct: `\<<<<<<< HEAD`
+- Wrong: `<<<<<<< HEAD`
+
+### Consider Related Changes (Medium Priority)
+
+Look beyond the immediate conflict to understand related changes in tests, documentation, or dependent code. A change might seem isolated but could be part of a larger feature or fix.
+
+## Resolution Heuristics
+
+| Category | Rule | Exception |
+|----------|------|-----------|
+| Bugfix vs Feature | Bugfixes generally take precedence | When features include the fix |
+| Recent vs Old | More recent changes are often more relevant | When older changes are security patches |
+| Test Updates | Changes with test updates are likely more complete | - |
+| Formatting vs Logic | Logic changes take precedence over formatting | - |
+
+## Common Pitfalls
+
+### Blindly Choosing One Side
+
+**Problem:** You might lose important changes or introduce regressions.
+**Solution:** Always analyze both sides using git blame and commit history.
+
+### Ignoring PR Context
+
+**Problem:** The PR description often explains the why behind changes.
+**Solution:** Always fetch and read the PR information before resolving.
+
+### Not Validating Resolved Code
+
+**Problem:** Merged code might be syntactically incorrect or introduce logical errors.
+**Solution:** Always check for syntax errors and review the final diff.
+
+### Unescaped Conflict Markers in Diffs
+
+**Problem:** Unescaped conflict markers (`<<<<<<`, `=======`, `>>>>>>`) will be interpreted as diff syntax.
+**Solution:** Always escape with backslash (`\`) when they appear in content.
+
+## Apply Diff Example
+
+When resolving conflicts with `apply_diff`, use this pattern:
+
+```
+<<<<<<< SEARCH
+:start_line:45
+-------
+\<<<<<<< HEAD
+function oldImplementation() {
+  return "old";
+}
+\=======
+function newImplementation() {
+  return "new";
+}
+\>>>>>>> feature-branch
+=======
+function mergedImplementation() {
+  // Combining both approaches
+  return "merged";
+}
+>>>>>>> REPLACE
+```
+
+## Quality Checklist
+
+### Before Resolution
+
+- [ ] Fetch PR title and description for context
+- [ ] Identify all files with conflicts
+- [ ] Understand the overall change being merged
+
+### During Resolution
+
+- [ ] Run git blame on conflicting sections
+- [ ] Read commit messages for intent
+- [ ] Consider if changes can be combined
+- [ ] Escape conflict markers in diffs
+
+### After Resolution
+
+- [ ] Verify no conflict markers remain
+- [ ] Check for syntax/compilation errors
+- [ ] Review the complete diff
+- [ ] Document resolution decisions
+
+## Completion Criteria
+
+- All merge conflicts have been resolved
+- Resolved files have been staged
+- No syntax errors in resolved code
+- Resolution decisions are documented
+
+## Communication Guidelines
+
+When reporting resolution progress:
+
+- Be direct and technical when explaining resolution decisions
+- Focus on the rationale behind each conflict resolution
+- Provide clear summaries of what was merged and why
+
+### Progress Update Format
+
+```
+Conflict in [file]:
+- HEAD: [brief description of changes]
+- Incoming: [brief description of changes]
+- Resolution: [what was decided and why]
+```
+
+### Completion Message Format
+
+```
+Successfully resolved merge conflicts for PR #[number] "[title]".
+
+Resolution Summary:
+- [file1]: [brief description of resolution]
+- [file2]: [brief description of resolution]
+
+[Key decision explanation if applicable]
+
+All conflicts have been resolved and files have been staged for commit.
+```

.roo/skills/roo-translation/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: roo-translation
+description: Provides comprehensive guidelines for translating and localizing Roo Code extension strings. Use when tasks involve i18n, translation, localization, adding new languages, or updating existing translation files. This skill covers both core extension (src/i18n/locales/) and WebView UI (webview-ui/src/i18n/locales/) localization.
+---
+
+# Roo Code Translation Skill
+
+## When to Use This Skill
+
+Use this skill when the task involves:
+
+- Adding new translatable strings to the Roo Code extension
+- Translating existing strings to new languages
+- Updating or fixing translations in existing language files
+- Understanding i18n patterns used in the codebase
+- Working with localization files in either core extension or WebView UI
+
+## When NOT to Use This Skill
+
+Do NOT use this skill when:
+
+- Working on non-translation code changes
+- The task doesn't involve i18n or localization
+- You're only reading translation files for reference without modifying them
+
+## Supported Languages and Locations
+
+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:
+
+| Component | Path | Purpose |
+|-----------|------|---------|
+| **Core Extension** | `src/i18n/locales/` | Extension backend strings |
+| **WebView UI** | `webview-ui/src/i18n/locales/` | User interface strings |
+
+## Brand Voice, Tone, and Word Choice
+
+For detailed brand voice, tone, and word choice guidance, refer to the guidance file:
+
+- [`.roo/guidance/roo-translator.md`](../../guidance/roo-translator.md)
+
+This guidance file is loaded at runtime and should be consulted for the latest brand and style standards.
+
+## Voice, Style and Tone Guidelines
+
+- 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
+
+### Terms to Keep in English
+
+- 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
+
+## 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
+
+## 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
+
+### Trans Component Example
+
+Translation string:
+```json
+"changeSettings": "You can always change this at the bottom of the <settingsLink>settings</settingsLink>"
+```
+
+React component usage:
+```tsx
+<Trans
+  i18nKey="welcome:telemetry.changeSettings"
+  components={{
+    settingsLink: <VSCodeLink href="#" onClick={handleOpenSettings} />
+  }}
+/>
+```
+
+## 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
+
+## Translation Workflow
+
+1. First add or modify English strings, then ask for confirmation before translating to all other languages
+2. 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 `search_files` tool to find JSON keys that are near new keys in English translations but do not yet exist in the other language files for `apply_diff` SEARCH context
+   5. Create appropriate translations for all other supported languages utilizing the `search_files` result using `apply_diff` 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
+
+3. Flag or comment if an English source string is incomplete ("please see this...") to avoid truncated or unclear translations
+
+4. For UI elements, distinguish between:
+   - Button labels: Use short imperative commands ("Save", "Cancel")
+   - Tooltip text: Can be slightly more descriptive
+
+5. Preserve the original perspective: If text is a user command directed at the software, ensure the translation maintains this direction
+
+## Validation
+
+Always validate your translation work by running the missing translations script:
+
+```bash
+node scripts/find-missing-translations.js
+```
+
+Address any missing translations identified by the script to ensure complete coverage across all locales.
+
+## 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
+
+## 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)
+- ✓ Ran the missing translations script to validate completeness

.roomodes

@@ -1,46 +1,4 @@
 customModes:
-  - 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: 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.
@@ -73,42 +31,6 @@ customModes:
       - edit
       - command
     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: docs-extractor
-    name: 📚 Docs Extractor
-    roleDefinition: |-
-      You are Roo, a documentation analysis specialist with two primary functions:
-      1. Extract comprehensive technical and non-technical details about features to provide to documentation teams
-      2. Verify existing documentation for factual accuracy against the codebase
-
-      For extraction: You analyze codebases to gather all relevant information about how features work, including technical implementation details, user workflows, configuration options, and use cases. You organize this information clearly for documentation teams to use.
-
-      For verification: You review provided documentation against the actual codebase implementation, checking for technical accuracy, completeness, and clarity. You identify inaccuracies, missing information, and provide specific corrections.
-
-      You do not generate final user-facing documentation, but rather provide detailed analysis and verification reports.
-    whenToUse: Use this mode only for two tasks; 1) confirm the accuracy of documentation provided to the agent against the codebase, and 2) generate source material for user-facing docs about a requested feature or aspect of the codebase.
-    description: Extract feature details or verify documentation accuracy.
-    groups:
-      - read
-      - - edit
-        - fileRegex: (EXTRACTION-.*\.md$|VERIFICATION-.*\.md$|DOCS-TEMP-.*\.md$|\.roo/docs-extractor/.*\.md$)
-          description: Extraction/Verification report files only (source-material), plus legacy DOCS-TEMP
-      - 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."
@@ -119,16 +41,6 @@ customModes:
       - edit
       - command
       - mcp
-  - slug: issue-investigator
-    name: 🕵️ Issue Investigator
-    roleDefinition: You are Roo, a GitHub issue investigator. Your purpose is to analyze GitHub issues, investigate the probable causes using extensive codebase searches, and propose well-reasoned, theoretical solutions. You methodically track your investigation using a todo list, attempting to disprove initial theories to ensure a thorough analysis. Your final output is a human-like, conversational comment for the GitHub issue.
-    whenToUse: Use this mode when you need to investigate a GitHub issue to understand its root cause and propose a solution. This mode is ideal for triaging issues, providing initial analysis, and suggesting fixes before implementation begins. It uses the `gh` CLI for issue interaction.
-    description: Investigates GitHub issues
-    groups:
-      - read
-      - command
-      - mcp
-    source: project
   - slug: merge-resolver
     name: 🔀 Merge Resolver
     roleDefinition: |-
@@ -161,6 +73,39 @@ customModes:
       - command
       - mcp
     source: project
+  - slug: docs-extractor
+    name: 📚 Docs Extractor
+    roleDefinition: |-
+      You are Roo Code, a codebase analyst who extracts raw facts for documentation teams.
+      You do NOT write documentation. You extract and organize information.
+
+      Two functions:
+      1. Extract: Gather facts about a feature/aspect from the codebase
+      2. Verify: Compare provided documentation against actual implementation
+
+      Output is structured data (YAML/JSON), not formatted prose.
+      No templates, no markdown formatting, no document structure decisions.
+      Let documentation-writer mode handle all writing.
+    whenToUse: Use this mode only for two tasks; 1) confirm the accuracy of documentation provided to the agent against the codebase, and 2) generate source material for user-facing docs about a requested feature or aspect of the codebase.
+    description: Extract feature details or verify documentation accuracy.
+    groups:
+      - read
+      - - edit
+        - fileRegex: \.roo/extraction/.*\.(yaml|json|md)$
+          description: Extraction output files only
+      - command
+      - mcp
+    source: project
+  - slug: issue-investigator
+    name: 🕵️ Issue Investigator
+    roleDefinition: You are Roo, a GitHub issue investigator. Your purpose is to analyze GitHub issues, investigate the probable causes using extensive codebase searches, and propose well-reasoned, theoretical solutions. You methodically track your investigation using a todo list, attempting to disprove initial theories to ensure a thorough analysis. Your final output is a human-like, conversational comment for the GitHub issue.
+    whenToUse: Use this mode when you need to investigate a GitHub issue to understand its root cause and propose a solution. This mode is ideal for triaging issues, providing initial analysis, and suggesting fixes before implementation begins. It uses the `gh` CLI for issue interaction.
+    description: Investigates GitHub issues
+    groups:
+      - read
+      - command
+      - mcp
+    source: project
   - slug: issue-writer
     name: 📝 Issue Writer
     roleDefinition: |-
@@ -183,56 +128,21 @@ customModes:
             
             <update_todo_list>
             <todos>
-            [ ] Detect current repository information
-            [ ] Determine repository structure (monorepo/standard)
-            [ ] Perform initial codebase discovery
-            [ ] Analyze user request to determine issue type
-            [ ] Gather and verify additional information
-            [ ] Determine if user wants to contribute
-            [ ] Perform issue scoping (if contributing)
-            [ ] Draft issue content
-            [ ] Review and confirm with user
-            [ ] Create GitHub issue
+            [ ] Detect repository context (OWNER/REPO, monorepo, roots)
+            [ ] Perform targeted codebase discovery (iteration 1)
+            [ ] Clarify missing details (repro or desired outcome)
+            [ ] Classify type (Bug | Enhancement)
+            [ ] Assemble Issue Body
+            [ ] Review and submit (Submit now | Submit now and assign to me)
             </todos>
             </update_todo_list>
           </instructions>
         </step>
       </initialization>
-    whenToUse: Use this mode when you need to create a GitHub issue. Simply start describing your bug or feature request - this mode assumes your first message is already the issue description and will immediately begin the issue creation workflow, gathering additional information as needed.
+    whenToUse: Use this mode when you need to create a GitHub issue. Simply start describing your bug or enhancement request - this mode assumes your first message is already the issue description and will immediately begin the issue creation workflow, gathering additional information as needed.
     description: Create well-structured GitHub issues.
     groups:
       - read
       - command
       - mcp
     source: project
-  - slug: mode-writer
-    name: ✍️ Mode Writer
-    roleDefinition: |-
-      You are Roo, a mode creation and editing specialist focused on designing, implementing, and enhancing 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
-      - Editing and enhancing existing modes while maintaining consistency
-      - 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
-      - Validating changes for cohesion and preventing contradictions
-
-      You help users by:
-      - Creating new modes: Gathering requirements, defining configurations, and implementing XML instructions
-      - Editing existing modes: Immersing in current implementation, analyzing requested changes, and ensuring cohesive updates
-      - Using ask_followup_question aggressively to clarify ambiguities and validate understanding
-      - Thoroughly validating all changes to prevent contradictions between different parts of a mode
-      - Ensuring instructions are well-organized with proper XML tags
-      - Following established patterns from existing modes
-      - Maintaining consistency across all mode components
-    whenToUse: Use this mode when you need to create a new custom mode or edit an existing one. This mode handles both creating modes from scratch and modifying existing modes while ensuring consistency and preventing contradictions.
-    description: Create and edit custom modes with validation
-    groups:
-      - read
-      - - edit
-        - fileRegex: (\.roomodes$|\.roo/.*\.xml$|\.yaml$)
-          description: Mode configuration files and XML instructions
-      - command
-      - mcp
-    source: project

.tool-versions

@@ -1 +1,2 @@
+pnpm 10.8.1
 nodejs 20.19.2

AGENTS.md

@@ -0,0 +1,5 @@
+# AGENTS.md
+
+This file provides guidance to agents when working with code in this repository.
+
+- Settings View Pattern: When working on `SettingsView`, inputs must bind to the local `cachedState`, NOT the live `useExtensionState()`. The `cachedState` acts as a buffer for user edits, isolating them from the `ContextProxy` source-of-truth until the user explicitly clicks "Save". Wiring inputs directly to the live state causes race conditions.

CHANGELOG.md

@@ -1,5 +1,737 @@
 # Roo Code Changelog
 
+## 3.53.0
+
+### Minor Changes
+
+- **The Roo Code plugin is not going away.** You may have seen the [recent announcement](https://x.com/mattrubens/status/2046636598859559114) that Roo Code hit 3 million installs and the original team is going all-in on Roomote. We know that news was hard for a lot of you. This plugin means a lot to us and to you, and we hear you. The good news: a community team has stepped up to carry Roo Code forward, and we're working with them on an official handoff so the plugin you rely on keeps getting maintained and improved.
+- Add GPT-5.5 support via the OpenAI Codex provider (PR #12170 by @hannesrudolph)
+- Add Claude Opus 4.7 support on Vertex AI (#12134 by @saneroen, PR #12135 by @saneroen)
+- Add previous checkpoint navigation controls and i18n in chat (#12138 by @saneroen, PR #12139 by @saneroen)
+- Add Roomote banner (PR #12119 by @brunobergher)
+- Redesign Roomote announcement banner with violet branding on the web (PR #12161 by @roomote-v0)
+- Add sunsetting Roo Code blog post (PR #12160 by @roomote-v0)
+
+## 3.52.1
+
+### Patch Changes
+
+- Add correct JSON schema for `.roomodes` configuration files (#11790 by @algorhythm85, PR #11791 by @app/roomote-v0)
+- Remove the hiring announcement from the VS Code extension UI (PR #12108 by @app/roomote-v0)
+
+## 3.52.0
+
+### Minor Changes
+
+- Add Poe as an AI provider so users can access Poe models directly in Roo Code (PR #12015 by @kamilio)
+- Improve the xAI provider by migrating it to the Responses API with reusable transform utilities (#11961 by @carlesso, PR #11962 by @carlesso)
+- Fix MiniMax model listings and context window handling for more reliable configuration (#11999 by @Rexarrior, PR #12069 by @Rexarrior)
+- Add xAI Grok-4.20 models and update the default xAI model selection (#11955 by @carlesso, PR #11956 by @carlesso)
+- Add OpenAI GPT-5.4 mini and nano models to expand the available OpenAI model lineup (PR #11946 by @PeterDaveHello)
+- Chore: include the automated version bump PR from the previous release cycle for complete release accounting (PR #11892 by @app/github-actions)
+
+### Patch Changes
+
+- Add support for OpenAI `gpt-5.4-mini` and `gpt-5.4-nano` models.
+
+## 3.51.1
+
+### Patch Changes
+
+- Feat: Add Cohere Embed v4 model support for Bedrock and improve credential handling (#11823 by @cscvenkatmadurai, PR #11824 by @cscvenkatmadurai)
+- Feat: Add Gemini 3.1 Pro customtools model to Vertex AI provider (PR #11857 by @NVolcz)
+- Feat: Add gpt-5.4 to ChatGPT Plus/Pro (Codex) model catalog (PR #11876 by @roomote-v0)
+
+## 3.51.0
+
+### Minor Changes
+
+- Add OpenAI GPT-5.4 and GPT-5.3 Chat Latest model support so Roo Code can use the newest OpenAI chat models (PR #11848 by @PeterDaveHello)
+- Add support for exposing skills as slash commands with skill fallback execution for faster workflows (PR #11834 by @hannesrudolph)
+- Add CLI support for `--create-with-session-id` plus UUID session validation for more controlled session creation (PR #11859 by @cte)
+- Add support for choosing a specific shell when running terminal commands (PR #11851 by @jr)
+- Feature: Add the `ROO_ACTIVE` environment variable to terminal session settings for safer terminal guardrails (#11864 by @ajjuaire, PR #11862 by @ajjuaire)
+- Improve cloud settings freshness by updating the refresh interval to one hour (PR #11749 by @roomote-v0)
+- Add CLI session resume/history support plus an upgrade command for better long-running workflows (PR #11768 by @cte)
+- Add support for images in CLI stdin stream commands (PR #11831 by @cte)
+- Include `exitCode` in CLI command `tool_result` events for more reliable automation (PR #11820 by @cte)
+- Add CLI types to improve development ergonomics and type safety (PR #11781 by @cte)
+- Add CLI integration coverage for stdin stream routing and race-condition invariants (PR #11846 by @cte)
+- Fix the CLI stdin-stream cancel race and add an integration test suite to prevent regressions (PR #11817 by @cte)
+- Improve CLI stream recovery and add a configurable consecutive mistake limit (PR #11775 by @cte)
+- Fix CLI streaming deltas, task ID propagation, cancel recovery, and other runtime edge cases (PR #11736 by @cte)
+- Fix CLI task resumption so paused work can reliably continue (PR #11739 by @cte)
+- Recover from unhandled exceptions in the CLI instead of failing hard (PR #11750 by @cte)
+- Scope CLI session and resume flags to the current workspace to avoid cross-workspace confusion (PR #11774 by @cte)
+- Fix stdin prompt streaming to forward task configuration correctly (PR #11778 by @daniel-lxs)
+- Handle stdin-stream control-flow errors gracefully in the CLI runtime (PR #11811 by @cte)
+- Fix stdin stream queued messages and command output streaming in the CLI (PR #11814 by @cte)
+- Increase the CLI command execution timeout for long-running commands (PR #11815 by @cte)
+- Fix knip checks to keep repository validation green (PR #11819 by @cte)
+- Fix CLI upgrade version detection so upgrades resolve the correct target version (PR #11829 by @cte)
+- Ignore model-provided timeout values in the CLI runtime to keep command handling consistent (PR #11835 by @cte)
+- Fix redundant skill reloading during conversations to reduce duplicate work (PR #11838 by @hannesrudolph)
+- Ensure full command output is streamed before the CLI reports completion (PR #11842 by @cte)
+- Fix CLI follow-up routing after completion prompts so next actions land in the right place (PR #11844 by @cte)
+- Remove the Netflix logo from the homepage (PR #11787 by @roomote-v0)
+- Chore: Prepare CLI release v0.1.2 (PR #11737 by @cte)
+- Chore: Prepare CLI release v0.1.3 (PR #11740 by @cte)
+- Chore: Prepare CLI release v0.1.4 (PR #11751 by @cte)
+- Chore: Prepare CLI release v0.1.5 (PR #11772 by @cte)
+- Chore: Prepare CLI release v0.1.6 (PR #11780 by @cte)
+- Release Roo Code v1.113.0 (PR #11782 by @cte)
+- Chore: Prepare CLI release v0.1.7 (PR #11812 by @cte)
+- Chore: Prepare CLI release v0.1.8 (PR #11816 by @cte)
+- Chore: Prepare CLI release v0.1.9 (PR #11818 by @cte)
+- Chore: Prepare CLI release v0.1.10 (PR #11821 by @cte)
+- Release Roo Code v1.114.0 (PR #11822 by @cte)
+- Chore: Prepare CLI release v0.1.11 (PR #11832 by @cte)
+- Release Roo Code v1.115.0 (PR #11833 by @cte)
+- Chore: Prepare CLI release v0.1.12 (PR #11836 by @cte)
+- Chore: Prepare CLI release v0.1.13 (PR #11837 by @hannesrudolph)
+- Chore: Prepare CLI release v0.1.14 (PR #11843 by @cte)
+- Chore: Prepare CLI release v0.1.15 (PR #11845 by @cte)
+- Chore: Prepare CLI release v0.1.16 (PR #11852 by @cte)
+- Chore: Prepare CLI release v0.1.17 (PR #11860 by @cte)
+
+### Patch Changes
+
+- Add OpenAI's GPT-5.3-Chat-Latest model support
+- Add OpenAI's GPT-5.3-Codex model support
+- Add OpenAI's GPT-5.4 model support
+- Add OpenAI's GPT-5.3-Codex model support (PR #11728 by @PeterDaveHello)
+- Warm Roo models on CLI startup for faster initial responses (PR #11722 by @cte)
+- Fix spelling/grammar and casing inconsistencies (#11478 by @PeterDaveHello, PR #11485 by @PeterDaveHello)
+- Fix: Restore Linear integration page (PR #11725 by @roomote)
+- Chore: Prepare CLI release v0.1.1 (PR #11723 by @cte)
+
+## [3.50.4] - 2026-02-21
+
+- Feat: Add MiniMax M2.5 model support (#11471 by @love8ko, PR #11458 by @roomote)
+
+## [3.50.3] - 2026-02-20
+
+- Fix: Correct Vertex AI claude-sonnet-4-6 model ID (#11625 by @yuvarajl, PR #11626 by @roomote)
+- Restore Unbound as a provider (PR #11624 by @pugazhendhi-m)
+
+## [3.50.2] - 2026-02-20
+
+- Fix: Inline terminal rendering parity with the VSCode Terminal (#10699 by @jerrill-johnson-bitwerx, PR #11361 by @RussellZager)
+- Fix: Enable prompt caching for Bedrock custom ARN and default to ON (#10846 by @wisestmumbler, PR #11373 by @roomote)
+- Feat: Add visual feedback to copy button in task actions (#11401 by @omagoduck, PR #11403 by @omagoduck)
+
+## [3.50.1] - 2026-02-20
+
+- Fix OpenAI Codex and OpenAI Native stream parsing for done-only and `content_part` events, including duplicate-text guards when deltas are already streamed.
+
+## [3.50.0] - 2026-02-19
+
+- Add Gemini 3.1 Pro support and set as default Gemini model (PR #11608 by @PeterDaveHello)
+- Add NDJSON stdin protocol, list subcommands, and modularize CLI run command (PR #11597 by @cte)
+- Prepare CLI v0.1.0 release (PR #11599 by @cte)
+- Remove integration tests (PR #11598 by @roomote)
+- Changeset version bump (PR #11596 by @github-actions)
+
+## [3.49.0] - 2026-02-19
+
+- Add file changes panel to track all file modifications per conversation (#11493 by @saneroen, PR #11494 by @saneroen)
+- Add per-workspace indexing opt-in and stop/cancel indexing controls (#11455 by @JamesRobert20, PR #11456 by @JamesRobert20)
+- Add per-task file-based history store for cross-instance safety (PR #11490 by @roomote)
+- Fix: Redesign rehydration scroll lifecycle for smoother chat experience (PR #11483 by @hannesrudolph)
+- Fix: Bump @roo-code/types metadata version to 1.111.0 after revert regression (PR #11588 by @roomote)
+
+## [3.48.1] - 2026-02-18
+
+- Fix: Await MCP server initialization before returning McpHub instance, preventing race conditions (PR #11518 by @daniel-lxs)
+- Fix: Correct Bedrock Claude Sonnet 4.6 model ID (#11509 by @PeterDaveHello, PR #11569 by @PeterDaveHello)
+- Add DeleteQueuedMessage IPC command for managing queued messages (PR #11464 by @roomote)
+
+## [3.48.0] - 2026-02-17
+
+- Add Anthropic Claude Sonnet 4.6 support across all providers — Anthropic, Bedrock, Vertex, OpenRouter, and Vercel AI Gateway (PR #11509 by @PeterDaveHello)
+- Add lock toggle to pin API config across all modes in a workspace (PR #11295 by @hannesrudolph)
+- Fix: Prevent parent task state loss during orchestrator delegation (PR #11281 by @hannesrudolph)
+- Fix: Resolve race condition in new_task delegation that loses parent task history (PR #11331 by @daniel-lxs)
+- Fix: Serialize taskHistory writes and fix delegation status overwrite race (PR #11335 by @hannesrudolph)
+- Fix: Prevent chat history loss during cloud/settings navigation (#11371 by @SannidhyaSah, PR #11372 by @SannidhyaSah)
+- Fix: Preserve condensation summary during task resume (#11487 by @SannidhyaSah, PR #11488 by @SannidhyaSah)
+- Fix: Resolve chat scroll anchoring and task-switch scroll race conditions (PR #11385 by @hannesrudolph)
+- Fix: Preserve pasted images in chatbox during chat activity (PR #11375 by @app/roomote)
+- Add disabledTools setting to globally disable native tools (PR #11277 by @daniel-lxs)
+- Rename search_and_replace tool to edit and unify edit-family UI (PR #11296 by @hannesrudolph)
+- Render nested subtasks as recursive tree in history view (PR #11299 by @hannesrudolph)
+- Remove 9 low-usage providers and add retired-provider UX (PR #11297 by @hannesrudolph)
+- Remove browser use functionality entirely (PR #11392 by @hannesrudolph)
+- Remove built-in skills and built-in skills mechanism (PR #11414 by @hannesrudolph)
+- Remove footgun prompting (file-based system prompt override) (PR #11387 by @hannesrudolph)
+- Batch consecutive tool calls in chat UI with shared utility (PR #11245 by @hannesrudolph)
+- Validate Gemini thinkingLevel against model capabilities and handle empty streams (PR #11303 by @hannesrudolph)
+- Add GLM-5 model support to Z.ai provider (PR #11440 by @app/roomote)
+- Fix: Prevent double notification sound playback (PR #11283 by @hannesrudolph)
+- Fix: Prevent false unsaved changes prompt with OpenAI Compatible headers (#8230 by @hannesrudolph, PR #11334 by @daniel-lxs)
+- Fix: Cancel backend auto-approval timeout when auto-approve is toggled off mid-countdown (PR #11439 by @SannidhyaSah)
+- Fix: Add follow_up param validation in AskFollowupQuestionTool (PR #11484 by @rossdonald)
+- Fix: Prevent webview postMessage crashes and make dispose idempotent (PR #11313 by @0xMink)
+- Fix: Avoid zsh process-substitution false positives in assignments (PR #11365 by @hannesrudolph)
+- Fix: Harden command auto-approval against inline JS false positives (PR #11382 by @hannesrudolph)
+- Fix: Make tab close best-effort in DiffViewProvider.open (PR #11363 by @0xMink)
+- Fix: Canonicalize core.worktree comparison to prevent Windows path mismatch failures (PR #11346 by @0xMink)
+- Fix: Make removeClineFromStack() delegation-aware to prevent orphaned parent tasks (PR #11302 by @app/roomote)
+- Fix task resumption in the API module (PR #11369 by @cte)
+- Make defaultTemperature required in getModelParams to prevent silent temperature overrides (PR #11218 by @app/roomote)
+- Remove noisy console.warn logs from NativeToolCallParser (PR #11264 by @daniel-lxs)
+- Consolidate getState calls in resolveWebviewView (PR #11320 by @0xMink)
+- Clean up repo-facing mode rules (PR #11410 by @hannesrudolph)
+- Implement ModelMessage storage layer with AI SDK response messages (PR #11409 by @daniel-lxs)
+- Extract translation and merge resolver modes into reusable skills (PR #11215 by @app/roomote)
+- Add blog section with initial posts to roocode.com (PR #11127 by @app/roomote)
+- Replace Roomote Control with Linear Integration in cloud features grid (PR #11280 by @app/roomote)
+- Add IPC query handlers for commands, modes, and models (PR #11279 by @cte)
+- Add stdin stream mode for the CLI (PR #11476 by @cte)
+- Make CLI auto-approve by default with require-approval opt-in (PR #11424 by @cte)
+- Update CLI default model from Opus 4.5 to Opus 4.6 (PR #11273 by @app/roomote)
+- Add linux-arm64 support for the Roo CLI (PR #11314 by @cte)
+- CLI release: v0.0.51 (PR #11274 by @cte)
+- CLI release: v0.0.52 (PR #11324 by @cte)
+- CLI release: v0.0.53 (PR #11425 by @cte)
+- CLI release: v0.0.54 (PR #11477 by @cte)
+
+## [3.45.0] - 2026-01-27
+
+![3.45.0 Release - Smart Code Folding](/releases/3.45.0-release.png)
+
+- Smart Code Folding: Context condensation now intelligently preserves a lightweight map of files you worked on—function signatures, class declarations, and type definitions—so Roo can continue referencing them accurately after condensing. Files are prioritized by most recent access, with a ~50k character budget ensuring your latest work is always preserved. (Idea by @shariqriazz, PR #10942 by @hannesrudolph)
+
+## [3.44.2] - 2026-01-27
+
+- Re-enable parallel tool calling with new_task isolation safeguards (PR #11006 by @mrubens)
+- Fix worktree indexing by using relative paths in isPathInIgnoredDirectory (PR #11009 by @daniel-lxs)
+- Fix local model validation error for Ollama models (PR #10893 by @roomote)
+- Fix duplicate tool_call emission from Responses API providers (PR #11008 by @daniel-lxs)
+
+## [3.44.1] - 2026-01-27
+
+- Fix LiteLLM tool ID validation errors for Bedrock proxy (PR #10990 by @daniel-lxs)
+- Add temperature=0.9 and top_p=0.95 to zai-glm-4.7 model for better generation quality (PR #10945 by @sebastiand-cerebras)
+- Add quality checks to marketing site deployment workflows (PR #10959 by @mp-roocode)
+
+## [3.44.0] - 2026-01-26
+
+![3.44.0 Release - Worktrees](/releases/3.44.0-release.png)
+
+- Add worktree selector and creation UX (PR #10940 by @brunobergher, thanks Cline!)
+- Improve subtask visibility and navigation in history and chat views (PR #10864 by @brunobergher)
+- Add wildcard support for MCP alwaysAllow configuration (PR #10948 by @app/roomote)
+- Fix: Prevent nested condensing from including previously-condensed content (PR #10985 by @hannesrudolph)
+- Fix: VS Code LM token counting returns 0 outside requests, breaking context condensing (#10968 by @srulyt, PR #10983 by @daniel-lxs)
+- Fix: Record truncation event when condensation fails but truncation succeeds (PR #10984 by @hannesrudolph)
+- Replace hyphen encoding with fuzzy matching for MCP tool names (PR #10775 by @daniel-lxs)
+- Remove MCP SERVERS section from system prompt for cleaner prompts (PR #10895 by @daniel-lxs)
+- new_task tool creates checkpoint the same way write_to_file does (PR #10982 by @daniel-lxs)
+- Update Fireworks provider with new models (#10674 by @hannesrudolph, PR #10679 by @ThanhNguyxn)
+- Fix: Truncate AWS Bedrock toolUseId to 64 characters (PR #10902 by @daniel-lxs)
+- Fix: Restore opaque background to settings section headers (PR #10951 by @app/roomote)
+- Fix: Remove unsupported Fireworks model tool fields (PR #10937 by @app/roomote)
+- Update and improve zh-TW Traditional Chinese locale and docs (PR #10953 by @PeterDaveHello)
+- Chore: Remove POWER_STEERING experiment remnants (PR #10980 by @hannesrudolph)
+
+## [3.43.0] - 2026-01-23
+
+![3.43.0 Release - Intelligent Context Condensation](/releases/3.43.0-release.png)
+
+- Intelligent Context Condensation v2: New context condensation system that intelligently summarizes conversation history when approaching context limits, preserving important information while reducing token usage (PR #10873 by @hannesrudolph)
+- Improved context condensation with environment details, accurate token counts, and lazy evaluation for better performance (PR #10920 by @hannesrudolph)
+- Move condense prompt editor to Context Management tab for better discoverability and organization (PR #10909 by @hannesrudolph)
+- Update Z.AI models with new variants and pricing (#10859 by @ErdemGKSL, PR #10860 by @ErdemGKSL)
+- Add pnpm install:vsix:nightly command for easier nightly build installation (PR #10912 by @hannesrudolph)
+- Fix: Convert orphaned tool_results to text blocks after condensing to prevent API errors (PR #10927 by @daniel-lxs)
+- Fix: Auto-migrate v1 condensing prompt and handle invalid providers on import (PR #10931 by @hannesrudolph)
+- Fix: Use json-stream-stringify for pretty-printing MCP config files to prevent memory issues with large configs (#9862 by @Michaelzag, PR #9864 by @Michaelzag)
+- Fix: Correct Gemini 3 pricing for Flash and Pro models (#10432 by @rossdonald, PR #10487 by @roomote)
+- Fix: Skip thoughtSignature blocks during markdown export for cleaner output (#10199 by @rossdonald, PR #10932 by @rossdonald)
+- Fix: Duplicate model display for OpenAI Codex provider (PR #10930 by @roomote)
+- Remove diffEnabled and fuzzyMatchThreshold settings as they are no longer needed (#10648 by @hannesrudolph, PR #10298 by @hannesrudolph)
+- Remove MULTI_FILE_APPLY_DIFF experiment (PR #10925 by @hannesrudolph)
+- Remove POWER_STEERING experimental feature (PR #10926 by @hannesrudolph)
+- Remove legacy XML tool calling code (getToolDescription) for cleaner codebase (PR #10929 by @hannesrudolph)
+
+## [3.42.0] - 2026-01-22
+
+![3.42.0 Release - ChatGPT Usage Tracking](/releases/3.42.0-release.png)
+
+- Added UI to track your ChatGPT usage limits in the OpenAI Codex provider (PR #10813 by @hannesrudolph)
+- Removed deprecated Claude Code provider (PR #10883 by @daniel-lxs)
+- Streamlined codebase by removing legacy XML tool calling functionality (#10848 by @hannesrudolph, PR #10841 by @hannesrudolph)
+- Standardize model selectors across all providers: Improved consistency of model selection UI (#10650 by @hannesrudolph, PR #10294 by @hannesrudolph)
+- Enable prompt caching for Cerebras zai-glm-4.7 model (#10601 by @jahanson, PR #10670 by @app/roomote)
+- Add Kimi K2 thinking model to VertexAI provider (#9268 by @diwakar-s-maurya, PR #9269 by @app/roomote)
+- Warn users when too many MCP tools are enabled (PR #10772 by @app/roomote)
+- Migrate context condensing prompt to customSupportPrompts (PR #10881 by @hannesrudolph)
+- Unify export path logic and default to Downloads folder (PR #10882 by @hannesrudolph)
+- Performance improvements for webview state synchronization (PR #10842 by @hannesrudolph)
+- Fix: Handle mode selector empty state on workspace switch (#10660 by @hannesrudolph, PR #9674 by @app/roomote)
+- Fix: Resolve race condition in context condensing prompt input (PR #10876 by @hannesrudolph)
+- Fix: Prevent double emission of text/reasoning in OpenAI native and codex handlers (PR #10888 by @hannesrudolph)
+- Fix: Prevent task abortion when resuming via IPC/bridge (PR #10892 by @cte)
+- Fix: Enforce file restrictions for all editing tools (PR #10896 by @app/roomote)
+- Fix: Remove custom condensing model option (PR #10901 by @hannesrudolph)
+- Unify user content tags to <user_message> for consistent prompt formatting (#10658 by @hannesrudolph, PR #10723 by @app/roomote)
+- Clarify linked SKILL.md file handling in prompts (PR #10907 by @hannesrudolph)
+- Fix: Padding on Roo Code Cloud teaser (PR #10889 by @app/roomote)
+
+## [3.41.3] - 2026-01-18
+
+- Fix: Thinking block word-breaking to prevent horizontal scroll in the chat UI (PR #10806 by @roomote)
+- Add Claude-like CLI flags and authentication fixes for the Roo Code CLI (PR #10797 by @cte)
+- Improve CLI authentication by using a redirect instead of a fetch (PR #10799 by @cte)
+- Fix: Roo Code Router fixes for the CLI (PR #10789 by @cte)
+- Release CLI v0.0.48 with latest improvements (PR #10800 by @cte)
+- Release CLI v0.0.47 (PR #10798 by @cte)
+- Revert E2E tests enablement to address stability issues (PR #10794 by @cte)
+
+## [3.41.2] - 2026-01-16
+
+- Add button to open markdown in VSCode preview for easier reading of formatted content (PR #10773 by @brunobergher)
+- Fix: Reset invalid model selection when using OpenAI Codex provider (PR #10777 by @hannesrudolph)
+- Fix: Add openai-codex to providers that don't require an API key (PR #10786 by @roomote)
+- Fix: Detect Gemini models with space-separated names for proper thought signature injection in LiteLLM (PR #10787 by @daniel-lxs)
+
+## [3.41.1] - 2026-01-16
+
+![3.41.1 Release - Aggregated Subtask Costs](/releases/3.41.1-release.png)
+
+- Feat: Aggregate subtask costs in parent task (#5376 by @hannesrudolph, PR #10757 by @taltas)
+- Fix: Prevent duplicate tool_use IDs causing API 400 errors (PR #10760 by @daniel-lxs)
+- Fix: Handle missing tool identity in OpenAI Native streams (PR #10719 by @hannesrudolph)
+- Fix: Truncate call_id to 64 chars for OpenAI Responses API (PR #10763 by @daniel-lxs)
+- Fix: Gemini thought signature validation errors (PR #10694 by @daniel-lxs)
+- Fix: Filter out empty text blocks from user messages for Gemini compatibility (PR #10728 by @daniel-lxs)
+- Fix: Flatten top-level anyOf/oneOf/allOf in MCP tool schemas (PR #10726 by @daniel-lxs)
+- Fix: Filter Ollama models without native tool support (PR #10735 by @daniel-lxs)
+- Feat: Add settings tab titles to search index (PR #10761 by @roomote)
+- Feat: Clarify Slack and Linear are Cloud Team only features (PR #10748 by @roomote)
+
+## [3.41.0] - 2026-01-15
+
+![3.41.0 Release - OpenAI - ChatGPT Plus/Pro Provider](/releases/3.41.0-release.png)
+
+- Add OpenAI - ChatGPT Plus/Pro Provider that gives subscription-based access to Codex models without per-token costs (PR #10736 by @hannesrudolph)
+- Add gpt-5.2-codex model to openai-native provider, providing access to the latest GPT model with enhanced coding capabilities (PR #10731 by @hannesrudolph)
+- Fix: Clear terminal output buffers to prevent memory leaks that could cause gray screens and performance degradation (#10666, PR #7666 by @hannesrudolph)
+- Fix: Inject dummy thought signatures on ALL tool calls for Gemini models, resolving issues with Gemini tool call handling through LiteLLM (PR #10743 by @daniel-lxs)
+- Enable E2E tests with 39 passing tests, improving test coverage and reliability (PR #10720 by @ArchimedesCrypto)
+- Add alwaysAllow config for MCP time server tools in E2E tests (PR #10733 by @ArchimedesCrypto)
+
+## [3.40.1] - 2026-01-13
+
+- Fix: Add allowedFunctionNames support for Gemini to prevent mode switch errors (#10711 by @hannesrudolph, PR #10708 by @hannesrudolph)
+
+## [3.40.0] - 2026-01-13
+
+![3.40.0 Release - Settings Search](/releases/3.40.0-release.png)
+
+- Add settings search functionality to quickly find and navigate to specific settings (PR #10619 by @mrubens)
+- Improve settings search UI with better styling and usability (PR #10633 by @brunobergher)
+- Add standardized stop button for improved task cancellation visibility (PR #10639 by @brunobergher)
+- Display edit_file errors in UI after consecutive failures for better debugging feedback (PR #10581 by @daniel-lxs)
+- Improve error display styling and visibility in chat messages (PR #10692 by @brunobergher)
+- Improve stop button visibility and streamline error handling (PR #10696 by @brunobergher)
+- Fix: Omit parallel_tool_calls when not explicitly enabled to prevent API errors (#10553 by @Idlebrand, PR #10671 by @daniel-lxs)
+- Fix: Encode hyphens in MCP tool names before sanitization (#10642 by @pdecat, PR #10644 by @pdecat)
+- Fix: Correct Gemini 3 thought signature injection format via OpenRouter (PR #10640 by @daniel-lxs)
+- Fix: Sanitize tool_use IDs to match API validation pattern (PR #10649 by @daniel-lxs)
+- Fix: Use placeholder for empty tool result content to fix Gemini API validation (PR #10672 by @daniel-lxs)
+- Fix: Return empty string from getReadablePath when path is empty (PR #10638 by @daniel-lxs)
+- Optimize message block cloning in presentAssistantMessage for better performance (PR #10616 by @ArchimedesCrypto)
+
+## [3.39.3] - 2026-01-10
+
+![3.39.3 Release - Roo Code Router](/releases/3.39.3-release.png)
+
+- Rename Roo Code Cloud Provider to Roo Code Router for clearer branding (PR #10560 by @roomote)
+- Update Roo Code Router service name throughout the codebase (PR #10607 by @mrubens)
+- Update router name in types for consistency (PR #10605 by @mrubens)
+- Improve ExtensionHost code organization and cleanup (PR #10600 by @cte)
+- Add local installation option to CLI release script for testing (PR #10597 by @cte)
+- Reorganize CLI file structure for better maintainability (PR #10599 by @cte)
+- Add TUI to CLI (PR #10480 by @cte)
+
+## [3.39.2] - 2026-01-09
+
+- Fix: Ensure all tools have consistent strict mode values for Cerebras compatibility (#10334 by @brianboysen51, PR #10589 by @app/roomote)
+- Fix: Remove convertToSimpleMessages to restore tool calling for OpenAI-compatible providers (PR #10575 by @daniel-lxs)
+- Fix: Make edit_file matching more resilient to prevent false negatives (PR #10585 by @hannesrudolph)
+- Fix: Order text parts before tool calls in assistant messages for vscode-lm (PR #10573 by @daniel-lxs)
+- Fix: Ensure assistant message content is never undefined for Gemini compatibility (PR #10559 by @daniel-lxs)
+- Fix: Merge approval feedback into tool result instead of pushing duplicate messages (PR #10519 by @daniel-lxs)
+- Fix: Round-trip Gemini thought signatures for tool calls (PR #10590 by @hannesrudolph)
+- Feature: Improve error messaging for stream termination errors from provider (PR #10548 by @daniel-lxs)
+- Feature: Add debug setting to settings page for easier troubleshooting (PR #10580 by @hannesrudolph)
+- Chore: Disable edit_file tool for Gemini/Vertex providers (PR #10594 by @hannesrudolph)
+- Chore: Stop overriding tool allow/deny lists for Gemini (PR #10592 by @hannesrudolph)
+- Chore: Change default CLI model to anthropic/claude-opus-4.5 (PR #10544 by @mrubens)
+- Chore: Update Terms of Service effective January 9, 2026 (PR #10568 by @mrubens)
+- Chore: Move more types to @roo-code/types for CLI support (PR #10583 by @cte)
+- Chore: Add functionality to @roo-code/core for CLI support (PR #10584 by @cte)
+- Chore: Add slash commands useful for CLI development (PR #10586 by @cte)
+
+## [3.39.1] - 2026-01-08
+
+- Fix: Stabilize file paths during native tool call streaming to prevent path corruption (PR #10555 by @daniel-lxs)
+- Fix: Disable Gemini thought signature persistence to prevent corrupted signature errors (PR #10554 by @daniel-lxs)
+- Fix: Change minItems from 2 to 1 for Anthropic API compatibility (PR #10551 by @daniel-lxs)
+
+## [3.39.0] - 2026-01-08
+
+![3.39.0 Release - Kangaroo go BRRR](/releases/3.39.0-release.png)
+
+- Implement sticky provider profile for task-level API config persistence (#8010 by @hannesrudolph, PR #10018 by @hannesrudolph)
+- Add support for image file @mentions (PR #10189 by @hannesrudolph)
+- Rename YOLO to BRRR (#8574 by @mojomast, PR #10507 by @roomote)
+- Add debug-mode proxy routing for debugging API calls (#7042 by @SleeperSmith, PR #10467 by @hannesrudolph)
+- Add Kimi K2 thinking model to Fireworks AI provider (#9201 by @kavehsfv, PR #9202 by @roomote)
+- Add xhigh reasoning effort to OpenAI compatible endpoints (#10060 by @Soorma718, PR #10061 by @roomote)
+- Filter @ mention file search results using .rooignore (#10169 by @jerrill-johnson-bitwerx, PR #10174 by @roomote)
+- Add image support documentation to read_file native tool description (#10440 by @nabilfreeman, PR #10442 by @roomote)
+- Add zai-glm-4.7 to Cerebras models (PR #10500 by @sebastiand-cerebras)
+- VSCode shim and basic CLI for running Roo Code headlessly (PR #10452 by @cte)
+- Add CLI installer for headless Roo Code (PR #10474 by @cte)
+- Add option to use CLI for evals (PR #10456 by @cte)
+- Remember last Roo model selection in web-evals and add evals skill (PR #10470 by @hannesrudolph)
+- Tweak the style of follow up suggestion modes (PR #9260 by @mrubens)
+- Fix: Handle PowerShell ENOENT error in os-name on Windows (#9859 by @Yang-strive, PR #9897 by @roomote)
+- Fix: Make command chaining examples shell-aware for Windows compatibility (#10352 by @AlexNek, PR #10434 by @roomote)
+- Fix: Preserve tool_use blocks for all tool_results in kept messages during condensation (PR #10471 by @daniel-lxs)
+- Fix: Add additionalProperties: false to MCP tool schemas for OpenAI Responses API (PR #10472 by @daniel-lxs)
+- Fix: Prevent duplicate tool_result blocks causing API errors (PR #10497 by @daniel-lxs)
+- Fix: Add explicit deduplication for duplicate tool_result blocks (#10465 by @nabilfreeman, PR #10466 by @roomote)
+- Fix: Use task stored API config as fallback for rate limit (PR #10266 by @roomote)
+- Fix: Remove legacy Claude 2 series models from Bedrock provider (#9220 by @KevinZhao, PR #10501 by @roomote)
+- Fix: Add missing description fields for debugProxy configuration (PR #10505 by @roomote)
+- Fix: Glitchy kangaroo bounce animation on welcome screen (PR #10035 by @objectiveSee)
+
+## [3.38.3] - 2026-01-03
+
+- Feat: Add option in Context settings to recursively load `.roo/rules` and `AGENTS.md` from subdirectories (PR #10446 by @mrubens)
+- Fix: Stop frequent Claude Code sign-ins by hardening OAuth refresh token handling (PR #10410 by @hannesrudolph)
+- Fix: Add `maxConcurrentFileReads` limit to native `read_file` tool schema (PR #10449 by @app/roomote)
+- Fix: Add type check for `lastMessage.text` in TTS useEffect to prevent runtime errors (PR #10431 by @app/roomote)
+
+## [3.38.2] - 2025-12-31
+
+![3.38.2 Release - Skill Alignment](/releases/3.38.2-release.png)
+
+- Align skills system with Agent Skills specification (PR #10409 by @hannesrudolph)
+- Prevent write_to_file from creating files at truncated paths (PR #10415 by @mrubens and @daniel-lxs)
+- Update Cerebras maxTokens to 16384 (PR #10387 by @sebastiand-cerebras)
+- Fix rate limit wait display (PR #10389 by @hannesrudolph)
+- Remove human-relay provider (PR #10388 by @hannesrudolph)
+- Replace Todo Lists video with Context Management video in documentation (PR #10375 by @SannidhyaSah)
+
+## [3.38.1] - 2025-12-29
+
+![3.38.1 Release - Bug Fixes and Stability](/releases/3.38.1-release.png)
+
+- Fix: Flush pending tool results before condensing context (PR #10379 by @daniel-lxs)
+- Fix: Revert mergeToolResultText for OpenAI-compatible providers (PR #10381 by @hannesrudolph)
+- Fix: Enforce maxConcurrentFileReads limit in read_file tool (PR #10363 by @roomote)
+- Fix: Improve feedback message when read_file is used on a directory (PR #10371 by @roomote)
+- Fix: Handle custom tool use similarly to MCP tools for IPC schema purposes (PR #10364 by @jr)
+- Fix: Correct GitHub repository URL in marketing page (#10376 by @jishnuteegala, PR #10377 by @roomote)
+- Docs: Clarify path to Security Settings in privacy policy (PR #10367 by @roomote)
+
+## [3.38.0] - 2025-12-27
+
+![3.38.0 Release - Skills](/releases/3.38.0-release.png)
+
+- Add support for [Agent Skills](https://agentskills.io/), enabling reusable packages of prompts, tools, and resources to extend Roo's capabilities (PR #10335 by @mrubens)
+- Add optional mode field to slash command front matter, allowing commands to automatically switch to a specific mode when triggered (PR #10344 by @app/roomote)
+- Add support for npm packages and .env files to custom tools, allowing custom tools to import dependencies and access environment variables (PR #10336 by @cte)
+- Remove simpleReadFileTool feature, streamlining the file reading experience (PR #10254 by @app/roomote)
+- Remove OpenRouter Transforms feature (PR #10341 by @app/roomote)
+- Fix mergeToolResultText handling in Roo provider (PR #10359 by @mrubens)
+
+## [3.37.1] - 2025-12-23
+
+![3.37.1 Release - Tool Fixes and Provider Improvements](/releases/3.37.1-release.png)
+
+- Fix: Send native tool definitions by default for OpenAI to ensure proper tool usage (PR #10314 by @hannesrudolph)
+- Fix: Preserve reasoning_details shape to prevent malformed responses when processing model output (PR #10313 by @hannesrudolph)
+- Fix: Drain queued messages while waiting for ask to prevent message loss (PR #10315 by @hannesrudolph)
+- Feat: Add grace retry for empty assistant messages to improve reliability (PR #10297 by @hannesrudolph)
+- Feat: Enable mergeToolResultText for all OpenAI-compatible providers for better tool result handling (PR #10299 by @hannesrudolph)
+- Feat: Enable mergeToolResultText for Roo Code Router (PR #10301 by @hannesrudolph)
+- Feat: Strengthen native tool-use guidance in prompts for improved model behavior (PR #10311 by @hannesrudolph)
+- UX: Account-centric signup flow for improved onboarding experience (PR #10306 by @brunobergher)
+
+## [3.37.0] - 2025-12-22
+
+![3.37.0 Release - Custom Tool Calling](/releases/3.37.0-release.png)
+
+- Add MiniMax M2.1 and improve environment_details handling for Minimax thinking models (PR #10284 by @hannesrudolph)
+- Add GLM-4.7 model with thinking mode support for Zai provider (PR #10282 by @hannesrudolph)
+- Add experimental custom tool calling - define custom tools that integrate seamlessly with your AI workflow (PR #10083 by @cte)
+- Deprecate XML tool protocol selection and force native tool format for new tasks (PR #10281 by @daniel-lxs)
+- Fix: Emit tool_call_end events in OpenAI handler when streaming ends (#10275 by @torxeon, PR #10280 by @daniel-lxs)
+- Fix: Emit tool_call_end events in BaseOpenAiCompatibleProvider (PR #10293 by @hannesrudolph)
+- Fix: Disable strict mode for MCP tools to preserve optional parameters (PR #10220 by @daniel-lxs)
+- Fix: Move array-specific properties into anyOf variant in normalizeToolSchema (PR #10276 by @daniel-lxs)
+- Fix: Add CRLF line ending normalization to search_replace and search_and_replace tools (PR #10288 by @hannesrudolph)
+- Fix: Add graceful fallback for model parsing in Chutes provider (PR #10279 by @hannesrudolph)
+- Fix: Enable Requesty refresh models with credentials (PR #10273 by @daniel-lxs)
+- Fix: Improve reasoning_details accumulation and serialization (PR #10285 by @hannesrudolph)
+- Fix: Preserve reasoning_content in condense summary for DeepSeek-reasoner (PR #10292 by @hannesrudolph)
+- Refactor Zai provider to merge environment_details into tool result instead of system message (PR #10289 by @hannesrudolph)
+- Remove parallel_tool_calls parameter from litellm provider (PR #10274 by @roomote)
+- Add Cloud Team page with comprehensive team management features (PR #10267 by @roomote)
+- Add message log deduper utility for evals (PR #10286 by @hannesrudolph)
+
+## [3.36.16] - 2025-12-19
+
+- Fix: Normalize tool schemas for VS Code LM API to resolve error 400 when using VS Code Language Model API providers (PR #10221 by @hannesrudolph)
+
+## [3.36.15] - 2025-12-19
+
+![3.36.15 Release - 1M Context Window Support](/releases/3.36.15-release.png)
+
+- Add 1M context window beta support for Claude Sonnet 4 on Vertex AI, enabling significantly larger context for complex tasks (PR #10209 by @hannesrudolph)
+- Add native tool calling support for LM Studio and Qwen-Code providers, improving compatibility with local models (PR #10208 by @hannesrudolph)
+- Add native tool call defaults for OpenAI-compatible providers, expanding native function calling across more configurations (PR #10213 by @hannesrudolph)
+- Enable native tool calls for Requesty provider (PR #10211 by @daniel-lxs)
+- Improve API error handling and visibility with clearer error messages and better user feedback (PR #10204 by @brunobergher)
+- Add downloadable error diagnostics from chat errors, making it easier to troubleshoot and report issues (PR #10188 by @brunobergher)
+- Fix refresh models button not properly flushing the cache, ensuring model lists update correctly (#9682 by @tl-hbk, PR #9870 by @pdecat)
+- Fix additionalProperties handling for strict mode compatibility, resolving schema validation issues with certain providers (PR #10210 by @daniel-lxs)
+
+## [3.36.14] - 2025-12-18
+
+![3.36.14 Release - Native Tool Calling for Claude on Vertex AI](/releases/3.36.14-release.png)
+
+- Add native tool calling support for Claude models on Vertex AI, enabling more efficient and reliable tool interactions (PR #10197 by @hannesrudolph)
+- Fix JSON Schema format value stripping for OpenAI compatibility, resolving issues with unsupported format values (PR #10198 by @daniel-lxs)
+- Improve "no tools used" error handling with graceful retry mechanism for better reliability when tools fail to execute (PR #10196 by @hannesrudolph)
+
+## [3.36.13] - 2025-12-18
+
+![3.36.13 Release - Native Tool Protocol](/releases/3.36.13-release.png)
+
+- Change default tool protocol from XML to native for improved reliability and performance (PR #10186 by @mrubens)
+- Add native tool support for VS Code Language Model API providers (PR #10191 by @daniel-lxs)
+- Lock task tool protocol for consistent task resumption, ensuring tasks resume with the same protocol they started with (PR #10192 by @daniel-lxs)
+- Replace edit_file tool alias with actual edit_file tool for improved diff editing capabilities (PR #9983 by @hannesrudolph)
+- Fix LiteLLM router models by merging default model info for native tool calling support (PR #10187 by @daniel-lxs)
+- Add PostHog exception tracking for consecutive mistake errors to improve error monitoring (PR #10193 by @daniel-lxs)
+
+## [3.36.12] - 2025-12-18
+
+![3.36.12 Release - Better telemetry and Bedrock fixes](/releases/3.36.12-release.png)
+
+- Fix: Add userAgentAppId to Bedrock embedder for code indexing (#10165 by @jackrein, PR #10166 by @roomote)
+- Update OpenAI and Gemini tool preferences for improved model behavior (PR #10170 by @hannesrudolph)
+- Extract error messages from JSON payloads for better PostHog error grouping (PR #10163 by @daniel-lxs)
+
+## [3.36.11] - 2025-12-17
+
+![3.36.11 Release - Native Tool Calling Enhancements](/releases/3.36.11-release.png)
+
+- Add support for Claude Code Provider native tool calling, improving tool execution performance and reliability (PR #10077 by @hannesrudolph)
+- Enable native tool calling by default for Z.ai models for better model compatibility (PR #10158 by @app/roomote)
+- Enable native tools by default for OpenAI compatible provider to improve tool calling support (PR #10159 by @daniel-lxs)
+- Fix: Normalize MCP tool schemas for Bedrock and OpenAI strict mode to ensure proper tool compatibility (PR #10148 by @daniel-lxs)
+- Fix: Remove dots and colons from MCP tool names for Bedrock compatibility (PR #10152 by @daniel-lxs)
+- Fix: Convert tool_result to XML text when native tools disabled for Bedrock (PR #10155 by @daniel-lxs)
+- Fix: Refresh Roo models cache with session token on auth state change to resolve model list refresh issues (PR #10156 by @daniel-lxs)
+- Fix: Support AWS GovCloud and China region ARNs in Bedrock provider for expanded regional support (PR #10157 by @app/roomote)
+
+## [3.36.10] - 2025-12-17
+
+![3.36.10 Release - Gemini 3 Flash Preview](/releases/3.36.10-release.png)
+
+- Add support for Gemini 3 Flash Preview model in the Gemini provider (PR #10151 by @hannesrudolph)
+- Implement interleaved thinking mode for DeepSeek Reasoner, enabling streaming reasoning output (PR #9969 by @hannesrudolph)
+- Fix: Preserve reasoning_content during tool call sequences in DeepSeek (PR #10141 by @hannesrudolph)
+- Fix: Correct token counting for context truncation display (PR #9961 by @hannesrudolph)
+- Update Next.js dependency to ~15.2.8 (PR #10140 by @jr)
+
+## [3.36.9] - 2025-12-15
+
+![3.36.9 Release - Cross-Provider Compatibility](/releases/3.36.9-release.png)
+
+- Fix: Normalize tool call IDs for cross-provider compatibility via OpenRouter, ensuring consistent handling across different AI providers (PR #10102 by @daniel-lxs)
+- Fix: Add additionalProperties: false to nested MCP tool schemas, improving schema validation and preventing unexpected properties (PR #10109 by @daniel-lxs)
+- Fix: Validate tool_result IDs in delegation resume flow, preventing errors when resuming delegated tasks (PR #10135 by @daniel-lxs)
+- Feat: Add full error details to streaming failure dialog, providing more comprehensive information for debugging streaming issues (PR #10131 by @roomote)
+- Feat: Improve evals UI with tool groups and duration fix, enhancing the evaluation interface organization and timing accuracy (PR #10133 by @hannesrudolph)
+
+## [3.36.8] - 2025-12-16
+
+![3.36.8 Release - Native Tools Enabled by Default](/releases/3.36.8-release.png)
+
+- Implement incremental token-budgeted file reading for smarter, more efficient file content retrieval (PR #10052 by @jr)
+- Enable native tools by default for multiple providers including OpenAI, Azure, Google, Vertex, and more (PR #10059 by @daniel-lxs)
+- Enable native tools by default for Anthropic and add telemetry tracking for tool format usage (PR #10021 by @daniel-lxs)
+- Fix: Prevent race condition from deleting wrong API messages during streaming (PR #10113 by @hannesrudolph)
+- Fix: Prevent duplicate MCP tools error by deduplicating servers at source (PR #10096 by @daniel-lxs)
+- Remove strict ARN validation for Bedrock custom ARN users allowing more flexibility (#10108 by @wisestmumbler, PR #10110 by @roomote)
+- Add metadata to error details dialog for improved debugging (PR #10050 by @roomote)
+- Add configuration to control public sharing feature (PR #10105 by @mrubens)
+- Remove description from Bedrock service tiers for cleaner UI (PR #10118 by @mrubens)
+- Fix: Correct link to provider pricing page on web (PR #10107 by @brunobergher)
+
+## [3.36.7] - 2025-12-15
+
+- Improve tool configuration for OpenAI models in OpenRouter (PR #10082 by @hannesrudolph)
+- Capture more detailed provider-specific error information from OpenRouter for better debugging (PR #10073 by @jr)
+- Add Amazon Nova 2 Lite model to Bedrock provider (#9802 by @Smartsheet-JB-Brown, PR #9830 by @roomote)
+- Add AWS Bedrock service tier support (#9874 by @Smartsheet-JB-Brown, PR #9955 by @roomote)
+- Remove auto-approve toggles for to-do and retry actions to simplify the approval workflow (PR #10062 by @hannesrudolph)
+- Move isToolAllowedForMode out of shared directory for better code organization (PR #10089 by @cte)
+- Improve run logs and formatters in web-evals for better evaluation tracking (PR #10081 by @hannesrudolph)
+
+## [3.36.6] - 2025-12-12
+
+![3.36.6 Release - Tool Alias Support](/releases/3.36.6-release.png)
+
+- Add tool alias support for model-specific tool customization, allowing users to configure how tools are presented to different AI models (PR #9989 by @daniel-lxs)
+- Sanitize MCP server and tool names for API compatibility, ensuring special characters don't cause issues with API calls (PR #10054 by @daniel-lxs)
+- Improve auto-approve timer visibility in follow-up suggestions for better user awareness of pending actions (PR #10048 by @brunobergher)
+- Fix: Cancel auto-approval timeout when user starts typing, preventing accidental auto-approvals during user interaction (PR #9937 by @roomote)
+- Add WorkspaceTaskVisibility type for organization cloud settings to support team visibility controls (PR #10020 by @roomote)
+- Fix: Extract raw error message from OpenRouter metadata for clearer error reporting (PR #10039 by @daniel-lxs)
+- Fix: Show tool protocol dropdown for LiteLLM provider, restoring missing configuration option (PR #10053 by @daniel-lxs)
+
+## [3.36.5] - 2025-12-11
+
+![3.36.5 Release - GPT-5.2](/releases/3.36.5-release.png)
+
+- Add: GPT-5.2 model to openai-native provider (PR #10024 by @hannesrudolph)
+- Add: Toggle for Enter key behavior in chat input allowing users to configure whether Enter sends or creates new line (#8555 by @lmtr0, PR #10002 by @hannesrudolph)
+- Add: App version to telemetry exception captures and filter 402 errors (PR #9996 by @daniel-lxs)
+- Fix: Handle empty Gemini responses and reasoning loops to prevent infinite retries (PR #10007 by @hannesrudolph)
+- Fix: Add missing tool_result blocks to prevent API errors when tool results are expected (PR #10015 by @daniel-lxs)
+- Fix: Filter orphaned tool_results when more results than tool_uses to prevent message validation errors (PR #10027 by @daniel-lxs)
+- Fix: Add general API endpoints for Z.ai provider (#9879 by @richtong, PR #9894 by @roomote)
+- Fix: Apply versioned settings on nightly builds (PR #9997 by @hannesrudolph)
+- Remove: Glama provider (PR #9801 by @hannesrudolph)
+- Remove: Deprecated list_code_definition_names tool (PR #10005 by @hannesrudolph)
+
+## [3.36.4] - 2025-12-10
+
+![3.36.4 Release - Error Details Modal](/releases/3.36.4-release.png)
+
+- Add error details modal with on-demand display for improved error visibility when debugging issues (PR #9985 by @roomote)
+- Fix: Prevent premature rawChunkTracker clearing for MCP tools, improving reliability of MCP tool streaming (PR #9993 by @daniel-lxs)
+- Fix: Filter out 429 rate limit errors from API error telemetry for cleaner metrics (PR #9987 by @daniel-lxs)
+- Fix: Correct TODO list display order in chat view to show items in proper sequence (PR #9991 by @roomote)
+
+## [3.36.3] - 2025-12-09
+
+![3.36.3 Release](/releases/3.36.3-release.png)
+
+- Refactor: Unified context-management architecture with improved UX for better context control (PR #9795 by @hannesrudolph)
+- Add new `search_replace` native tool for single-replacement operations with improved editing precision (PR #9918 by @hannesrudolph)
+- Streaming tool stats and token usage throttling for better real-time feedback during generation (PR #9926 by @hannesrudolph)
+- Add versioned settings support with minPluginVersion gating for Roo provider (PR #9934 by @hannesrudolph)
+- Make Architect mode save plans to `/plans` directory and gitignore it (PR #9944 by @brunobergher)
+- Add announcement support CTA and social icons to UI (PR #9945 by @hannesrudolph)
+- Add ability to save screenshots from the browser tool (PR #9963 by @mrubens)
+- Refactor: Decouple tools from system prompt for cleaner architecture (PR #9784 by @daniel-lxs)
+- Update DeepSeek models to V3.2 with new pricing (PR #9962 by @hannesrudolph)
+- Add minimal and medium reasoning effort levels for Gemini models (PR #9973 by @hannesrudolph)
+- Update xAI models catalog with latest model options (PR #9872 by @hannesrudolph)
+- Add DeepSeek V3-2 support for Baseten provider (PR #9861 by @AlexKer)
+- Tweaks to Baseten model definitions for better defaults (PR #9866 by @mrubens)
+- Fix: Add xhigh reasoning effort support for gpt-5.1-codex-max (#9891 by @andrewginns, PR #9900 by @andrewginns)
+- Fix: Add Kimi, MiniMax, and Qwen model configurations for Bedrock (#9902 by @jbearak, PR #9905 by @app/roomote)
+- Configure tool preferences for xAI models (PR #9923 by @hannesrudolph)
+- Default to using native tools when supported on OpenRouter (PR #9878 by @mrubens)
+- Fix: Exclude apply_diff from native tools when diffEnabled is false (#9919 by @denis-kudelin, PR #9920 by @app/roomote)
+- Fix: Always show tool protocol selector for openai-compatible provider (#9965 by @bozoweed, PR #9966 by @hannesrudolph)
+- Fix: Respect explicit supportsReasoningEffort array values for proper model configuration (PR #9970 by @hannesrudolph)
+- Add timeout configuration to OpenAI Compatible Provider Client (PR #9898 by @dcbartlett)
+- Revert default tool protocol change from xml to native for stability (PR #9956 by @mrubens)
+- Remove defaultTemperature from Roo provider configuration (PR #9932 by @mrubens)
+- Improve OpenAI error messages to be more useful for debugging (PR #9639 by @mrubens)
+- Better error logs for parseToolCall exceptions (PR #9857 by @cte)
+- Improve cloud job error logging for RCC provider errors (PR #9924 by @cte)
+- Fix: Display actual API error message instead of generic text on retry (PR #9954 by @hannesrudolph)
+- Add API error telemetry to OpenRouter provider for better diagnostics (PR #9953 by @daniel-lxs)
+- Fix: Sanitize removed/invalid API providers to prevent infinite loop (PR #9869 by @hannesrudolph)
+- Fix: Use foreground color for context-management icons (PR #9912 by @hannesrudolph)
+- Fix: Suppress 'ask promise was ignored' error in handleError (PR #9914 by @daniel-lxs)
+- Fix: Process finish_reason to emit tool_call_end events properly (PR #9927 by @daniel-lxs)
+- Fix: Add finish_reason processing to xai.ts provider (PR #9929 by @daniel-lxs)
+- Fix: Validate and fix tool_result IDs before API requests (PR #9952 by @daniel-lxs)
+- Fix: Return undefined instead of 0 for disabled API timeout (PR #9960 by @hannesrudolph)
+- Stop making unnecessary count_tokens requests for better performance (PR #9884 by @mrubens)
+- Refactor: Consolidate ThinkingBudget components and fix disable handling (PR #9930 by @hannesrudolph)
+- Forbid time estimates in architect mode for more focused planning (PR #9931 by @app/roomote)
+- Web: Add product pages (PR #9865 by @brunobergher)
+- Make eval runs deletable in the web UI (PR #9909 by @mrubens)
+- Feat: Change defaultToolProtocol default from xml to native (later reverted) (PR #9892 by @app/roomote)
+
+## [3.36.2] - 2025-12-04
+
+![3.36.2 Release - Dynamic API Settings](/releases/3.36.2-release.png)
+
+- Restrict GPT-5 tool set to apply_patch for improved compatibility (PR #9853 by @hannesrudolph)
+- Add dynamic settings support for Roo models from API, allowing model-specific configurations to be fetched dynamically (PR #9852 by @hannesrudolph)
+- Fix: Resolve Chutes provider model fetching issue (PR #9854 by @cte)
+
+## [3.36.1] - 2025-12-04
+
+![3.36.1 Release - Message Management & Stability Improvements](/releases/3.36.1-release.png)
+
+- Add MessageManager layer for centralized history coordination, fixing message synchronization issues (PR #9842 by @hannesrudolph)
+- Fix: Prevent cascading truncation loop by only truncating visible messages (PR #9844 by @hannesrudolph)
+- Fix: Handle unknown/invalid native tool calls to prevent extension freeze (PR #9834 by @daniel-lxs)
+- Always enable reasoning for models that require it (PR #9836 by @cte)
+- ChatView: Smoother stick-to-bottom behavior during streaming (PR #8999 by @hannesrudolph)
+- UX: Improved error messages and documentation links (PR #9777 by @brunobergher)
+- Fix: Overly round follow-up question suggestions styling (PR #9829 by @brunobergher)
+- Add symlink support for slash commands in .roo/commands folder (PR #9838 by @mrubens)
+- Ignore input to the execa terminal process for safer command execution (PR #9827 by @mrubens)
+- Be safer about large file reads (PR #9843 by @jr)
+- Add gpt-5.1-codex-max model to OpenAI provider (PR #9848 by @hannesrudolph)
+- Evals UI: Add filtering, bulk delete, tool consolidation, and run notes (PR #9837 by @hannesrudolph)
+- Evals UI: Add multi-model launch and UI improvements (PR #9845 by @hannesrudolph)
+- Web: New pricing page (PR #9821 by @brunobergher)
+
+## [3.36.0] - 2025-12-04
+
+![3.36.0 Release - Rewind Kangaroo](/releases/3.36.0-release.png)
+
+- Fix: Restore context when rewinding after condense (#8295 by @hannesrudolph, PR #9665 by @hannesrudolph)
+- Add reasoning_details support to Roo provider for enhanced model reasoning visibility (PR #9796 by @app/roomote)
+- Default to native tools for all models in the Roo provider for improved performance (PR #9811 by @mrubens)
+- Enable search_and_replace for Minimax models (PR #9780 by @mrubens)
+- Fix: Resolve Vercel AI Gateway model fetching issues (PR #9791 by @cte)
+- Fix: Apply conservative max tokens for Cerebras provider (PR #9804 by @sebastiand-cerebras)
+- Fix: Remove omission detection logic to eliminate false positives (#9785 by @Michaelzag, PR #9787 by @app/roomote)
+- Refactor: Remove deprecated insert_content tool (PR #9751 by @daniel-lxs)
+- Chore: Hide parallel tool calls experiment and disable feature (PR #9798 by @hannesrudolph)
+- Update next.js documentation site dependencies (PR #9799 by @jr)
+- Fix: Correct download count display on homepage (PR #9807 by @mrubens)
+
+## [3.35.5] - 2025-12-03
+
+- Feat: Add provider routing selection for OpenRouter embeddings (#9144 by @SannidhyaSah, PR #9693 by @SannidhyaSah)
+- Default Minimax M2 to native tool calling (PR #9778 by @mrubens)
+- Sanitize the native tool calls to fix a bug with Gemini (PR #9769 by @mrubens)
+- UX: Updates to CloudView (PR #9776 by @roomote)
+
+## [3.35.4] - 2025-12-02
+
+- Fix: Handle malformed native tool calls to prevent hanging (PR #9758 by @daniel-lxs)
+- Fix: Remove reasoning toggles for GLM-4.5 and GLM-4.6 on z.ai provider (PR #9752 by @roomote)
+- Refactor: Remove line_count parameter from write_to_file tool (PR #9667 by @hannesrudolph)
+
+## [3.35.3] - 2025-12-02
+
+- Switch to new welcome view for improved onboarding experience (PR #9741 by @mrubens)
+- Update homepage with latest changes (PR #9675 by @brunobergher)
+- Improve privacy for stealth models by adding vendor confidentiality section to system prompt (PR #9742 by @mrubens)
+
 ## [3.35.2] - 2025-12-01
 
 ![3.35.2 Release - Model Default Temperatures](/releases/3.35.2-release.png)
@@ -22,7 +754,7 @@
 - Native tool calling support expanded across many providers: Bedrock (PR #9698 by @mrubens), Cerebras (PR #9692 by @mrubens), Chutes with auto-detection from API (PR #9715 by @daniel-lxs), DeepInfra (PR #9691 by @mrubens), DeepSeek and Doubao (PR #9671 by @daniel-lxs), Groq (PR #9673 by @daniel-lxs), LiteLLM (PR #9719 by @daniel-lxs), Ollama (PR #9696 by @mrubens), OpenAI-compatible providers (PR #9676 by @daniel-lxs), Requesty (PR #9672 by @daniel-lxs), Unbound (PR #9699 by @mrubens), Vercel AI Gateway (PR #9697 by @mrubens), Vertex Gemini (PR #9678 by @daniel-lxs), and xAI with new Grok 4 Fast and Grok 4.1 Fast models (PR #9690 by @mrubens)
 - Fix: Preserve tool_use blocks in summary for parallel tool calls (#9700 by @SilentFlower, PR #9714 by @SilentFlower)
 - Default Grok Code Fast to native tools for better performance (PR #9717 by @mrubens)
-- UX improvements to the Roo Code Cloud provider-centric onboarding flow (PR #9709 by @brunobergher)
+- UX improvements to the Roo Code Router-centric onboarding flow (PR #9709 by @brunobergher)
 - UX toolbar cleanup and settings consolidation for a cleaner interface (PR #9710 by @brunobergher)
 - Add model-specific tool customization via `excludedTools` and `includedTools` configuration (PR #9641 by @daniel-lxs)
 - Add new `apply_patch` native tool for more efficient file editing operations (PR #9663 by @hannesrudolph)
@@ -121,7 +853,7 @@
 - Show the prompt for image generation in the UI (PR #9505 by @mrubens)
 - Fix double todo list display issue (PR #9517 by @mrubens)
 - Add tracking for cloud synced messages (PR #9518 by @mrubens)
-- Enable the Roo Code Cloud provider in evals (PR #9492 by @cte)
+- Enable the Roo Code Router in evals (PR #9492 by @cte)
 
 ## [3.34.0] - 2025-11-21
 
@@ -181,7 +913,7 @@
 
 ## [3.33.0] - 2025-11-18
 
-![v3.33.0 Release - Twin Kangaroos and the Gemini Constellation](/releases/v3.33.0-release.png)
+![3.33.0 Release - Twin Kangaroos and the Gemini Constellation](/releases/3.33.0-release.png)
 
 - Add Gemini 3 Pro Preview model (PR #9357 by @hannesrudolph)
 - Improve Google Gemini defaults with better temperature and cost reporting (PR #9327 by @hannesrudolph)
@@ -201,7 +933,7 @@
 - Use VSCode theme color for outline button borders (PR #9336 by @app/roomote)
 - Replace broken badgen.net badges with shields.io (PR #9318 by @app/roomote)
 - Add max git status files setting to evals (PR #9322 by @mrubens)
-- Roo Code Cloud Provider pricing page and changes elsewhere (PR #9195 by @brunobergher)
+- Roo Code Router pricing page and changes elsewhere (PR #9195 by @brunobergher)
 
 ## [3.32.1] - 2025-11-14
 
@@ -227,7 +959,7 @@
 ![3.31.3 Release - Kangaroo Decrypting a Message](/releases/3.31.3-release.png)
 
 - Fix: OpenAI Native encrypted_content handling and remove gpt-5-chat-latest verbosity flag (#9225 by @politsin, PR by @hannesrudolph)
-- Fix: Roo Code Cloud provider Anthropic input token normalization to avoid double-counting (thanks @hannesrudolph!)
+- Fix: Roo Code Router Anthropic input token normalization to avoid double-counting (thanks @hannesrudolph!)
 - Refactor: Rename sliding-window to context-management and truncateConversationIfNeeded to manageContext (thanks @hannesrudolph!)
 
 ## [3.31.2] - 2025-11-12
@@ -367,7 +1099,7 @@
 
 - Add token-budget based file reading with intelligent preview to avoid context overruns (thanks @daniel-lxs!)
 - Enable browser-use tool for all image-capable models (#8116 by @hannesrudolph, PR by @app/roomote!)
-- Add dynamic model loading for Roo Code Cloud provider (thanks @app/roomote!)
+- Add dynamic model loading for Roo Code Router (thanks @app/roomote!)
 - Fix: Respect nested .gitignore files in search_files (#7921 by @hannesrudolph, PR by @daniel-lxs)
 - Fix: Preserve trailing newlines in stripLineNumbers for apply_diff (#8020 by @liyi3c, PR by @app/roomote)
 - Fix: Exclude max tokens field for models that don't support it in export (#7944 by @hannesrudolph, PR by @elianiva)
@@ -525,7 +1257,7 @@
 - UX: Responsive Auto-Approve (thanks @brunobergher!)
 - Add telemetry retry queue for network resilience (thanks @daniel-lxs!)
 - Fix: Transform keybindings in nightly build to fix command+y shortcut (thanks @app/roomote!)
-- New code-supernova stealth model in the Roo Code Cloud provider (thanks @mrubens!)
+- New code-supernova stealth model in the Roo Code Router (thanks @mrubens!)
 
 ## [3.28.3] - 2025-09-16
 
@@ -542,7 +1274,6 @@
 - Reposition Add Image button inside ChatTextArea (thanks @roomote!)
 - Bring back a way to temporarily and globally pause auto-approve without losing your toggle state (thanks @brunobergher!)
 - Makes text area buttons appear only when there's text (thanks @brunobergher!)
-- CONTRIBUTING.md tweaks and issue template rewrite (thanks @hannesrudolph!)
 - Bump axios from 1.9.0 to 1.12.0 (thanks @dependabot!)
 
 ## [3.28.2] - 2025-09-14
@@ -736,11 +1467,11 @@
 
 ## [3.25.19] - 2025-08-19
 
-- Fix issue where new users couldn't select the Roo Code Cloud provider (thanks @daniel-lxs!)
+- Fix issue where new users couldn't select the Roo Code Router (thanks @daniel-lxs!)
 
 ## [3.25.18] - 2025-08-19
 
-- Add new stealth Sonic model through the Roo Code Cloud provider
+- Add new stealth Sonic model through the Roo Code Router
 - Fix: respect enableReasoningEffort setting when determining reasoning usage (#7048 by @ikbencasdoei, PR by @app/roomote)
 - Fix: prevent duplicate LM Studio models with case-insensitive deduplication (#6954 by @fbuechler, PR by @daniel-lxs)
 - Feat: simplify ask_followup_question prompt documentation (thanks @daniel-lxs!)
@@ -983,7 +1714,7 @@
 - Add: Mistral embedding provider (thanks @SannidhyaSah!)
 - Fix: add run parameter to vitest command in rules (thanks @KJ7LNW!)
 - Update: the max_tokens fallback logic in the sliding window
-- Fix: Bedrock and Vertext token counting improvements (thanks @daniel-lxs!)
+- Fix: Bedrock and Vertex token counting improvements (thanks @daniel-lxs!)
 - Add: llama-4-maverick model to Vertex AI provider (thanks @MuriloFP!)
 - Fix: properly distinguish between user cancellations and API failures
 - Fix: add case sensitivity mention to suggested fixes in apply_diff error message
@@ -1002,7 +1733,6 @@
 - Fix Claude model detection by name for API protocol selection (thanks @daniel-lxs!)
 - Move marketplace icon from overflow menu to top navigation
 - Optional setting to prevent completion with open todos
-- Added YouTube to website footer (thanks @thill2323!)
 
 ## [3.23.14] - 2025-07-17
 
@@ -1293,7 +2023,7 @@
 - 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!)
+- Allow a lower context condensing threshold (thanks @SECKainersdorfer!)
 - Avoid type system duplication for cleaner codebase (thanks @EamonNerbonne!)
 
 ## [3.20.1] - 2025-06-12
@@ -1396,7 +2126,6 @@
 - 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
@@ -1450,7 +2179,7 @@
 
 ## [3.18.2] - 2025-05-23
 
-- Fix vscode-material-icons in the filer picker
+- Fix vscode-material-icons in the file picker
 - Fix global settings export
 - Respect user-configured terminal integration timeout (thanks @KJ7LNW)
 - Context condensing enhancements (thanks @SannidhyaSah)
@@ -1568,7 +2297,7 @@
 - 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)
+- Improve accessibility of auto-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)
@@ -1630,7 +2359,7 @@
 - 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)
+- Improve support for multi-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)
@@ -2036,7 +2765,7 @@
 - Custom ARNs in Amazon 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!)
+- 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!)
@@ -2141,7 +2870,7 @@
 
 ## [3.7.6] - 2025-02-26
 
-- Handle really long text better in the in the ChatRow similar to TaskHeader (thanks @joemanley201!)
+- Handle really long text better in the ChatRow similar to TaskHeader (thanks @joemanley201!)
 - Support multiple files in drag-and-drop
 - Truncate search_file output to avoid crashing the extension
 - Better OpenRouter error handling (no more "Provider Error")
@@ -2364,7 +3093,6 @@
 - Ask and Architect modes can now edit markdown files
 - Custom modes can now be restricted to specific file patterns (for example, a technical writer who can only edit markdown files 👋)
 - Support for configuring the Bedrock provider with AWS Profiles
-- New Roo Code community Discord at https://roocode.com/discord!
 
 ## [3.2.8]
 
@@ -2404,8 +3132,6 @@
     - Create specialized assistants for any workflow
     - Just type "Create a new mode for <X>" or visit the Prompts tab in the top menu to get started
 
-Join us at https://www.reddit.com/r/RooCode to share your custom modes and be part of our next chapter!
-
 ## [3.1.7]
 
 - DeepSeek-R1 support (thanks @philipnext!)
@@ -2453,12 +3179,8 @@ Join us at https://www.reddit.com/r/RooCode to share your custom modes and be pa
 
 ## [3.0.1]
 
-- Fix the reddit link and a small visual glitch in the chat input
-
 ## [3.0.0]
 
-- This release adds chat modes! Now you can ask Roo Code questions about system architecture or the codebase without immediately jumping into writing code. You can even assign different API configuration profiles to each mode if you prefer to use different models for thinking vs coding. Would love feedback in the new Roo Code Reddit! https://www.reddit.com/r/RooCode
-
 ## [2.2.46]
 
 - Only parse @-mentions in user input (not in files)

CODE_OF_CONDUCT.md

@@ -1,90 +0,0 @@
-<div align="center">
-<sub>
-
-<b>English</b> • [Català](locales/ca/CODE_OF_CONDUCT.md) • [Deutsch](locales/de/CODE_OF_CONDUCT.md) • [Español](locales/es/CODE_OF_CONDUCT.md) • [Français](locales/fr/CODE_OF_CONDUCT.md) • [हिंदी](locales/hi/CODE_OF_CONDUCT.md) • [Bahasa Indonesia](locales/id/CODE_OF_CONDUCT.md) • [Italiano](locales/it/CODE_OF_CONDUCT.md) • [日本語](locales/ja/CODE_OF_CONDUCT.md)
-
-</sub>
-<sub>
-
-[한국어](locales/ko/CODE_OF_CONDUCT.md) • [Nederlands](locales/nl/CODE_OF_CONDUCT.md) • [Polski](locales/pl/CODE_OF_CONDUCT.md) • [Português (BR)](locales/pt-BR/CODE_OF_CONDUCT.md) • [Русский](locales/ru/CODE_OF_CONDUCT.md) • [Türkçe](locales/tr/CODE_OF_CONDUCT.md) • [Tiếng Việt](locales/vi/CODE_OF_CONDUCT.md) • [简体中文](locales/zh-CN/CODE_OF_CONDUCT.md) • [繁體中文](locales/zh-TW/CODE_OF_CONDUCT.md)
-
-</sub>
-</div>
-
-# 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

CONTRIBUTING.md

@@ -1,141 +0,0 @@
-<div align="center">
-<sub>
-
-<b>English</b> • [Català](locales/ca/CONTRIBUTING.md) • [Deutsch](locales/de/CONTRIBUTING.md) • [Español](locales/es/CONTRIBUTING.md) • [Français](locales/fr/CONTRIBUTING.md) • [हिंदी](locales/hi/CONTRIBUTING.md) • [Bahasa Indonesia](locales/id/CONTRIBUTING.md) • [Italiano](locales/it/CONTRIBUTING.md) • [日本語](locales/ja/CONTRIBUTING.md)
-
-</sub>
-<sub>
-
-[한국어](locales/ko/CONTRIBUTING.md) • [Nederlands](locales/nl/CONTRIBUTING.md) • [Polski](locales/pl/CONTRIBUTING.md) • [Português (BR)](locales/pt-BR/CONTRIBUTING.md) • [Русский](locales/ru/CONTRIBUTING.md) • [Türkçe](locales/tr/CONTRIBUTING.md) • [Tiếng Việt](locales/vi/CONTRIBUTING.md) • [简体中文](locales/zh-CN/CONTRIBUTING.md) • [繁體中文](locales/zh-TW/CONTRIBUTING.md)
-
-</sub>
-</div>
-
-# 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 start with a GitHub Issue using our skinny templates.
-
-- **Check existing issues**: Search [GitHub Issues](https://github.com/RooCodeInc/Roo-Code/issues).
-- **Create an issue** using:
-    - **Enhancements:** "Enhancement Request" template (plain language focused on user benefit).
-    - **Bugs:** "Bug Report" template (minimal repro + expected vs actual + version).
-- **Want to work on it?** Comment "Claiming" on the issue and DM **Hannes Rudolph (`hrudolph`)** on [Discord](https://discord.gg/roocode) to get assigned. Assignment will be confirmed in the thread.
-- **PRs must link to the issue.** Unlinked PRs may be closed.
-
-### Deciding What to Work On
-
-- Check the [GitHub Project](https://github.com/orgs/RooCodeInc/projects/1) for "Issue [Unassigned]" issues.
-- For docs, visit [Roo Code Docs](https://github.com/RooCodeInc/Roo-Code-Docs).
-
-### Reporting Bugs
-
-- Check for existing reports first.
-- Create a new bug using the ["Bug Report" template](https://github.com/RooCodeInc/Roo-Code/issues/new/choose) with:
-    - Clear, numbered reproduction steps
-    - Expected vs actual result
-    - Roo Code version (required); API provider/model if relevant
-- **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.
-- Link the issue in the PR description/title (e.g., "Fixes #123").
-- Provide screenshots/videos for UI changes.
-- Indicate if documentation updates are necessary.
-
-### Pull Request Policy
-
-- Must reference an assigned GitHub Issue. To get assigned: comment "Claiming" on the issue and DM **Hannes Rudolph (`hrudolph`)** on [Discord](https://discord.gg/roocode). Assignment will be confirmed in the thread.
-- Unlinked PRs 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.

PRIVACY.md

@@ -6,12 +6,11 @@ Roo Code respects your privacy and is committed to transparency about how we han
 
 ### **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. If you select Roo Code Cloud as the model provider (proxy mode), your code may transit Roo Code servers only to forward it to the upstream provider. We do not store your code; it is deleted immediately after forwarding. Otherwise, your code is sent directly to the provider. AI providers may store data per their privacy policies.
+- **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. AI providers may store data 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. If you choose Roo Code Cloud as the provider (proxy mode), prompts may transit Roo Code servers only to forward them to the upstream model and are not stored.
+- **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 collect anonymous feature usage and error data to help us improve Roo Code. This telemetry is powered by PostHog and includes your VS Code machine ID, feature usage patterns, and exception reports. This telemetry does **not** collect personally identifiable information, your code, or AI prompts. You can opt out of this telemetry at any time through the settings.
-- **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)**
 

README.md

@@ -1,12 +1,5 @@
 <p align="center">
-  <a href="https://marketplace.visualstudio.com/items?itemName=RooVeterinaryInc.roo-cline"><img src="https://img.shields.io/badge/VS_Code_Marketplace-007ACC?style=flat&logo=visualstudiocode&logoColor=white" alt="VS Code Marketplace"></a>
-  <a href="https://x.com/roocode"><img src="https://img.shields.io/badge/roocode-000000?style=flat&logo=x&logoColor=white" alt="X"></a>
-  <a href="https://youtube.com/@roocodeyt?feature=shared"><img src="https://img.shields.io/badge/YouTube-FF0000?style=flat&logo=youtube&logoColor=white" alt="YouTube"></a>
-  <a href="https://discord.gg/roocode"><img src="https://img.shields.io/badge/Join%20Discord-5865F2?style=flat&logo=discord&logoColor=white" alt="Join Discord"></a>
-  <a href="https://www.reddit.com/r/RooCode/"><img src="https://img.shields.io/badge/Join%20r%2FRooCode-FF4500?style=flat&logo=reddit&logoColor=white" alt="Join r/RooCode"></a>
-</p>
-<p align="center">
-  <em>Get help fast → <a href="https://discord.gg/roocode">Join Discord</a> • Prefer async? → <a href="https://www.reddit.com/r/RooCode/">Join r/RooCode</a></em>
+  <a href="https://marketplace.visualstudio.com/items?itemName=RooVeterinaryInc.roo-cline"><img src="https://img.shields.io/badge/VS_Code_Marketplace-007ACC?style=flat&logo=visualstudiocode&logoColor=white" alt="VS Code Marketplace"></a>  
 </p>
 
 # Roo Code
@@ -35,7 +28,7 @@
 - [简体中文](locales/zh-CN/README.md)
 - [繁體中文](locales/zh-TW/README.md)
 - ...
-      </details>
+    </details>
 
 ---
 
@@ -58,119 +51,27 @@ Roo Code adapts to how you work:
 - Ask Mode: fast answers, explanations, and docs
 - Debug Mode: trace issues, add logs, isolate root causes
 - Custom Modes: build specialized modes for your team or workflow
-- Roomote Control: Roomote Control lets you remotely control tasks running in your local VS Code instance.
 
-Learn more: [Using Modes](https://docs.roocode.com/basic-usage/using-modes) • [Custom Modes](https://docs.roocode.com/advanced-usage/custom-modes) • [Roomote Control](https://docs.roocode.com/roo-code-cloud/roomote-control)
-
-## Tutorial & Feature Videos
-
-<div align="center">
-
-|                                                                                                                                                                           |                                                                                                                                                                            |                                                                                                                                                                         |
-| :-----------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
-| <a href="https://www.youtube.com/watch?v=Mcq3r1EPZ-4"><img src="https://img.youtube.com/vi/Mcq3r1EPZ-4/maxresdefault.jpg" width="100%"></a><br><b>Installing Roo Code</b> | <a href="https://www.youtube.com/watch?v=ZBML8h5cCgo"><img src="https://img.youtube.com/vi/ZBML8h5cCgo/maxresdefault.jpg" width="100%"></a><br><b>Configuring Profiles</b> | <a href="https://www.youtube.com/watch?v=r1bpod1VWhg"><img src="https://img.youtube.com/vi/r1bpod1VWhg/maxresdefault.jpg" width="100%"></a><br><b>Codebase Indexing</b> |
-|    <a href="https://www.youtube.com/watch?v=iiAv1eKOaxk"><img src="https://img.youtube.com/vi/iiAv1eKOaxk/maxresdefault.jpg" width="100%"></a><br><b>Custom Modes</b>     |     <a href="https://www.youtube.com/watch?v=Ho30nyY332E"><img src="https://img.youtube.com/vi/Ho30nyY332E/maxresdefault.jpg" width="100%"></a><br><b>Checkpoints</b>      |    <a href="https://www.youtube.com/watch?v=6h5vB9PpoPk"><img src="https://img.youtube.com/vi/6h5vB9PpoPk/maxresdefault.jpg" width="100%"></a><br><b>Todo Lists</b>     |
-
-</div>
-<p align="center">
-<a href="https://docs.roocode.com/tutorial-videos">More quick tutorial and feature videos...</a>
-</p>
+Learn more: [Using Modes](https://roocodeinc.github.io/Roo-Code/basic-usage/using-modes) • [Custom Modes](https://roocodeinc.github.io/Roo-Code/advanced-usage/custom-modes)
 
 ## Resources
 
-- **[Documentation](https://docs.roocode.com):** The official guide to installing, configuring, and mastering Roo Code.
-- **[YouTube Channel](https://youtube.com/@roocodeyt?feature=shared):** Watch tutorials and see features in action.
-- **[Discord Server](https://discord.gg/roocode):** Join the community for real-time help and discussion.
-- **[Reddit Community](https://www.reddit.com/r/RooCode):** Share your experiences and see what others are building.
+- **[Documentation](https://roocodeinc.github.io/Roo-Code/):** The official guide to installing, configuring, and mastering Roo Code.
 - **[GitHub Issues](https://github.com/RooCodeInc/Roo-Code/issues):** Report bugs and track development.
-- **[Feature Requests](https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests?discussions_q=is%3Aopen+category%3A%22Feature+Requests%22+sort%3Atop):** Have an idea? Share it with the developers.
-
----
-
-## Local Setup & Development
-
-1. **Clone** the repo:
-
-```sh
-git clone https://github.com/RooCodeInc/Roo-Code.git
-```
-
-2. **Install dependencies**:
-
-```sh
-pnpm install
-```
-
-3. **Run the extension**:
-
-There are several ways to run the Roo Code extension:
-
-### Development Mode (F5)
-
-For active development, use VSCode's built-in debugging:
-
-Press `F5` (or go to **Run** → **Start Debugging**) in VSCode. This will open a new VSCode window with the Roo Code extension running.
-
-- Changes to the webview will appear immediately.
-- Changes to the core extension will also hot reload automatically.
-
-### Automated VSIX Installation
-
-To build and install the extension as a VSIX package directly into VSCode:
-
-```sh
-pnpm install:vsix [-y] [--editor=<command>]
-```
-
-This command will:
-
-- Ask which editor command to use (code/cursor/code-insiders) - defaults to 'code'
-- Uninstall any existing version of the extension.
-- Build the latest VSIX package.
-- Install the newly built VSIX.
-- Prompt you to restart VS Code for changes to take effect.
-
-Options:
-
-- `-y`: Skip all confirmation prompts and use defaults
-- `--editor=<command>`: Specify the editor command (e.g., `--editor=cursor` or `--editor=code-insiders`)
-
-### Manual VSIX Installation
-
-If you prefer to install the VSIX package manually:
-
-1.  First, build the VSIX package:
-    ```sh
-    pnpm vsix
-    ```
-2.  A `.vsix` file will be generated in the `bin/` directory (e.g., `bin/roo-cline-<version>.vsix`).
-3.  Install it manually using the VSCode CLI:
-    ```sh
-    code --install-extension bin/roo-cline-<version>.vsix
-    ```
-
----
-
-We use [changesets](https://github.com/changesets/changesets) for versioning and publishing. Check our `CHANGELOG.md` for release notes.
 
 ---
 
 ## Disclaimer
 
+The Roo Code Extension was shut down on May 15th.
+
+- If you're looking for an alternative, check out [ZooCode](https://github.com/Zoo-Code-Org/Zoo-Code/) (a fork started by the Roo Code community) and [Cline](https://cline.bot/) (from where Roo Code originated).
+- If you were a paying user and have billing questions, please write [billing@roocode.com](mailto:billing@roocode.com).
+
 **Please note** that Roo Code, Inc does **not** make any representations or warranties regarding any code, models, or other tools provided or made available in connection with Roo Code, any associated third-party tools, or any resulting outputs. You assume **all risks** associated with the use of any such tools or outputs; such tools are provided on an **"AS IS"** and **"AS AVAILABLE"** basis. Such risks may include, without limitation, intellectual property infringement, cyber vulnerabilities or attacks, bias, inaccuracies, errors, defects, viruses, downtime, property loss or damage, and/or personal injury. You are solely responsible for your use of any such tools or outputs (including, without limitation, the legality, appropriateness, and results thereof).
 
 ---
 
-## Contributing
-
-We love community contributions! Get started by reading our [CONTRIBUTING.md](CONTRIBUTING.md).
-
----
-
 ## License
 
-[Apache 2.0 © 2025 Roo Code, Inc.](./LICENSE)
-
----
-
-**Enjoy Roo Code!** Whether you keep it on a short leash or let it roam autonomously, we can’t wait to see what you build. If you have questions or feature ideas, drop by our [Reddit community](https://www.reddit.com/r/RooCode/) or [Discord](https://discord.gg/roocode). Happy coding!
+[Apache 2.0 © 2026 Roo Code, Inc.](./LICENSE)

apps/cli/CHANGELOG.md

@@ -0,0 +1,391 @@
+# Changelog
+
+All notable changes to the `@roo-code/cli` package will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [0.1.17] - 2026-03-04
+
+### Added
+
+- **Custom Session ID Support**: New `--create-with-session-id` flag allows specifying a custom UUID session ID when creating tasks. Session IDs are now validated as UUIDs for both create and resume operations, as well as for `start.taskId` in stdin-stream mode.
+
+### Tests
+
+- Added integration coverage for create+resume loading the correct session.
+
+## [0.1.16] - 2026-03-04
+
+### Added
+
+- **Custom Shell Selection**: New `--terminal-shell` flag to specify which shell to use for inline command execution. The shell path is validated at the CLI layer and passed through the standard settings mechanism.
+
+### Tests
+
+- Added integration coverage for stdin stream routing and race invariants.
+
+## [0.1.15] - 2026-03-03
+
+### Fixed
+
+- **Follow-up Routing for Completion Asks**: Fixed routing of follow-up messages when the agent asks for clarification (ask_followup_question) in stdin-stream mode. Messages sent after a completion ask are now correctly delivered to the agent instead of being queued.
+
+## [0.1.14] - 2026-03-03
+
+### Fixed
+
+- **Command Output Streaming**: Ensure full command output is streamed before the done event is emitted, preventing truncated output in stdin-stream mode.
+
+## [0.1.13] - 2026-03-02
+
+### Added
+
+- **Skills as Slash Commands**: Skills are now exposed as slash commands, so you can invoke skill workflows directly from command-style input.
+- **Skill Fallback Execution**: When a slash command does not match a command file but matches a skill slug, the CLI can resolve and execute that skill path.
+
+### Changed
+
+- **Slash Command Resolution Priority**: Command precedence is preserved, with skill fallback only used when no matching slash command is found.
+
+### Tests
+
+- Added and updated tests for slash command + skill fallback behavior, including command precedence and duplicate skill-slug handling.
+
+## [0.1.12] - 2026-03-02
+
+### Fixed
+
+- **Command Timeout Handling**: CLI runtime now correctly ignores model-provided background timeouts for commands, ensuring command lifetime is governed solely by the `--timeout` setting.
+
+## [0.1.11] - 2026-03-02
+
+### Added
+
+- **Image Support in Stdin Stream**: The `start` and `message` commands in stdin-stream mode now support an optional `images` field (array of base64 data URIs) to attach images to prompts.
+
+### Fixed
+
+- **Upgrade Version Detection**: Fixed version detection in the `upgrade` command to correctly identify when updates are available.
+
+## [0.1.10] - 2026-03-02
+
+### Added
+
+- **Command Exit Code in Events**: The `tool_result` event for command executions now includes an `exitCode` field, allowing CLI consumers to programmatically distinguish between successful and failed command executions without parsing output text.
+
+## [0.1.9] - 2026-03-02
+
+### Fixed
+
+- **Stdin Stream Cancel Race**: Fixed a race condition during startup cancellation in stdin-stream mode that could cause unexpected behavior when canceling tasks immediately after starting them.
+
+### Tests
+
+- **Integration Test Suite**: Added comprehensive integration test suite for stdin-stream protocol covering cancel, followup, multi-message queue, and shutdown scenarios.
+
+## [0.1.8] - 2026-03-02
+
+### Changed
+
+- **Command Execution Timeout**: Increased timeout for command execution to improve reliability for long-running operations.
+
+### Fixed
+
+- **Stdin Stream Queue Handling**: Fixed stdin stream queued messages and command output streaming to ensure messages are properly processed.
+
+## [0.1.7] - 2026-03-01
+
+### Fixed
+
+- **Stdin Stream Control Flow**: Gracefully handle control-flow errors in stdin-stream mode to prevent unexpected crashes during cancellation and shutdown sequences.
+
+### Changed
+
+- **Type Definitions**: Refactored and simplified JSON event type definitions for better type safety.
+
+## [0.1.6] - 2026-02-27
+
+### Added
+
+- **Consecutive Mistake Limit**: New `--mistake-limit` flag to configure the maximum number of consecutive mistakes before the agent pauses for intervention.
+
+### Changed
+
+- **Workspace-Scoped Sessions**: The `list sessions` command and `--resume` flag now only show and resume sessions from the current workspace directory.
+
+### Fixed
+
+- **Task Configuration Forwarding**: Task configuration (custom modes, disabled tools, etc.) passed via the stdin-prompt-stream protocol is now correctly forwarded to the extension host instead of being silently dropped.
+- **Stream Error Recovery**: Improved recovery from streaming errors to prevent task interruption.
+
+## [0.1.5] - 2026-02-26
+
+### Added
+
+- **Session History**: New `list sessions` subcommand to view recent CLI sessions with task IDs, timestamps, and initial prompts.
+- **Session Resume**: New `--resume <taskId>` flag to continue a previous session from where it left off.
+- **Upgrade Command**: New `upgrade` command to check for and install the latest CLI version.
+
+## [0.1.4] - 2026-02-26
+
+### Fixed
+
+- **Exception Handling**: Improved recovery from unhandled exceptions in the CLI to prevent unexpected crashes.
+
+## [0.1.3] - 2026-02-25
+
+### Fixed
+
+- **Task Resumption**: Fixed an issue where resuming a previously suspended task could fail due to state initialization timing in the extension host.
+
+## [0.1.2] - 2026-02-25
+
+### Changed
+
+- **Streaming Deltas**: Tool use ask messages (command, tool, mcp) are now streamed as structured deltas instead of full snapshots in json-event-emitter for improved efficiency.
+- **Task ID Propagation**: Task ID is now generated upfront and propagated through runTask/createTask so currentTaskId is available in extension state immediately.
+- **Custom Tools**: Enabled customTools experiment in extension host.
+
+### Fixed
+
+- **Cancel Recovery**: Wait for resumable state after cancel before processing follow-up messages to prevent race conditions in stdin-stream.
+- **Custom Tool Schema**: Provide valid empty JSON Schema for custom tools without parameters to fix strict-mode API validation.
+- **Path Handling**: Skip paths outside cwd in RooProtectedController to avoid RangeError.
+- **Retry Handling**: Silently handle abort during exponential backoff retry countdown.
+- Fixed spelling/grammar and casing inconsistencies.
+
+### Added
+
+- **Telemetry Control**: Added `ROO_CODE_DISABLE_TELEMETRY=1` environment variable to disable cloud telemetry.
+
+## [0.1.1] - 2026-02-24
+
+### Added
+
+- **Roo Model Warmup**: When configured with the Roo provider, the CLI now proactively fetches and warms the model list during activation so that model information is available before the first prompt is sent. The warmup has a 10s timeout and failures are logged only in debug mode.
+- **Unbound Provider**: Added Unbound as an available provider option.
+
+## [0.1.0] - 2026-02-19
+
+### Added
+
+- **NDJSON Stdin Protocol**: Overhauled the stdin prompt stream from raw text lines to a structured NDJSON command protocol (`start`/`message`/`cancel`/`ping`/`shutdown`) with requestId correlation, ack/done/error lifecycle events, and queue telemetry. See [`stdin-stream.ts`](src/ui/stdin-stream.ts) for implementation.
+- **List Subcommands**: New `list` subcommands (`commands`, `modes`, `models`) for programmatic discovery of available CLI capabilities.
+- **Shared Utilities**: Added `isRecord` guard utility for improved type safety.
+
+### Changed
+
+- **Modularized Architecture**: Extracted stdin stream logic from `run.ts` into dedicated [`stdin-stream.ts`](src/ui/stdin-stream.ts) module for better code organization and maintainability.
+
+### Fixed
+
+- Fixed a bug in `Task.ts` affecting CLI operation.
+
+## [0.0.55] - 2026-02-17
+
+### Fixed
+
+- **Stdin Stream Mode**: Fixed issue where new tasks were incorrectly being created in stdin-prompt-stream mode. The mode now properly reuses the existing task for subsequent prompts instead of creating new tasks.
+
+## [0.0.54] - 2026-02-15
+
+### Added
+
+- **Stdin Stream Mode**: New `stdin-prompt-stream` mode that reads prompts from stdin, allowing batch processing and piping multiple tasks. Each line of stdin is processed as a separate prompt with streaming JSON output. See [`stdin-prompt-stream.ts`](src/ui/stdin-prompt-stream.ts) for implementation.
+
+### Fixed
+
+- Fixed JSON emitter state not being cleared between tasks in stdin-prompt-stream mode
+- Fixed inconsistent user role for prompt echo partials in stream-json mode
+
+## [0.0.53] - 2026-02-12
+
+### Changed
+
+- **Auto-Approve by Default**: The CLI now auto-approves all actions (tools, commands, browser, MCP) by default. Followup questions auto-select the first suggestion after a 60-second timeout.
+- **New `--require-approval` Flag**: Replaced `-y`/`--yes`/`--dangerously-skip-permissions` flags with a new `-a, --require-approval` flag for users who want manual approval prompts before actions execute.
+
+### Fixed
+
+- Spamming the escape key to cancel a running task no longer crashes the cli.
+
+## [0.0.52] - 2026-02-09
+
+### Added
+
+- **Linux Support**: Added support for `linux-arm64`.
+
+## [0.0.51] - 2026-02-06
+
+### Changed
+
+- **Default Model Update**: Changed the default model from Opus 4.5 to Opus 4.6 for improved performance and capabilities
+
+## [0.0.50] - 2026-02-05
+
+### Added
+
+- **Linux Support**: The CLI now supports Linux platforms in addition to macOS
+- **Roo Provider API Key Support**: Allow `--api-key` flag and `ROO_API_KEY` environment variable for the roo provider instead of requiring cloud auth token
+- **Exit on Error**: New `--exit-on-error` flag to exit immediately on API request errors instead of retrying, useful for CI/CD pipelines
+
+### Changed
+
+- **Improved Dev Experience**: Dev scripts now use `tsx` for running directly from source without building first
+- **Path Resolution Fixes**: Fixed path resolution in [`version.ts`](src/lib/utils/version.ts), [`extension.ts`](src/lib/utils/extension.ts), and [`extension-host.ts`](src/agent/extension-host.ts) to work from both source and bundled locations
+- **Debug Logging**: Debug log file (`~/.roo/cli-debug.log`) is now disabled by default unless `--debug` flag is passed
+- Updated README with complete environment variable table and dev workflow documentation
+
+### Fixed
+
+- Corrected example in install script
+
+### Removed
+
+- Dropped macOS 13 support
+
+## [0.0.49] - 2026-01-18
+
+### Added
+
+- **Output Format Options**: New `--output-format` flag to control CLI output format for scripting and automation:
+    - `text` (default) - Human-readable interactive output
+    - `json` - Single JSON object with all events and final result at task completion
+    - `stream-json` - NDJSON (newline-delimited JSON) for real-time streaming of events
+    - See [`json-events.ts`](src/types/json-events.ts) for the complete event schema
+    - New [`JsonEventEmitter`](src/agent/json-event-emitter.ts) for structured output generation
+
+## [0.0.48] - 2026-01-17
+
+### Changed
+
+- Simplified authentication callback flow by using HTTP redirects instead of POST requests with CORS headers for improved browser compatibility
+
+## [0.0.47] - 2026-01-17
+
+### Added
+
+- **Workspace flag**: New `-w, --workspace <path>` option to specify a custom workspace directory instead of using the current working directory
+- **Oneshot mode**: New `--oneshot` flag to exit upon task completion, useful for scripting and automation (can also be saved in settings via [`CliSettings.oneshot`](src/types/types.ts))
+
+### Changed
+
+- Skip onboarding flow when a provider is explicitly specified via `--provider` flag or saved in settings
+- Unified permission flags: Combined approval-skipping flags into a single option for Claude Code-like CLI compatibility
+- Improved Roo Code Router authentication flow and error messaging
+
+### Fixed
+
+- Removed unnecessary timeout that could cause issues with long-running tasks
+- Fixed authentication token validation for Roo Code Router provider
+
+## [0.0.45] - 2026-01-08
+
+### Changed
+
+- **Major Refactor**: Extracted ~1400 lines from [`App.tsx`](src/ui/App.tsx) into reusable hooks and utilities for better maintainability:
+
+    - [`useExtensionHost`](src/ui/hooks/useExtensionHost.ts) - Extension host connection and lifecycle management
+    - [`useMessageHandlers`](src/ui/hooks/useMessageHandlers.ts) - Message processing and state updates
+    - [`useTaskSubmit`](src/ui/hooks/useTaskSubmit.ts) - Task submission logic
+    - [`useGlobalInput`](src/ui/hooks/useGlobalInput.ts) - Global keyboard shortcut handling
+    - [`useFollowupCountdown`](src/ui/hooks/useFollowupCountdown.ts) - Auto-approval countdown logic
+    - [`useFocusManagement`](src/ui/hooks/useFocusManagement.ts) - Input focus state management
+    - [`usePickerHandlers`](src/ui/hooks/usePickerHandlers.ts) - Picker component event handling
+    - [`uiStateStore`](src/ui/stores/uiStateStore.ts) - UI-specific state (showExitHint, countdown, etc.)
+    - Tool data utilities ([`extractToolData`](src/ui/utils/toolDataUtils.ts), `formatToolOutput`, etc.)
+    - [`HorizontalLine`](src/ui/components/HorizontalLine.tsx) component
+
+- **Performance Optimizations**:
+
+    - Added RAF-style scroll throttling to reduce state updates
+    - Stabilized `useExtensionHost` hook return values with `useCallback`/`useMemo`
+    - Added streaming message debouncing to batch rapid partial updates
+    - Added shallow array equality checks to prevent unnecessary re-renders
+
+- Simplified [`ModeTool`](src/ui/components/tools/ModeTool.tsx) layout to horizontal with mode suffix
+- Simplified logging by removing verbose debug output and adding first/last partial message logging pattern
+- Updated Nerd Font icon codepoints in [`Icon`](src/ui/components/Icon.tsx) component
+
+### Added
+
+- `#` shortcut in help trigger for quick access to task history autocomplete
+
+### Fixed
+
+- Fixed a crash in message handling
+- Added protected file warning in tool approval prompts
+- Enabled `alwaysAllowWriteProtected` for non-interactive mode
+
+### Removed
+
+- Removed unused `renderLogger.ts` utility file
+
+### Tests
+
+- Updated extension-host tests to expect `[Tool Request]` format
+- Updated Icon tests to expect single-char Nerd Font icons
+
+## [0.0.44] - 2026-01-08
+
+### Added
+
+- **Tool Renderer Components**: Specialized renderers for displaying tool outputs with optimized formatting for each tool type. Each renderer provides a focused view of its data structure.
+
+    - [`FileReadTool`](src/ui/components/tools/FileReadTool.tsx) - Display file read operations with syntax highlighting
+    - [`FileWriteTool`](src/ui/components/tools/FileWriteTool.tsx) - Show file write/edit operations with diff views
+    - [`SearchTool`](src/ui/components/tools/SearchTool.tsx) - Render search results with context
+    - [`CommandTool`](src/ui/components/tools/CommandTool.tsx) - Display command execution with output
+    - [`BrowserTool`](src/ui/components/tools/BrowserTool.tsx) - Show browser automation actions
+    - [`ModeTool`](src/ui/components/tools/ModeTool.tsx) - Display mode switching operations
+    - [`CompletionTool`](src/ui/components/tools/CompletionTool.tsx) - Show task completion status
+    - [`GenericTool`](src/ui/components/tools/GenericTool.tsx) - Fallback renderer for other tools
+
+- **History Trigger**: New `#` trigger for task history autocomplete with fuzzy search support. Type `#` at the start of a line to browse and resume previous tasks.
+
+    - [`HistoryTrigger.tsx`](src/ui/components/autocomplete/triggers/HistoryTrigger.tsx) - Trigger implementation with fuzzy filtering
+    - Shows task status, mode, and relative timestamps
+    - Supports keyboard navigation for quick task selection
+
+- **Release Confirmation Prompt**: The release script now prompts for confirmation before creating a release.
+
+### Fixed
+
+- Task history picker selection and navigation issues
+- Mode switcher keyboard handling bug
+
+### Changed
+
+- Reorganized test files into `__tests__` directories for better project structure
+- Refactored utility modules into dedicated `utils/` directory
+
+## [0.0.43] - 2026-01-07
+
+### Added
+
+- **Toast Notification System**: New toast notifications for user feedback with support for info, success, warning, and error types. Toasts auto-dismiss after a configurable duration and are managed via Zustand store.
+
+    - New [`ToastDisplay`](src/ui/components/ToastDisplay.tsx) component for rendering toast messages
+    - New [`useToast`](src/ui/hooks/useToast.ts) hook for managing toast state and displaying notifications
+
+- **Global Input Sequences Registry**: Centralized system for handling keyboard shortcuts at the application level, preventing conflicts with input components.
+
+    - New [`globalInputSequences.ts`](src/ui/utils/globalInputSequences.ts) utility module
+    - Support for Kitty keyboard protocol (CSI u encoding) for better terminal compatibility
+    - Built-in sequences for `Ctrl+C` (exit) and `Ctrl+M` (mode cycling)
+
+- **Local Tarball Installation**: The install script now supports installing from a local tarball via the `ROO_LOCAL_TARBALL` environment variable, useful for offline installation or testing pre-release builds.
+
+### Changed
+
+- **MultilineTextInput**: Updated to respect global input sequences, preventing the component from consuming shortcuts meant for application-level handling.
+
+### Tests
+
+- Added comprehensive tests for the toast notification system
+- Added tests for global input sequence matching
+
+## [0.0.42] - 2025-01-07
+
+The cli is alive!

apps/cli/README.md

@@ -0,0 +1,240 @@
+# @roo-code/cli
+
+Command Line Interface for Roo Code - Run the Roo Code agent from the terminal without VSCode.
+
+## Overview
+
+This CLI uses the `@roo-code/vscode-shim` package to provide a VSCode API compatibility layer, allowing the main Roo Code extension to run in a Node.js environment.
+
+## Installation
+
+### Quick Install (Recommended)
+
+Install the Roo Code CLI with a single command:
+
+```bash
+curl -fsSL https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/install.sh | sh
+```
+
+**Requirements:**
+
+- Node.js 20 or higher
+- macOS Apple Silicon (M1/M2/M3/M4) or Linux x64
+
+**Custom installation directory:**
+
+```bash
+ROO_INSTALL_DIR=/opt/roo-code ROO_BIN_DIR=/usr/local/bin curl -fsSL ... | sh
+```
+
+**Install a specific version:**
+
+```bash
+ROO_VERSION=0.1.0 curl -fsSL https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/install.sh | sh
+```
+
+### Updating
+
+Re-run the install script to update to the latest version:
+
+```bash
+curl -fsSL https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/install.sh | sh
+```
+
+Or run:
+
+```bash
+roo upgrade
+```
+
+### Uninstalling
+
+```bash
+rm -rf ~/.roo/cli ~/.local/bin/roo
+```
+
+## Usage
+
+### Interactive Mode (Default)
+
+By default, the CLI auto-approves actions and runs in interactive TUI mode:
+
+```bash
+export OPENROUTER_API_KEY=sk-or-v1-...
+
+roo "What is this project?" -w ~/Documents/my-project
+```
+
+You can also run without a prompt and enter it interactively in TUI mode:
+
+```bash
+roo -w ~/Documents/my-project
+```
+
+In interactive mode:
+
+- Tool executions are auto-approved
+- Commands are auto-approved
+- Followup questions show suggestions with a 60-second timeout, then auto-select the first suggestion
+- Browser and MCP actions are auto-approved
+
+### Approval-Required Mode (`--require-approval`)
+
+If you want manual approval prompts, enable approval-required mode:
+
+```bash
+roo "Refactor the utils.ts file" --require-approval -w ~/Documents/my-project
+```
+
+In approval-required mode:
+
+- Tool, command, browser, and MCP actions prompt for yes/no approval
+- Followup questions wait for manual input (no auto-timeout)
+
+### Print Mode (`--print`)
+
+Use `--print` for non-interactive execution and machine-readable output:
+
+```bash
+# Prompt is required
+roo --print "Summarize this repository"
+
+# Create a new task with a specific session ID (UUID)
+roo --print --create-with-session-id 018f7fc8-7c96-7f7c-98aa-2ec4ff7f6d87 "Summarize this repository"
+```
+
+### Stdin Stream Mode (`--stdin-prompt-stream`)
+
+For programmatic control (one process, multiple prompts), use `--stdin-prompt-stream` with `--print`.
+Send NDJSON commands via stdin:
+
+```bash
+printf '{"command":"start","requestId":"1","prompt":"1+1=?"}\n' | roo --print --stdin-prompt-stream --output-format stream-json
+
+# Optional: provide taskId per start command
+printf '{"command":"start","requestId":"1","taskId":"018f7fc8-7c96-7f7c-98aa-2ec4ff7f6d87","prompt":"1+1=?"}\n' | roo --print --stdin-prompt-stream --output-format stream-json
+```
+
+## Options
+
+| Option                                  | Description                                                                             | Default                     |
+| --------------------------------------- | --------------------------------------------------------------------------------------- | --------------------------- |
+| `[prompt]`                              | Your prompt (positional argument, optional)                                             | None                        |
+| `--prompt-file <path>`                  | Read prompt from a file instead of command line argument                                | None                        |
+| `--create-with-session-id <session-id>` | Create a new task using the provided session ID (UUID)                                  | None                        |
+| `-w, --workspace <path>`                | Workspace path to operate in                                                            | Current directory           |
+| `-p, --print`                           | Print response and exit (non-interactive mode)                                          | `false`                     |
+| `--stdin-prompt-stream`                 | Read NDJSON control commands from stdin (requires `--print`)                            | `false`                     |
+| `-e, --extension <path>`                | Path to the extension bundle directory                                                  | Auto-detected               |
+| `-d, --debug`                           | Enable debug output (includes detailed debug information, prompts, paths, etc)          | `false`                     |
+| `-a, --require-approval`                | Require manual approval before actions execute                                          | `false`                     |
+| `-k, --api-key <key>`                   | API key for the LLM provider                                                            | From env var                |
+| `--provider <provider>`                 | API provider (anthropic, openai, openrouter, etc.)                                      | `openrouter`                |
+| `-m, --model <model>`                   | Model to use                                                                            | `anthropic/claude-opus-4.6` |
+| `--mode <mode>`                         | Mode to start in (code, architect, ask, debug, etc.)                                    | `code`                      |
+| `--terminal-shell <path>`               | Absolute shell path for inline terminal command execution                               | Auto-detected shell         |
+| `-r, --reasoning-effort <effort>`       | Reasoning effort level (unspecified, disabled, none, minimal, low, medium, high, xhigh) | `medium`                    |
+| `--consecutive-mistake-limit <n>`       | Consecutive error/repetition limit before guidance prompt (`0` disables the limit)      | `10`                        |
+| `--ephemeral`                           | Run without persisting state (uses temporary storage)                                   | `false`                     |
+| `--oneshot`                             | Exit upon task completion                                                               | `false`                     |
+| `--output-format <format>`              | Output format with `--print`: `text`, `json`, or `stream-json`                          | `text`                      |
+
+## Environment Variables
+
+The CLI will look for API keys in environment variables if not provided via `--api-key`:
+
+| Provider          | Environment Variable        |
+| ----------------- | --------------------------- |
+| anthropic         | `ANTHROPIC_API_KEY`         |
+| openai-native     | `OPENAI_API_KEY`            |
+| openrouter        | `OPENROUTER_API_KEY`        |
+| gemini            | `GOOGLE_API_KEY`            |
+| vercel-ai-gateway | `VERCEL_AI_GATEWAY_API_KEY` |
+
+## Architecture
+
+```
+┌─────────────────┐
+│   CLI Entry     │
+│   (index.ts)    │
+└────────┬────────┘
+         │
+         ▼
+┌─────────────────┐
+│  ExtensionHost  │
+│  (extension-    │
+│   host.ts)      │
+└────────┬────────┘
+         │
+    ┌────┴────┐
+    │         │
+    ▼         ▼
+┌───────┐  ┌──────────┐
+│vscode │  │Extension │
+│-shim  │  │ Bundle   │
+└───────┘  └──────────┘
+```
+
+## How It Works
+
+1. **CLI Entry Point** (`index.ts`): Parses command line arguments and initializes the ExtensionHost
+
+2. **ExtensionHost** (`extension-host.ts`):
+
+    - Creates a VSCode API mock using `@roo-code/vscode-shim`
+    - Intercepts `require('vscode')` to return the mock
+    - Loads and activates the extension bundle
+    - Manages bidirectional message flow
+
+3. **Message Flow**:
+    - CLI → Extension: `emit("webviewMessage", {...})`
+    - Extension → CLI: `emit("extensionWebviewMessage", {...})`
+
+## Development
+
+```bash
+# Run directly from source (no build required)
+pnpm dev --provider openrouter --api-key $OPENROUTER_API_KEY --print "Hello"
+
+# Run tests
+pnpm test
+
+# Type checking
+pnpm check-types
+
+# Linting
+pnpm lint
+```
+
+## Releasing
+
+Official releases are created via the GitHub Actions workflow at `.github/workflows/cli-release.yml`.
+
+To trigger a release:
+
+1. Go to **Actions** → **CLI Release**
+2. Click **Run workflow**
+3. Optionally specify a version (defaults to `package.json` version)
+4. Click **Run workflow**
+
+The workflow will:
+
+1. Build the CLI on all platforms (macOS Apple Silicon, Linux x64)
+2. Create platform-specific tarballs with bundled ripgrep
+3. Verify each tarball
+4. Create a GitHub release with all tarballs attached
+
+### Local Builds
+
+For local development and testing, use the build script:
+
+```bash
+# Build tarball for your current platform
+./apps/cli/scripts/build.sh
+
+# Build and install locally
+./apps/cli/scripts/build.sh --install
+
+# Fast build (skip verification)
+./apps/cli/scripts/build.sh --skip-verify
+```

apps/cli/docs/AGENT_LOOP.md

@@ -0,0 +1,356 @@
+# CLI Agent Loop
+
+This document explains how the Roo Code CLI detects and tracks the agent loop state.
+
+## Overview
+
+The CLI needs to know when the agent is:
+
+- **Running** (actively processing)
+- **Streaming** (receiving content from the API)
+- **Waiting for input** (needs user approval or answer)
+- **Idle** (task completed or failed)
+
+This is accomplished by analyzing the messages the extension sends to the client.
+
+## The Message Model
+
+All agent activity is communicated through **ClineMessages** - a stream of timestamped messages that represent everything the agent does.
+
+### Message Structure
+
+```typescript
+interface ClineMessage {
+	ts: number // Unique timestamp identifier
+	type: "ask" | "say" // Message category
+	ask?: ClineAsk // Specific ask type (when type="ask")
+	say?: ClineSay // Specific say type (when type="say")
+	text?: string // Message content
+	partial?: boolean // Is this message still streaming?
+}
+```
+
+### Two Types of Messages
+
+| Type    | Purpose                                        | Blocks Agent? |
+| ------- | ---------------------------------------------- | ------------- |
+| **say** | Informational - agent is telling you something | No            |
+| **ask** | Interactive - agent needs something from you   | Usually yes   |
+
+## The Key Insight
+
+> **The agent loop stops whenever the last message is an `ask` type (with `partial: false`).**
+
+The specific `ask` value tells you exactly what the agent needs.
+
+## Ask Categories
+
+The CLI categorizes asks into four groups:
+
+### 1. Interactive Asks → `WAITING_FOR_INPUT` state
+
+These require user action to continue:
+
+| Ask Type                | What It Means                     | Required Response |
+| ----------------------- | --------------------------------- | ----------------- |
+| `tool`                  | Wants to edit/create/delete files | Approve or Reject |
+| `command`               | Wants to run a terminal command   | Approve or Reject |
+| `followup`              | Asking a question                 | Text answer       |
+| `browser_action_launch` | Wants to use the browser          | Approve or Reject |
+| `use_mcp_server`        | Wants to use an MCP server        | Approve or Reject |
+
+### 2. Idle Asks → `IDLE` state
+
+These indicate the task has stopped:
+
+| Ask Type                        | What It Means               | Response Options            |
+| ------------------------------- | --------------------------- | --------------------------- |
+| `completion_result`             | Task completed successfully | New task or feedback        |
+| `api_req_failed`                | API request failed          | Retry or new task           |
+| `mistake_limit_reached`         | Too many errors             | Continue anyway or new task |
+| `auto_approval_max_req_reached` | Auto-approval limit hit     | Continue manually or stop   |
+| `resume_completed_task`         | Viewing completed task      | New task                    |
+
+### 3. Resumable Asks → `RESUMABLE` state
+
+| Ask Type      | What It Means             | Response Options  |
+| ------------- | ------------------------- | ----------------- |
+| `resume_task` | Task paused mid-execution | Resume or abandon |
+
+### 4. Non-Blocking Asks → `RUNNING` state
+
+| Ask Type         | What It Means      | Response Options  |
+| ---------------- | ------------------ | ----------------- |
+| `command_output` | Command is running | Continue or abort |
+
+## Streaming Detection
+
+The agent is **streaming** when:
+
+1. **`partial: true`** on the last message, OR
+2. **An `api_req_started` message exists** with `cost: undefined` in its text field
+
+```typescript
+// Streaming detection pseudocode
+function isStreaming(messages) {
+	const lastMessage = messages.at(-1)
+
+	// Check partial flag (primary indicator)
+	if (lastMessage?.partial === true) {
+		return true
+	}
+
+	// Check for in-progress API request
+	const apiReq = messages.findLast((m) => m.say === "api_req_started")
+	if (apiReq?.text) {
+		const data = JSON.parse(apiReq.text)
+		if (data.cost === undefined) {
+			return true // API request not yet complete
+		}
+	}
+
+	return false
+}
+```
+
+## State Machine
+
+```
+                    ┌─────────────────┐
+                    │    NO_TASK      │  (no messages)
+                    └────────┬────────┘
+                             │ newTask
+                             ▼
+              ┌─────────────────────────────┐
+         ┌───▶│         RUNNING             │◀───┐
+         │    └──────────┬──────────────────┘    │
+         │               │                       │
+         │    ┌──────────┼──────────────┐        │
+         │    │          │              │        │
+         │    ▼          ▼              ▼        │
+         │ ┌──────┐  ┌─────────┐  ┌──────────┐   │
+         │ │STREAM│  │WAITING_ │  │   IDLE   │   │
+         │ │ ING  │  │FOR_INPUT│  │          │   │
+         │ └──┬───┘  └────┬────┘  └────┬─────┘   │
+         │    │           │            │         │
+         │    │ done      │ approved   │ newTask │
+         └────┴───────────┴────────────┘         │
+                                                 │
+         ┌──────────────┐                        │
+         │  RESUMABLE   │────────────────────────┘
+         └──────────────┘  resumed
+```
+
+## Architecture
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│                        ExtensionHost                            │
+│                                                                 │
+│  ┌──────────────────┐                                           │
+│  │   Extension      │──── extensionWebviewMessage ─────┐        │
+│  │   (Task.ts)      │                                  │        │
+│  └──────────────────┘                                  │        │
+│                                                        ▼        │
+│  ┌───────────────────────────────────────────────────────────┐  │
+│  │                    ExtensionClient                        │  │
+│  │                (Single Source of Truth)                   │  │
+│  │                                                           │  │
+│  │  ┌─────────────────┐    ┌────────────────────┐            │  │
+│  │  │ MessageProcessor │───▶│    StateStore     │            │  │
+│  │  │                 │    │  (clineMessages)   │            │  │
+│  │  └─────────────────┘    └────────┬───────────┘            │  │
+│  │                                  │                        │  │
+│  │                                  ▼                        │  │
+│  │                         detectAgentState()                │  │
+│  │                                  │                        │  │
+│  │                                  ▼                        │  │
+│  │  Events: stateChange, message, waitingForInput, etc.      │  │
+│  └───────────────────────────────────────────────────────────┘  │
+│                           │                                     │
+│                           ▼                                     │
+│  ┌────────────────┐  ┌────────────────┐  ┌────────────────┐     │
+│  │ OutputManager  │  │  AskDispatcher │  │ PromptManager  │     │
+│  │  (stdout)      │  │  (ask routing) │  │  (user input)  │     │
+│  └────────────────┘  └────────────────┘  └────────────────┘     │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+## Component Responsibilities
+
+### ExtensionClient
+
+The **single source of truth** for agent state, including the current mode. It:
+
+- Receives all messages from the extension
+- Stores them in the `StateStore`
+- Tracks the current mode from state messages
+- Computes the current state via `detectAgentState()`
+- Emits events when state changes (including mode changes)
+
+```typescript
+const client = new ExtensionClient({
+	sendMessage: (msg) => extensionHost.sendToExtension(msg),
+	debug: true, // Writes to ~/.roo/cli-debug.log
+})
+
+// Query state at any time
+const state = client.getAgentState()
+if (state.isWaitingForInput) {
+	console.log(`Agent needs: ${state.currentAsk}`)
+}
+
+// Query current mode
+const mode = client.getCurrentMode()
+console.log(`Current mode: ${mode}`) // e.g., "code", "architect", "ask"
+
+// Subscribe to events
+client.on("waitingForInput", (event) => {
+	console.log(`Waiting for: ${event.ask}`)
+})
+
+// Subscribe to mode changes
+client.on("modeChanged", (event) => {
+	console.log(`Mode changed: ${event.previousMode} -> ${event.currentMode}`)
+})
+```
+
+### StateStore
+
+Holds the `clineMessages` array, computed state, and current mode:
+
+```typescript
+interface StoreState {
+	messages: ClineMessage[] // The raw message array
+	agentState: AgentStateInfo // Computed state
+	isInitialized: boolean // Have we received any state?
+	currentMode: string | undefined // Current mode (e.g., "code", "architect")
+}
+```
+
+### MessageProcessor
+
+Handles incoming messages from the extension:
+
+- `"state"` messages → Update `clineMessages` array and track mode
+- `"messageUpdated"` messages → Update single message in array
+- Emits events for state transitions and mode changes
+
+### AskDispatcher
+
+Routes asks to appropriate handlers:
+
+- Uses type guards: `isIdleAsk()`, `isInteractiveAsk()`, etc.
+- Coordinates between `OutputManager` and `PromptManager`
+- By default, the CLI auto-approves tool/command/browser/MCP actions
+- In `--require-approval` mode, those actions prompt for manual approval
+
+### OutputManager
+
+Handles all CLI output:
+
+- Streams partial content with delta computation
+- Tracks what's been displayed to avoid duplicates
+- Writes directly to `process.stdout` (bypasses quiet mode)
+
+### PromptManager
+
+Handles user input:
+
+- Yes/no prompts
+- Text input prompts
+- Timed prompts with auto-defaults
+
+## Response Messages
+
+When the agent is waiting, send these responses:
+
+```typescript
+// Approve an action (tool, command, browser, MCP)
+client.sendMessage({
+	type: "askResponse",
+	askResponse: "yesButtonClicked",
+})
+
+// Reject an action
+client.sendMessage({
+	type: "askResponse",
+	askResponse: "noButtonClicked",
+})
+
+// Answer a question
+client.sendMessage({
+	type: "askResponse",
+	askResponse: "messageResponse",
+	text: "My answer here",
+})
+
+// Start a new task
+client.sendMessage({
+	type: "newTask",
+	text: "Build a web app",
+})
+
+// Cancel current task
+client.sendMessage({
+	type: "cancelTask",
+})
+```
+
+## Type Guards
+
+The CLI uses type guards from `@roo-code/types` for categorization:
+
+```typescript
+import { isIdleAsk, isInteractiveAsk, isResumableAsk, isNonBlockingAsk } from "@roo-code/types"
+
+const ask = message.ask
+if (isInteractiveAsk(ask)) {
+	// Needs approval: tool, command, followup, etc.
+} else if (isIdleAsk(ask)) {
+	// Task stopped: completion_result, api_req_failed, etc.
+} else if (isResumableAsk(ask)) {
+	// Task paused: resume_task
+} else if (isNonBlockingAsk(ask)) {
+	// Command running: command_output
+}
+```
+
+## Debug Logging
+
+Enable with `-d` flag. Logs go to `~/.roo/cli-debug.log`:
+
+```bash
+roo -d -P "Build something" --no-tui
+```
+
+View logs:
+
+```bash
+tail -f ~/.roo/cli-debug.log
+```
+
+Example output:
+
+```
+[MessageProcessor] State update: {
+  "messageCount": 5,
+  "lastMessage": {
+    "msgType": "ask:completion_result"
+  },
+  "stateTransition": "running → idle",
+  "currentAsk": "completion_result",
+  "isWaitingForInput": true
+}
+[MessageProcessor] EMIT waitingForInput: { "ask": "completion_result" }
+[MessageProcessor] EMIT taskCompleted: { "success": true }
+```
+
+## Summary
+
+1. **Agent communicates via `ClineMessage` stream**
+2. **Last message determines state**
+3. **`ask` messages (non-partial) block the agent**
+4. **Ask category determines required action**
+5. **`partial: true` or `api_req_started` without cost = streaming**
+6. **`ExtensionClient` is the single source of truth**

apps/cli/install.sh

@@ -0,0 +1,353 @@
+#!/bin/sh
+# Roo Code CLI Installer
+# Usage: curl -fsSL https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/install.sh | sh
+#
+# Environment variables:
+#   ROO_INSTALL_DIR   - Installation directory (default: ~/.roo/cli)
+#   ROO_BIN_DIR       - Binary symlink directory (default: ~/.local/bin)
+#   ROO_VERSION       - Specific version to install (default: latest)
+#   ROO_LOCAL_TARBALL - Path to local tarball to install (skips download)
+
+set -e
+
+# Configuration
+INSTALL_DIR="${ROO_INSTALL_DIR:-$HOME/.roo/cli}"
+BIN_DIR="${ROO_BIN_DIR:-$HOME/.local/bin}"
+REPO="RooCodeInc/Roo-Code"
+MIN_NODE_VERSION=20
+
+# Color output (only if terminal supports it)
+if [ -t 1 ]; then
+    RED='\033[0;31m'
+    GREEN='\033[0;32m'
+    YELLOW='\033[1;33m'
+    BLUE='\033[0;34m'
+    BOLD='\033[1m'
+    NC='\033[0m'
+else
+    RED=''
+    GREEN=''
+    YELLOW=''
+    BLUE=''
+    BOLD=''
+    NC=''
+fi
+
+info() { printf "${GREEN}==>${NC} %s\n" "$1"; }
+warn() { printf "${YELLOW}Warning:${NC} %s\n" "$1"; }
+error() { printf "${RED}Error:${NC} %s\n" "$1" >&2; exit 1; }
+
+# Check Node.js version
+check_node() {
+    if ! command -v node >/dev/null 2>&1; then
+        error "Node.js is not installed. Please install Node.js $MIN_NODE_VERSION or higher.
+
+Install Node.js:
+  - macOS: brew install node
+  - Linux: https://nodejs.org/en/download/package-manager
+  - Or use a version manager like fnm, nvm, or mise"
+    fi
+    
+    NODE_VERSION=$(node -v | sed 's/v//' | cut -d. -f1)
+    if [ "$NODE_VERSION" -lt "$MIN_NODE_VERSION" ]; then
+        error "Node.js $MIN_NODE_VERSION+ required. Found: $(node -v)
+
+Please upgrade Node.js to version $MIN_NODE_VERSION or higher."
+    fi
+    
+    info "Found Node.js $(node -v)"
+}
+
+# Detect OS and architecture
+detect_platform() {
+    OS=$(uname -s | tr '[:upper:]' '[:lower:]')
+    ARCH=$(uname -m)
+    
+    case "$OS" in
+        darwin) OS="darwin" ;;
+        linux) OS="linux" ;;
+        mingw*|msys*|cygwin*) 
+            error "Windows is not supported by this installer. Please use WSL or install manually."
+            ;;
+        *) error "Unsupported OS: $OS" ;;
+    esac
+    
+    case "$ARCH" in
+        x86_64|amd64) ARCH="x64" ;;
+        arm64|aarch64) ARCH="arm64" ;;
+        *) error "Unsupported architecture: $ARCH" ;;
+    esac
+    
+    PLATFORM="${OS}-${ARCH}"
+    info "Detected platform: $PLATFORM"
+}
+
+# Get latest release version or use specified version
+get_version() {
+    # Skip version fetch if using local tarball
+    if [ -n "$ROO_LOCAL_TARBALL" ]; then
+        VERSION="${ROO_VERSION:-local}"
+        info "Using local tarball (version: $VERSION)"
+        return
+    fi
+    
+    if [ -n "$ROO_VERSION" ]; then
+        VERSION="$ROO_VERSION"
+        info "Using specified version: $VERSION"
+        return
+    fi
+    
+    info "Fetching latest version..."
+    
+    # Try to get the latest cli release
+    RELEASES_JSON=$(curl -fsSL "https://api.github.com/repos/$REPO/releases" 2>/dev/null) || {
+        error "Failed to fetch releases from GitHub. Check your internet connection."
+    }
+    
+    # Extract highest cli-v* tag by semantic version (do not rely on API ordering)
+    VERSION=$(printf "%s" "$RELEASES_JSON" | node -e '
+const fs = require("fs")
+const input = fs.readFileSync(0, "utf8")
+let releases
+try {
+  releases = JSON.parse(input)
+} catch {
+  process.exit(1)
+}
+
+function parseVersion(version) {
+  const core = String(version).trim().split("+", 1)[0].split("-", 1)[0]
+  if (!core) return null
+  const parts = core.split(".")
+  if (parts.length === 0 || parts.some((part) => !/^\d+$/.test(part))) {
+    return null
+  }
+  return parts.map((part) => Number.parseInt(part, 10))
+}
+
+function compareVersions(a, b) {
+  const maxLength = Math.max(a.length, b.length)
+  for (let i = 0; i < maxLength; i++) {
+    const aPart = a[i] ?? 0
+    const bPart = b[i] ?? 0
+    if (aPart > bPart) return 1
+    if (aPart < bPart) return -1
+  }
+  return 0
+}
+
+let latestVersion = ""
+let latestParts = null
+
+if (Array.isArray(releases)) {
+  for (const release of releases) {
+    if (!release || typeof release.tag_name !== "string" || !release.tag_name.startsWith("cli-v")) {
+      continue
+    }
+    const candidate = release.tag_name.slice("cli-v".length)
+    const candidateParts = parseVersion(candidate)
+    if (!candidateParts) continue
+    if (!latestParts || compareVersions(candidateParts, latestParts) > 0) {
+      latestVersion = candidate
+      latestParts = candidateParts
+    }
+  }
+}
+
+if (latestVersion) {
+  process.stdout.write(latestVersion)
+}
+')
+    
+    if [ -z "$VERSION" ]; then
+        error "Could not find any CLI releases. The CLI may not have been released yet."
+    fi
+    
+    info "Latest version: $VERSION"
+}
+
+# Download and extract
+download_and_install() {
+    TARBALL="roo-cli-${PLATFORM}.tar.gz"
+    
+    # Create temp directory
+    TMP_DIR=$(mktemp -d)
+    trap "rm -rf $TMP_DIR" EXIT
+    
+    # Use local tarball if provided, otherwise download
+    if [ -n "$ROO_LOCAL_TARBALL" ]; then
+        if [ ! -f "$ROO_LOCAL_TARBALL" ]; then
+            error "Local tarball not found: $ROO_LOCAL_TARBALL"
+        fi
+        info "Using local tarball: $ROO_LOCAL_TARBALL"
+        cp "$ROO_LOCAL_TARBALL" "$TMP_DIR/$TARBALL"
+    else
+        URL="https://github.com/$REPO/releases/download/cli-v${VERSION}/${TARBALL}"
+        
+        info "Downloading from $URL..."
+        
+        # Download with progress indicator
+        HTTP_CODE=$(curl -fsSL -w "%{http_code}" "$URL" -o "$TMP_DIR/$TARBALL" 2>/dev/null) || {
+            if [ "$HTTP_CODE" = "404" ]; then
+                error "Release not found for platform $PLATFORM version $VERSION.
+
+Available at: https://github.com/$REPO/releases"
+            fi
+            error "Download failed. HTTP code: $HTTP_CODE"
+        }
+
+        # Verify we got something
+        if [ ! -s "$TMP_DIR/$TARBALL" ]; then
+            error "Downloaded file is empty. Please try again."
+        fi
+    fi
+
+    # Remove old installation if exists
+    if [ -d "$INSTALL_DIR" ]; then
+        info "Removing previous installation..."
+        rm -rf "$INSTALL_DIR"
+    fi
+    
+    mkdir -p "$INSTALL_DIR"
+    
+    # Extract
+    info "Extracting to $INSTALL_DIR..."
+    tar -xzf "$TMP_DIR/$TARBALL" -C "$INSTALL_DIR" --strip-components=1 || {
+        error "Failed to extract tarball. The download may be corrupted."
+    }
+    
+    # Save ripgrep binary before npm install (npm install will overwrite node_modules)
+    RIPGREP_BIN=""
+    if [ -f "$INSTALL_DIR/node_modules/@vscode/ripgrep/bin/rg" ]; then
+        RIPGREP_BIN="$TMP_DIR/rg"
+        cp "$INSTALL_DIR/node_modules/@vscode/ripgrep/bin/rg" "$RIPGREP_BIN"
+    fi
+    
+    # Install npm dependencies
+    info "Installing dependencies..."
+    cd "$INSTALL_DIR"
+    npm install --production --silent 2>/dev/null || {
+        warn "npm install failed, trying with --legacy-peer-deps..."
+        npm install --production --legacy-peer-deps --silent 2>/dev/null || {
+            error "Failed to install dependencies. Make sure npm is available."
+        }
+    }
+    cd - > /dev/null
+    
+    # Restore ripgrep binary after npm install
+    if [ -n "$RIPGREP_BIN" ] && [ -f "$RIPGREP_BIN" ]; then
+        mkdir -p "$INSTALL_DIR/node_modules/@vscode/ripgrep/bin"
+        cp "$RIPGREP_BIN" "$INSTALL_DIR/node_modules/@vscode/ripgrep/bin/rg"
+        chmod +x "$INSTALL_DIR/node_modules/@vscode/ripgrep/bin/rg"
+    fi
+    
+    # Make executable
+    chmod +x "$INSTALL_DIR/bin/roo"
+    
+    # Also make ripgrep executable if it exists
+    if [ -f "$INSTALL_DIR/bin/rg" ]; then
+        chmod +x "$INSTALL_DIR/bin/rg"
+    fi
+}
+
+# Create symlink in bin directory
+setup_bin() {
+    mkdir -p "$BIN_DIR"
+    
+    # Remove old symlink if exists
+    if [ -L "$BIN_DIR/roo" ] || [ -f "$BIN_DIR/roo" ]; then
+        rm -f "$BIN_DIR/roo"
+    fi
+    
+    ln -sf "$INSTALL_DIR/bin/roo" "$BIN_DIR/roo"
+    info "Created symlink: $BIN_DIR/roo"
+}
+
+# Check if bin dir is in PATH and provide instructions
+check_path() {
+    case ":$PATH:" in
+        *":$BIN_DIR:"*) 
+            # Already in PATH
+            return 0
+            ;;
+    esac
+    
+    warn "$BIN_DIR is not in your PATH"
+    echo ""
+    echo "Add this line to your shell profile:"
+    echo ""
+    
+    # Detect shell and provide specific instructions
+    SHELL_NAME=$(basename "$SHELL")
+    case "$SHELL_NAME" in
+        zsh)
+            echo "  echo 'export PATH=\"$BIN_DIR:\$PATH\"' >> ~/.zshrc"
+            echo "  source ~/.zshrc"
+            ;;
+        bash)
+            if [ -f "$HOME/.bashrc" ]; then
+                echo "  echo 'export PATH=\"$BIN_DIR:\$PATH\"' >> ~/.bashrc"
+                echo "  source ~/.bashrc"
+            else
+                echo "  echo 'export PATH=\"$BIN_DIR:\$PATH\"' >> ~/.bash_profile"
+                echo "  source ~/.bash_profile"
+            fi
+            ;;
+        fish)
+            echo "  set -Ux fish_user_paths $BIN_DIR \$fish_user_paths"
+            ;;
+        *)
+            echo "  export PATH=\"$BIN_DIR:\$PATH\""
+            ;;
+    esac
+    echo ""
+}
+
+# Verify installation
+verify_install() {
+    if [ -x "$BIN_DIR/roo" ]; then
+        info "Verifying installation..."
+        # Just check if it runs without error
+        "$BIN_DIR/roo" --version >/dev/null 2>&1 || true
+    fi
+}
+
+# Print success message
+print_success() {
+    echo ""
+    printf "${GREEN}${BOLD}✓ Roo Code CLI installed successfully!${NC}\n"
+    echo ""
+    echo "  Installation: $INSTALL_DIR"
+    echo "  Binary: $BIN_DIR/roo"
+    echo "  Version: $VERSION"
+    echo ""
+    echo "  ${BOLD}Get started:${NC}"
+    echo "    roo --help"
+    echo ""
+    echo "  ${BOLD}Example:${NC}"
+    echo "    export OPENROUTER_API_KEY=sk-or-v1-..."
+    echo "    cd ~/my-project && roo \"What is this project?\""
+    echo ""
+}
+
+# Main
+main() {
+    echo ""
+    printf "${BLUE}${BOLD}"
+    echo "  ╭─────────────────────────────────╮"
+    echo "  │     Roo Code CLI Installer      │"
+    echo "  ╰─────────────────────────────────╯"
+    printf "${NC}"
+    echo ""
+    
+    check_node
+    detect_platform
+    get_version
+    download_and_install
+    setup_bin
+    check_path
+    verify_install
+    print_success
+}
+
+main "$@"

apps/cli/package.json

@@ -0,0 +1,50 @@
+{
+	"name": "@roo-code/cli",
+	"version": "0.1.17",
+	"description": "Roo Code CLI - Run the Roo Code agent from the command line",
+	"private": true,
+	"type": "module",
+	"main": "dist/index.js",
+	"bin": {
+		"roo": "dist/index.js"
+	},
+	"scripts": {
+		"format": "prettier --write 'src/**/*.ts'",
+		"lint": "eslint src --ext .ts --max-warnings=0",
+		"check-types": "tsc --noEmit",
+		"test": "vitest run",
+		"test:integration": "tsx scripts/integration/run.ts",
+		"build": "tsup",
+		"build:extension": "pnpm --filter roo-cline bundle",
+		"dev": "tsx src/index.ts",
+		"dev:local": "tsx src/index.ts",
+		"clean": "rimraf dist .turbo"
+	},
+	"dependencies": {
+		"@inkjs/ui": "^2.0.0",
+		"@roo-code/core": "workspace:^",
+		"@roo-code/types": "workspace:^",
+		"@roo-code/vscode-shim": "workspace:^",
+		"@trpc/client": "^11.8.1",
+		"@vscode/ripgrep": "^1.15.9",
+		"commander": "^12.1.0",
+		"cross-spawn": "^7.0.6",
+		"execa": "^9.5.2",
+		"fuzzysort": "^3.1.0",
+		"ink": "^6.6.0",
+		"p-wait-for": "^5.0.2",
+		"react": "^19.1.0",
+		"superjson": "^2.2.6",
+		"zustand": "^5.0.0"
+	},
+	"devDependencies": {
+		"@roo-code/config-eslint": "workspace:^",
+		"@roo-code/config-typescript": "workspace:^",
+		"@types/node": "^24.1.0",
+		"@types/react": "^19.1.6",
+		"ink-testing-library": "^4.0.0",
+		"rimraf": "^6.0.1",
+		"tsup": "^8.4.0",
+		"vitest": "^3.2.3"
+	}
+}

apps/cli/scripts/build.sh

@@ -0,0 +1,358 @@
+#!/bin/bash
+# Roo Code CLI Local Build Script
+#
+# Usage:
+#   ./apps/cli/scripts/build.sh [options]
+#
+# Options:
+#   --install      Install locally after building
+#   --skip-verify  Skip end-to-end verification tests (faster builds)
+#
+# Examples:
+#   ./apps/cli/scripts/build.sh              # Build for local testing
+#   ./apps/cli/scripts/build.sh --install    # Build and install locally
+#   ./apps/cli/scripts/build.sh --skip-verify  # Fast local build
+#
+# This script builds the CLI for your current platform. For official releases
+# with multi-platform support, use the GitHub Actions workflow instead:
+#   .github/workflows/cli-release.yml
+#
+# Prerequisites:
+#   - pnpm installed
+#   - Run from the monorepo root directory
+
+set -e
+
+# Parse arguments
+LOCAL_INSTALL=false
+SKIP_VERIFY=false
+
+while [[ $# -gt 0 ]]; do
+    case $1 in
+        --install)
+            LOCAL_INSTALL=true
+            shift
+            ;;
+        --skip-verify)
+            SKIP_VERIFY=true
+            shift
+            ;;
+        -*)
+            echo "Unknown option: $1" >&2
+            exit 1
+            ;;
+        *)
+            shift
+            ;;
+    esac
+done
+
+# Colors
+RED='\033[0;31m'
+GREEN='\033[0;32m'
+YELLOW='\033[1;33m'
+BLUE='\033[0;34m'
+BOLD='\033[1m'
+NC='\033[0m'
+
+info() { printf "${GREEN}==>${NC} %s\n" "$1"; }
+warn() { printf "${YELLOW}Warning:${NC} %s\n" "$1"; }
+error() { printf "${RED}Error:${NC} %s\n" "$1" >&2; exit 1; }
+step() { printf "${BLUE}${BOLD}[%s]${NC} %s\n" "$1" "$2"; }
+
+# Get script directory and repo root
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+REPO_ROOT="$(cd "$SCRIPT_DIR/../../.." && pwd)"
+CLI_DIR="$REPO_ROOT/apps/cli"
+
+# Detect current platform
+detect_platform() {
+    OS=$(uname -s | tr '[:upper:]' '[:lower:]')
+    ARCH=$(uname -m)
+
+    case "$OS" in
+        darwin) OS="darwin" ;;
+        linux) OS="linux" ;;
+        *) error "Unsupported OS: $OS" ;;
+    esac
+
+    case "$ARCH" in
+        x86_64|amd64) ARCH="x64" ;;
+        arm64|aarch64) ARCH="arm64" ;;
+        *) error "Unsupported architecture: $ARCH" ;;
+    esac
+
+    PLATFORM="${OS}-${ARCH}"
+}
+
+# Check prerequisites
+check_prerequisites() {
+    step "1/6" "Checking prerequisites..."
+
+    if ! command -v pnpm &> /dev/null; then
+        error "pnpm is not installed."
+    fi
+
+    if ! command -v node &> /dev/null; then
+        error "Node.js is not installed."
+    fi
+
+    info "Prerequisites OK"
+}
+
+# Get version
+get_version() {
+    VERSION=$(node -p "require('$CLI_DIR/package.json').version")
+    GIT_SHORT_HASH=$(git rev-parse --short HEAD 2>/dev/null || echo "unknown")
+    VERSION="${VERSION}-local.${GIT_SHORT_HASH}"
+
+    info "Version: $VERSION"
+}
+
+# Build everything
+build() {
+    step "2/6" "Building extension bundle..."
+    cd "$REPO_ROOT"
+    pnpm bundle
+
+    step "3/6" "Building CLI..."
+    pnpm --filter @roo-code/cli build
+
+    info "Build complete"
+}
+
+# Create release tarball
+create_tarball() {
+    step "4/6" "Creating release tarball for $PLATFORM..."
+
+    RELEASE_DIR="$REPO_ROOT/roo-cli-${PLATFORM}"
+    TARBALL="roo-cli-${PLATFORM}.tar.gz"
+
+    # Clean up any previous build
+    rm -rf "$RELEASE_DIR"
+    rm -f "$REPO_ROOT/$TARBALL"
+
+    # Create directory structure
+    mkdir -p "$RELEASE_DIR/bin"
+    mkdir -p "$RELEASE_DIR/lib"
+    mkdir -p "$RELEASE_DIR/extension"
+
+    # Copy CLI dist files
+    info "Copying CLI files..."
+    cp -r "$CLI_DIR/dist/"* "$RELEASE_DIR/lib/"
+
+    # Create package.json for npm install
+    info "Creating package.json..."
+    node -e "
+      const pkg = require('$CLI_DIR/package.json');
+      const newPkg = {
+        name: '@roo-code/cli',
+        version: '$VERSION',
+        type: 'module',
+        dependencies: {
+          '@inkjs/ui': pkg.dependencies['@inkjs/ui'],
+          '@trpc/client': pkg.dependencies['@trpc/client'],
+          'commander': pkg.dependencies.commander,
+          'fuzzysort': pkg.dependencies.fuzzysort,
+          'ink': pkg.dependencies.ink,
+          'p-wait-for': pkg.dependencies['p-wait-for'],
+          'react': pkg.dependencies.react,
+          'superjson': pkg.dependencies.superjson,
+          'zustand': pkg.dependencies.zustand
+        }
+      };
+      console.log(JSON.stringify(newPkg, null, 2));
+    " > "$RELEASE_DIR/package.json"
+
+    # Copy extension bundle
+    info "Copying extension bundle..."
+    cp -r "$REPO_ROOT/src/dist/"* "$RELEASE_DIR/extension/"
+
+    # Add package.json to extension directory for CommonJS
+    echo '{"type": "commonjs"}' > "$RELEASE_DIR/extension/package.json"
+
+    # Find and copy ripgrep binary
+    info "Looking for ripgrep binary..."
+    RIPGREP_PATH=$(find "$REPO_ROOT/node_modules" -path "*/@vscode/ripgrep/bin/rg" -type f 2>/dev/null | head -1)
+    if [ -n "$RIPGREP_PATH" ] && [ -f "$RIPGREP_PATH" ]; then
+        info "Found ripgrep at: $RIPGREP_PATH"
+        mkdir -p "$RELEASE_DIR/node_modules/@vscode/ripgrep/bin"
+        cp "$RIPGREP_PATH" "$RELEASE_DIR/node_modules/@vscode/ripgrep/bin/"
+        chmod +x "$RELEASE_DIR/node_modules/@vscode/ripgrep/bin/rg"
+        mkdir -p "$RELEASE_DIR/bin"
+        cp "$RIPGREP_PATH" "$RELEASE_DIR/bin/"
+        chmod +x "$RELEASE_DIR/bin/rg"
+    else
+        warn "ripgrep binary not found - users will need ripgrep installed"
+    fi
+
+    # Create the wrapper script
+    info "Creating wrapper script..."
+    cat > "$RELEASE_DIR/bin/roo" << 'WRAPPER_EOF'
+#!/usr/bin/env node
+
+import { fileURLToPath } from 'url';
+import { dirname, join } from 'path';
+import { existsSync } from 'fs';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = dirname(__filename);
+
+// Set environment variables for the CLI
+process.env.ROO_CLI_ROOT = join(__dirname, '..');
+process.env.ROO_EXTENSION_PATH = join(__dirname, '..', 'extension');
+const ripgrepPath = join(__dirname, 'rg');
+if (existsSync(ripgrepPath)) {
+  process.env.ROO_RIPGREP_PATH = ripgrepPath;
+}
+
+// Import and run the actual CLI
+await import(join(__dirname, '..', 'lib', 'index.js'));
+WRAPPER_EOF
+
+    chmod +x "$RELEASE_DIR/bin/roo"
+
+    # Create empty .env file
+    touch "$RELEASE_DIR/.env"
+
+    # Strip macOS metadata artifacts before packaging.
+    find "$RELEASE_DIR" -type f -name "._*" -delete
+    find "$RELEASE_DIR" -type f -name ".DS_Store" -delete
+    find "$RELEASE_DIR" -type d -name "__MACOSX" -prune -exec rm -rf {} +
+
+    # Create tarball
+    info "Creating tarball..."
+    cd "$REPO_ROOT"
+    COPYFILE_DISABLE=1 tar \
+        --exclude="._*" \
+        --exclude=".DS_Store" \
+        --exclude="__MACOSX" \
+        --exclude="*/._*" \
+        --exclude="*/.DS_Store" \
+        -czvf "$TARBALL" "$(basename "$RELEASE_DIR")"
+
+    # Clean up release directory
+    rm -rf "$RELEASE_DIR"
+
+    # Show size
+    TARBALL_PATH="$REPO_ROOT/$TARBALL"
+    TARBALL_SIZE=$(ls -lh "$TARBALL_PATH" | awk '{print $5}')
+    info "Created: $TARBALL ($TARBALL_SIZE)"
+}
+
+# Verify local installation
+verify_local_install() {
+    if [ "$SKIP_VERIFY" = true ]; then
+        step "5/6" "Skipping verification (--skip-verify)"
+        return
+    fi
+
+    step "5/6" "Verifying installation..."
+
+    VERIFY_DIR="$REPO_ROOT/.verify-release"
+    VERIFY_INSTALL_DIR="$VERIFY_DIR/cli"
+    VERIFY_BIN_DIR="$VERIFY_DIR/bin"
+
+    rm -rf "$VERIFY_DIR"
+    mkdir -p "$VERIFY_DIR"
+
+    TARBALL_PATH="$REPO_ROOT/$TARBALL"
+
+    ROO_LOCAL_TARBALL="$TARBALL_PATH" \
+    ROO_INSTALL_DIR="$VERIFY_INSTALL_DIR" \
+    ROO_BIN_DIR="$VERIFY_BIN_DIR" \
+    ROO_VERSION="$VERSION" \
+    "$CLI_DIR/install.sh" || {
+        rm -rf "$VERIFY_DIR"
+        error "Installation verification failed!"
+    }
+
+    # Test --help
+    if ! "$VERIFY_BIN_DIR/roo" --help > /dev/null 2>&1; then
+        rm -rf "$VERIFY_DIR"
+        error "CLI --help check failed!"
+    fi
+    info "CLI --help check passed"
+
+    # Test --version
+    if ! "$VERIFY_BIN_DIR/roo" --version > /dev/null 2>&1; then
+        rm -rf "$VERIFY_DIR"
+        error "CLI --version check failed!"
+    fi
+    info "CLI --version check passed"
+
+    cd "$REPO_ROOT"
+    rm -rf "$VERIFY_DIR"
+
+    info "Verification passed!"
+}
+
+# Install locally
+install_local() {
+    if [ "$LOCAL_INSTALL" = false ]; then
+        step "6/6" "Skipping install (use --install to auto-install)"
+        return
+    fi
+
+    step "6/6" "Installing locally..."
+
+    TARBALL_PATH="$REPO_ROOT/$TARBALL"
+
+    ROO_LOCAL_TARBALL="$TARBALL_PATH" \
+    ROO_VERSION="$VERSION" \
+    "$CLI_DIR/install.sh" || {
+        error "Local installation failed!"
+    }
+
+    info "Local installation complete!"
+}
+
+# Print summary
+print_summary() {
+    echo ""
+    printf "${GREEN}${BOLD}✓ Local build complete for v$VERSION${NC}\n"
+    echo ""
+    echo "  Tarball: $REPO_ROOT/$TARBALL"
+    echo ""
+
+    if [ "$LOCAL_INSTALL" = true ]; then
+        echo "  Installed to: ~/.roo/cli"
+        echo "  Binary: ~/.local/bin/roo"
+        echo ""
+        echo "  Test it out:"
+        echo "    roo --version"
+        echo "    roo --help"
+    else
+        echo "  To install manually:"
+        echo "    ROO_LOCAL_TARBALL=$REPO_ROOT/$TARBALL ./apps/cli/install.sh"
+        echo ""
+        echo "  Or re-run with --install:"
+        echo "    ./apps/cli/scripts/build.sh --install"
+    fi
+    echo ""
+    echo "  For official multi-platform releases, use the GitHub Actions workflow:"
+    echo "    .github/workflows/cli-release.yml"
+    echo ""
+}
+
+# Main
+main() {
+    echo ""
+    printf "${BLUE}${BOLD}"
+    echo "  ╭─────────────────────────────────╮"
+    echo "  │   Roo Code CLI Local Build      │"
+    echo "  ╰─────────────────────────────────╯"
+    printf "${NC}"
+    echo ""
+
+    detect_platform
+    check_prerequisites
+    get_version
+    build
+    create_tarball
+    verify_local_install
+    install_local
+    print_summary
+}
+
+main

apps/cli/scripts/integration/cases/cancel-active-task.ts

@@ -0,0 +1,104 @@
+import { runStreamCase, StreamEvent } from "../lib/stream-harness"
+
+const LONG_PROMPT =
+	'Run exactly this command and do not summarize until it finishes: sleep 12 && echo "done". After it finishes, reply with exactly "done".'
+
+async function main() {
+	const startRequestId = `start-a-${Date.now()}`
+	const cancelRequestId = `cancel-${Date.now()}`
+	const shutdownRequestId = `shutdown-${Date.now()}`
+
+	let initSeen = false
+	let startAccepted = false
+	let startCommandToolUseSeen = false
+	let sentCancel = false
+	let cancelDone = false
+	let sentShutdown = false
+
+	await runStreamCase({
+		onEvent(event: StreamEvent, context) {
+			if (event.type === "system" && event.subtype === "init" && !initSeen) {
+				initSeen = true
+				context.sendCommand({
+					command: "start",
+					requestId: startRequestId,
+					prompt: LONG_PROMPT,
+				})
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "ack" &&
+				event.command === "start" &&
+				event.requestId === startRequestId
+			) {
+				startAccepted = true
+				return
+			}
+
+			if (
+				event.type === "tool_use" &&
+				event.subtype === "command" &&
+				event.done === true &&
+				event.requestId === startRequestId
+			) {
+				startCommandToolUseSeen = true
+			}
+
+			if (startAccepted && startCommandToolUseSeen && !sentCancel) {
+				context.sendCommand({
+					command: "cancel",
+					requestId: cancelRequestId,
+				})
+				sentCancel = true
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "done" &&
+				event.command === "cancel" &&
+				event.requestId === cancelRequestId
+			) {
+				if (event.code === "cancel_requested" || event.code === "no_active_task") {
+					cancelDone = true
+				}
+				return
+			}
+
+			if (cancelDone && !sentShutdown) {
+				context.sendCommand({
+					command: "shutdown",
+					requestId: shutdownRequestId,
+				})
+				sentShutdown = true
+				return
+			}
+
+			if (event.type === "control" && event.subtype === "error" && event.requestId === cancelRequestId) {
+				throw new Error(
+					`cancel command failed with code=${event.code ?? "unknown"} content="${event.content ?? ""}"`,
+				)
+			}
+
+			if (event.type === "error") {
+				throw new Error(`unexpected stream error event: ${event.content ?? "unknown error"}`)
+			}
+		},
+		onTimeoutMessage() {
+			return `timed out waiting for cancel flow (initSeen=${initSeen}, startAccepted=${startAccepted}, startCommandToolUseSeen=${startCommandToolUseSeen}, sentCancel=${sentCancel}, cancelDone=${cancelDone}, sentShutdown=${sentShutdown})`
+		},
+	})
+
+	if (!startAccepted || !startCommandToolUseSeen || !sentCancel || !cancelDone || !sentShutdown) {
+		throw new Error(
+			`cancel flow did not complete expected transitions (startAccepted=${startAccepted}, startCommandToolUseSeen=${startCommandToolUseSeen}, sentCancel=${sentCancel}, cancelDone=${cancelDone}, sentShutdown=${sentShutdown})`,
+		)
+	}
+}
+
+main().catch((error) => {
+	console.error(`[FAIL] ${error instanceof Error ? error.message : String(error)}`)
+	process.exit(1)
+})

apps/cli/scripts/integration/cases/cancel-immediately-after-start-ack.ts

@@ -0,0 +1,83 @@
+import { runStreamCase, StreamEvent } from "../lib/stream-harness"
+
+const LONG_PROMPT =
+	'Run exactly this command and do not summarize until it finishes: sleep 12 && echo "done". After it finishes, reply with exactly "done".'
+
+async function main() {
+	const startRequestId = `start-${Date.now()}`
+	const cancelRequestId = `cancel-${Date.now()}`
+	const shutdownRequestId = `shutdown-${Date.now()}`
+
+	let initSeen = false
+	let startAccepted = false
+	let sentCancel = false
+	let cancelDone = false
+	let sentShutdown = false
+
+	await runStreamCase({
+		onEvent(event: StreamEvent, context) {
+			if (event.type === "system" && event.subtype === "init" && !initSeen) {
+				initSeen = true
+				context.sendCommand({
+					command: "start",
+					requestId: startRequestId,
+					prompt: LONG_PROMPT,
+				})
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "ack" &&
+				event.command === "start" &&
+				event.requestId === startRequestId &&
+				!startAccepted
+			) {
+				startAccepted = true
+				context.sendCommand({
+					command: "cancel",
+					requestId: cancelRequestId,
+				})
+				sentCancel = true
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "done" &&
+				event.command === "cancel" &&
+				event.requestId === cancelRequestId
+			) {
+				if (event.code === "cancel_requested" || event.code === "no_active_task") {
+					cancelDone = true
+					if (!sentShutdown) {
+						context.sendCommand({
+							command: "shutdown",
+							requestId: shutdownRequestId,
+						})
+						sentShutdown = true
+					}
+				}
+				return
+			}
+
+			if (event.type === "error") {
+				throw new Error(`unexpected stream error event: ${event.content ?? "unknown error"}`)
+			}
+		},
+		onTimeoutMessage() {
+			return `timed out waiting for immediate-cancel flow (initSeen=${initSeen}, startAccepted=${startAccepted}, sentCancel=${sentCancel}, cancelDone=${cancelDone}, sentShutdown=${sentShutdown})`
+		},
+	})
+
+	if (!startAccepted || !sentCancel || !cancelDone || !sentShutdown) {
+		throw new Error(
+			`immediate-cancel flow did not complete expected transitions (startAccepted=${startAccepted}, sentCancel=${sentCancel}, cancelDone=${cancelDone}, sentShutdown=${sentShutdown})`,
+		)
+	}
+}
+
+main().catch((error) => {
+	console.error(`[FAIL] ${error instanceof Error ? error.message : String(error)}`)
+	process.exit(1)
+})

apps/cli/scripts/integration/cases/cancel-message-recovery-race.ts

@@ -0,0 +1,161 @@
+import { runStreamCase, StreamEvent } from "../lib/stream-harness"
+
+const START_PROMPT =
+	'Run exactly this command and do not summarize until it finishes: sleep 12 && echo "done". After it finishes, reply with exactly "done".'
+const FOLLOWUP_PROMPT = 'After cancellation, reply with only "RACE-OK".'
+
+async function main() {
+	const startRequestId = `start-${Date.now()}`
+	const cancelRequestId = `cancel-${Date.now()}`
+	const followupRequestId = `message-${Date.now()}`
+	const shutdownRequestId = `shutdown-${Date.now()}`
+
+	let initSeen = false
+	let sentCancelAndFollowup = false
+	let sentShutdown = false
+	let cancelDoneCode: string | undefined
+	let followupDoneCode: string | undefined
+	let followupResult = ""
+	let sawFollowupUserTurn = false
+	let sawMisroutedToolResult = false
+	let sawMessageControlError = false
+
+	await runStreamCase({
+		onEvent(event: StreamEvent, context) {
+			if (event.type === "system" && event.subtype === "init" && !initSeen) {
+				initSeen = true
+				context.sendCommand({
+					command: "start",
+					requestId: startRequestId,
+					prompt: START_PROMPT,
+				})
+				return
+			}
+
+			if (event.type === "control" && event.subtype === "error") {
+				if (event.requestId === followupRequestId) {
+					sawMessageControlError = true
+				}
+				throw new Error(
+					`received control error for requestId=${event.requestId ?? "unknown"} command=${event.command ?? "unknown"} code=${event.code ?? "unknown"} content=${event.content ?? ""}`,
+				)
+			}
+
+			if (
+				!sentCancelAndFollowup &&
+				event.type === "tool_use" &&
+				event.requestId === startRequestId &&
+				event.subtype === "command"
+			) {
+				context.sendCommand({
+					command: "cancel",
+					requestId: cancelRequestId,
+				})
+				context.sendCommand({
+					command: "message",
+					requestId: followupRequestId,
+					prompt: FOLLOWUP_PROMPT,
+				})
+				sentCancelAndFollowup = true
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.command === "cancel" &&
+				event.subtype === "done" &&
+				event.requestId === cancelRequestId
+			) {
+				cancelDoneCode = event.code
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.command === "message" &&
+				event.subtype === "done" &&
+				event.requestId === followupRequestId
+			) {
+				followupDoneCode = event.code
+				return
+			}
+
+			if (
+				event.type === "tool_result" &&
+				event.requestId === followupRequestId &&
+				typeof event.content === "string" &&
+				event.content.includes("<user_message>")
+			) {
+				sawMisroutedToolResult = true
+				return
+			}
+
+			if (event.type === "user" && event.requestId === followupRequestId) {
+				sawFollowupUserTurn = typeof event.content === "string" && event.content.includes("RACE-OK")
+				return
+			}
+
+			if (event.type !== "result" || event.done !== true || event.requestId !== followupRequestId) {
+				return
+			}
+
+			followupResult = event.content ?? ""
+
+			if (followupResult.trim().length === 0) {
+				throw new Error("follow-up after cancel produced an empty result")
+			}
+			if (cancelDoneCode !== "cancel_requested") {
+				throw new Error(
+					`cancel done code mismatch; expected cancel_requested, got "${cancelDoneCode ?? "none"}"`,
+				)
+			}
+			if (followupDoneCode !== "responded" && followupDoneCode !== "queued") {
+				throw new Error(
+					`unexpected follow-up done code after cancel race; expected responded|queued, got "${followupDoneCode ?? "none"}"`,
+				)
+			}
+			if (sawMessageControlError) {
+				throw new Error("follow-up message emitted control error in cancel recovery race")
+			}
+			if (sawMisroutedToolResult) {
+				throw new Error(
+					"follow-up message was misrouted into tool_result (<user_message>) in cancel recovery race",
+				)
+			}
+			if (!sawFollowupUserTurn) {
+				throw new Error("follow-up after cancel did not appear as a normal user turn")
+			}
+
+			console.log(`[PASS] cancel done code: "${cancelDoneCode}"`)
+			console.log(`[PASS] follow-up done code: "${followupDoneCode}"`)
+			console.log(`[PASS] follow-up user turn observed: ${sawFollowupUserTurn}`)
+			console.log(`[PASS] follow-up result: "${followupResult}"`)
+
+			if (!sentShutdown) {
+				context.sendCommand({
+					command: "shutdown",
+					requestId: shutdownRequestId,
+				})
+				sentShutdown = true
+			}
+		},
+		onTimeoutMessage() {
+			return [
+				"timed out waiting for cancel-message-recovery-race validation",
+				`initSeen=${initSeen}`,
+				`sentCancelAndFollowup=${sentCancelAndFollowup}`,
+				`cancelDoneCode=${cancelDoneCode ?? "none"}`,
+				`followupDoneCode=${followupDoneCode ?? "none"}`,
+				`sawFollowupUserTurn=${sawFollowupUserTurn}`,
+				`sawMisroutedToolResult=${sawMisroutedToolResult}`,
+				`sawMessageControlError=${sawMessageControlError}`,
+				`haveFollowupResult=${Boolean(followupResult)}`,
+			].join(" ")
+		},
+	})
+}
+
+main().catch((error) => {
+	console.error(`[FAIL] ${error instanceof Error ? error.message : String(error)}`)
+	process.exit(1)
+})

apps/cli/scripts/integration/cases/cancel-without-active-task.ts

@@ -0,0 +1,73 @@
+import { runStreamCase, StreamEvent } from "../lib/stream-harness"
+
+async function main() {
+	const cancelRequestId = `cancel-${Date.now()}`
+	const shutdownRequestId = `shutdown-${Date.now()}`
+
+	let initSeen = false
+	let cancelAckSeen = false
+	let cancelDoneSeen = false
+	let shutdownSent = false
+
+	await runStreamCase({
+		onEvent(event: StreamEvent, context) {
+			if (event.type === "system" && event.subtype === "init" && !initSeen) {
+				initSeen = true
+				context.sendCommand({
+					command: "cancel",
+					requestId: cancelRequestId,
+				})
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "ack" &&
+				event.command === "cancel" &&
+				event.requestId === cancelRequestId
+			) {
+				cancelAckSeen = true
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "done" &&
+				event.command === "cancel" &&
+				event.requestId === cancelRequestId
+			) {
+				cancelDoneSeen = true
+
+				if (event.code !== "no_active_task") {
+					throw new Error(`cancel without task should return no_active_task, got "${event.code ?? "none"}"`)
+				}
+				if (event.success !== true) {
+					throw new Error("cancel without task should be treated as successful no-op")
+				}
+
+				if (!shutdownSent) {
+					context.sendCommand({
+						command: "shutdown",
+						requestId: shutdownRequestId,
+					})
+					shutdownSent = true
+				}
+				return
+			}
+
+			if (event.type === "control" && event.subtype === "error") {
+				throw new Error(
+					`unexpected control error command=${event.command ?? "unknown"} code=${event.code ?? "unknown"} content=${event.content ?? ""}`,
+				)
+			}
+		},
+		onTimeoutMessage() {
+			return `timed out waiting for cancel-without-active-task validation (initSeen=${initSeen}, cancelAckSeen=${cancelAckSeen}, cancelDoneSeen=${cancelDoneSeen}, shutdownSent=${shutdownSent})`
+		},
+	})
+}
+
+main().catch((error) => {
+	console.error(`[FAIL] ${error instanceof Error ? error.message : String(error)}`)
+	process.exit(1)
+})

apps/cli/scripts/integration/cases/create-with-session-id-resume-loads-correct-session.ts

@@ -0,0 +1,364 @@
+import fs from "fs/promises"
+import os from "os"
+import path from "path"
+import readline from "readline"
+import { fileURLToPath } from "url"
+import { randomUUID } from "crypto"
+
+import { execa } from "execa"
+import type { TaskSessionEntry } from "@roo-code/core/cli"
+
+type StreamEvent = {
+	type?: string
+	subtype?: string
+	requestId?: string
+	command?: string
+	taskId?: string
+	content?: string
+	code?: string
+	success?: boolean
+	done?: boolean
+}
+
+const RESUME_TIMEOUT_MS = 180_000
+const __dirname = path.dirname(fileURLToPath(import.meta.url))
+
+function parseStreamEvent(line: string): StreamEvent | null {
+	const trimmed = line.trim()
+
+	if (!trimmed.startsWith("{")) {
+		return null
+	}
+
+	try {
+		return JSON.parse(trimmed) as StreamEvent
+	} catch {
+		return null
+	}
+}
+
+async function listSessions(cliRoot: string, workspacePath: string): Promise<TaskSessionEntry[]> {
+	const result = await execa("pnpm", ["dev", "list", "sessions", "--workspace", workspacePath, "--format", "json"], {
+		cwd: cliRoot,
+		reject: false,
+	})
+
+	if (result.exitCode !== 0) {
+		throw new Error(`list sessions failed with exit code ${result.exitCode}: ${result.stderr || result.stdout}`)
+	}
+
+	const stdoutLines = result.stdout.split("\n")
+	const jsonStartIndex = stdoutLines.findIndex((line) => line.trim().startsWith("{"))
+	if (jsonStartIndex === -1) {
+		throw new Error(`list sessions output did not contain JSON payload: ${result.stdout}`)
+	}
+
+	const jsonPayload = stdoutLines.slice(jsonStartIndex).join("\n").trim()
+
+	let parsed: unknown
+	try {
+		parsed = JSON.parse(jsonPayload)
+	} catch (error) {
+		throw new Error(
+			`failed to parse list sessions output as JSON: ${error instanceof Error ? error.message : String(error)}`,
+		)
+	}
+
+	if (
+		typeof parsed !== "object" ||
+		parsed === null ||
+		!("sessions" in parsed) ||
+		!Array.isArray((parsed as { sessions?: unknown }).sessions)
+	) {
+		throw new Error("list sessions output missing sessions array")
+	}
+
+	return (parsed as { sessions: TaskSessionEntry[] }).sessions
+}
+
+async function createSessionWithCustomId(
+	cliRoot: string,
+	workspacePath: string,
+	sessionId: string,
+	prompt: string,
+): Promise<void> {
+	const result = await execa(
+		"pnpm",
+		[
+			"dev",
+			"--print",
+			"--provider",
+			"openrouter",
+			"--output-format",
+			"stream-json",
+			"--workspace",
+			workspacePath,
+			"--create-with-session-id",
+			sessionId,
+			prompt,
+		],
+		{
+			cwd: cliRoot,
+			reject: false,
+		},
+	)
+
+	if (result.exitCode !== 0) {
+		throw new Error(
+			`create-with-session-id failed for ${sessionId} with exit code ${result.exitCode}: ${result.stderr || result.stdout}`,
+		)
+	}
+
+	const lines = result.stdout.split("\n")
+	const events = lines.map(parseStreamEvent).filter((event): event is StreamEvent => Boolean(event))
+	const errorEvent = events.find((event) => event.type === "error")
+
+	if (errorEvent) {
+		throw new Error(
+			`create-with-session-id emitted error for ${sessionId}: code=${errorEvent.code ?? "none"} content=${errorEvent.content ?? ""}`,
+		)
+	}
+
+	const completion = events.find((event) => event.type === "result" && event.done === true)
+	if (!completion) {
+		throw new Error(`create-with-session-id did not emit final result for ${sessionId}`)
+	}
+
+	if (completion.success !== true) {
+		throw new Error(`create-with-session-id completed unsuccessfully for ${sessionId}`)
+	}
+}
+
+async function resumeSessionAndSendMarker(
+	cliRoot: string,
+	workspacePath: string,
+	sessionId: string,
+	messageToken: string,
+): Promise<void> {
+	const pingRequestId = `ping-${Date.now()}`
+	const messageRequestId = `message-${Date.now()}`
+	const shutdownRequestId = `shutdown-${Date.now()}`
+
+	const messagePrompt = `Resume marker token: ${messageToken}. Reply with exactly "ack-${messageToken}".`
+
+	const child = execa(
+		"pnpm",
+		[
+			"dev",
+			"--print",
+			"--stdin-prompt-stream",
+			"--provider",
+			"openrouter",
+			"--output-format",
+			"stream-json",
+			"--workspace",
+			workspacePath,
+			"--session-id",
+			sessionId,
+		],
+		{
+			cwd: cliRoot,
+			stdin: "pipe",
+			stdout: "pipe",
+			stderr: "pipe",
+			reject: false,
+			forceKillAfterDelay: 2_000,
+		},
+	)
+
+	child.stderr?.on("data", (chunk) => {
+		process.stderr.write(chunk)
+	})
+
+	let pingSent = false
+	let messageSent = false
+	let shutdownSent = false
+	let sawMessageControlDone = false
+	let sawUserTurnWithMarker = false
+	let shutdownTaskId: string | undefined
+	let handlerError: Error | null = null
+	let timedOut = false
+
+	const sendCommand = (command: { command: "ping" | "message" | "shutdown"; requestId: string; prompt?: string }) => {
+		if (!child.stdin || child.stdin.destroyed) {
+			return
+		}
+		child.stdin.write(`${JSON.stringify(command)}\n`)
+	}
+
+	const timeout = setTimeout(() => {
+		timedOut = true
+		handlerError = new Error(
+			`timed out resuming session ${sessionId} (pingSent=${pingSent}, messageSent=${messageSent}, sawMessageControlDone=${sawMessageControlDone}, sawUserTurnWithMarker=${sawUserTurnWithMarker})`,
+		)
+		child.kill("SIGTERM")
+	}, RESUME_TIMEOUT_MS)
+
+	const rl = readline.createInterface({
+		input: child.stdout!,
+		crlfDelay: Infinity,
+	})
+
+	rl.on("line", (line) => {
+		process.stdout.write(`${line}\n`)
+
+		const event = parseStreamEvent(line)
+		if (!event) {
+			return
+		}
+
+		if (event.type === "system" && event.subtype === "init" && !pingSent) {
+			pingSent = true
+			sendCommand({ command: "ping", requestId: pingRequestId })
+			return
+		}
+
+		if (
+			event.type === "control" &&
+			event.subtype === "done" &&
+			event.command === "ping" &&
+			event.requestId === pingRequestId &&
+			!messageSent
+		) {
+			messageSent = true
+			sendCommand({
+				command: "message",
+				requestId: messageRequestId,
+				prompt: messagePrompt,
+			})
+			return
+		}
+
+		if (
+			event.type === "control" &&
+			event.subtype === "error" &&
+			event.command === "message" &&
+			event.requestId === messageRequestId
+		) {
+			handlerError = new Error(
+				`message command failed while resuming ${sessionId}: code=${event.code ?? "unknown"} content=${event.content ?? ""}`,
+			)
+			child.kill("SIGTERM")
+			return
+		}
+
+		if (
+			event.type === "control" &&
+			event.subtype === "done" &&
+			event.command === "message" &&
+			event.requestId === messageRequestId
+		) {
+			sawMessageControlDone = true
+			return
+		}
+
+		if (event.type === "user" && event.requestId === messageRequestId && event.content?.includes(messageToken)) {
+			sawUserTurnWithMarker = true
+
+			if (!shutdownSent) {
+				shutdownSent = true
+				sendCommand({ command: "shutdown", requestId: shutdownRequestId })
+			}
+			return
+		}
+
+		if (
+			event.type === "control" &&
+			(event.subtype === "ack" || event.subtype === "done") &&
+			event.command === "shutdown" &&
+			event.requestId === shutdownRequestId &&
+			typeof event.taskId === "string"
+		) {
+			shutdownTaskId = event.taskId
+			return
+		}
+
+		if (event.type === "control" && event.subtype === "error" && event.requestId !== shutdownRequestId) {
+			handlerError = new Error(
+				`unexpected control error while resuming ${sessionId}: command=${event.command ?? "unknown"} code=${event.code ?? "unknown"} content=${event.content ?? ""}`,
+			)
+			child.kill("SIGTERM")
+			return
+		}
+	})
+
+	const result = await child
+	clearTimeout(timeout)
+	rl.close()
+
+	if (handlerError) {
+		throw handlerError
+	}
+
+	if (timedOut) {
+		throw new Error(`stream resume for ${sessionId} timed out`)
+	}
+
+	if (result.exitCode !== 0) {
+		throw new Error(`stream resume for ${sessionId} exited non-zero: ${result.exitCode}`)
+	}
+
+	if (!sawMessageControlDone) {
+		throw new Error(`did not observe message control completion while resuming ${sessionId}`)
+	}
+
+	if (!sawUserTurnWithMarker) {
+		throw new Error(`did not observe resumed user marker turn while resuming ${sessionId}`)
+	}
+
+	if (shutdownTaskId !== sessionId) {
+		throw new Error(
+			`shutdown taskId did not match resumed session (expected=${sessionId}, actual=${shutdownTaskId ?? "none"})`,
+		)
+	}
+}
+
+async function main() {
+	const cliRoot = process.env.ROO_CLI_ROOT
+		? path.resolve(process.env.ROO_CLI_ROOT)
+		: path.resolve(__dirname, "../../..")
+	const workspacePath = await fs.mkdtemp(path.join(os.tmpdir(), "roo-cli-create-session-id-"))
+
+	const firstSessionId = randomUUID()
+	const secondSessionId = randomUUID()
+	const firstMarker = `FIRST-MARKER-${Date.now()}`
+	const secondMarker = `SECOND-MARKER-${Date.now()}`
+
+	try {
+		await createSessionWithCustomId(
+			cliRoot,
+			workspacePath,
+			firstSessionId,
+			`Create first session marker ${firstMarker}. Reply with exactly "ok-${firstMarker}".`,
+		)
+		await createSessionWithCustomId(
+			cliRoot,
+			workspacePath,
+			secondSessionId,
+			`Create second session marker ${secondMarker}. Reply with exactly "ok-${secondMarker}".`,
+		)
+
+		const initialSessions = await listSessions(cliRoot, workspacePath)
+		if (!initialSessions.some((session) => session.id === firstSessionId)) {
+			throw new Error(`session list missing first custom session id ${firstSessionId}`)
+		}
+		if (!initialSessions.some((session) => session.id === secondSessionId)) {
+			throw new Error(`session list missing second custom session id ${secondSessionId}`)
+		}
+
+		const resumeMarkerForFirst = `resume-first-${Date.now()}`
+		await resumeSessionAndSendMarker(cliRoot, workspacePath, firstSessionId, resumeMarkerForFirst)
+
+		const resumeMarkerForSecond = `resume-second-${Date.now()}`
+		await resumeSessionAndSendMarker(cliRoot, workspacePath, secondSessionId, resumeMarkerForSecond)
+
+		console.log(`[PASS] created and resumed custom sessions: ${firstSessionId}, ${secondSessionId}`)
+	} finally {
+		await fs.rm(workspacePath, { recursive: true, force: true })
+	}
+}
+
+main().catch((error) => {
+	console.error(`[FAIL] ${error instanceof Error ? error.message : String(error)}`)
+	process.exit(1)
+})

apps/cli/scripts/integration/cases/followup-after-completion.ts

@@ -0,0 +1,135 @@
+import { runStreamCase, StreamEvent } from "../lib/stream-harness"
+
+const FIRST_PROMPT = `What is 1+1? Reply with only "2".`
+const FOLLOWUP_PROMPT = `Different question now: what is 3+3? Reply with only "6".`
+
+function parseEventContent(text: string | undefined): string {
+	return typeof text === "string" ? text : ""
+}
+
+function validateFollowupResult(text: string): void {
+	if (text.trim().length === 0) {
+		throw new Error("follow-up produced an empty result")
+	}
+}
+
+async function main() {
+	const startRequestId = `start-${Date.now()}`
+	const followupRequestId = `message-${Date.now()}`
+	const shutdownRequestId = `shutdown-${Date.now()}`
+
+	let initSeen = false
+	let sentFollowup = false
+	let sentShutdown = false
+	let firstResult = ""
+	let followupResult = ""
+	let followupDoneCode: string | undefined
+	let sawFollowupUserTurn = false
+	let sawMisroutedToolResult = false
+
+	await runStreamCase({
+		onEvent(event: StreamEvent, context) {
+			if (event.type === "system" && event.subtype === "init" && !initSeen) {
+				initSeen = true
+				context.sendCommand({
+					command: "start",
+					requestId: startRequestId,
+					prompt: FIRST_PROMPT,
+				})
+				return
+			}
+
+			if (event.type === "control" && event.subtype === "error") {
+				throw new Error(
+					`received control error for requestId=${event.requestId ?? "unknown"} command=${event.command ?? "unknown"} code=${event.code ?? "unknown"} content=${event.content ?? ""}`,
+				)
+			}
+
+			if (event.type !== "result" || event.done !== true) {
+				if (
+					event.type === "control" &&
+					event.requestId === followupRequestId &&
+					event.command === "message" &&
+					event.subtype === "done"
+				) {
+					followupDoneCode = event.code
+					return
+				}
+
+				if (
+					event.type === "tool_result" &&
+					event.requestId === followupRequestId &&
+					typeof event.content === "string" &&
+					event.content.includes("<user_message>")
+				) {
+					sawMisroutedToolResult = true
+					return
+				}
+
+				if (event.type === "user" && event.requestId === followupRequestId) {
+					sawFollowupUserTurn = typeof event.content === "string" && event.content.includes("3+3")
+					return
+				}
+
+				return
+			}
+
+			if (event.requestId === startRequestId) {
+				firstResult = parseEventContent(event.content)
+				if (!/\b2\b/.test(firstResult)) {
+					throw new Error(`first result did not answer first prompt; result="${firstResult}"`)
+				}
+
+				if (!sentFollowup) {
+					context.sendCommand({
+						command: "message",
+						requestId: followupRequestId,
+						prompt: FOLLOWUP_PROMPT,
+					})
+					sentFollowup = true
+				}
+				return
+			}
+
+			if (event.requestId !== followupRequestId) {
+				return
+			}
+
+			followupResult = parseEventContent(event.content)
+			validateFollowupResult(followupResult)
+
+			if (followupDoneCode !== "responded") {
+				throw new Error(
+					`follow-up message was not routed as ask response; code="${followupDoneCode ?? "none"}"`,
+				)
+			}
+
+			if (!sawFollowupUserTurn) {
+				throw new Error("follow-up did not appear as a normal user turn in stream output")
+			}
+
+			if (sawMisroutedToolResult) {
+				throw new Error("follow-up message was misrouted into tool_result (<user_message>), old bug reproduced")
+			}
+
+			console.log(`[PASS] first result="${firstResult}"`)
+			console.log(`[PASS] follow-up result="${followupResult}"`)
+
+			if (!sentShutdown) {
+				context.sendCommand({
+					command: "shutdown",
+					requestId: shutdownRequestId,
+				})
+				sentShutdown = true
+			}
+		},
+		onTimeoutMessage() {
+			return `timed out waiting for completion (initSeen=${initSeen}, sentFollowup=${sentFollowup}, firstResult=${Boolean(firstResult)}, followupResult=${Boolean(followupResult)})`
+		},
+	})
+}
+
+main().catch((error) => {
+	console.error(`[FAIL] ${error instanceof Error ? error.message : String(error)}`)
+	process.exit(1)
+})

apps/cli/scripts/integration/cases/followup-completion-ask-response-images.ts

@@ -0,0 +1,136 @@
+import { runStreamCase, StreamEvent } from "../lib/stream-harness"
+
+const START_PROMPT = 'Answer this question and finish: What is 1+1? Reply with only "2", then complete the task.'
+const FOLLOWUP_PROMPT = 'Different question now: what is 3+3? Reply with only "6".'
+const ONE_PIXEL_IMAGE =
+	"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mP8/x8AAusB9Y9R4WQAAAAASUVORK5CYII="
+
+async function main() {
+	const startRequestId = `start-${Date.now()}`
+	const followupRequestId = `message-${Date.now()}`
+	const shutdownRequestId = `shutdown-${Date.now()}`
+
+	let initSeen = false
+	let sentFollowup = false
+	let sentShutdown = false
+	let followupDoneCode: string | undefined
+	let sawFollowupUserTurn = false
+	let sawMisroutedToolResult = false
+	let sawQueueImageMetadata = false
+	let shutdownDoneSeen = false
+
+	await runStreamCase({
+		onEvent(event: StreamEvent, context) {
+			if (event.type === "system" && event.subtype === "init" && !initSeen) {
+				initSeen = true
+				context.sendCommand({
+					command: "start",
+					requestId: startRequestId,
+					prompt: START_PROMPT,
+				})
+				return
+			}
+
+			if (event.type === "control" && event.subtype === "error") {
+				throw new Error(
+					`received control error for requestId=${event.requestId ?? "unknown"} command=${event.command ?? "unknown"} code=${event.code ?? "unknown"} content=${event.content ?? ""}`,
+				)
+			}
+
+			if (
+				event.type === "control" &&
+				event.command === "message" &&
+				event.subtype === "done" &&
+				event.requestId === followupRequestId
+			) {
+				followupDoneCode = event.code
+				if (!sentShutdown) {
+					context.sendCommand({
+						command: "shutdown",
+						requestId: shutdownRequestId,
+					})
+					sentShutdown = true
+				}
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.command === "shutdown" &&
+				event.subtype === "done" &&
+				event.requestId === shutdownRequestId
+			) {
+				shutdownDoneSeen = true
+
+				if (followupDoneCode !== "responded") {
+					throw new Error(
+						`follow-up image message was not routed as ask response; code="${followupDoneCode ?? "none"}"`,
+					)
+				}
+				if (sawQueueImageMetadata) {
+					throw new Error("follow-up image message was unexpectedly queued (observed queue image metadata)")
+				}
+				if (sawMisroutedToolResult) {
+					throw new Error("follow-up image message was misrouted into tool_result (<user_message>)")
+				}
+
+				console.log(`[PASS] follow-up image control code: "${followupDoneCode}"`)
+				console.log(`[PASS] follow-up image user turn observed before shutdown: ${sawFollowupUserTurn}`)
+				return
+			}
+
+			if (
+				event.type === "queue" &&
+				Array.isArray(event.queue) &&
+				event.queue.some((item) => item?.imageCount === 1)
+			) {
+				sawQueueImageMetadata = true
+				return
+			}
+
+			if (
+				event.type === "tool_result" &&
+				event.requestId === followupRequestId &&
+				typeof event.content === "string" &&
+				event.content.includes("<user_message>")
+			) {
+				sawMisroutedToolResult = true
+				return
+			}
+
+			if (event.type === "user" && event.requestId === followupRequestId) {
+				sawFollowupUserTurn = typeof event.content === "string" && event.content.includes("3+3")
+				return
+			}
+
+			if (event.type === "result" && event.done === true && event.requestId === startRequestId && !sentFollowup) {
+				context.sendCommand({
+					command: "message",
+					requestId: followupRequestId,
+					prompt: FOLLOWUP_PROMPT,
+					images: [ONE_PIXEL_IMAGE],
+				})
+				sentFollowup = true
+				return
+			}
+		},
+		onTimeoutMessage() {
+			return [
+				"timed out waiting for followup-completion-ask-response-images validation",
+				`initSeen=${initSeen}`,
+				`sentFollowup=${sentFollowup}`,
+				`sentShutdown=${sentShutdown}`,
+				`shutdownDoneSeen=${shutdownDoneSeen}`,
+				`followupDoneCode=${followupDoneCode ?? "none"}`,
+				`sawFollowupUserTurn=${sawFollowupUserTurn}`,
+				`sawMisroutedToolResult=${sawMisroutedToolResult}`,
+				`sawQueueImageMetadata=${sawQueueImageMetadata}`,
+			].join(" ")
+		},
+	})
+}
+
+main().catch((error) => {
+	console.error(`[FAIL] ${error instanceof Error ? error.message : String(error)}`)
+	process.exit(1)
+})

apps/cli/scripts/integration/cases/followup-completion-ask-response.ts

@@ -0,0 +1,153 @@
+import { runStreamCase, StreamEvent } from "../lib/stream-harness"
+
+const START_PROMPT = 'Answer this question and finish: What is 1+1? Reply with only "2", then complete the task.'
+const FOLLOWUP_PROMPT = 'Different question now: what is 3+3? Reply with only "6".'
+
+async function main() {
+	const startRequestId = `start-${Date.now()}`
+	const followupRequestId = `message-${Date.now()}`
+	const shutdownRequestId = `shutdown-${Date.now()}`
+
+	let initSeen = false
+	let sentFollowup = false
+	let sentShutdown = false
+	let startAckCount = 0
+	let sawStartControlAfterFollowup = false
+	let followupDoneCode: string | undefined
+	let sawFollowupUserTurn = false
+	let sawMisroutedToolResult = false
+	let sawQueueEventForFollowupRequest = false
+	let followupResult = ""
+
+	await runStreamCase({
+		onEvent(event: StreamEvent, context) {
+			if (event.type === "system" && event.subtype === "init" && !initSeen) {
+				initSeen = true
+				context.sendCommand({
+					command: "start",
+					requestId: startRequestId,
+					prompt: START_PROMPT,
+				})
+				return
+			}
+
+			if (event.type === "control" && event.subtype === "error") {
+				throw new Error(
+					`received control error for requestId=${event.requestId ?? "unknown"} command=${event.command ?? "unknown"} code=${event.code ?? "unknown"} content=${event.content ?? ""}`,
+				)
+			}
+
+			if (event.type === "control" && event.command === "start" && event.subtype === "ack") {
+				startAckCount += 1
+				if (sentFollowup) {
+					sawStartControlAfterFollowup = true
+				}
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.command === "message" &&
+				event.subtype === "done" &&
+				event.requestId === followupRequestId
+			) {
+				followupDoneCode = event.code
+				return
+			}
+
+			if (event.type === "queue" && event.requestId === followupRequestId) {
+				sawQueueEventForFollowupRequest = true
+				return
+			}
+
+			if (
+				event.type === "tool_result" &&
+				event.requestId === followupRequestId &&
+				typeof event.content === "string" &&
+				event.content.includes("<user_message>")
+			) {
+				sawMisroutedToolResult = true
+				return
+			}
+
+			if (event.type === "user" && event.requestId === followupRequestId) {
+				sawFollowupUserTurn = typeof event.content === "string" && event.content.includes("3+3")
+				return
+			}
+
+			if (event.type === "result" && event.done === true && event.requestId === startRequestId && !sentFollowup) {
+				context.sendCommand({
+					command: "message",
+					requestId: followupRequestId,
+					prompt: FOLLOWUP_PROMPT,
+				})
+				sentFollowup = true
+				return
+			}
+
+			if (event.type !== "result" || event.done !== true || event.requestId !== followupRequestId) {
+				return
+			}
+
+			followupResult = event.content ?? ""
+			if (followupResult.trim().length === 0) {
+				throw new Error("follow-up produced an empty result")
+			}
+
+			if (followupDoneCode !== "responded") {
+				throw new Error(
+					`follow-up message was not routed as ask response; code="${followupDoneCode ?? "none"}"`,
+				)
+			}
+
+			if (sawMisroutedToolResult) {
+				throw new Error("follow-up message was misrouted into tool_result (<user_message>), old bug reproduced")
+			}
+			if (sawQueueEventForFollowupRequest) {
+				throw new Error("follow-up message produced queue events despite responded routing")
+			}
+
+			if (!sawFollowupUserTurn) {
+				throw new Error("follow-up did not appear as a normal user turn in stream output")
+			}
+
+			if (sawStartControlAfterFollowup) {
+				throw new Error("unexpected start control event after follow-up; message should not trigger a new task")
+			}
+
+			if (startAckCount !== 1) {
+				throw new Error(`expected exactly one start ack event, saw ${startAckCount}`)
+			}
+
+			console.log(`[PASS] follow-up control code: "${followupDoneCode}"`)
+			console.log(`[PASS] follow-up user turn observed: ${sawFollowupUserTurn}`)
+			console.log(`[PASS] follow-up result: "${followupResult}"`)
+
+			if (!sentShutdown) {
+				context.sendCommand({
+					command: "shutdown",
+					requestId: shutdownRequestId,
+				})
+				sentShutdown = true
+			}
+		},
+		onTimeoutMessage() {
+			return [
+				"timed out waiting for completion ask-response follow-up validation",
+				`initSeen=${initSeen}`,
+				`sentFollowup=${sentFollowup}`,
+				`startAckCount=${startAckCount}`,
+				`followupDoneCode=${followupDoneCode ?? "none"}`,
+				`sawFollowupUserTurn=${sawFollowupUserTurn}`,
+				`sawMisroutedToolResult=${sawMisroutedToolResult}`,
+				`sawQueueEventForFollowupRequest=${sawQueueEventForFollowupRequest}`,
+				`haveFollowupResult=${Boolean(followupResult)}`,
+			].join(" ")
+		},
+	})
+}
+
+main().catch((error) => {
+	console.error(`[FAIL] ${error instanceof Error ? error.message : String(error)}`)
+	process.exit(1)
+})

apps/cli/scripts/integration/cases/followup-during-streaming.ts

@@ -0,0 +1,159 @@
+import { runStreamCase, StreamEvent } from "../lib/stream-harness"
+
+const START_PROMPT = 'Answer this question and finish: What is 1+1? Reply with only "2", then complete the task.'
+const FOLLOWUP_PROMPT = 'Different question now: what is 3+3? Reply with only "6".'
+
+function looksLikeAttemptCompletionToolUse(event: StreamEvent): boolean {
+	if (event.type !== "tool_use") {
+		return false
+	}
+
+	if (event.tool_use?.name === "attempt_completion") {
+		return true
+	}
+
+	const content = event.content ?? ""
+	return content.includes('"tool":"attempt_completion"') || content.includes('"name":"attempt_completion"')
+}
+
+function validateFollowupResult(text: string): void {
+	if (text.trim().length === 0) {
+		throw new Error("follow-up produced an empty result")
+	}
+}
+
+async function main() {
+	const startRequestId = `start-${Date.now()}`
+	const followupRequestId = `message-${Date.now()}`
+	const shutdownRequestId = `shutdown-${Date.now()}`
+
+	let initSeen = false
+	let sentFollowup = false
+	let sentShutdown = false
+	let sawAttemptCompletion = false
+	let sawFollowupUserTurn = false
+	let sawMisroutedToolResult = false
+	let followupResult = ""
+	let sawFirstAssistantChunkForStart = false
+
+	await runStreamCase({
+		onEvent(event: StreamEvent, context) {
+			if (event.type === "system" && event.subtype === "init" && !initSeen) {
+				initSeen = true
+				context.sendCommand({
+					command: "start",
+					requestId: startRequestId,
+					prompt: START_PROMPT,
+				})
+				return
+			}
+
+			if (event.type === "control" && event.subtype === "error") {
+				throw new Error(
+					`received control error for requestId=${event.requestId ?? "unknown"} command=${event.command ?? "unknown"} code=${event.code ?? "unknown"} content=${event.content ?? ""}`,
+				)
+			}
+
+			if (!sawAttemptCompletion && looksLikeAttemptCompletionToolUse(event)) {
+				sawAttemptCompletion = true
+				if (!sentFollowup) {
+					context.sendCommand({
+						command: "message",
+						requestId: followupRequestId,
+						prompt: FOLLOWUP_PROMPT,
+					})
+					sentFollowup = true
+				}
+				return
+			}
+
+			if (
+				event.type === "assistant" &&
+				event.requestId === startRequestId &&
+				event.done !== true &&
+				!sawFirstAssistantChunkForStart
+			) {
+				sawFirstAssistantChunkForStart = true
+				if (!sentFollowup) {
+					context.sendCommand({
+						command: "message",
+						requestId: followupRequestId,
+						prompt: FOLLOWUP_PROMPT,
+					})
+					sentFollowup = true
+				}
+				return
+			}
+
+			if (
+				event.type === "tool_result" &&
+				event.requestId === followupRequestId &&
+				typeof event.content === "string" &&
+				event.content.includes("<user_message>")
+			) {
+				sawMisroutedToolResult = true
+				return
+			}
+
+			if (event.type === "user" && event.requestId === followupRequestId) {
+				sawFollowupUserTurn = typeof event.content === "string" && event.content.includes("3+3")
+				return
+			}
+
+			if (event.type === "result" && event.done === true && event.requestId === startRequestId && !sentFollowup) {
+				context.sendCommand({
+					command: "message",
+					requestId: followupRequestId,
+					prompt: FOLLOWUP_PROMPT,
+				})
+				sentFollowup = true
+				return
+			}
+
+			if (event.type !== "result" || event.done !== true || event.requestId !== followupRequestId) {
+				return
+			}
+
+			followupResult = event.content ?? ""
+			validateFollowupResult(followupResult)
+
+			if (sawMisroutedToolResult) {
+				throw new Error("follow-up message was misrouted into tool_result (<user_message>), old bug reproduced")
+			}
+
+			if (!sawFollowupUserTurn) {
+				throw new Error("follow-up did not appear as a normal user turn in stream output")
+			}
+
+			console.log(`[PASS] saw attempt_completion tool use: ${sawAttemptCompletion}`)
+			console.log(`[PASS] saw start assistant chunk before follow-up: ${sawFirstAssistantChunkForStart}`)
+			console.log(`[PASS] follow-up user turn observed: ${sawFollowupUserTurn}`)
+			console.log(`[PASS] follow-up result: "${followupResult}"`)
+
+			if (!sentShutdown) {
+				context.sendCommand({
+					command: "shutdown",
+					requestId: shutdownRequestId,
+				})
+				sentShutdown = true
+			}
+		},
+		onTimeoutMessage() {
+			return [
+				"timed out waiting for follow-up validation",
+				`initSeen=${initSeen}`,
+				`sentFollowup=${sentFollowup}`,
+				`sawAttemptCompletion=${sawAttemptCompletion}`,
+				`sawFirstAssistantChunkForStart=${sawFirstAssistantChunkForStart}`,
+				`sawFollowupUserTurn=${sawFollowupUserTurn}`,
+				`sawMisroutedToolResult=${sawMisroutedToolResult}`,
+				`haveFollowupResult=${Boolean(followupResult)}`,
+			].join(" ")
+		},
+	})
+}
+
+main().catch((error) => {
+	console.error(`[FAIL] ${error instanceof Error ? error.message : String(error)}`)
+	process.exit(1)
+})

apps/cli/scripts/integration/cases/message-images-queue-metadata.ts

@@ -0,0 +1,124 @@
+import { runStreamCase, StreamEvent } from "../lib/stream-harness"
+
+const LONG_PROMPT =
+	'Run exactly this command and do not summarize until it finishes: sleep 20 && echo "done". After it finishes, reply with exactly "done".'
+
+async function main() {
+	const startRequestId = `start-${Date.now()}`
+	const messageRequestId = `message-${Date.now()}`
+	const shutdownRequestId = `shutdown-${Date.now()}`
+	const testImage = "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAAB"
+
+	let initSeen = false
+	let startAccepted = false
+	let messageAccepted = false
+	let messageQueued = false
+	let queueImageCountObserved = false
+	let shutdownSent = false
+	let shutdownAck = false
+	let shutdownDone = false
+
+	await runStreamCase({
+		timeoutMs: 180_000,
+		onEvent(event: StreamEvent, context) {
+			if (event.type === "system" && event.subtype === "init" && !initSeen) {
+				initSeen = true
+				context.sendCommand({ command: "start", requestId: startRequestId, prompt: LONG_PROMPT })
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "ack" &&
+				event.command === "start" &&
+				event.requestId === startRequestId &&
+				!startAccepted
+			) {
+				startAccepted = true
+
+				context.sendCommand({
+					command: "message",
+					requestId: messageRequestId,
+					prompt: "Respond with exactly IMAGE-QUEUED when this message is processed.",
+					images: [testImage],
+				})
+
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "ack" &&
+				event.command === "message" &&
+				event.requestId === messageRequestId
+			) {
+				messageAccepted = true
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "done" &&
+				event.command === "message" &&
+				event.requestId === messageRequestId &&
+				event.code === "queued"
+			) {
+				messageQueued = true
+				return
+			}
+
+			if (
+				event.type === "queue" &&
+				(event.subtype === "snapshot" || event.subtype === "enqueued" || event.subtype === "updated") &&
+				Array.isArray(event.queue) &&
+				event.queue.some((item) => item?.imageCount === 1)
+			) {
+				queueImageCountObserved = true
+
+				if (!shutdownSent) {
+					context.sendCommand({ command: "shutdown", requestId: shutdownRequestId })
+					shutdownSent = true
+				}
+
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "ack" &&
+				event.command === "shutdown" &&
+				event.requestId === shutdownRequestId
+			) {
+				shutdownAck = true
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "done" &&
+				event.command === "shutdown" &&
+				event.requestId === shutdownRequestId
+			) {
+				shutdownDone = true
+			}
+		},
+		onTimeoutMessage() {
+			return `timed out waiting for queue image metadata (initSeen=${initSeen}, startAccepted=${startAccepted}, messageAccepted=${messageAccepted}, messageQueued=${messageQueued}, queueImageCountObserved=${queueImageCountObserved}, shutdownSent=${shutdownSent}, shutdownAck=${shutdownAck}, shutdownDone=${shutdownDone})`
+		},
+	})
+
+	if (!messageAccepted || !messageQueued || !queueImageCountObserved) {
+		throw new Error(
+			`expected queued message with image metadata (messageAccepted=${messageAccepted}, messageQueued=${messageQueued}, queueImageCountObserved=${queueImageCountObserved})`,
+		)
+	}
+
+	if (!shutdownAck || !shutdownDone) {
+		throw new Error("shutdown control events were not fully observed")
+	}
+}
+
+main().catch((error) => {
+	console.error(`[FAIL] ${error instanceof Error ? error.message : String(error)}`)
+	process.exit(1)
+})

apps/cli/scripts/integration/cases/message-without-active-task.ts

@@ -0,0 +1,51 @@
+import { runStreamCase, StreamEvent } from "../lib/stream-harness"
+
+async function main() {
+	const messageRequestId = `message-${Date.now()}`
+	const shutdownRequestId = `shutdown-${Date.now()}`
+	let initSeen = false
+	let sawNoActiveTaskError = false
+	let sentShutdown = false
+
+	await runStreamCase({
+		onEvent(event: StreamEvent, context) {
+			if (event.type === "system" && event.subtype === "init" && !initSeen) {
+				initSeen = true
+				context.sendCommand({
+					command: "message",
+					requestId: messageRequestId,
+					prompt: "Hello",
+				})
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "error" &&
+				event.requestId === messageRequestId &&
+				event.code === "no_active_task"
+			) {
+				sawNoActiveTaskError = true
+				if (!sentShutdown) {
+					context.sendCommand({
+						command: "shutdown",
+						requestId: shutdownRequestId,
+					})
+					sentShutdown = true
+				}
+			}
+		},
+		onTimeoutMessage() {
+			return `timed out waiting for no_active_task error (initSeen=${initSeen}, sawNoActiveTaskError=${sawNoActiveTaskError})`
+		},
+	})
+
+	if (!sawNoActiveTaskError) {
+		throw new Error("expected no_active_task error was not observed")
+	}
+}
+
+main().catch((error) => {
+	console.error(`[FAIL] ${error instanceof Error ? error.message : String(error)}`)
+	process.exit(1)
+})

apps/cli/scripts/integration/cases/mixed-command-ordering.ts

@@ -0,0 +1,148 @@
+import { runStreamCase, StreamEvent } from "../lib/stream-harness"
+
+const START_PROMPT =
+	'Run exactly this command and do not summarize until it finishes: sleep 8 && echo "done". After it finishes, reply with exactly "done".'
+
+async function main() {
+	const startRequestId = `start-${Date.now()}`
+	const pingARequestId = `ping-a-${Date.now()}`
+	const messageRequestId = `message-${Date.now()}`
+	const pingBRequestId = `ping-b-${Date.now()}`
+	const shutdownRequestId = `shutdown-${Date.now()}`
+
+	let initSeen = false
+	let sentInterleavedCommands = false
+	let sentShutdown = false
+
+	const eventOrderByRequestId = new Map<string, string[]>()
+	let messageDoneCode: string | undefined
+	let messageQueueEnqueuedSeen = false
+	let messageResultSeen = false
+
+	function recordControlEvent(event: StreamEvent): void {
+		if (!event.requestId || event.type !== "control" || !event.subtype) {
+			return
+		}
+		const existing = eventOrderByRequestId.get(event.requestId) ?? []
+		existing.push(event.subtype)
+		eventOrderByRequestId.set(event.requestId, existing)
+	}
+
+	await runStreamCase({
+		onEvent(event: StreamEvent, context) {
+			if (event.type === "system" && event.subtype === "init" && !initSeen) {
+				initSeen = true
+				context.sendCommand({
+					command: "start",
+					requestId: startRequestId,
+					prompt: START_PROMPT,
+				})
+				return
+			}
+
+			recordControlEvent(event)
+
+			if (event.type === "control" && event.subtype === "error") {
+				throw new Error(
+					`received control error for requestId=${event.requestId ?? "unknown"} command=${event.command ?? "unknown"} code=${event.code ?? "unknown"} content=${event.content ?? ""}`,
+				)
+			}
+
+			if (
+				!sentInterleavedCommands &&
+				event.type === "control" &&
+				event.subtype === "ack" &&
+				event.command === "start" &&
+				event.requestId === startRequestId
+			) {
+				context.sendCommand({
+					command: "ping",
+					requestId: pingARequestId,
+				})
+				context.sendCommand({
+					command: "message",
+					requestId: messageRequestId,
+					prompt: 'When this queued message is processed, reply with only "INTERLEAVED".',
+				})
+				context.sendCommand({
+					command: "ping",
+					requestId: pingBRequestId,
+				})
+				sentInterleavedCommands = true
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "done" &&
+				event.command === "message" &&
+				event.requestId === messageRequestId
+			) {
+				messageDoneCode = event.code
+				return
+			}
+
+			if (
+				event.type === "queue" &&
+				event.subtype === "enqueued" &&
+				event.requestId === startRequestId &&
+				event.queueDepth === 1
+			) {
+				messageQueueEnqueuedSeen = true
+				return
+			}
+
+			if (event.type === "result" && event.done === true && event.requestId === messageRequestId) {
+				messageResultSeen = true
+
+				const pingAOrder = eventOrderByRequestId.get(pingARequestId) ?? []
+				const pingBOrder = eventOrderByRequestId.get(pingBRequestId) ?? []
+				const messageOrder = eventOrderByRequestId.get(messageRequestId) ?? []
+
+				if (pingAOrder.join(",") !== "ack,done") {
+					throw new Error(`ping A control order mismatch: ${pingAOrder.join(",") || "none"}`)
+				}
+				if (pingBOrder.join(",") !== "ack,done") {
+					throw new Error(`ping B control order mismatch: ${pingBOrder.join(",") || "none"}`)
+				}
+				if (messageOrder.join(",") !== "ack,done") {
+					throw new Error(`message control order mismatch: ${messageOrder.join(",") || "none"}`)
+				}
+				if (messageDoneCode !== "queued") {
+					throw new Error(
+						`expected interleaved message done code \"queued\", got \"${messageDoneCode ?? "none"}\"`,
+					)
+				}
+				if (!messageQueueEnqueuedSeen) {
+					throw new Error("expected queue enqueued event after interleaved message")
+				}
+
+				if (!sentShutdown) {
+					context.sendCommand({
+						command: "shutdown",
+						requestId: shutdownRequestId,
+					})
+					sentShutdown = true
+				}
+			}
+		},
+		onTimeoutMessage() {
+			return [
+				"timed out waiting for mixed-command-ordering validation",
+				`initSeen=${initSeen}`,
+				`sentInterleavedCommands=${sentInterleavedCommands}`,
+				`messageDoneCode=${messageDoneCode ?? "none"}`,
+				`messageQueueEnqueuedSeen=${messageQueueEnqueuedSeen}`,
+				`messageResultSeen=${messageResultSeen}`,
+				`pingAOrder=${(eventOrderByRequestId.get(pingARequestId) ?? []).join(",") || "none"}`,
+				`messageOrder=${(eventOrderByRequestId.get(messageRequestId) ?? []).join(",") || "none"}`,
+				`pingBOrder=${(eventOrderByRequestId.get(pingBRequestId) ?? []).join(",") || "none"}`,
+			].join(" ")
+		},
+	})
+}
+
+main().catch((error) => {
+	console.error(`[FAIL] ${error instanceof Error ? error.message : String(error)}`)
+	process.exit(1)
+})

apps/cli/scripts/integration/cases/multi-message-queue-order.ts

@@ -0,0 +1,184 @@
+import { runStreamCase, StreamEvent } from "../lib/stream-harness"
+
+const LONG_PROMPT =
+	'Run exactly this command and do not summarize until it finishes: sleep 6 && echo "done". After it finishes, reply with exactly "done".'
+const MESSAGE_ONE_PROMPT = 'For this follow-up, reply with only "ALPHA".'
+const MESSAGE_TWO_PROMPT = 'For this follow-up, reply with only "BETA".'
+
+async function main() {
+	const startRequestId = `start-${Date.now()}`
+	const firstMessageRequestId = `message-a-${Date.now()}`
+	const secondMessageRequestId = `message-b-${Date.now()}`
+	const shutdownRequestId = `shutdown-${Date.now()}`
+
+	let initSeen = false
+	let startAccepted = false
+	let sentQueuedMessages = false
+	let sentShutdown = false
+
+	let firstMessageAccepted = false
+	let secondMessageAccepted = false
+	let firstMessageQueued = false
+	let secondMessageQueued = false
+
+	const resultOrder: string[] = []
+	let queueDequeuedByFirst = false
+	let queueDrainedBySecond = false
+	let firstResultSeen = false
+	let secondResultSeen = false
+
+	await runStreamCase({
+		timeoutMs: 180_000,
+		onEvent(event: StreamEvent, context) {
+			if (event.type === "system" && event.subtype === "init" && !initSeen) {
+				initSeen = true
+				context.sendCommand({
+					command: "start",
+					requestId: startRequestId,
+					prompt: LONG_PROMPT,
+				})
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "ack" &&
+				event.command === "start" &&
+				event.requestId === startRequestId &&
+				!startAccepted
+			) {
+				startAccepted = true
+				context.sendCommand({
+					command: "message",
+					requestId: firstMessageRequestId,
+					prompt: MESSAGE_ONE_PROMPT,
+				})
+				context.sendCommand({
+					command: "message",
+					requestId: secondMessageRequestId,
+					prompt: MESSAGE_TWO_PROMPT,
+				})
+				sentQueuedMessages = true
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "ack" &&
+				event.command === "message" &&
+				event.requestId === firstMessageRequestId
+			) {
+				firstMessageAccepted = true
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "ack" &&
+				event.command === "message" &&
+				event.requestId === secondMessageRequestId
+			) {
+				secondMessageAccepted = true
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "done" &&
+				event.command === "message" &&
+				event.requestId === firstMessageRequestId &&
+				event.code === "queued"
+			) {
+				firstMessageQueued = true
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "done" &&
+				event.command === "message" &&
+				event.requestId === secondMessageRequestId &&
+				event.code === "queued"
+			) {
+				secondMessageQueued = true
+				return
+			}
+
+			if (
+				event.type === "queue" &&
+				event.subtype === "dequeued" &&
+				event.requestId === firstMessageRequestId &&
+				event.queueDepth === 1
+			) {
+				queueDequeuedByFirst = true
+				return
+			}
+
+			if (
+				event.type === "queue" &&
+				event.subtype === "drained" &&
+				event.requestId === secondMessageRequestId &&
+				event.queueDepth === 0
+			) {
+				queueDrainedBySecond = true
+				return
+			}
+
+			if (event.type === "result" && event.done === true) {
+				if (event.requestId === firstMessageRequestId) {
+					firstResultSeen = true
+					resultOrder.push(firstMessageRequestId)
+				}
+				if (event.requestId === secondMessageRequestId) {
+					secondResultSeen = true
+					resultOrder.push(secondMessageRequestId)
+				}
+			}
+
+			if (!firstResultSeen || !secondResultSeen || sentShutdown) {
+				return
+			}
+
+			const expectedOrder = [firstMessageRequestId, secondMessageRequestId].join(",")
+			if (resultOrder.join(",") !== expectedOrder) {
+				throw new Error(
+					`queued message result order mismatch; expected=${expectedOrder} actual=${resultOrder.join(",")}`,
+				)
+			}
+
+			context.sendCommand({
+				command: "shutdown",
+				requestId: shutdownRequestId,
+			})
+			sentShutdown = true
+		},
+		onTimeoutMessage() {
+			return `timed out waiting for queued message order validation (initSeen=${initSeen}, startAccepted=${startAccepted}, sentQueuedMessages=${sentQueuedMessages}, firstMessageAccepted=${firstMessageAccepted}, secondMessageAccepted=${secondMessageAccepted}, firstMessageQueued=${firstMessageQueued}, secondMessageQueued=${secondMessageQueued}, queueDequeuedByFirst=${queueDequeuedByFirst}, queueDrainedBySecond=${queueDrainedBySecond}, resultOrder=${resultOrder.join(" -> ")}, firstResultSeen=${firstResultSeen}, secondResultSeen=${secondResultSeen})`
+		},
+	})
+
+	if (
+		!firstMessageAccepted ||
+		!secondMessageAccepted ||
+		!firstMessageQueued ||
+		!secondMessageQueued ||
+		!queueDequeuedByFirst ||
+		!queueDrainedBySecond
+	) {
+		throw new Error(
+			`expected both queued messages to be accepted/queued and queue transitions observed (firstMessageAccepted=${firstMessageAccepted}, secondMessageAccepted=${secondMessageAccepted}, firstMessageQueued=${firstMessageQueued}, secondMessageQueued=${secondMessageQueued}, queueDequeuedByFirst=${queueDequeuedByFirst}, queueDrainedBySecond=${queueDrainedBySecond})`,
+		)
+	}
+
+	const expectedOrder = [firstMessageRequestId, secondMessageRequestId].join(",")
+	if (resultOrder.join(",") !== expectedOrder) {
+		throw new Error(
+			`queued message result order mismatch; expected=${expectedOrder} actual=${resultOrder.join(",")}`,
+		)
+	}
+}
+
+main().catch((error) => {
+	console.error(`[FAIL] ${error instanceof Error ? error.message : String(error)}`)
+	process.exit(1)
+})

apps/cli/scripts/integration/cases/shutdown-while-running.ts

@@ -0,0 +1,76 @@
+import { runStreamCase, StreamEvent } from "../lib/stream-harness"
+
+const LONG_PROMPT =
+	'Run exactly this command and do not summarize until it finishes: sleep 20 && echo "done". After it finishes, reply with exactly "done".'
+
+async function main() {
+	const startRequestId = `start-${Date.now()}`
+	const shutdownRequestId = `shutdown-${Date.now()}`
+
+	let initSeen = false
+	let startAccepted = false
+	let shutdownSent = false
+	let shutdownAck = false
+	let shutdownDone = false
+
+	await runStreamCase({
+		onEvent(event: StreamEvent, context) {
+			if (event.type === "system" && event.subtype === "init" && !initSeen) {
+				initSeen = true
+				context.sendCommand({
+					command: "start",
+					requestId: startRequestId,
+					prompt: LONG_PROMPT,
+				})
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "ack" &&
+				event.command === "start" &&
+				event.requestId === startRequestId &&
+				!startAccepted
+			) {
+				startAccepted = true
+				context.sendCommand({
+					command: "shutdown",
+					requestId: shutdownRequestId,
+				})
+				shutdownSent = true
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "ack" &&
+				event.command === "shutdown" &&
+				event.requestId === shutdownRequestId
+			) {
+				shutdownAck = true
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "done" &&
+				event.command === "shutdown" &&
+				event.requestId === shutdownRequestId
+			) {
+				shutdownDone = true
+			}
+		},
+		onTimeoutMessage() {
+			return `timed out waiting for shutdown flow (initSeen=${initSeen}, startAccepted=${startAccepted}, shutdownSent=${shutdownSent}, shutdownAck=${shutdownAck}, shutdownDone=${shutdownDone})`
+		},
+	})
+
+	if (!shutdownAck || !shutdownDone) {
+		throw new Error("shutdown control events were not fully observed")
+	}
+}
+
+main().catch((error) => {
+	console.error(`[FAIL] ${error instanceof Error ? error.message : String(error)}`)
+	process.exit(1)
+})

apps/cli/scripts/integration/cases/start-while-busy.ts

@@ -0,0 +1,77 @@
+import { runStreamCase, StreamEvent } from "../lib/stream-harness"
+
+const LONG_PROMPT =
+	'Run exactly this command and do not summarize until it finishes: sleep 8 && echo "done". After it finishes, reply with exactly "done".'
+
+async function main() {
+	const firstStartRequestId = `start-a-${Date.now()}`
+	const secondStartRequestId = `start-b-${Date.now()}`
+	const shutdownRequestId = `shutdown-${Date.now()}`
+
+	let initSeen = false
+	let firstStartAccepted = false
+	let secondStartSent = false
+	let sawTaskBusyError = false
+	let sentShutdown = false
+
+	await runStreamCase({
+		onEvent(event: StreamEvent, context) {
+			if (event.type === "system" && event.subtype === "init" && !initSeen) {
+				initSeen = true
+				context.sendCommand({
+					command: "start",
+					requestId: firstStartRequestId,
+					prompt: LONG_PROMPT,
+				})
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "ack" &&
+				event.command === "start" &&
+				event.requestId === firstStartRequestId &&
+				!firstStartAccepted
+			) {
+				firstStartAccepted = true
+				context.sendCommand({
+					command: "start",
+					requestId: secondStartRequestId,
+					prompt: "What is 1+1? Reply with only 2.",
+				})
+				secondStartSent = true
+				return
+			}
+
+			if (
+				event.type === "control" &&
+				event.subtype === "error" &&
+				event.command === "start" &&
+				event.requestId === secondStartRequestId &&
+				event.code === "task_busy"
+			) {
+				sawTaskBusyError = true
+				if (!sentShutdown) {
+					context.sendCommand({
+						command: "shutdown",
+						requestId: shutdownRequestId,
+					})
+					sentShutdown = true
+				}
+				return
+			}
+		},
+		onTimeoutMessage() {
+			return `timed out waiting for task_busy error (initSeen=${initSeen}, firstStartAccepted=${firstStartAccepted}, secondStartSent=${secondStartSent}, sawTaskBusyError=${sawTaskBusyError})`
+		},
+	})
+
+	if (!sawTaskBusyError) {
+		throw new Error("expected task_busy error for second start command was not observed")
+	}
+}
+
+main().catch((error) => {
+	console.error(`[FAIL] ${error instanceof Error ? error.message : String(error)}`)
+	process.exit(1)
+})

apps/cli/scripts/integration/lib/stream-harness.ts

@@ -0,0 +1,152 @@
+import path from "path"
+import { fileURLToPath } from "url"
+import readline from "readline"
+
+import { execa } from "execa"
+
+export type StreamEvent = {
+	type?: string
+	subtype?: string
+	requestId?: string
+	command?: string
+	content?: string
+	code?: string
+	success?: boolean
+	done?: boolean
+	id?: number
+	queueDepth?: number
+	queue?: Array<{ id?: string; text?: string; imageCount?: number; timestamp?: number }>
+	tool_use?: {
+		name?: string
+		input?: Record<string, unknown>
+	}
+	tool_result?: {
+		name?: string
+		output?: string
+	}
+}
+
+export type StreamCommand = {
+	command: "start" | "message" | "cancel" | "ping" | "shutdown"
+	requestId: string
+	prompt?: string
+	images?: string[]
+}
+
+export interface StreamCaseContext {
+	readonly cliRoot: string
+	readonly timeoutMs: number
+	nextRequestId(prefix: string): string
+	sendCommand(command: StreamCommand): void
+}
+
+export interface RunStreamCaseOptions {
+	timeoutMs?: number
+	onEvent: (event: StreamEvent, context: StreamCaseContext) => void
+	onTimeoutMessage?: (context: StreamCaseContext) => string
+}
+
+const __dirname = path.dirname(fileURLToPath(import.meta.url))
+const defaultCliRoot = path.resolve(__dirname, "../../..")
+
+function parseEvent(line: string): StreamEvent | null {
+	const trimmed = line.trim()
+
+	if (!trimmed.startsWith("{")) {
+		return null
+	}
+
+	try {
+		return JSON.parse(trimmed) as StreamEvent
+	} catch {
+		return null
+	}
+}
+
+export async function runStreamCase(options: RunStreamCaseOptions): Promise<void> {
+	const cliRoot = process.env.ROO_CLI_ROOT ? path.resolve(process.env.ROO_CLI_ROOT) : defaultCliRoot
+	const timeoutMs = options.timeoutMs ?? 120_000
+
+	const child = execa(
+		"pnpm",
+		["dev", "--print", "--stdin-prompt-stream", "--provider", "openrouter", "--output-format", "stream-json"],
+		{
+			cwd: cliRoot,
+			stdin: "pipe",
+			stdout: "pipe",
+			stderr: "pipe",
+			reject: false,
+			forceKillAfterDelay: 2_000,
+		},
+	)
+
+	child.stderr?.on("data", (chunk) => {
+		process.stderr.write(chunk)
+	})
+
+	let requestCounter = 0
+
+	const context: StreamCaseContext = {
+		cliRoot,
+		timeoutMs,
+		nextRequestId(prefix: string): string {
+			requestCounter += 1
+			return `${prefix}-${Date.now()}-${requestCounter}`
+		},
+		sendCommand(command: StreamCommand): void {
+			if (child.stdin?.destroyed) {
+				return
+			}
+
+			child.stdin.write(`${JSON.stringify(command)}\n`)
+		},
+	}
+
+	let handlerError: Error | null = null
+	let timedOut = false
+
+	const timeout = setTimeout(() => {
+		timedOut = true
+		const message = options.onTimeoutMessage?.(context) ?? "timed out waiting for stream scenario completion"
+		handlerError = new Error(message)
+		child.kill("SIGTERM")
+	}, timeoutMs)
+
+	const rl = readline.createInterface({
+		input: child.stdout!,
+		crlfDelay: Infinity,
+	})
+
+	rl.on("line", (line) => {
+		process.stdout.write(`${line}\n`)
+
+		const event = parseEvent(line)
+
+		if (!event) {
+			return
+		}
+
+		try {
+			options.onEvent(event, context)
+		} catch (error) {
+			handlerError = error instanceof Error ? error : new Error(String(error))
+			child.kill("SIGTERM")
+		}
+	})
+
+	const result = await child
+	clearTimeout(timeout)
+	rl.close()
+
+	if (handlerError) {
+		throw handlerError
+	}
+
+	if (timedOut) {
+		throw new Error("stream scenario timed out")
+	}
+
+	if (result.exitCode !== 0) {
+		throw new Error(`CLI exited with non-zero code: ${result.exitCode}`)
+	}
+}

apps/cli/scripts/integration/run.ts

@@ -0,0 +1,111 @@
+import fs from "fs/promises"
+import path from "path"
+import { fileURLToPath } from "url"
+
+import { execa } from "execa"
+
+const __dirname = path.dirname(fileURLToPath(import.meta.url))
+const cliRoot = path.resolve(__dirname, "../..")
+const casesDir = path.resolve(__dirname, "cases")
+
+interface RunnerOptions {
+	listOnly: boolean
+	match?: string
+}
+
+function parseArgs(argv: string[]): RunnerOptions {
+	let listOnly = false
+	let match: string | undefined
+
+	for (let i = 0; i < argv.length; i++) {
+		const arg = argv[i]
+		if (arg === "--list") {
+			listOnly = true
+			continue
+		}
+		if (arg === "--match") {
+			match = argv[i + 1]
+			i += 1
+			continue
+		}
+	}
+
+	return { listOnly, match }
+}
+
+async function discoverCaseFiles(match?: string): Promise<string[]> {
+	const entries = await fs.readdir(casesDir, { withFileTypes: true })
+	const files = entries
+		.filter((entry) => entry.isFile() && entry.name.endsWith(".ts"))
+		.map((entry) => path.resolve(casesDir, entry.name))
+		.sort((a, b) => a.localeCompare(b))
+
+	if (!match) {
+		return files
+	}
+
+	const normalized = match.toLowerCase()
+	return files.filter((file) => path.basename(file).toLowerCase().includes(normalized))
+}
+
+async function runCase(caseFile: string): Promise<void> {
+	const caseName = path.basename(caseFile, ".ts")
+	console.log(`\n[RUN] ${caseName}`)
+
+	await execa("tsx", [caseFile], {
+		cwd: cliRoot,
+		stdio: "inherit",
+		reject: true,
+		env: {
+			...process.env,
+			ROO_CLI_ROOT: cliRoot,
+		},
+	})
+
+	console.log(`[PASS] ${caseName}`)
+}
+
+async function main() {
+	const options = parseArgs(process.argv.slice(2))
+	const caseFiles = await discoverCaseFiles(options.match)
+
+	if (caseFiles.length === 0) {
+		throw new Error(
+			options.match ? `no integration cases matched --match "${options.match}"` : "no integration cases found",
+		)
+	}
+
+	if (options.listOnly) {
+		console.log("Available integration cases:")
+		for (const file of caseFiles) {
+			console.log(`- ${path.basename(file, ".ts")}`)
+		}
+		return
+	}
+
+	const failures: Array<{ caseName: string; error: string }> = []
+
+	for (const caseFile of caseFiles) {
+		const caseName = path.basename(caseFile, ".ts")
+		try {
+			await runCase(caseFile)
+		} catch (error) {
+			const errorText = error instanceof Error ? error.message : String(error)
+			failures.push({ caseName, error: errorText })
+			console.error(`[FAIL] ${caseName}: ${errorText}`)
+		}
+	}
+
+	const total = caseFiles.length
+	const passed = total - failures.length
+	console.log(`\nSummary: ${passed}/${total} passed`)
+
+	if (failures.length > 0) {
+		process.exitCode = 1
+	}
+}
+
+main().catch((error) => {
+	console.error(`[FAIL] ${error instanceof Error ? error.message : String(error)}`)
+	process.exit(1)
+})

apps/cli/src/__tests__/index.test.ts

@@ -0,0 +1,126 @@
+/**
+ * Integration tests for CLI
+ *
+ * These tests require:
+ * 1. RUN_CLI_INTEGRATION_TESTS=true environment variable (opt-in)
+ * 2. A valid OPENROUTER_API_KEY environment variable
+ * 3. A built CLI at apps/cli/dist (will auto-build if missing)
+ * 4. A built extension at src/dist (will auto-build if missing)
+ *
+ * Run with: RUN_CLI_INTEGRATION_TESTS=true OPENROUTER_API_KEY=sk-or-v1-... pnpm test
+ */
+
+// pnpm --filter @roo-code/cli test src/__tests__/index.test.ts
+
+import path from "path"
+import fs from "fs"
+import { execSync, spawn, type ChildProcess } from "child_process"
+import { fileURLToPath } from "url"
+
+const __filename = fileURLToPath(import.meta.url)
+const __dirname = path.dirname(__filename)
+
+const RUN_INTEGRATION_TESTS = process.env.RUN_CLI_INTEGRATION_TESTS === "true"
+const OPENROUTER_API_KEY = process.env.OPENROUTER_API_KEY
+const hasApiKey = !!OPENROUTER_API_KEY
+
+function findCliRoot(): string {
+	// From apps/cli/src/__tests__, go up to apps/cli.
+	return path.resolve(__dirname, "../..")
+}
+
+function findMonorepoRoot(): string {
+	// From apps/cli/src/__tests__, go up to monorepo root.
+	return path.resolve(__dirname, "../../../..")
+}
+
+function isCliBuilt(): boolean {
+	return fs.existsSync(path.join(findCliRoot(), "dist", "index.js"))
+}
+
+function isExtensionBuilt(): boolean {
+	const monorepoRoot = findMonorepoRoot()
+	const extensionPath = path.join(monorepoRoot, "src/dist")
+	return fs.existsSync(path.join(extensionPath, "extension.js"))
+}
+
+function buildCliIfNeeded(): void {
+	if (!isCliBuilt()) {
+		execSync("pnpm build", { cwd: findCliRoot(), stdio: "inherit" })
+		console.log("CLI build complete.")
+	}
+}
+
+function buildExtensionIfNeeded(): void {
+	if (!isExtensionBuilt()) {
+		execSync("pnpm --filter roo-cline bundle", { cwd: findMonorepoRoot(), stdio: "inherit" })
+		console.log("Extension build complete.")
+	}
+}
+
+function runCli(
+	args: string[],
+	options: { timeout?: number } = {},
+): Promise<{ stdout: string; stderr: string; exitCode: number }> {
+	return new Promise((resolve) => {
+		const timeout = options.timeout ?? 60000
+
+		let stdout = ""
+		let stderr = ""
+		let timedOut = false
+
+		const proc: ChildProcess = spawn("pnpm", ["start", ...args], {
+			cwd: findCliRoot(),
+			env: { ...process.env, OPENROUTER_API_KEY, NO_COLOR: "1", FORCE_COLOR: "0" },
+			stdio: ["pipe", "pipe", "pipe"],
+		})
+
+		const timeoutId = setTimeout(() => {
+			timedOut = true
+			proc.kill("SIGTERM")
+		}, timeout)
+
+		proc.stdout?.on("data", (data: Buffer) => {
+			stdout += data.toString()
+		})
+
+		proc.stderr?.on("data", (data: Buffer) => {
+			stderr += data.toString()
+		})
+
+		proc.on("close", (code: number | null) => {
+			clearTimeout(timeoutId)
+			resolve({ stdout, stderr, exitCode: timedOut ? -1 : (code ?? 1) })
+		})
+
+		proc.on("error", (error: Error) => {
+			clearTimeout(timeoutId)
+			stderr += error.message
+			resolve({ stdout, stderr, exitCode: 1 })
+		})
+	})
+}
+
+describe.skipIf(!RUN_INTEGRATION_TESTS || !hasApiKey)("CLI Integration Tests", () => {
+	beforeAll(() => {
+		buildExtensionIfNeeded()
+		buildCliIfNeeded()
+	})
+
+	it("should complete end-to-end task execution via CLI", async () => {
+		const result = await runCli(
+			["--no-tui", "-m", "anthropic/claude-sonnet-4.5", "-M", "ask", "-r", "disabled", "-P", "1+1=?"],
+			{ timeout: 30_000 },
+		)
+
+		console.log("CLI stdout:", result.stdout)
+
+		if (result.stderr) {
+			console.log("CLI stderr:", result.stderr)
+		}
+
+		expect(result.exitCode).toBe(0)
+		expect(result.stdout).toContain("2")
+		expect(result.stdout).toContain("[task complete]")
+	}, 30_000)
+})

apps/cli/src/agent/__tests__/events.test.ts

@@ -0,0 +1,35 @@
+import type { ClineMessage } from "@roo-code/types"
+
+import { detectAgentState } from "../agent-state.js"
+import { taskCompleted } from "../events.js"
+
+function createMessage(overrides: Partial<ClineMessage>): ClineMessage {
+	return { ts: Date.now() + Math.random() * 1000, type: "say", ...overrides }
+}
+
+describe("taskCompleted", () => {
+	it("returns true for completion_result", () => {
+		const previous = detectAgentState([createMessage({ type: "say", say: "text", text: "working" })])
+		const current = detectAgentState([createMessage({ type: "ask", ask: "completion_result", partial: false })])
+
+		expect(taskCompleted(previous, current)).toBe(true)
+	})
+
+	it("returns true for resume_completed_task", () => {
+		const previous = detectAgentState([createMessage({ type: "say", say: "text", text: "working" })])
+		const current = detectAgentState([createMessage({ type: "ask", ask: "resume_completed_task", partial: false })])
+
+		expect(taskCompleted(previous, current)).toBe(true)
+	})
+
+	it("returns false for recoverable idle asks", () => {
+		const previous = detectAgentState([createMessage({ type: "say", say: "text", text: "working" })])
+		const mistakeLimit = detectAgentState([
+			createMessage({ type: "ask", ask: "mistake_limit_reached", partial: false }),
+		])
+		const apiFailed = detectAgentState([createMessage({ type: "ask", ask: "api_req_failed", partial: false })])
+
+		expect(taskCompleted(previous, mistakeLimit)).toBe(false)
+		expect(taskCompleted(previous, apiFailed)).toBe(false)
+	})
+})

apps/cli/src/agent/__tests__/extension-client.test.ts

@@ -0,0 +1,850 @@
+import {
+	type ClineMessage,
+	type ExtensionMessage,
+	isIdleAsk,
+	isResumableAsk,
+	isInteractiveAsk,
+	isNonBlockingAsk,
+} from "@roo-code/types"
+
+import { AgentLoopState, detectAgentState } from "../agent-state.js"
+import { createMockClient } from "../extension-client.js"
+
+function createMessage(overrides: Partial<ClineMessage>): ClineMessage {
+	return { ts: Date.now() + Math.random() * 1000, type: "say", ...overrides }
+}
+
+function createStateMessage(messages: ClineMessage[], mode?: string): ExtensionMessage {
+	return { type: "state", state: { clineMessages: messages, mode } } as ExtensionMessage
+}
+
+describe("detectAgentState", () => {
+	describe("NO_TASK state", () => {
+		it("should return NO_TASK for empty messages array", () => {
+			const state = detectAgentState([])
+			expect(state.state).toBe(AgentLoopState.NO_TASK)
+			expect(state.isWaitingForInput).toBe(false)
+			expect(state.isRunning).toBe(false)
+		})
+
+		it("should return NO_TASK for undefined messages", () => {
+			const state = detectAgentState(undefined as unknown as ClineMessage[])
+			expect(state.state).toBe(AgentLoopState.NO_TASK)
+		})
+	})
+
+	describe("STREAMING state", () => {
+		it("should detect streaming when partial is true", () => {
+			const messages = [createMessage({ type: "ask", ask: "tool", partial: true })]
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.STREAMING)
+			expect(state.isStreaming).toBe(true)
+			expect(state.isWaitingForInput).toBe(false)
+		})
+
+		it("should detect streaming when api_req_started has no cost", () => {
+			const messages = [
+				createMessage({
+					say: "api_req_started",
+					text: JSON.stringify({ tokensIn: 100 }), // No cost field.
+				}),
+			]
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.STREAMING)
+			expect(state.isStreaming).toBe(true)
+		})
+
+		it("should NOT be streaming when api_req_started has cost", () => {
+			const messages = [
+				createMessage({
+					say: "api_req_started",
+					text: JSON.stringify({ cost: 0.001, tokensIn: 100 }),
+				}),
+			]
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.RUNNING)
+			expect(state.isStreaming).toBe(false)
+		})
+	})
+
+	describe("WAITING_FOR_INPUT state", () => {
+		it("should detect waiting for tool approval", () => {
+			const messages = [createMessage({ type: "ask", ask: "tool", partial: false })]
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.WAITING_FOR_INPUT)
+			expect(state.isWaitingForInput).toBe(true)
+			expect(state.currentAsk).toBe("tool")
+			expect(state.requiredAction).toBe("approve")
+		})
+
+		it("should detect waiting for command approval", () => {
+			const messages = [createMessage({ type: "ask", ask: "command", partial: false })]
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.WAITING_FOR_INPUT)
+			expect(state.currentAsk).toBe("command")
+			expect(state.requiredAction).toBe("approve")
+		})
+
+		it("should detect waiting for followup answer", () => {
+			const messages = [createMessage({ type: "ask", ask: "followup", partial: false })]
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.WAITING_FOR_INPUT)
+			expect(state.currentAsk).toBe("followup")
+			expect(state.requiredAction).toBe("answer")
+		})
+
+		it("should detect waiting for use_mcp_server approval", () => {
+			const messages = [createMessage({ type: "ask", ask: "use_mcp_server", partial: false })]
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.WAITING_FOR_INPUT)
+			expect(state.requiredAction).toBe("approve")
+		})
+	})
+
+	describe("IDLE state", () => {
+		it("should detect completion_result as idle", () => {
+			const messages = [createMessage({ type: "ask", ask: "completion_result", partial: false })]
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.IDLE)
+			expect(state.isWaitingForInput).toBe(true)
+			expect(state.requiredAction).toBe("start_task")
+		})
+
+		it("should detect api_req_failed as idle", () => {
+			const messages = [createMessage({ type: "ask", ask: "api_req_failed", partial: false })]
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.IDLE)
+			expect(state.requiredAction).toBe("retry_or_new_task")
+		})
+
+		it("should detect mistake_limit_reached as idle", () => {
+			const messages = [createMessage({ type: "ask", ask: "mistake_limit_reached", partial: false })]
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.IDLE)
+			expect(state.requiredAction).toBe("proceed_or_new_task")
+		})
+
+		it("should detect auto_approval_max_req_reached as idle", () => {
+			const messages = [createMessage({ type: "ask", ask: "auto_approval_max_req_reached", partial: false })]
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.IDLE)
+			expect(state.requiredAction).toBe("start_new_task")
+		})
+
+		it("should detect resume_completed_task as idle", () => {
+			const messages = [createMessage({ type: "ask", ask: "resume_completed_task", partial: false })]
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.IDLE)
+			expect(state.requiredAction).toBe("start_new_task")
+		})
+	})
+
+	describe("RESUMABLE state", () => {
+		it("should detect resume_task as resumable", () => {
+			const messages = [createMessage({ type: "ask", ask: "resume_task", partial: false })]
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.RESUMABLE)
+			expect(state.isWaitingForInput).toBe(true)
+			expect(state.requiredAction).toBe("resume_or_abandon")
+		})
+	})
+
+	describe("RUNNING state", () => {
+		it("should detect running for say messages", () => {
+			const messages = [
+				createMessage({
+					say: "api_req_started",
+					text: JSON.stringify({ cost: 0.001 }),
+				}),
+				createMessage({ say: "text", text: "Working on it..." }),
+			]
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.RUNNING)
+			expect(state.isRunning).toBe(true)
+			expect(state.isWaitingForInput).toBe(false)
+		})
+
+		it("should detect running for command_output (non-blocking)", () => {
+			const messages = [createMessage({ type: "ask", ask: "command_output", partial: false })]
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.RUNNING)
+			expect(state.requiredAction).toBe("continue_or_abort")
+		})
+	})
+})
+
+describe("Type Guards", () => {
+	describe("isIdleAsk", () => {
+		it("should return true for idle asks", () => {
+			expect(isIdleAsk("completion_result")).toBe(true)
+			expect(isIdleAsk("api_req_failed")).toBe(true)
+			expect(isIdleAsk("mistake_limit_reached")).toBe(true)
+			expect(isIdleAsk("auto_approval_max_req_reached")).toBe(true)
+			expect(isIdleAsk("resume_completed_task")).toBe(true)
+		})
+
+		it("should return false for non-idle asks", () => {
+			expect(isIdleAsk("tool")).toBe(false)
+			expect(isIdleAsk("followup")).toBe(false)
+			expect(isIdleAsk("resume_task")).toBe(false)
+		})
+	})
+
+	describe("isInteractiveAsk", () => {
+		it("should return true for interactive asks", () => {
+			expect(isInteractiveAsk("tool")).toBe(true)
+			expect(isInteractiveAsk("command")).toBe(true)
+			expect(isInteractiveAsk("followup")).toBe(true)
+			expect(isInteractiveAsk("use_mcp_server")).toBe(true)
+		})
+
+		it("should return false for non-interactive asks", () => {
+			expect(isInteractiveAsk("completion_result")).toBe(false)
+			expect(isInteractiveAsk("command_output")).toBe(false)
+		})
+	})
+
+	describe("isResumableAsk", () => {
+		it("should return true for resumable asks", () => {
+			expect(isResumableAsk("resume_task")).toBe(true)
+		})
+
+		it("should return false for non-resumable asks", () => {
+			expect(isResumableAsk("completion_result")).toBe(false)
+			expect(isResumableAsk("tool")).toBe(false)
+		})
+	})
+
+	describe("isNonBlockingAsk", () => {
+		it("should return true for non-blocking asks", () => {
+			expect(isNonBlockingAsk("command_output")).toBe(true)
+		})
+
+		it("should return false for blocking asks", () => {
+			expect(isNonBlockingAsk("tool")).toBe(false)
+			expect(isNonBlockingAsk("followup")).toBe(false)
+		})
+	})
+})
+
+describe("ExtensionClient", () => {
+	describe("State queries", () => {
+		it("should return NO_TASK when not initialized", () => {
+			const { client } = createMockClient()
+			expect(client.getCurrentState()).toBe(AgentLoopState.NO_TASK)
+			expect(client.isInitialized()).toBe(false)
+		})
+
+		it("should update state when receiving messages", () => {
+			const { client } = createMockClient()
+
+			const message = createStateMessage([createMessage({ type: "ask", ask: "tool", partial: false })])
+
+			client.handleMessage(message)
+
+			expect(client.isInitialized()).toBe(true)
+			expect(client.getCurrentState()).toBe(AgentLoopState.WAITING_FOR_INPUT)
+			expect(client.isWaitingForInput()).toBe(true)
+			expect(client.getCurrentAsk()).toBe("tool")
+		})
+	})
+
+	describe("Event emission", () => {
+		it("should emit stateChange events", () => {
+			const { client } = createMockClient()
+			const stateChanges: AgentLoopState[] = []
+
+			client.onStateChange((event) => {
+				stateChanges.push(event.currentState.state)
+			})
+
+			client.handleMessage(createStateMessage([createMessage({ type: "ask", ask: "tool", partial: false })]))
+
+			expect(stateChanges).toContain(AgentLoopState.WAITING_FOR_INPUT)
+		})
+
+		it("should emit waitingForInput events", () => {
+			const { client } = createMockClient()
+			const waitingEvents: string[] = []
+
+			client.onWaitingForInput((event) => {
+				waitingEvents.push(event.ask)
+			})
+
+			client.handleMessage(createStateMessage([createMessage({ type: "ask", ask: "followup", partial: false })]))
+
+			expect(waitingEvents).toContain("followup")
+		})
+
+		it("should allow unsubscribing from events", () => {
+			const { client } = createMockClient()
+			let callCount = 0
+
+			const unsubscribe = client.onStateChange(() => {
+				callCount++
+			})
+
+			client.handleMessage(createStateMessage([createMessage({ say: "text" })]))
+			expect(callCount).toBe(1)
+
+			unsubscribe()
+
+			client.handleMessage(createStateMessage([createMessage({ say: "text", ts: Date.now() + 1 })]))
+			expect(callCount).toBe(1) // Should not increase.
+		})
+
+		it("should emit modeChanged events", () => {
+			const { client } = createMockClient()
+			const modeChanges: { previousMode: string | undefined; currentMode: string }[] = []
+
+			client.onModeChanged((event) => {
+				modeChanges.push(event)
+			})
+
+			// Set initial mode
+			client.handleMessage(createStateMessage([createMessage({ say: "text" })], "code"))
+
+			expect(modeChanges).toHaveLength(1)
+			expect(modeChanges[0]).toEqual({ previousMode: undefined, currentMode: "code" })
+
+			// Change mode
+			client.handleMessage(createStateMessage([createMessage({ say: "text" })], "architect"))
+
+			expect(modeChanges).toHaveLength(2)
+			expect(modeChanges[1]).toEqual({ previousMode: "code", currentMode: "architect" })
+		})
+
+		it("should not emit modeChanged when mode stays the same", () => {
+			const { client } = createMockClient()
+			let modeChangeCount = 0
+
+			client.onModeChanged(() => {
+				modeChangeCount++
+			})
+
+			// Set initial mode
+			client.handleMessage(createStateMessage([createMessage({ say: "text" })], "code"))
+			expect(modeChangeCount).toBe(1)
+
+			// Same mode - should not emit
+			client.handleMessage(createStateMessage([createMessage({ say: "text", ts: Date.now() + 1 })], "code"))
+			expect(modeChangeCount).toBe(1)
+		})
+	})
+
+	describe("Response methods", () => {
+		it("should send approve response", () => {
+			const { client, sentMessages } = createMockClient()
+
+			client.approve()
+
+			expect(sentMessages).toHaveLength(1)
+			expect(sentMessages[0]).toEqual({
+				type: "askResponse",
+				askResponse: "yesButtonClicked",
+				text: undefined,
+				images: undefined,
+			})
+		})
+
+		it("should send reject response", () => {
+			const { client, sentMessages } = createMockClient()
+
+			client.reject()
+
+			expect(sentMessages).toHaveLength(1)
+			const msg = sentMessages[0]
+			expect(msg).toBeDefined()
+			expect(msg?.askResponse).toBe("noButtonClicked")
+		})
+
+		it("should send text response", () => {
+			const { client, sentMessages } = createMockClient()
+
+			client.respond("My answer", ["image-data"])
+
+			expect(sentMessages).toHaveLength(1)
+			expect(sentMessages[0]).toEqual({
+				type: "askResponse",
+				askResponse: "messageResponse",
+				text: "My answer",
+				images: ["image-data"],
+			})
+		})
+
+		it("should send newTask message", () => {
+			const { client, sentMessages } = createMockClient()
+
+			client.newTask("Build a web app")
+
+			expect(sentMessages).toHaveLength(1)
+			expect(sentMessages[0]).toEqual({
+				type: "newTask",
+				text: "Build a web app",
+				images: undefined,
+			})
+		})
+
+		it("should send clearTask message", () => {
+			const { client, sentMessages } = createMockClient()
+
+			client.clearTask()
+
+			expect(sentMessages).toHaveLength(1)
+			expect(sentMessages[0]).toEqual({
+				type: "clearTask",
+			})
+		})
+
+		it("should send cancelTask message", () => {
+			const { client, sentMessages } = createMockClient()
+
+			client.cancelTask()
+
+			expect(sentMessages).toHaveLength(1)
+			expect(sentMessages[0]).toEqual({
+				type: "cancelTask",
+			})
+		})
+
+		it("should send terminal continue operation", () => {
+			const { client, sentMessages } = createMockClient()
+
+			client.continueTerminal()
+
+			expect(sentMessages).toHaveLength(1)
+			expect(sentMessages[0]).toEqual({
+				type: "terminalOperation",
+				terminalOperation: "continue",
+			})
+		})
+
+		it("should send terminal abort operation", () => {
+			const { client, sentMessages } = createMockClient()
+
+			client.abortTerminal()
+
+			expect(sentMessages).toHaveLength(1)
+			expect(sentMessages[0]).toEqual({
+				type: "terminalOperation",
+				terminalOperation: "abort",
+			})
+		})
+	})
+
+	describe("Message handling", () => {
+		it("should handle JSON string messages", () => {
+			const { client } = createMockClient()
+
+			const message = JSON.stringify(
+				createStateMessage([createMessage({ type: "ask", ask: "completion_result", partial: false })]),
+			)
+
+			client.handleMessage(message)
+
+			expect(client.getCurrentState()).toBe(AgentLoopState.IDLE)
+		})
+
+		it("should ignore invalid JSON", () => {
+			const { client } = createMockClient()
+
+			client.handleMessage("not valid json")
+
+			expect(client.getCurrentState()).toBe(AgentLoopState.NO_TASK)
+		})
+
+		it("should handle messageUpdated messages", () => {
+			const { client } = createMockClient()
+
+			// First, set initial state.
+			client.handleMessage(
+				createStateMessage([createMessage({ ts: 123, type: "ask", ask: "tool", partial: true })]),
+			)
+
+			expect(client.isStreaming()).toBe(true)
+
+			// Now update the message.
+			client.handleMessage({
+				type: "messageUpdated",
+				clineMessage: createMessage({ ts: 123, type: "ask", ask: "tool", partial: false }),
+			})
+
+			expect(client.isStreaming()).toBe(false)
+			expect(client.isWaitingForInput()).toBe(true)
+		})
+	})
+
+	describe("Reset functionality", () => {
+		it("should reset state", () => {
+			const { client } = createMockClient()
+
+			client.handleMessage(createStateMessage([createMessage({ type: "ask", ask: "tool", partial: false })]))
+
+			expect(client.isInitialized()).toBe(true)
+			expect(client.getCurrentState()).toBe(AgentLoopState.WAITING_FOR_INPUT)
+
+			client.reset()
+
+			expect(client.isInitialized()).toBe(false)
+			expect(client.getCurrentState()).toBe(AgentLoopState.NO_TASK)
+		})
+
+		it("should reset mode on reset", () => {
+			const { client } = createMockClient()
+
+			client.handleMessage(createStateMessage([createMessage({ say: "text" })], "code"))
+			expect(client.getCurrentMode()).toBe("code")
+
+			client.reset()
+
+			expect(client.getCurrentMode()).toBeUndefined()
+		})
+	})
+
+	describe("Mode tracking", () => {
+		it("should return undefined mode when not initialized", () => {
+			const { client } = createMockClient()
+			expect(client.getCurrentMode()).toBeUndefined()
+		})
+
+		it("should track mode from state messages", () => {
+			const { client } = createMockClient()
+
+			client.handleMessage(createStateMessage([createMessage({ say: "text" })], "code"))
+
+			expect(client.getCurrentMode()).toBe("code")
+		})
+
+		it("should update mode when it changes", () => {
+			const { client } = createMockClient()
+
+			client.handleMessage(createStateMessage([createMessage({ say: "text" })], "code"))
+			expect(client.getCurrentMode()).toBe("code")
+
+			client.handleMessage(createStateMessage([createMessage({ say: "text", ts: Date.now() + 1 })], "architect"))
+			expect(client.getCurrentMode()).toBe("architect")
+		})
+
+		it("should preserve mode when state message has no mode", () => {
+			const { client } = createMockClient()
+
+			// Set initial mode
+			client.handleMessage(createStateMessage([createMessage({ say: "text" })], "code"))
+			expect(client.getCurrentMode()).toBe("code")
+
+			// State update without mode - should preserve existing mode
+			client.handleMessage(createStateMessage([createMessage({ say: "text", ts: Date.now() + 1 })]))
+			expect(client.getCurrentMode()).toBe("code")
+		})
+
+		it("should preserve mode when task is cleared", () => {
+			const { client } = createMockClient()
+
+			client.handleMessage(createStateMessage([createMessage({ say: "text" })], "architect"))
+			expect(client.getCurrentMode()).toBe("architect")
+
+			client.clearTask()
+			// Mode should be preserved after clear
+			expect(client.getCurrentMode()).toBe("architect")
+		})
+	})
+})
+
+describe("Integration", () => {
+	it("should handle a complete task flow", () => {
+		const { client } = createMockClient()
+		const states: AgentLoopState[] = []
+
+		client.onStateChange((event) => {
+			states.push(event.currentState.state)
+		})
+
+		// 1. Task starts, API request begins.
+		client.handleMessage(
+			createStateMessage([
+				createMessage({
+					say: "api_req_started",
+					text: JSON.stringify({}), // No cost = streaming.
+				}),
+			]),
+		)
+		expect(client.isStreaming()).toBe(true)
+
+		// 2. API request completes.
+		client.handleMessage(
+			createStateMessage([
+				createMessage({
+					say: "api_req_started",
+					text: JSON.stringify({ cost: 0.001 }),
+				}),
+				createMessage({ say: "text", text: "I'll help you with that." }),
+			]),
+		)
+		expect(client.isStreaming()).toBe(false)
+		expect(client.isRunning()).toBe(true)
+
+		// 3. Tool ask (partial).
+		client.handleMessage(
+			createStateMessage([
+				createMessage({
+					say: "api_req_started",
+					text: JSON.stringify({ cost: 0.001 }),
+				}),
+				createMessage({ say: "text", text: "I'll help you with that." }),
+				createMessage({ type: "ask", ask: "tool", partial: true }),
+			]),
+		)
+		expect(client.isStreaming()).toBe(true)
+
+		// 4. Tool ask (complete).
+		client.handleMessage(
+			createStateMessage([
+				createMessage({
+					say: "api_req_started",
+					text: JSON.stringify({ cost: 0.001 }),
+				}),
+				createMessage({ say: "text", text: "I'll help you with that." }),
+				createMessage({ type: "ask", ask: "tool", partial: false }),
+			]),
+		)
+		expect(client.isWaitingForInput()).toBe(true)
+		expect(client.getCurrentAsk()).toBe("tool")
+
+		// 5. User approves, task completes.
+		client.handleMessage(
+			createStateMessage([
+				createMessage({
+					say: "api_req_started",
+					text: JSON.stringify({ cost: 0.001 }),
+				}),
+				createMessage({ say: "text", text: "I'll help you with that." }),
+				createMessage({ type: "ask", ask: "tool", partial: false }),
+				createMessage({ say: "text", text: "File created." }),
+				createMessage({ type: "ask", ask: "completion_result", partial: false }),
+			]),
+		)
+		expect(client.getCurrentState()).toBe(AgentLoopState.IDLE)
+		expect(client.getCurrentAsk()).toBe("completion_result")
+
+		// Verify we saw the expected state transitions.
+		expect(states).toContain(AgentLoopState.STREAMING)
+		expect(states).toContain(AgentLoopState.RUNNING)
+		expect(states).toContain(AgentLoopState.WAITING_FOR_INPUT)
+		expect(states).toContain(AgentLoopState.IDLE)
+	})
+})
+
+describe("Edge Cases", () => {
+	describe("Messages with missing or empty text field", () => {
+		it("should handle ask message with missing text field", () => {
+			const messages = [createMessage({ type: "ask", ask: "tool", partial: false })]
+			// Text is undefined by default.
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.WAITING_FOR_INPUT)
+			expect(state.currentAsk).toBe("tool")
+		})
+
+		it("should handle ask message with empty text field", () => {
+			const messages = [createMessage({ type: "ask", ask: "followup", partial: false, text: "" })]
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.WAITING_FOR_INPUT)
+			expect(state.currentAsk).toBe("followup")
+		})
+
+		it("should handle say message with missing text field", () => {
+			const messages = [createMessage({ say: "text" })]
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.RUNNING)
+		})
+	})
+
+	describe("api_req_started edge cases", () => {
+		it("should handle api_req_started with empty text field as streaming", () => {
+			const messages = [createMessage({ say: "api_req_started", text: "" })]
+			const state = detectAgentState(messages)
+			// Empty text is treated as "no text yet" = still in progress (streaming).
+			// This matches the behavior: !message.text is true for "" (falsy).
+			expect(state.state).toBe(AgentLoopState.STREAMING)
+			expect(state.isStreaming).toBe(true)
+		})
+
+		it("should handle api_req_started with invalid JSON", () => {
+			const messages = [createMessage({ say: "api_req_started", text: "not valid json" })]
+			const state = detectAgentState(messages)
+			// Invalid JSON should not crash, should return not streaming.
+			expect(state.state).toBe(AgentLoopState.RUNNING)
+			expect(state.isStreaming).toBe(false)
+		})
+
+		it("should handle api_req_started with null text", () => {
+			const messages = [createMessage({ say: "api_req_started", text: undefined })]
+			const state = detectAgentState(messages)
+			// No text means still in progress (streaming).
+			expect(state.state).toBe(AgentLoopState.STREAMING)
+			expect(state.isStreaming).toBe(true)
+		})
+
+		it("should handle api_req_started with cost of 0", () => {
+			const messages = [createMessage({ say: "api_req_started", text: JSON.stringify({ cost: 0 }) })]
+			const state = detectAgentState(messages)
+			// cost: 0 is defined (not undefined), so NOT streaming.
+			expect(state.state).toBe(AgentLoopState.RUNNING)
+			expect(state.isStreaming).toBe(false)
+		})
+
+		it("should handle api_req_started with cost of null", () => {
+			const messages = [createMessage({ say: "api_req_started", text: JSON.stringify({ cost: null }) })]
+			const state = detectAgentState(messages)
+			// cost: null is defined (not undefined), so NOT streaming.
+			expect(state.state).toBe(AgentLoopState.RUNNING)
+			expect(state.isStreaming).toBe(false)
+		})
+
+		it("should find api_req_started when it's not the last message", () => {
+			const messages = [
+				createMessage({ say: "api_req_started", text: JSON.stringify({ tokensIn: 100 }) }), // No cost = streaming
+				createMessage({ say: "text", text: "Some text" }),
+			]
+			const state = detectAgentState(messages)
+			// Last message is say:text, but api_req_started has no cost.
+			expect(state.state).toBe(AgentLoopState.STREAMING)
+			expect(state.isStreaming).toBe(true)
+		})
+	})
+
+	describe("Rapid state transitions", () => {
+		it("should handle multiple rapid state changes", () => {
+			const { client } = createMockClient()
+			const states: AgentLoopState[] = []
+
+			client.onStateChange((event) => {
+				states.push(event.currentState.state)
+			})
+
+			// Rapid updates.
+			client.handleMessage(createStateMessage([createMessage({ say: "text" })]))
+			client.handleMessage(createStateMessage([createMessage({ type: "ask", ask: "tool", partial: true })]))
+			client.handleMessage(createStateMessage([createMessage({ type: "ask", ask: "tool", partial: false })]))
+			client.handleMessage(
+				createStateMessage([createMessage({ type: "ask", ask: "completion_result", partial: false })]),
+			)
+
+			// Should have tracked all transitions.
+			expect(states.length).toBeGreaterThanOrEqual(3)
+			expect(states).toContain(AgentLoopState.STREAMING)
+			expect(states).toContain(AgentLoopState.WAITING_FOR_INPUT)
+			expect(states).toContain(AgentLoopState.IDLE)
+		})
+	})
+
+	describe("Message array edge cases", () => {
+		it("should handle single message array", () => {
+			const messages = [createMessage({ say: "text", text: "Hello" })]
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.RUNNING)
+			expect(state.lastMessage).toBeDefined()
+			expect(state.lastMessageTs).toBe(messages[0]!.ts)
+		})
+
+		it("should use last message for state detection", () => {
+			// Multiple messages, last one determines state.
+			const messages = [
+				createMessage({ type: "ask", ask: "tool", partial: false }),
+				createMessage({ say: "text", text: "Tool executed" }),
+				createMessage({ type: "ask", ask: "completion_result", partial: false }),
+			]
+			const state = detectAgentState(messages)
+			// Last message is completion_result, so IDLE.
+			expect(state.state).toBe(AgentLoopState.IDLE)
+			expect(state.currentAsk).toBe("completion_result")
+		})
+
+		it("should handle very long message arrays", () => {
+			// Create many messages.
+			const messages: ClineMessage[] = []
+
+			for (let i = 0; i < 100; i++) {
+				messages.push(createMessage({ say: "text", text: `Message ${i}` }))
+			}
+
+			messages.push(createMessage({ type: "ask", ask: "followup", partial: false }))
+
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.WAITING_FOR_INPUT)
+			expect(state.currentAsk).toBe("followup")
+		})
+	})
+
+	describe("State message edge cases", () => {
+		it("should handle state message with empty clineMessages", () => {
+			const { client } = createMockClient()
+			client.handleMessage({ type: "state", state: { clineMessages: [] } } as unknown as ExtensionMessage)
+			expect(client.getCurrentState()).toBe(AgentLoopState.NO_TASK)
+			expect(client.isInitialized()).toBe(true)
+		})
+
+		it("should handle state message with missing clineMessages", () => {
+			const { client } = createMockClient()
+
+			client.handleMessage({
+				type: "state",
+				// eslint-disable-next-line @typescript-eslint/no-explicit-any
+				state: {} as any,
+			})
+
+			// Should not crash, state should remain unchanged.
+			expect(client.getCurrentState()).toBe(AgentLoopState.NO_TASK)
+		})
+
+		it("should handle state message with missing state field", () => {
+			const { client } = createMockClient()
+
+			// eslint-disable-next-line @typescript-eslint/no-explicit-any
+			client.handleMessage({ type: "state" } as any)
+
+			// Should not crash
+			expect(client.getCurrentState()).toBe(AgentLoopState.NO_TASK)
+		})
+	})
+
+	describe("Partial to complete transitions", () => {
+		it("should transition from streaming to waiting when partial becomes false", () => {
+			const ts = Date.now()
+			const messages1 = [createMessage({ ts, type: "ask", ask: "tool", partial: true })]
+			const messages2 = [createMessage({ ts, type: "ask", ask: "tool", partial: false })]
+
+			const state1 = detectAgentState(messages1)
+			const state2 = detectAgentState(messages2)
+
+			expect(state1.state).toBe(AgentLoopState.STREAMING)
+			expect(state1.isWaitingForInput).toBe(false)
+
+			expect(state2.state).toBe(AgentLoopState.WAITING_FOR_INPUT)
+			expect(state2.isWaitingForInput).toBe(true)
+		})
+
+		it("should handle partial say messages", () => {
+			const messages = [createMessage({ say: "text", text: "Typing...", partial: true })]
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.STREAMING)
+			expect(state.isStreaming).toBe(true)
+		})
+	})
+
+	describe("Unknown message types", () => {
+		it("should handle unknown ask types gracefully", () => {
+			// eslint-disable-next-line @typescript-eslint/no-explicit-any
+			const messages = [createMessage({ type: "ask", ask: "unknown_type" as any, partial: false })]
+			const state = detectAgentState(messages)
+			// Unknown ask type should default to RUNNING.
+			expect(state.state).toBe(AgentLoopState.RUNNING)
+		})
+
+		it("should handle unknown say types gracefully", () => {
+			// eslint-disable-next-line @typescript-eslint/no-explicit-any
+			const messages = [createMessage({ say: "unknown_say_type" as any })]
+			const state = detectAgentState(messages)
+			expect(state.state).toBe(AgentLoopState.RUNNING)
+		})
+	})
+})

apps/cli/src/agent/__tests__/extension-host.test.ts

@@ -0,0 +1,760 @@
+// pnpm --filter @roo-code/cli test src/agent/__tests__/extension-host.test.ts
+
+import { EventEmitter } from "events"
+import fs from "fs"
+
+import type { ExtensionMessage, WebviewMessage } from "@roo-code/types"
+
+import { DEFAULT_FLAGS } from "@/types/index.js"
+
+import { type ExtensionHostOptions, ExtensionHost } from "../extension-host.js"
+import { ExtensionClient } from "../extension-client.js"
+import { AgentLoopState } from "../agent-state.js"
+
+vi.mock("@roo-code/vscode-shim", () => ({
+	createVSCodeAPI: vi.fn(() => ({
+		context: { extensionPath: "/test/extension" },
+	})),
+	setRuntimeConfigValues: vi.fn(),
+}))
+
+vi.mock("@/lib/storage/index.js", () => ({
+	createEphemeralStorageDir: vi.fn(() => Promise.resolve("/tmp/roo-cli-test-ephemeral")),
+}))
+
+/**
+ * Create a test ExtensionHost with default options.
+ */
+function createTestHost({
+	mode = "code",
+	provider = "openrouter",
+	model = "test-model",
+	...options
+}: Partial<ExtensionHostOptions> = {}): ExtensionHost {
+	return new ExtensionHost({
+		mode,
+		user: null,
+		provider,
+		model,
+		workspacePath: "/test/workspace",
+		extensionPath: "/test/extension",
+		ephemeral: false,
+		debug: false,
+		exitOnComplete: false,
+		...options,
+	})
+}
+
+// Type for accessing private members
+type PrivateHost = Record<string, unknown>
+
+/**
+ * Helper to access private members for testing
+ */
+function getPrivate<T>(host: ExtensionHost, key: string): T {
+	return (host as unknown as PrivateHost)[key] as T
+}
+
+/**
+ * Helper to set private members for testing
+ */
+function setPrivate(host: ExtensionHost, key: string, value: unknown): void {
+	;(host as unknown as PrivateHost)[key] = value
+}
+
+/**
+ * Helper to call private methods for testing
+ * This uses a more permissive type to avoid TypeScript errors with private methods
+ */
+function callPrivate<T>(host: ExtensionHost, method: string, ...args: unknown[]): T {
+	const fn = (host as unknown as PrivateHost)[method] as ((...a: unknown[]) => T) | undefined
+	if (!fn) throw new Error(`Method ${method} not found`)
+	return fn.apply(host, args)
+}
+
+/**
+ * Helper to spy on private methods
+ * This uses a more permissive type to avoid TypeScript errors with vi.spyOn on private methods
+ */
+function spyOnPrivate(host: ExtensionHost, method: string) {
+	// eslint-disable-next-line @typescript-eslint/no-explicit-any
+	return vi.spyOn(host as any, method)
+}
+
+describe("ExtensionHost", () => {
+	const initialRooCliRuntimeEnv = process.env.ROO_CLI_RUNTIME
+
+	beforeEach(() => {
+		vi.resetAllMocks()
+		if (initialRooCliRuntimeEnv === undefined) {
+			delete process.env.ROO_CLI_RUNTIME
+		} else {
+			process.env.ROO_CLI_RUNTIME = initialRooCliRuntimeEnv
+		}
+		// Clean up globals
+		delete (global as Record<string, unknown>).vscode
+		delete (global as Record<string, unknown>).__extensionHost
+	})
+
+	afterAll(() => {
+		if (initialRooCliRuntimeEnv === undefined) {
+			delete process.env.ROO_CLI_RUNTIME
+		} else {
+			process.env.ROO_CLI_RUNTIME = initialRooCliRuntimeEnv
+		}
+	})
+
+	describe("constructor", () => {
+		it("should store options correctly", () => {
+			const options: ExtensionHostOptions = {
+				mode: "code",
+				workspacePath: "/my/workspace",
+				extensionPath: "/my/extension",
+				user: null,
+				apiKey: "test-key",
+				provider: "openrouter",
+				model: "test-model",
+				ephemeral: false,
+				debug: false,
+				exitOnComplete: false,
+				integrationTest: true, // Set explicitly for testing
+			}
+
+			const host = new ExtensionHost(options)
+
+			// Options are stored as-is
+			const storedOptions = getPrivate<ExtensionHostOptions>(host, "options")
+			expect(storedOptions.mode).toBe(options.mode)
+			expect(storedOptions.workspacePath).toBe(options.workspacePath)
+			expect(storedOptions.extensionPath).toBe(options.extensionPath)
+			expect(storedOptions.integrationTest).toBe(true)
+		})
+
+		it("should be an EventEmitter instance", () => {
+			const host = createTestHost()
+			expect(host).toBeInstanceOf(EventEmitter)
+		})
+
+		it("should initialize with default state values", () => {
+			const host = createTestHost()
+
+			expect(getPrivate(host, "isReady")).toBe(false)
+			expect(getPrivate(host, "vscode")).toBeNull()
+			expect(getPrivate(host, "extensionModule")).toBeNull()
+		})
+
+		it("should initialize managers", () => {
+			const host = createTestHost()
+
+			// Should have client, outputManager, promptManager, and askDispatcher
+			expect(getPrivate(host, "client")).toBeDefined()
+			expect(getPrivate(host, "outputManager")).toBeDefined()
+			expect(getPrivate(host, "promptManager")).toBeDefined()
+			expect(getPrivate(host, "askDispatcher")).toBeDefined()
+		})
+
+		it("should mark process as CLI runtime", () => {
+			delete process.env.ROO_CLI_RUNTIME
+			createTestHost()
+			expect(process.env.ROO_CLI_RUNTIME).toBe("1")
+		})
+
+		it("should set execaShellPath in initialSettings when terminalShell is provided", () => {
+			const host = createTestHost({ terminalShell: "/bin/bash" })
+			const emitSpy = vi.spyOn(host, "emit")
+			host.markWebviewReady()
+			const updateSettingsCall = emitSpy.mock.calls.find(
+				(call) =>
+					call[0] === "webviewMessage" &&
+					typeof call[1] === "object" &&
+					call[1] !== null &&
+					(call[1] as WebviewMessage).type === "updateSettings",
+			)
+			expect(updateSettingsCall).toBeDefined()
+			const payload = updateSettingsCall?.[1] as WebviewMessage
+			expect(payload.updatedSettings?.execaShellPath).toBe("/bin/bash")
+		})
+	})
+
+	describe("webview provider registration", () => {
+		it("should register webview provider without throwing", () => {
+			const host = createTestHost()
+			const mockProvider = { resolveWebviewView: vi.fn() }
+
+			// registerWebviewProvider is now a no-op, just ensure it doesn't throw
+			expect(() => {
+				host.registerWebviewProvider("test-view", mockProvider)
+			}).not.toThrow()
+		})
+
+		it("should unregister webview provider without throwing", () => {
+			const host = createTestHost()
+			const mockProvider = { resolveWebviewView: vi.fn() }
+
+			host.registerWebviewProvider("test-view", mockProvider)
+
+			// unregisterWebviewProvider is now a no-op, just ensure it doesn't throw
+			expect(() => {
+				host.unregisterWebviewProvider("test-view")
+			}).not.toThrow()
+		})
+
+		it("should handle unregistering non-existent provider gracefully", () => {
+			const host = createTestHost()
+
+			expect(() => {
+				host.unregisterWebviewProvider("non-existent")
+			}).not.toThrow()
+		})
+	})
+
+	describe("webview ready state", () => {
+		describe("isInInitialSetup", () => {
+			it("should return true before webview is ready", () => {
+				const host = createTestHost()
+				expect(host.isInInitialSetup()).toBe(true)
+			})
+
+			it("should return false after markWebviewReady is called", () => {
+				const host = createTestHost()
+				host.markWebviewReady()
+				expect(host.isInInitialSetup()).toBe(false)
+			})
+		})
+
+		describe("markWebviewReady", () => {
+			it("should set isReady to true", () => {
+				const host = createTestHost()
+				host.markWebviewReady()
+				expect(getPrivate(host, "isReady")).toBe(true)
+			})
+
+			it("should send webviewDidLaunch message", () => {
+				const host = createTestHost()
+				const emitSpy = vi.spyOn(host, "emit")
+
+				host.markWebviewReady()
+
+				expect(emitSpy).toHaveBeenCalledWith("webviewMessage", { type: "webviewDidLaunch" })
+			})
+
+			it("should send updateSettings message", () => {
+				const host = createTestHost()
+				const emitSpy = vi.spyOn(host, "emit")
+
+				host.markWebviewReady()
+
+				// Check that updateSettings was called
+				const updateSettingsCall = emitSpy.mock.calls.find(
+					(call) =>
+						call[0] === "webviewMessage" &&
+						typeof call[1] === "object" &&
+						call[1] !== null &&
+						(call[1] as WebviewMessage).type === "updateSettings",
+				)
+				expect(updateSettingsCall).toBeDefined()
+			})
+
+			it("should force terminalShellIntegrationDisabled when terminalShell is provided", () => {
+				const host = createTestHost({ terminalShell: "/bin/bash" })
+				const emitSpy = vi.spyOn(host, "emit")
+
+				host.markWebviewReady()
+
+				const updateSettingsCall = emitSpy.mock.calls.find(
+					(call) =>
+						call[0] === "webviewMessage" &&
+						typeof call[1] === "object" &&
+						call[1] !== null &&
+						(call[1] as WebviewMessage).type === "updateSettings",
+				)
+
+				expect(updateSettingsCall).toBeDefined()
+				const payload = updateSettingsCall?.[1] as WebviewMessage
+				expect(payload.type).toBe("updateSettings")
+				expect(payload.updatedSettings?.terminalShellIntegrationDisabled).toBe(true)
+			})
+		})
+	})
+
+	describe("sendToExtension", () => {
+		it("should throw error when extension not ready", () => {
+			const host = createTestHost()
+			const message: WebviewMessage = { type: "requestModes" }
+
+			expect(() => {
+				host.sendToExtension(message)
+			}).toThrow("You cannot send messages to the extension before it is ready")
+		})
+
+		it("should emit webviewMessage event when webview is ready", () => {
+			const host = createTestHost()
+			const emitSpy = vi.spyOn(host, "emit")
+			const message: WebviewMessage = { type: "requestModes" }
+
+			host.markWebviewReady()
+			emitSpy.mockClear() // Clear the markWebviewReady calls
+			host.sendToExtension(message)
+
+			expect(emitSpy).toHaveBeenCalledWith("webviewMessage", message)
+		})
+
+		it("should not throw when webview is ready", () => {
+			const host = createTestHost()
+
+			host.markWebviewReady()
+
+			expect(() => {
+				host.sendToExtension({ type: "requestModes" })
+			}).not.toThrow()
+		})
+	})
+
+	describe("message handling via client", () => {
+		it("should forward extension messages to the client", () => {
+			const host = createTestHost()
+			const client = getPrivate(host, "client") as ExtensionClient
+
+			// Simulate extension message.
+			host.emit("extensionWebviewMessage", {
+				type: "state",
+				state: { clineMessages: [] },
+			} as unknown as ExtensionMessage)
+
+			// Message listener is set up in activate(), which we can't easily call in unit tests.
+			// But we can verify the client exists and has the handleMessage method.
+			expect(typeof client.handleMessage).toBe("function")
+		})
+	})
+
+	describe("public agent state API", () => {
+		it("should return agent state from getAgentState()", () => {
+			const host = createTestHost()
+			const state = host.getAgentState()
+
+			expect(state).toBeDefined()
+			expect(state.state).toBeDefined()
+			expect(state.isWaitingForInput).toBeDefined()
+			expect(state.isRunning).toBeDefined()
+		})
+
+		it("should return isWaitingForInput() status", () => {
+			const host = createTestHost()
+			expect(typeof host.isWaitingForInput()).toBe("boolean")
+		})
+	})
+
+	describe("quiet mode", () => {
+		describe("setupQuietMode", () => {
+			it("should not modify console when integrationTest is true", () => {
+				// By default, constructor sets integrationTest = true
+				const host = createTestHost()
+				const originalLog = console.log
+
+				callPrivate(host, "setupQuietMode")
+
+				// Console should not be modified since integrationTest is true
+				expect(console.log).toBe(originalLog)
+			})
+
+			it("should suppress console when integrationTest is false", () => {
+				// Capture the real console.log before any host is created
+				const originalLog = console.log
+
+				// Create host with integrationTest: true to prevent constructor from suppressing
+				const host = createTestHost({ integrationTest: true })
+
+				// Override integrationTest to false to test suppression
+				const options = getPrivate<ExtensionHostOptions>(host, "options")
+				options.integrationTest = false
+
+				callPrivate(host, "setupQuietMode")
+
+				// Console should be modified (suppressed)
+				expect(console.log).not.toBe(originalLog)
+
+				// Restore for other tests
+				callPrivate(host, "restoreConsole")
+			})
+
+			it("should preserve console.error even when suppressing", () => {
+				const host = createTestHost()
+				const originalError = console.error
+
+				// Override integrationTest to false
+				const options = getPrivate<ExtensionHostOptions>(host, "options")
+				options.integrationTest = false
+
+				callPrivate(host, "setupQuietMode")
+
+				expect(console.error).toBe(originalError)
+
+				callPrivate(host, "restoreConsole")
+			})
+		})
+
+		describe("restoreConsole", () => {
+			it("should restore original console methods when suppressed", () => {
+				// Capture the real console.log before any host is created
+				const originalLog = console.log
+
+				// Create host with integrationTest: true to prevent constructor from suppressing
+				const host = createTestHost({ integrationTest: true })
+
+				// Override integrationTest to false to actually suppress
+				const options = getPrivate<ExtensionHostOptions>(host, "options")
+				options.integrationTest = false
+
+				callPrivate(host, "setupQuietMode")
+				callPrivate(host, "restoreConsole")
+
+				expect(console.log).toBe(originalLog)
+			})
+
+			it("should handle case where console was not suppressed", () => {
+				const host = createTestHost()
+
+				expect(() => {
+					callPrivate(host, "restoreConsole")
+				}).not.toThrow()
+			})
+		})
+	})
+
+	describe("dispose", () => {
+		let host: ExtensionHost
+
+		beforeEach(() => {
+			host = createTestHost()
+		})
+
+		it("should remove message listener", async () => {
+			const listener = vi.fn()
+			setPrivate(host, "messageListener", listener)
+			host.on("extensionWebviewMessage", listener)
+
+			await host.dispose()
+
+			expect(getPrivate(host, "messageListener")).toBeNull()
+		})
+
+		it("should call extension deactivate if available", async () => {
+			const deactivateMock = vi.fn()
+			setPrivate(host, "extensionModule", {
+				deactivate: deactivateMock,
+			})
+
+			await host.dispose()
+
+			expect(deactivateMock).toHaveBeenCalled()
+		})
+
+		it("should clear vscode reference", async () => {
+			setPrivate(host, "vscode", { context: {} })
+
+			await host.dispose()
+
+			expect(getPrivate(host, "vscode")).toBeNull()
+		})
+
+		it("should clear extensionModule reference", async () => {
+			setPrivate(host, "extensionModule", {})
+
+			await host.dispose()
+
+			expect(getPrivate(host, "extensionModule")).toBeNull()
+		})
+
+		it("should delete global vscode", async () => {
+			;(global as Record<string, unknown>).vscode = {}
+
+			await host.dispose()
+
+			expect((global as Record<string, unknown>).vscode).toBeUndefined()
+		})
+
+		it("should delete global __extensionHost", async () => {
+			;(global as Record<string, unknown>).__extensionHost = {}
+
+			await host.dispose()
+
+			expect((global as Record<string, unknown>).__extensionHost).toBeUndefined()
+		})
+
+		it("should call restoreConsole", async () => {
+			const restoreConsoleSpy = spyOnPrivate(host, "restoreConsole")
+
+			await host.dispose()
+
+			expect(restoreConsoleSpy).toHaveBeenCalled()
+		})
+
+		it("should clear ROO_CLI_RUNTIME on dispose when it was previously unset", async () => {
+			delete process.env.ROO_CLI_RUNTIME
+			host = createTestHost()
+			expect(process.env.ROO_CLI_RUNTIME).toBe("1")
+
+			await host.dispose()
+
+			expect(process.env.ROO_CLI_RUNTIME).toBeUndefined()
+		})
+
+		it("should restore prior ROO_CLI_RUNTIME value on dispose", async () => {
+			process.env.ROO_CLI_RUNTIME = "preexisting-value"
+			host = createTestHost()
+			expect(process.env.ROO_CLI_RUNTIME).toBe("1")
+
+			await host.dispose()
+
+			expect(process.env.ROO_CLI_RUNTIME).toBe("preexisting-value")
+		})
+	})
+
+	describe("runTask", () => {
+		it("should send newTask message when called", async () => {
+			const host = createTestHost()
+			host.markWebviewReady()
+
+			const emitSpy = vi.spyOn(host, "emit")
+			const client = getPrivate(host, "client") as ExtensionClient
+
+			// Start the task (will hang waiting for completion)
+			const taskPromise = host.runTask("test prompt")
+
+			// Emit completion to resolve the promise via the client's emitter
+			const taskCompletedEvent = {
+				success: true,
+				stateInfo: {
+					state: AgentLoopState.IDLE,
+					isWaitingForInput: false,
+					isRunning: false,
+					isStreaming: false,
+					requiredAction: "start_task" as const,
+					description: "Task completed",
+				},
+			}
+			setTimeout(() => client.getEmitter().emit("taskCompleted", taskCompletedEvent), 10)
+
+			await taskPromise
+
+			expect(emitSpy).toHaveBeenCalledWith("webviewMessage", { type: "newTask", text: "test prompt" })
+		})
+
+		it("should include taskId when provided", async () => {
+			const host = createTestHost()
+			host.markWebviewReady()
+
+			const emitSpy = vi.spyOn(host, "emit")
+			const client = getPrivate(host, "client") as ExtensionClient
+
+			const taskPromise = host.runTask("test prompt", "task-123")
+
+			const taskCompletedEvent = {
+				success: true,
+				stateInfo: {
+					state: AgentLoopState.IDLE,
+					isWaitingForInput: false,
+					isRunning: false,
+					isStreaming: false,
+					requiredAction: "start_task" as const,
+					description: "Task completed",
+				},
+			}
+			setTimeout(() => client.getEmitter().emit("taskCompleted", taskCompletedEvent), 10)
+
+			await taskPromise
+
+			expect(emitSpy).toHaveBeenCalledWith("webviewMessage", {
+				type: "newTask",
+				text: "test prompt",
+				taskId: "task-123",
+			})
+		})
+
+		it("should resolve when taskCompleted is emitted on client", async () => {
+			const host = createTestHost()
+			host.markWebviewReady()
+
+			const client = getPrivate(host, "client") as ExtensionClient
+			const taskPromise = host.runTask("test prompt")
+
+			// Emit completion after a short delay via the client's emitter
+			const taskCompletedEvent = {
+				success: true,
+				stateInfo: {
+					state: AgentLoopState.IDLE,
+					isWaitingForInput: false,
+					isRunning: false,
+					isStreaming: false,
+					requiredAction: "start_task" as const,
+					description: "Task completed",
+				},
+			}
+			setTimeout(() => client.getEmitter().emit("taskCompleted", taskCompletedEvent), 10)
+
+			await expect(taskPromise).resolves.toBeUndefined()
+		})
+
+		it("should send showTaskWithId for resumeTask and resolve on completion", async () => {
+			const host = createTestHost()
+			host.markWebviewReady()
+
+			const emitSpy = vi.spyOn(host, "emit")
+			const client = getPrivate(host, "client") as ExtensionClient
+
+			const taskPromise = host.resumeTask("task-abc")
+
+			const taskCompletedEvent = {
+				success: true,
+				stateInfo: {
+					state: AgentLoopState.IDLE,
+					isWaitingForInput: false,
+					isRunning: false,
+					isStreaming: false,
+					requiredAction: "start_task" as const,
+					description: "Task completed",
+				},
+			}
+			setTimeout(() => client.getEmitter().emit("taskCompleted", taskCompletedEvent), 10)
+
+			await taskPromise
+
+			expect(emitSpy).toHaveBeenCalledWith("webviewMessage", { type: "showTaskWithId", text: "task-abc" })
+		})
+	})
+
+	describe("initial settings", () => {
+		it("should set mode from options", () => {
+			const host = createTestHost({ mode: "architect" })
+
+			const initialSettings = getPrivate<Record<string, unknown>>(host, "initialSettings")
+			expect(initialSettings.mode).toBe("architect")
+		})
+
+		it("should use default consecutiveMistakeLimit when not provided", () => {
+			const host = createTestHost()
+
+			const initialSettings = getPrivate<Record<string, unknown>>(host, "initialSettings")
+			expect(initialSettings.consecutiveMistakeLimit).toBe(DEFAULT_FLAGS.consecutiveMistakeLimit)
+		})
+
+		it("should set consecutiveMistakeLimit from options", () => {
+			const host = createTestHost({ consecutiveMistakeLimit: 8 })
+
+			const initialSettings = getPrivate<Record<string, unknown>>(host, "initialSettings")
+			expect(initialSettings.consecutiveMistakeLimit).toBe(8)
+		})
+
+		it("should enable auto-approval in non-interactive mode", () => {
+			const host = createTestHost({ nonInteractive: true })
+
+			const initialSettings = getPrivate<Record<string, unknown>>(host, "initialSettings")
+			expect(initialSettings.autoApprovalEnabled).toBe(true)
+			expect(initialSettings.alwaysAllowReadOnly).toBe(true)
+			expect(initialSettings.alwaysAllowWrite).toBe(true)
+			expect(initialSettings.alwaysAllowExecute).toBe(true)
+		})
+
+		it("should disable auto-approval in interactive mode", () => {
+			const host = createTestHost({ nonInteractive: false })
+
+			const initialSettings = getPrivate<Record<string, unknown>>(host, "initialSettings")
+			expect(initialSettings.autoApprovalEnabled).toBe(false)
+		})
+
+		it("should set reasoning effort when specified", () => {
+			const host = createTestHost({ reasoningEffort: "high" })
+
+			const initialSettings = getPrivate<Record<string, unknown>>(host, "initialSettings")
+			expect(initialSettings.enableReasoningEffort).toBe(true)
+			expect(initialSettings.reasoningEffort).toBe("high")
+		})
+
+		it("should disable reasoning effort when set to disabled", () => {
+			const host = createTestHost({ reasoningEffort: "disabled" })
+
+			const initialSettings = getPrivate<Record<string, unknown>>(host, "initialSettings")
+			expect(initialSettings.enableReasoningEffort).toBe(false)
+		})
+
+		it("should not set reasoning effort when unspecified", () => {
+			const host = createTestHost({ reasoningEffort: "unspecified" })
+
+			const initialSettings = getPrivate<Record<string, unknown>>(host, "initialSettings")
+			expect(initialSettings.enableReasoningEffort).toBeUndefined()
+			expect(initialSettings.reasoningEffort).toBeUndefined()
+		})
+	})
+
+	describe("ephemeral mode", () => {
+		it("should store ephemeral option correctly", () => {
+			const host = createTestHost({ ephemeral: true })
+
+			const options = getPrivate<ExtensionHostOptions>(host, "options")
+			expect(options.ephemeral).toBe(true)
+		})
+
+		it("should default ephemeralStorageDir to null", () => {
+			const host = createTestHost()
+
+			expect(getPrivate(host, "ephemeralStorageDir")).toBeNull()
+		})
+
+		it("should clean up ephemeral storage directory on dispose", async () => {
+			const host = createTestHost({ ephemeral: true })
+
+			// Set up a mock ephemeral storage directory
+			const mockEphemeralDir = "/tmp/roo-cli-test-ephemeral-cleanup"
+			setPrivate(host, "ephemeralStorageDir", mockEphemeralDir)
+
+			// Mock fs.promises.rm
+			const rmMock = vi.spyOn(fs.promises, "rm").mockResolvedValue(undefined)
+
+			await host.dispose()
+
+			expect(rmMock).toHaveBeenCalledWith(mockEphemeralDir, { recursive: true, force: true })
+			expect(getPrivate(host, "ephemeralStorageDir")).toBeNull()
+
+			rmMock.mockRestore()
+		})
+
+		it("should not clean up when ephemeralStorageDir is null", async () => {
+			const host = createTestHost()
+
+			// ephemeralStorageDir is null by default
+			expect(getPrivate(host, "ephemeralStorageDir")).toBeNull()
+
+			const rmMock = vi.spyOn(fs.promises, "rm").mockResolvedValue(undefined)
+
+			await host.dispose()
+
+			// rm should not be called when there's no ephemeral storage
+			expect(rmMock).not.toHaveBeenCalled()
+
+			rmMock.mockRestore()
+		})
+
+		it("should handle ephemeral storage cleanup errors gracefully", async () => {
+			const host = createTestHost({ ephemeral: true })
+
+			// Set up a mock ephemeral storage directory
+			setPrivate(host, "ephemeralStorageDir", "/tmp/roo-cli-test-ephemeral-error")
+
+			// Mock fs.promises.rm to throw an error
+			const rmMock = vi.spyOn(fs.promises, "rm").mockRejectedValue(new Error("Cleanup failed"))
+
+			// dispose should not throw even if cleanup fails
+			await expect(host.dispose()).resolves.toBeUndefined()
+
+			rmMock.mockRestore()
+		})
+
+		it("should not affect normal mode when ephemeral is false", () => {
+			const host = createTestHost({ ephemeral: false })
+
+			const options = getPrivate<ExtensionHostOptions>(host, "options")
+			expect(options.ephemeral).toBe(false)
+			expect(getPrivate(host, "ephemeralStorageDir")).toBeNull()
+		})
+	})
+})

apps/cli/src/agent/__tests__/json-event-emitter-control.test.ts

@@ -0,0 +1,170 @@
+import { Writable } from "stream"
+
+import { JsonEventEmitter } from "../json-event-emitter.js"
+
+function createMockStdout(): { stdout: NodeJS.WriteStream; lines: () => Record<string, unknown>[] } {
+	const chunks: string[] = []
+
+	const writable = new Writable({
+		write(chunk, _encoding, callback) {
+			chunks.push(chunk.toString())
+			callback()
+		},
+	}) as unknown as NodeJS.WriteStream
+
+	// Each write is a JSON line terminated by \n
+	const lines = () =>
+		chunks
+			.join("")
+			.split("\n")
+			.filter((l) => l.length > 0)
+			.map((l) => JSON.parse(l) as Record<string, unknown>)
+
+	return { stdout: writable, lines }
+}
+
+describe("JsonEventEmitter control events", () => {
+	describe("emitControl", () => {
+		it("emits an ack event with type control", () => {
+			const { stdout, lines } = createMockStdout()
+			const emitter = new JsonEventEmitter({ mode: "stream-json", stdout })
+
+			emitter.emitControl({
+				subtype: "ack",
+				requestId: "req-1",
+				command: "start",
+				content: "starting task",
+				code: "accepted",
+				success: true,
+			})
+
+			const output = lines()
+			expect(output).toHaveLength(1)
+			expect(output[0]!).toMatchObject({
+				type: "control",
+				subtype: "ack",
+				requestId: "req-1",
+				command: "start",
+				content: "starting task",
+				code: "accepted",
+				success: true,
+			})
+			expect(output[0]!.done).toBeUndefined()
+		})
+
+		it("sets done: true for done events", () => {
+			const { stdout, lines } = createMockStdout()
+			const emitter = new JsonEventEmitter({ mode: "stream-json", stdout })
+
+			emitter.emitControl({
+				subtype: "done",
+				requestId: "req-2",
+				command: "start",
+				content: "task completed",
+				code: "task_completed",
+				success: true,
+			})
+
+			const output = lines()
+			expect(output[0]!).toMatchObject({ type: "control", subtype: "done", done: true })
+		})
+
+		it("does not set done for error events", () => {
+			const { stdout, lines } = createMockStdout()
+			const emitter = new JsonEventEmitter({ mode: "stream-json", stdout })
+
+			emitter.emitControl({
+				subtype: "error",
+				requestId: "req-3",
+				command: "start",
+				content: "something went wrong",
+				code: "task_error",
+				success: false,
+			})
+
+			const output = lines()
+			expect(output[0]!.done).toBeUndefined()
+			expect(output[0]!.success).toBe(false)
+		})
+	})
+
+	describe("requestIdProvider", () => {
+		it("injects requestId from provider when event has none", () => {
+			const { stdout, lines } = createMockStdout()
+			const emitter = new JsonEventEmitter({
+				mode: "stream-json",
+				stdout,
+				requestIdProvider: () => "injected-id",
+			})
+
+			emitter.emitControl({ subtype: "ack", content: "test" })
+
+			const output = lines()
+			expect(output[0]!.requestId).toBe("injected-id")
+		})
+
+		it("keeps explicit requestId when provider also returns one", () => {
+			const { stdout, lines } = createMockStdout()
+			const emitter = new JsonEventEmitter({
+				mode: "stream-json",
+				stdout,
+				requestIdProvider: () => "provider-id",
+			})
+
+			emitter.emitControl({ subtype: "ack", requestId: "explicit-id", content: "test" })
+
+			const output = lines()
+			expect(output[0]!.requestId).toBe("explicit-id")
+		})
+
+		it("omits requestId when provider returns undefined and event has none", () => {
+			const { stdout, lines } = createMockStdout()
+			const emitter = new JsonEventEmitter({
+				mode: "stream-json",
+				stdout,
+				requestIdProvider: () => undefined,
+			})
+
+			emitter.emitControl({ subtype: "ack", content: "test" })
+
+			const output = lines()
+			expect(output[0]!).not.toHaveProperty("requestId")
+		})
+	})
+
+	describe("emitInit", () => {
+		it("emits system init with default schema values", () => {
+			const { stdout, lines } = createMockStdout()
+			const emitter = new JsonEventEmitter({ mode: "stream-json", stdout })
+
+			// emitInit requires a client — we call emitControl to test init-like fields instead.
+			// emitInit is called internally by attach(), so we test the init fields via options.
+			// Instead, directly verify the constructor defaults by emitting a control event
+			// and checking that the emitter was created with correct defaults.
+
+			// We can't call emitInit without a client, but we can verify the options
+			// were stored correctly by checking what emitControl produces.
+			emitter.emitControl({ subtype: "ack", content: "test" })
+
+			// The control event itself doesn't include schema fields, but at least
+			// we verify the emitter was constructed successfully with defaults.
+			const output = lines()
+			expect(output).toHaveLength(1)
+		})
+
+		it("accepts custom schemaVersion, protocol, and capabilities", () => {
+			const { stdout } = createMockStdout()
+
+			// Should not throw when constructed with custom values
+			const emitter = new JsonEventEmitter({
+				mode: "stream-json",
+				stdout,
+				schemaVersion: 2,
+				protocol: "custom-protocol",
+				capabilities: ["stdin:start", "stdin:message"],
+			})
+
+			expect(emitter).toBeDefined()
+		})
+	})
+})

apps/cli/src/agent/__tests__/json-event-emitter-result.test.ts

@@ -0,0 +1,129 @@
+import type { ClineMessage } from "@roo-code/types"
+import { Writable } from "stream"
+
+import type { TaskCompletedEvent } from "../events.js"
+import { JsonEventEmitter } from "../json-event-emitter.js"
+import { AgentLoopState, type AgentStateInfo } from "../agent-state.js"
+
+function createMockStdout(): { stdout: NodeJS.WriteStream; lines: () => Record<string, unknown>[] } {
+	const chunks: string[] = []
+
+	const writable = new Writable({
+		write(chunk, _encoding, callback) {
+			chunks.push(chunk.toString())
+			callback()
+		},
+	}) as unknown as NodeJS.WriteStream
+
+	const lines = () =>
+		chunks
+			.join("")
+			.split("\n")
+			.filter((line) => line.length > 0)
+			.map((line) => JSON.parse(line) as Record<string, unknown>)
+
+	return { stdout: writable, lines }
+}
+
+function emitMessage(emitter: JsonEventEmitter, message: ClineMessage): void {
+	;(emitter as unknown as { handleMessage: (msg: ClineMessage, isUpdate: boolean) => void }).handleMessage(
+		message,
+		false,
+	)
+}
+
+function emitTaskCompleted(emitter: JsonEventEmitter, event: TaskCompletedEvent): void {
+	;(emitter as unknown as { handleTaskCompleted: (taskCompleted: TaskCompletedEvent) => void }).handleTaskCompleted(
+		event,
+	)
+}
+
+function createAskCompletionMessage(ts: number, text = ""): ClineMessage {
+	return {
+		ts,
+		type: "ask",
+		ask: "completion_result",
+		partial: false,
+		text,
+	} as ClineMessage
+}
+
+function createCompletedStateInfo(message: ClineMessage): AgentStateInfo {
+	return {
+		state: AgentLoopState.IDLE,
+		isWaitingForInput: true,
+		isRunning: false,
+		isStreaming: false,
+		currentAsk: "completion_result",
+		requiredAction: "start_task",
+		lastMessageTs: message.ts,
+		lastMessage: message,
+		description: "Task completed successfully. You can provide feedback or start a new task.",
+	}
+}
+
+describe("JsonEventEmitter result emission", () => {
+	it("prefers current completion message content over stale cached completion text", () => {
+		const { stdout, lines } = createMockStdout()
+		const emitter = new JsonEventEmitter({ mode: "stream-json", stdout })
+
+		emitMessage(emitter, {
+			ts: 100,
+			type: "say",
+			say: "completion_result",
+			partial: false,
+			text: "FIRST",
+		} as ClineMessage)
+
+		const firstCompletionMessage = createAskCompletionMessage(101, "")
+		emitTaskCompleted(emitter, {
+			success: true,
+			stateInfo: createCompletedStateInfo(firstCompletionMessage),
+			message: firstCompletionMessage,
+		})
+
+		const secondCompletionMessage = createAskCompletionMessage(102, "SECOND")
+		emitTaskCompleted(emitter, {
+			success: true,
+			stateInfo: createCompletedStateInfo(secondCompletionMessage),
+			message: secondCompletionMessage,
+		})
+
+		const output = lines().filter((line) => line.type === "result")
+		expect(output).toHaveLength(2)
+		expect(output[0]?.content).toBe("FIRST")
+		expect(output[1]?.content).toBe("SECOND")
+	})
+
+	it("clears cached completion text after each result emission", () => {
+		const { stdout, lines } = createMockStdout()
+		const emitter = new JsonEventEmitter({ mode: "stream-json", stdout })
+
+		emitMessage(emitter, {
+			ts: 200,
+			type: "say",
+			say: "completion_result",
+			partial: false,
+			text: "FIRST",
+		} as ClineMessage)
+
+		const firstCompletionMessage = createAskCompletionMessage(201, "")
+		emitTaskCompleted(emitter, {
+			success: true,
+			stateInfo: createCompletedStateInfo(firstCompletionMessage),
+			message: firstCompletionMessage,
+		})
+
+		const secondCompletionMessage = createAskCompletionMessage(202, "")
+		emitTaskCompleted(emitter, {
+			success: true,
+			stateInfo: createCompletedStateInfo(secondCompletionMessage),
+			message: secondCompletionMessage,
+		})
+
+		const output = lines().filter((line) => line.type === "result")
+		expect(output).toHaveLength(2)
+		expect(output[0]?.content).toBe("FIRST")
+		expect(output[1]).not.toHaveProperty("content")
+	})
+})

apps/cli/src/agent/__tests__/json-event-emitter-streaming.test.ts

@@ -0,0 +1,389 @@
+import type { ClineMessage } from "@roo-code/types"
+import { Writable } from "stream"
+
+import { JsonEventEmitter } from "../json-event-emitter.js"
+
+function createMockStdout(): { stdout: NodeJS.WriteStream; lines: () => Record<string, unknown>[] } {
+	const chunks: string[] = []
+
+	const writable = new Writable({
+		write(chunk, _encoding, callback) {
+			chunks.push(chunk.toString())
+			callback()
+		},
+	}) as unknown as NodeJS.WriteStream
+
+	const lines = () =>
+		chunks
+			.join("")
+			.split("\n")
+			.filter((line) => line.length > 0)
+			.map((line) => JSON.parse(line) as Record<string, unknown>)
+
+	return { stdout: writable, lines }
+}
+
+function emitMessage(emitter: JsonEventEmitter, message: ClineMessage): void {
+	;(emitter as unknown as { handleMessage: (msg: ClineMessage, isUpdate: boolean) => void }).handleMessage(
+		message,
+		false,
+	)
+}
+
+function createAskMessage(overrides: Partial<ClineMessage>): ClineMessage {
+	return {
+		ts: 1,
+		type: "ask",
+		ask: "tool",
+		partial: true,
+		text: "",
+		...overrides,
+	} as ClineMessage
+}
+
+describe("JsonEventEmitter streaming deltas", () => {
+	it("streams ask:command partial updates as deltas and emits full final snapshot", () => {
+		const { stdout, lines } = createMockStdout()
+		const emitter = new JsonEventEmitter({ mode: "stream-json", stdout })
+		const id = 101
+
+		emitMessage(
+			emitter,
+			createAskMessage({
+				ts: id,
+				ask: "command",
+				partial: true,
+				text: "g",
+			}),
+		)
+		emitMessage(
+			emitter,
+			createAskMessage({
+				ts: id,
+				ask: "command",
+				partial: true,
+				text: "gh",
+			}),
+		)
+		emitMessage(
+			emitter,
+			createAskMessage({
+				ts: id,
+				ask: "command",
+				partial: true,
+				text: "gh pr",
+			}),
+		)
+		emitMessage(
+			emitter,
+			createAskMessage({
+				ts: id,
+				ask: "command",
+				partial: false,
+				text: "gh pr",
+			}),
+		)
+
+		const output = lines()
+		expect(output).toHaveLength(4)
+		expect(output[0]).toMatchObject({
+			type: "tool_use",
+			id,
+			subtype: "command",
+			content: "g",
+			tool_use: { name: "execute_command", input: { command: "g" } },
+		})
+		expect(output[1]).toMatchObject({
+			type: "tool_use",
+			id,
+			subtype: "command",
+			content: "h",
+			tool_use: { name: "execute_command", input: { command: "h" } },
+		})
+		expect(output[2]).toMatchObject({
+			type: "tool_use",
+			id,
+			subtype: "command",
+			content: " pr",
+			tool_use: { name: "execute_command", input: { command: " pr" } },
+		})
+		expect(output[3]).toMatchObject({
+			type: "tool_use",
+			id,
+			subtype: "command",
+			tool_use: { name: "execute_command", input: { command: "gh pr" } },
+			done: true,
+		})
+		expect(output[3]).not.toHaveProperty("content")
+	})
+
+	it("streams ask:tool snapshots as structured deltas and preserves full final payload", () => {
+		const { stdout, lines } = createMockStdout()
+		const emitter = new JsonEventEmitter({ mode: "stream-json", stdout })
+		const id = 202
+		const first = JSON.stringify({ tool: "readFile", path: "a" })
+		const second = JSON.stringify({ tool: "readFile", path: "ab" })
+
+		emitMessage(
+			emitter,
+			createAskMessage({
+				ts: id,
+				ask: "tool",
+				partial: true,
+				text: first,
+			}),
+		)
+		emitMessage(
+			emitter,
+			createAskMessage({
+				ts: id,
+				ask: "tool",
+				partial: true,
+				text: second,
+			}),
+		)
+		emitMessage(
+			emitter,
+			createAskMessage({
+				ts: id,
+				ask: "tool",
+				partial: false,
+				text: second,
+			}),
+		)
+
+		const output = lines()
+		expect(output).toHaveLength(3)
+		expect(output[0]).toMatchObject({
+			type: "tool_use",
+			id,
+			subtype: "tool",
+			content: first,
+			tool_use: { name: "readFile" },
+		})
+		expect(output[1]).toMatchObject({
+			type: "tool_use",
+			id,
+			subtype: "tool",
+			content: "b",
+			tool_use: { name: "readFile" },
+		})
+		expect(output[2]).toMatchObject({
+			type: "tool_use",
+			id,
+			subtype: "tool",
+			tool_use: { name: "readFile", input: { tool: "readFile", path: "ab" } },
+			done: true,
+		})
+	})
+
+	it("suppresses duplicate partial tool snapshots with no delta", () => {
+		const { stdout, lines } = createMockStdout()
+		const emitter = new JsonEventEmitter({ mode: "stream-json", stdout })
+		const id = 303
+
+		emitMessage(
+			emitter,
+			createAskMessage({
+				ts: id,
+				ask: "command",
+				partial: true,
+				text: "gh",
+			}),
+		)
+		emitMessage(
+			emitter,
+			createAskMessage({
+				ts: id,
+				ask: "command",
+				partial: true,
+				text: "gh",
+			}),
+		)
+		emitMessage(
+			emitter,
+			createAskMessage({
+				ts: id,
+				ask: "command",
+				partial: true,
+				text: "gh pr",
+			}),
+		)
+
+		const output = lines()
+		expect(output).toHaveLength(2)
+		expect(output[0]).toMatchObject({ content: "gh" })
+		expect(output[1]).toMatchObject({ content: " pr" })
+	})
+
+	it("streams say:command_output as deltas and correlates tool_result id to execute_command", () => {
+		const { stdout, lines } = createMockStdout()
+		const emitter = new JsonEventEmitter({ mode: "stream-json", stdout })
+		const commandId = 404
+		const outputTs = 405
+
+		emitMessage(
+			emitter,
+			createAskMessage({
+				ts: commandId,
+				ask: "command",
+				partial: false,
+				text: "echo hello",
+			}),
+		)
+
+		emitMessage(emitter, {
+			ts: outputTs,
+			type: "say",
+			say: "command_output",
+			partial: true,
+			text: "line1\n",
+		} as ClineMessage)
+		emitMessage(emitter, {
+			ts: outputTs,
+			type: "say",
+			say: "command_output",
+			partial: true,
+			text: "line1\nline2\n",
+		} as ClineMessage)
+		emitMessage(emitter, {
+			ts: outputTs,
+			type: "say",
+			say: "command_output",
+			partial: false,
+			text: "line1\nline2\n",
+		} as ClineMessage)
+
+		const output = lines()
+		expect(output).toHaveLength(4)
+		expect(output[0]).toMatchObject({
+			type: "tool_use",
+			id: commandId,
+			subtype: "command",
+			tool_use: { name: "execute_command", input: { command: "echo hello" } },
+			done: true,
+		})
+		expect(output[1]).toMatchObject({
+			type: "tool_result",
+			id: commandId,
+			subtype: "command",
+			tool_result: { name: "execute_command", output: "line1\n" },
+		})
+		expect(output[2]).toMatchObject({
+			type: "tool_result",
+			id: commandId,
+			subtype: "command",
+			tool_result: { name: "execute_command", output: "line2\n" },
+		})
+		expect(output[3]).toMatchObject({
+			type: "tool_result",
+			id: commandId,
+			subtype: "command",
+			tool_result: { name: "execute_command" },
+			done: true,
+		})
+		expect(output[3]).not.toHaveProperty("tool_result.output")
+	})
+
+	it("prefers status-driven command output streaming and suppresses duplicate say completion", () => {
+		const { stdout, lines } = createMockStdout()
+		const emitter = new JsonEventEmitter({ mode: "stream-json", stdout })
+		const commandId = 505
+
+		emitMessage(
+			emitter,
+			createAskMessage({
+				ts: commandId,
+				ask: "command",
+				partial: false,
+				text: "echo streamed",
+			}),
+		)
+
+		emitter.emitCommandOutputChunk("line1\n")
+		emitter.emitCommandOutputChunk("line1\nline2\n")
+		emitter.markCommandOutputExited(17)
+
+		// This completion say is expected from the extension and should finalize
+		// the status-driven command_output stream without duplicating content.
+		emitMessage(emitter, {
+			ts: 999,
+			type: "say",
+			say: "command_output",
+			partial: false,
+			text: "line1\nline2\n",
+		} as ClineMessage)
+
+		const output = lines()
+		expect(output).toHaveLength(4)
+		expect(output[0]).toMatchObject({
+			type: "tool_use",
+			id: commandId,
+			subtype: "command",
+			tool_use: { name: "execute_command", input: { command: "echo streamed" } },
+			done: true,
+		})
+		expect(output[1]).toMatchObject({
+			type: "tool_result",
+			id: commandId,
+			subtype: "command",
+			tool_result: { name: "execute_command", output: "line1\n" },
+		})
+		expect(output[2]).toMatchObject({
+			type: "tool_result",
+			id: commandId,
+			subtype: "command",
+			tool_result: { name: "execute_command", output: "line2\n" },
+		})
+		expect(output[3]).toMatchObject({
+			type: "tool_result",
+			id: commandId,
+			subtype: "command",
+			tool_result: { name: "execute_command", exitCode: 17 },
+			done: true,
+		})
+	})
+
+	it("flushes remaining output on final say completion after fast status:exited", () => {
+		const { stdout, lines } = createMockStdout()
+		const emitter = new JsonEventEmitter({ mode: "stream-json", stdout })
+		const commandId = 606
+
+		emitMessage(
+			emitter,
+			createAskMessage({
+				ts: commandId,
+				ask: "command",
+				partial: false,
+				text: "aws sts get-caller-identity",
+			}),
+		)
+
+		emitter.emitCommandOutputChunk("{\n")
+		emitter.markCommandOutputExited(0)
+
+		emitMessage(emitter, {
+			ts: 607,
+			type: "say",
+			say: "command_output",
+			partial: false,
+			text: '{\n  "Account": "123"\n}\n',
+		} as ClineMessage)
+
+		const output = lines()
+		expect(output).toHaveLength(3)
+		expect(output[1]).toMatchObject({
+			type: "tool_result",
+			id: commandId,
+			subtype: "command",
+			tool_result: { name: "execute_command", output: "{\n" },
+		})
+		expect(output[2]).toMatchObject({
+			type: "tool_result",
+			id: commandId,
+			subtype: "command",
+			tool_result: { name: "execute_command", output: '  "Account": "123"\n}\n', exitCode: 0 },
+			done: true,
+		})
+	})
+})

apps/cli/src/agent/agent-state.ts

@@ -0,0 +1,463 @@
+/**
+ * Agent Loop State Detection
+ *
+ * This module provides the core logic for detecting the current state of the
+ * Roo Code agent loop. The state is determined by analyzing the clineMessages
+ * array, specifically the last message's type and properties.
+ *
+ * Key insight: The agent loop stops whenever a message with `type: "ask"` arrives,
+ * and the specific `ask` value determines what kind of response the agent is waiting for.
+ */
+
+import { ClineMessage, ClineAsk, isIdleAsk, isResumableAsk, isInteractiveAsk, isNonBlockingAsk } from "@roo-code/types"
+
+// =============================================================================
+// Agent Loop State Enum
+// =============================================================================
+
+/**
+ * The possible states of the agent loop.
+ *
+ * State Machine:
+ * ```
+ *                    ┌─────────────────┐
+ *                    │   NO_TASK       │ (initial state)
+ *                    └────────┬────────┘
+ *                             │ newTask
+ *                             ▼
+ *              ┌─────────────────────────────┐
+ *         ┌───▶│         RUNNING             │◀───┐
+ *         │    └──────────┬──────────────────┘    │
+ *         │               │                       │
+ *         │    ┌──────────┼──────────────┐        │
+ *         │    │          │              │        │
+ *         │    ▼          ▼              ▼        │
+ *         │ ┌──────┐  ┌─────────┐  ┌──────────┐   │
+ *         │ │STREAM│  │INTERACT │  │  IDLE    │   │
+ *         │ │ ING  │  │  IVE    │  │          │   │
+ *         │ └──┬───┘  └────┬────┘  └────┬─────┘   │
+ *         │    │           │            │         │
+ *         │    │ done      │ approved   │ newTask │
+ *         └────┴───────────┴────────────┘         │
+ *                                                 │
+ *         ┌──────────────┐                        │
+ *         │  RESUMABLE   │────────────────────────┘
+ *         └──────────────┘  resumed
+ * ```
+ */
+export enum AgentLoopState {
+	/**
+	 * No active task. This is the initial state before any task is started,
+	 * or after a task has been cleared.
+	 */
+	NO_TASK = "no_task",
+
+	/**
+	 * Agent is actively processing. This means:
+	 * - The last message is a "say" type (informational), OR
+	 * - The last message is a non-blocking ask (command_output)
+	 *
+	 * In this state, the agent may be:
+	 * - Executing tools
+	 * - Thinking/reasoning
+	 * - Processing between API calls
+	 */
+	RUNNING = "running",
+
+	/**
+	 * Agent is streaming a response. This is detected when:
+	 * - `partial === true` on the last message, OR
+	 * - The last `api_req_started` message has no `cost` in its text field
+	 *
+	 * Do NOT consider the agent "waiting" while streaming.
+	 */
+	STREAMING = "streaming",
+
+	/**
+	 * Agent is waiting for user approval or input. This includes:
+	 * - Tool approvals (file operations)
+	 * - Command execution permission
+	 * - Browser action permission
+	 * - MCP server permission
+	 * - Follow-up questions
+	 *
+	 * User must approve, reject, or provide input to continue.
+	 */
+	WAITING_FOR_INPUT = "waiting_for_input",
+
+	/**
+	 * Task is in an idle/terminal state. This includes:
+	 * - Task completed successfully (completion_result)
+	 * - API request failed (api_req_failed)
+	 * - Too many errors (mistake_limit_reached)
+	 * - Auto-approval limit reached
+	 * - Completed task waiting to be resumed
+	 *
+	 * User can start a new task or retry.
+	 */
+	IDLE = "idle",
+
+	/**
+	 * Task is paused and can be resumed. This happens when:
+	 * - User navigated away from a task
+	 * - Extension was restarted mid-task
+	 *
+	 * User can resume or abandon the task.
+	 */
+	RESUMABLE = "resumable",
+}
+
+// =============================================================================
+// Detailed State Info
+// =============================================================================
+
+/**
+ * What action the user should/can take in the current state.
+ */
+export type RequiredAction =
+	| "none" // No action needed (running/streaming)
+	| "approve" // Can approve/reject (tool, command, mcp)
+	| "answer" // Need to answer a question (followup)
+	| "retry_or_new_task" // Can retry or start new task (api_req_failed)
+	| "proceed_or_new_task" // Can proceed or start new task (mistake_limit)
+	| "start_task" // Should start a new task (completion_result)
+	| "resume_or_abandon" // Can resume or abandon (resume_task)
+	| "start_new_task" // Should start new task (resume_completed_task, no_task)
+	| "continue_or_abort" // Can continue or abort (command_output)
+
+/**
+ * Detailed information about the current agent state.
+ * Provides everything needed to render UI or make decisions.
+ */
+export interface AgentStateInfo {
+	/** The high-level state of the agent loop */
+	state: AgentLoopState
+
+	/** Whether the agent is waiting for user input/action */
+	isWaitingForInput: boolean
+
+	/** Whether the agent loop is actively processing */
+	isRunning: boolean
+
+	/** Whether content is being streamed */
+	isStreaming: boolean
+
+	/** The specific ask type if waiting on an ask, undefined otherwise */
+	currentAsk?: ClineAsk
+
+	/** What action the user should/can take */
+	requiredAction: RequiredAction
+
+	/** The timestamp of the last message, useful for tracking */
+	lastMessageTs?: number
+
+	/** The full last message for advanced usage */
+	lastMessage?: ClineMessage
+
+	/** Human-readable description of the current state */
+	description: string
+}
+
+// =============================================================================
+// State Detection Functions
+// =============================================================================
+
+/**
+ * Structure of the text field in api_req_started messages.
+ * Used to determine if the API request has completed (cost is defined).
+ */
+export interface ApiReqStartedText {
+	cost?: number // Undefined while streaming, defined when complete.
+	tokensIn?: number
+	tokensOut?: number
+	cacheWrites?: number
+	cacheReads?: number
+}
+
+/**
+ * Check if an API request is still in progress (streaming).
+ *
+ * API requests are considered in-progress when:
+ * - An api_req_started message exists
+ * - Its text field, when parsed, has `cost: undefined`
+ *
+ * Once the request completes, the cost field will be populated.
+ */
+function isApiRequestInProgress(messages: ClineMessage[]): boolean {
+	// Find the last api_req_started message.
+	// Using reverse iteration for efficiency (most recent first).
+	for (let i = messages.length - 1; i >= 0; i--) {
+		const message = messages[i]
+
+		if (!message) {
+			continue
+		}
+
+		if (message.say === "api_req_started") {
+			if (!message.text) {
+				// No text yet means still in progress.
+				return true
+			}
+
+			try {
+				const data: ApiReqStartedText = JSON.parse(message.text)
+				// cost is undefined while streaming, defined when complete.
+				return data.cost === undefined
+			} catch {
+				// Parse error - assume not in progress.
+				return false
+			}
+		}
+	}
+	return false
+}
+
+/**
+ * Determine the required action based on the current ask type.
+ */
+function getRequiredAction(ask: ClineAsk): RequiredAction {
+	switch (ask) {
+		case "followup":
+			return "answer"
+		case "command":
+		case "tool":
+		case "use_mcp_server":
+			return "approve"
+		case "command_output":
+			return "continue_or_abort"
+		case "api_req_failed":
+			return "retry_or_new_task"
+		case "mistake_limit_reached":
+			return "proceed_or_new_task"
+		case "completion_result":
+			return "start_task"
+		case "resume_task":
+			return "resume_or_abandon"
+		case "resume_completed_task":
+		case "auto_approval_max_req_reached":
+			return "start_new_task"
+		default:
+			return "none"
+	}
+}
+
+/**
+ * Get a human-readable description for the current state.
+ */
+function getStateDescription(state: AgentLoopState, ask?: ClineAsk): string {
+	switch (state) {
+		case AgentLoopState.NO_TASK:
+			return "No active task. Ready to start a new task."
+
+		case AgentLoopState.RUNNING:
+			return "Agent is actively processing."
+
+		case AgentLoopState.STREAMING:
+			return "Agent is streaming a response."
+
+		case AgentLoopState.WAITING_FOR_INPUT:
+			switch (ask) {
+				case "followup":
+					return "Agent is asking a follow-up question. Please provide an answer."
+				case "command":
+					return "Agent wants to execute a command. Approve or reject."
+				case "tool":
+					return "Agent wants to perform a file operation. Approve or reject."
+				case "use_mcp_server":
+					return "Agent wants to use an MCP server. Approve or reject."
+				default:
+					return "Agent is waiting for user input."
+			}
+
+		case AgentLoopState.IDLE:
+			switch (ask) {
+				case "completion_result":
+					return "Task completed successfully. You can provide feedback or start a new task."
+				case "api_req_failed":
+					return "API request failed. You can retry or start a new task."
+				case "mistake_limit_reached":
+					return "Too many errors encountered. You can proceed anyway or start a new task."
+				case "auto_approval_max_req_reached":
+					return "Auto-approval limit reached. Manual approval required."
+				case "resume_completed_task":
+					return "Previously completed task. Start a new task to continue."
+				default:
+					return "Task is idle."
+			}
+
+		case AgentLoopState.RESUMABLE:
+			return "Task is paused. You can resume or start a new task."
+
+		default:
+			return "Unknown state."
+	}
+}
+
+/**
+ * Detect the current state of the agent loop from the clineMessages array.
+ *
+ * This is the main state detection function. It analyzes the messages array
+ * and returns detailed information about the current agent state.
+ *
+ * @param messages - The clineMessages array from extension state
+ * @returns Detailed state information
+ */
+export function detectAgentState(messages: ClineMessage[]): AgentStateInfo {
+	// No messages means no task
+	if (!messages || messages.length === 0) {
+		return {
+			state: AgentLoopState.NO_TASK,
+			isWaitingForInput: false,
+			isRunning: false,
+			isStreaming: false,
+			requiredAction: "start_new_task",
+			description: getStateDescription(AgentLoopState.NO_TASK),
+		}
+	}
+
+	const lastMessage = messages[messages.length - 1]
+
+	// Guard against undefined (should never happen after length check, but TypeScript requires it)
+	if (!lastMessage) {
+		return {
+			state: AgentLoopState.NO_TASK,
+			isWaitingForInput: false,
+			isRunning: false,
+			isStreaming: false,
+			requiredAction: "start_new_task",
+			description: getStateDescription(AgentLoopState.NO_TASK),
+		}
+	}
+
+	// Check if the message is still streaming (partial)
+	// This is the PRIMARY indicator of streaming
+	if (lastMessage.partial === true) {
+		return {
+			state: AgentLoopState.STREAMING,
+			isWaitingForInput: false,
+			isRunning: true,
+			isStreaming: true,
+			currentAsk: lastMessage.ask,
+			requiredAction: "none",
+			lastMessageTs: lastMessage.ts,
+			lastMessage,
+			description: getStateDescription(AgentLoopState.STREAMING),
+		}
+	}
+
+	// Handle "ask" type messages
+	if (lastMessage.type === "ask" && lastMessage.ask) {
+		const ask = lastMessage.ask
+
+		// Non-blocking asks (command_output) - agent is running but can be interrupted
+		if (isNonBlockingAsk(ask)) {
+			return {
+				state: AgentLoopState.RUNNING,
+				isWaitingForInput: false,
+				isRunning: true,
+				isStreaming: false,
+				currentAsk: ask,
+				requiredAction: "continue_or_abort",
+				lastMessageTs: lastMessage.ts,
+				lastMessage,
+				description: "Command is running. You can continue or abort.",
+			}
+		}
+
+		// Idle asks - task has stopped
+		if (isIdleAsk(ask)) {
+			return {
+				state: AgentLoopState.IDLE,
+				isWaitingForInput: true, // User needs to decide what to do next
+				isRunning: false,
+				isStreaming: false,
+				currentAsk: ask,
+				requiredAction: getRequiredAction(ask),
+				lastMessageTs: lastMessage.ts,
+				lastMessage,
+				description: getStateDescription(AgentLoopState.IDLE, ask),
+			}
+		}
+
+		// Resumable asks - task is paused
+		if (isResumableAsk(ask)) {
+			return {
+				state: AgentLoopState.RESUMABLE,
+				isWaitingForInput: true,
+				isRunning: false,
+				isStreaming: false,
+				currentAsk: ask,
+				requiredAction: getRequiredAction(ask),
+				lastMessageTs: lastMessage.ts,
+				lastMessage,
+				description: getStateDescription(AgentLoopState.RESUMABLE, ask),
+			}
+		}
+
+		// Interactive asks - waiting for approval/input
+		if (isInteractiveAsk(ask)) {
+			return {
+				state: AgentLoopState.WAITING_FOR_INPUT,
+				isWaitingForInput: true,
+				isRunning: false,
+				isStreaming: false,
+				currentAsk: ask,
+				requiredAction: getRequiredAction(ask),
+				lastMessageTs: lastMessage.ts,
+				lastMessage,
+				description: getStateDescription(AgentLoopState.WAITING_FOR_INPUT, ask),
+			}
+		}
+	}
+
+	// For "say" type messages, check if API request is in progress
+	if (isApiRequestInProgress(messages)) {
+		return {
+			state: AgentLoopState.STREAMING,
+			isWaitingForInput: false,
+			isRunning: true,
+			isStreaming: true,
+			requiredAction: "none",
+			lastMessageTs: lastMessage.ts,
+			lastMessage,
+			description: getStateDescription(AgentLoopState.STREAMING),
+		}
+	}
+
+	// Default: agent is running
+	return {
+		state: AgentLoopState.RUNNING,
+		isWaitingForInput: false,
+		isRunning: true,
+		isStreaming: false,
+		requiredAction: "none",
+		lastMessageTs: lastMessage.ts,
+		lastMessage,
+		description: getStateDescription(AgentLoopState.RUNNING),
+	}
+}
+
+/**
+ * Quick check: Is the agent waiting for user input?
+ *
+ * This is a convenience function for simple use cases where you just need
+ * to know if user action is required.
+ */
+export function isAgentWaitingForInput(messages: ClineMessage[]): boolean {
+	return detectAgentState(messages).isWaitingForInput
+}
+
+/**
+ * Quick check: Is the agent actively running (not waiting)?
+ */
+export function isAgentRunning(messages: ClineMessage[]): boolean {
+	const state = detectAgentState(messages)
+	return state.isRunning && !state.isWaitingForInput
+}
+
+/**
+ * Quick check: Is content currently streaming?
+ */
+export function isContentStreaming(messages: ClineMessage[]): boolean {
+	return detectAgentState(messages).isStreaming
+}

apps/cli/src/agent/ask-dispatcher.ts

@@ -0,0 +1,664 @@
+/**
+ * AskDispatcher - Routes ask messages to appropriate handlers
+ *
+ * This dispatcher is responsible for:
+ * - Categorizing ask types using type guards from client module
+ * - Routing to the appropriate handler based on ask category
+ * - Coordinating between OutputManager and PromptManager
+ * - Tracking which asks have been handled (to avoid duplicates)
+ *
+ * Design notes:
+ * - Uses isIdleAsk, isInteractiveAsk, isResumableAsk, isNonBlockingAsk type guards
+ * - Single responsibility: Ask routing and handling only
+ * - Delegates output to OutputManager, input to PromptManager
+ * - Sends responses back through a provided callback
+ */
+
+import {
+	type WebviewMessage,
+	type ClineMessage,
+	type ClineAsk,
+	type ClineAskResponse,
+	isIdleAsk,
+	isInteractiveAsk,
+	isResumableAsk,
+	isNonBlockingAsk,
+} from "@roo-code/types"
+import { debugLog } from "@roo-code/core/cli"
+
+import { FOLLOWUP_TIMEOUT_SECONDS } from "@/types/index.js"
+
+import type { OutputManager } from "./output-manager.js"
+import type { PromptManager } from "./prompt-manager.js"
+
+// =============================================================================
+// Types
+// =============================================================================
+
+/**
+ * Configuration for AskDispatcher.
+ */
+export interface AskDispatcherOptions {
+	/**
+	 * OutputManager for displaying ask-related output.
+	 */
+	outputManager: OutputManager
+
+	/**
+	 * PromptManager for collecting user input.
+	 */
+	promptManager: PromptManager
+
+	/**
+	 * Callback to send responses to the extension.
+	 */
+	sendMessage: (message: WebviewMessage) => void
+
+	/**
+	 * Whether running in non-interactive mode (auto-approve).
+	 */
+	nonInteractive?: boolean
+
+	/**
+	 * Whether to exit on API request errors instead of retrying.
+	 */
+	exitOnError?: boolean
+
+	/**
+	 * Whether to disable ask handling (for TUI mode).
+	 * In TUI mode, the TUI handles asks directly.
+	 */
+	disabled?: boolean
+}
+
+/**
+ * Result of handling an ask.
+ */
+export interface AskHandleResult {
+	/** Whether the ask was handled */
+	handled: boolean
+	/** The response sent (if any) */
+	response?: ClineAskResponse
+	/** Any error that occurred */
+	error?: Error
+}
+
+// =============================================================================
+// AskDispatcher Class
+// =============================================================================
+
+export class AskDispatcher {
+	private outputManager: OutputManager
+	private promptManager: PromptManager
+	private sendMessage: (message: WebviewMessage) => void
+	private nonInteractive: boolean
+	private exitOnError: boolean
+	private disabled: boolean
+
+	/**
+	 * Track which asks have been handled to avoid duplicates.
+	 * Key: message ts
+	 */
+	private handledAsks = new Set<number>()
+
+	constructor(options: AskDispatcherOptions) {
+		this.outputManager = options.outputManager
+		this.promptManager = options.promptManager
+		this.sendMessage = options.sendMessage
+		this.nonInteractive = options.nonInteractive ?? false
+		this.exitOnError = options.exitOnError ?? false
+		this.disabled = options.disabled ?? false
+	}
+
+	// ===========================================================================
+	// Public API
+	// ===========================================================================
+
+	/**
+	 * Handle an ask message.
+	 * Routes to the appropriate handler based on ask type.
+	 *
+	 * @param message - The ClineMessage with type="ask"
+	 * @returns Promise<AskHandleResult>
+	 */
+	async handleAsk(message: ClineMessage): Promise<AskHandleResult> {
+		// Disabled in TUI mode - TUI handles asks directly
+		if (this.disabled) {
+			return { handled: false }
+		}
+
+		const ts = message.ts
+		const ask = message.ask
+		const text = message.text || ""
+
+		// Check if already handled
+		if (this.handledAsks.has(ts)) {
+			return { handled: true }
+		}
+
+		// Must be an ask message
+		if (message.type !== "ask" || !ask) {
+			return { handled: false }
+		}
+
+		// Skip partial messages (wait for complete)
+		if (message.partial) {
+			return { handled: false }
+		}
+
+		// Mark as being handled
+		this.handledAsks.add(ts)
+
+		try {
+			// Route based on ask category
+			if (isNonBlockingAsk(ask)) {
+				return await this.handleNonBlockingAsk(ts, ask, text)
+			}
+
+			if (isIdleAsk(ask)) {
+				return await this.handleIdleAsk(ts, ask, text)
+			}
+
+			if (isResumableAsk(ask)) {
+				return await this.handleResumableAsk(ts, ask, text)
+			}
+
+			if (isInteractiveAsk(ask)) {
+				return await this.handleInteractiveAsk(ts, ask, text)
+			}
+
+			// Unknown ask type - log and handle generically
+			debugLog("[AskDispatcher] Unknown ask type", { ask, ts })
+			return await this.handleUnknownAsk(ts, ask, text)
+		} catch (error) {
+			// Re-allow handling on error
+			this.handledAsks.delete(ts)
+			return {
+				handled: false,
+				error: error instanceof Error ? error : new Error(String(error)),
+			}
+		}
+	}
+
+	/**
+	 * Check if an ask has been handled.
+	 */
+	isHandled(ts: number): boolean {
+		return this.handledAsks.has(ts)
+	}
+
+	/**
+	 * Clear handled asks (call when starting new task).
+	 */
+	clear(): void {
+		this.handledAsks.clear()
+	}
+
+	// ===========================================================================
+	// Category Handlers
+	// ===========================================================================
+
+	/**
+	 * Handle non-blocking asks (command_output).
+	 * These don't actually block the agent - just need acknowledgment.
+	 */
+	private async handleNonBlockingAsk(_ts: number, _ask: ClineAsk, _text: string): Promise<AskHandleResult> {
+		// command_output - output is handled by OutputManager
+		// Just send approval to continue
+		this.sendApprovalResponse(true)
+		return { handled: true, response: "yesButtonClicked" }
+	}
+
+	/**
+	 * Handle idle asks (completion_result, api_req_failed, etc.).
+	 * These indicate the task has stopped.
+	 */
+	private async handleIdleAsk(ts: number, ask: ClineAsk, text: string): Promise<AskHandleResult> {
+		switch (ask) {
+			case "completion_result":
+				// Task complete - nothing to do here, TaskCompleted event handles it
+				return { handled: true }
+
+			case "api_req_failed":
+				return await this.handleApiFailedRetry(ts, text)
+
+			case "mistake_limit_reached":
+				return await this.handleMistakeLimitReached(ts, text)
+
+			case "resume_completed_task":
+				return await this.handleResumeTask(ts, ask, text)
+
+			case "auto_approval_max_req_reached":
+				return await this.handleAutoApprovalMaxReached(ts, text)
+
+			default:
+				return { handled: false }
+		}
+	}
+
+	/**
+	 * Handle resumable asks (resume_task).
+	 */
+	private async handleResumableAsk(ts: number, ask: ClineAsk, text: string): Promise<AskHandleResult> {
+		return await this.handleResumeTask(ts, ask, text)
+	}
+
+	/**
+	 * Handle interactive asks (followup, command, tool, use_mcp_server).
+	 * These require user approval or input.
+	 */
+	private async handleInteractiveAsk(ts: number, ask: ClineAsk, text: string): Promise<AskHandleResult> {
+		switch (ask) {
+			case "followup":
+				return await this.handleFollowupQuestion(ts, text)
+
+			case "command":
+				return await this.handleCommandApproval(ts, text)
+
+			case "tool":
+				return await this.handleToolApproval(ts, text)
+
+			case "use_mcp_server":
+				return await this.handleMcpApproval(ts, text)
+
+			default:
+				return { handled: false }
+		}
+	}
+
+	/**
+	 * Handle unknown ask types.
+	 */
+	private async handleUnknownAsk(ts: number, ask: ClineAsk, text: string): Promise<AskHandleResult> {
+		if (this.nonInteractive) {
+			if (text) {
+				this.outputManager.output(`\n[${ask}]`, text)
+			}
+			return { handled: true }
+		}
+
+		return await this.handleGenericApproval(ts, ask, text)
+	}
+
+	// ===========================================================================
+	// Specific Ask Handlers
+	// ===========================================================================
+
+	/**
+	 * Handle followup questions - prompt for text input with suggestions.
+	 */
+	private async handleFollowupQuestion(ts: number, text: string): Promise<AskHandleResult> {
+		let question = text
+		let suggestions: Array<{ answer: string; mode?: string | null }> = []
+
+		try {
+			const data = JSON.parse(text)
+			question = data.question || text
+			suggestions = Array.isArray(data.suggest) ? data.suggest : []
+		} catch {
+			// Use raw text if not JSON
+		}
+
+		this.outputManager.output("\n[question]", question)
+
+		if (suggestions.length > 0) {
+			this.outputManager.output("\nSuggested answers:")
+			suggestions.forEach((suggestion, index) => {
+				const suggestionText = suggestion.answer || String(suggestion)
+				const modeHint = suggestion.mode ? ` (mode: ${suggestion.mode})` : ""
+				this.outputManager.output(`  ${index + 1}. ${suggestionText}${modeHint}`)
+			})
+			this.outputManager.output("")
+		}
+
+		const firstSuggestion = suggestions.length > 0 ? suggestions[0] : null
+		const defaultAnswer = firstSuggestion?.answer ?? ""
+
+		if (this.nonInteractive) {
+			// Use timeout prompt in non-interactive mode
+			const timeoutMs = FOLLOWUP_TIMEOUT_SECONDS * 1000
+			const result = await this.promptManager.promptWithTimeout(
+				suggestions.length > 0
+					? `Enter number (1-${suggestions.length}) or type your answer (auto-select in ${Math.round(timeoutMs / 1000)}s): `
+					: `Your answer (auto-select in ${Math.round(timeoutMs / 1000)}s): `,
+				timeoutMs,
+				defaultAnswer,
+			)
+
+			let responseText = result.value.trim()
+			responseText = this.resolveNumberedSuggestion(responseText, suggestions)
+
+			if (result.timedOut || result.cancelled) {
+				this.outputManager.output(`[Using default: ${defaultAnswer || "(empty)"}]`)
+			}
+
+			this.sendFollowupResponse(responseText)
+			return { handled: true, response: "messageResponse" }
+		}
+
+		// Interactive mode
+		try {
+			const answer = await this.promptManager.promptForInput(
+				suggestions.length > 0
+					? `Enter number (1-${suggestions.length}) or type your answer: `
+					: "Your answer: ",
+			)
+
+			let responseText = answer.trim()
+			responseText = this.resolveNumberedSuggestion(responseText, suggestions)
+
+			this.sendFollowupResponse(responseText)
+			return { handled: true, response: "messageResponse" }
+		} catch {
+			this.outputManager.output(`[Using default: ${defaultAnswer || "(empty)"}]`)
+			this.sendFollowupResponse(defaultAnswer)
+			return { handled: true, response: "messageResponse" }
+		}
+	}
+
+	/**
+	 * Handle command execution approval.
+	 */
+	private async handleCommandApproval(ts: number, text: string): Promise<AskHandleResult> {
+		this.outputManager.output("\n[command request]")
+		this.outputManager.output(`  Command: ${text || "(no command specified)"}`)
+		this.outputManager.markDisplayed(ts, text || "", false)
+
+		if (this.nonInteractive) {
+			// Auto-approved by extension settings
+			return { handled: true }
+		}
+
+		try {
+			const approved = await this.promptManager.promptForYesNo("Execute this command? (y/n): ")
+			this.sendApprovalResponse(approved)
+			return { handled: true, response: approved ? "yesButtonClicked" : "noButtonClicked" }
+		} catch {
+			this.outputManager.output("[Defaulting to: no]")
+			this.sendApprovalResponse(false)
+			return { handled: true, response: "noButtonClicked" }
+		}
+	}
+
+	/**
+	 * Handle tool execution approval.
+	 */
+	private async handleToolApproval(ts: number, text: string): Promise<AskHandleResult> {
+		let toolName = "unknown"
+		let toolInfo: Record<string, unknown> = {}
+
+		try {
+			toolInfo = JSON.parse(text) as Record<string, unknown>
+			toolName = (toolInfo.tool as string) || "unknown"
+		} catch {
+			// Use raw text if not JSON
+		}
+
+		const isProtected = toolInfo.isProtected === true
+
+		if (isProtected) {
+			this.outputManager.output(`\n[Tool Request] ${toolName} [PROTECTED CONFIGURATION FILE]`)
+			this.outputManager.output(`⚠️  WARNING: This tool wants to modify a protected configuration file.`)
+			this.outputManager.output(
+				`    Protected files include .rooignore, .roo/*, and other sensitive config files.`,
+			)
+		} else {
+			this.outputManager.output(`\n[Tool Request] ${toolName}`)
+		}
+
+		// Display tool details
+		for (const [key, value] of Object.entries(toolInfo)) {
+			if (key === "tool" || key === "isProtected") continue
+
+			let displayValue: string
+			if (typeof value === "string") {
+				displayValue = value.length > 200 ? value.substring(0, 200) + "..." : value
+			} else if (typeof value === "object" && value !== null) {
+				const json = JSON.stringify(value)
+				displayValue = json.length > 200 ? json.substring(0, 200) + "..." : json
+			} else {
+				displayValue = String(value)
+			}
+
+			this.outputManager.output(`  ${key}: ${displayValue}`)
+		}
+
+		this.outputManager.markDisplayed(ts, text || "", false)
+
+		if (this.nonInteractive) {
+			// Auto-approved by extension settings (unless protected)
+			return { handled: true }
+		}
+
+		try {
+			const approved = await this.promptManager.promptForYesNo("Approve this action? (y/n): ")
+			this.sendApprovalResponse(approved)
+			return { handled: true, response: approved ? "yesButtonClicked" : "noButtonClicked" }
+		} catch {
+			this.outputManager.output("[Defaulting to: no]")
+			this.sendApprovalResponse(false)
+			return { handled: true, response: "noButtonClicked" }
+		}
+	}
+
+	/**
+	 * Handle MCP server access approval.
+	 */
+	private async handleMcpApproval(ts: number, text: string): Promise<AskHandleResult> {
+		let serverName = "unknown"
+		let toolName = ""
+		let resourceUri = ""
+
+		try {
+			const mcpInfo = JSON.parse(text)
+			serverName = mcpInfo.server_name || "unknown"
+
+			if (mcpInfo.type === "use_mcp_tool") {
+				toolName = mcpInfo.tool_name || ""
+			} else if (mcpInfo.type === "access_mcp_resource") {
+				resourceUri = mcpInfo.uri || ""
+			}
+		} catch {
+			// Use raw text if not JSON
+		}
+
+		this.outputManager.output("\n[mcp request]")
+		this.outputManager.output(`  Server: ${serverName}`)
+		if (toolName) {
+			this.outputManager.output(`  Tool: ${toolName}`)
+		}
+		if (resourceUri) {
+			this.outputManager.output(`  Resource: ${resourceUri}`)
+		}
+		this.outputManager.markDisplayed(ts, text || "", false)
+
+		if (this.nonInteractive) {
+			// Auto-approved by extension settings
+			return { handled: true }
+		}
+
+		try {
+			const approved = await this.promptManager.promptForYesNo("Allow MCP access? (y/n): ")
+			this.sendApprovalResponse(approved)
+			return { handled: true, response: approved ? "yesButtonClicked" : "noButtonClicked" }
+		} catch {
+			this.outputManager.output("[Defaulting to: no]")
+			this.sendApprovalResponse(false)
+			return { handled: true, response: "noButtonClicked" }
+		}
+	}
+
+	/**
+	 * Handle API request failed - retry prompt.
+	 */
+	private async handleApiFailedRetry(ts: number, text: string): Promise<AskHandleResult> {
+		this.outputManager.output("\n[api request failed]")
+		this.outputManager.output(`  Error: ${text || "Unknown error"}`)
+		this.outputManager.markDisplayed(ts, text || "", false)
+
+		if (this.exitOnError) {
+			console.error(`[CLI] API request failed: ${text || "Unknown error"}`)
+			process.exit(1)
+		}
+
+		if (this.nonInteractive) {
+			this.outputManager.output("\n[retrying api request]")
+			// Auto-retry in non-interactive mode
+			return { handled: true }
+		}
+
+		try {
+			const retry = await this.promptManager.promptForYesNo("Retry the request? (y/n): ")
+			this.sendApprovalResponse(retry)
+			return { handled: true, response: retry ? "yesButtonClicked" : "noButtonClicked" }
+		} catch {
+			this.outputManager.output("[Defaulting to: no]")
+			this.sendApprovalResponse(false)
+			return { handled: true, response: "noButtonClicked" }
+		}
+	}
+
+	/**
+	 * Handle mistake limit reached.
+	 */
+	private async handleMistakeLimitReached(ts: number, text: string): Promise<AskHandleResult> {
+		this.outputManager.output("\n[mistake limit reached]")
+		if (text) {
+			this.outputManager.output(`  Details: ${text}`)
+		}
+		this.outputManager.markDisplayed(ts, text || "", false)
+
+		if (this.nonInteractive) {
+			// Auto-proceed in non-interactive mode
+			this.sendApprovalResponse(true)
+			return { handled: true, response: "yesButtonClicked" }
+		}
+
+		try {
+			const proceed = await this.promptManager.promptForYesNo("Continue anyway? (y/n): ")
+			this.sendApprovalResponse(proceed)
+			return { handled: true, response: proceed ? "yesButtonClicked" : "noButtonClicked" }
+		} catch {
+			this.outputManager.output("[Defaulting to: no]")
+			this.sendApprovalResponse(false)
+			return { handled: true, response: "noButtonClicked" }
+		}
+	}
+
+	/**
+	 * Handle auto-approval max reached.
+	 */
+	private async handleAutoApprovalMaxReached(ts: number, text: string): Promise<AskHandleResult> {
+		this.outputManager.output("\n[auto-approval limit reached]")
+		if (text) {
+			this.outputManager.output(`  Details: ${text}`)
+		}
+		this.outputManager.markDisplayed(ts, text || "", false)
+
+		if (this.nonInteractive) {
+			// Auto-proceed in non-interactive mode
+			this.sendApprovalResponse(true)
+			return { handled: true, response: "yesButtonClicked" }
+		}
+
+		try {
+			const proceed = await this.promptManager.promptForYesNo("Continue with manual approval? (y/n): ")
+			this.sendApprovalResponse(proceed)
+			return { handled: true, response: proceed ? "yesButtonClicked" : "noButtonClicked" }
+		} catch {
+			this.outputManager.output("[Defaulting to: no]")
+			this.sendApprovalResponse(false)
+			return { handled: true, response: "noButtonClicked" }
+		}
+	}
+
+	/**
+	 * Handle task resume prompt.
+	 */
+	private async handleResumeTask(ts: number, ask: ClineAsk, text: string): Promise<AskHandleResult> {
+		const isCompleted = ask === "resume_completed_task"
+		this.outputManager.output(`\n[Resume ${isCompleted ? "Completed " : ""}Task]`)
+		if (text) {
+			this.outputManager.output(`  ${text}`)
+		}
+		this.outputManager.markDisplayed(ts, text || "", false)
+
+		if (this.nonInteractive) {
+			this.outputManager.output("\n[continuing task]")
+			// Auto-resume in non-interactive mode
+			this.sendApprovalResponse(true)
+			return { handled: true, response: "yesButtonClicked" }
+		}
+
+		try {
+			const resume = await this.promptManager.promptForYesNo("Continue with this task? (y/n): ")
+			this.sendApprovalResponse(resume)
+			return { handled: true, response: resume ? "yesButtonClicked" : "noButtonClicked" }
+		} catch {
+			this.outputManager.output("[Defaulting to: no]")
+			this.sendApprovalResponse(false)
+			return { handled: true, response: "noButtonClicked" }
+		}
+	}
+
+	/**
+	 * Handle generic approval prompts for unknown ask types.
+	 */
+	private async handleGenericApproval(ts: number, ask: ClineAsk, text: string): Promise<AskHandleResult> {
+		this.outputManager.output(`\n[${ask}]`)
+		if (text) {
+			this.outputManager.output(`  ${text}`)
+		}
+		this.outputManager.markDisplayed(ts, text || "", false)
+
+		try {
+			const approved = await this.promptManager.promptForYesNo("Approve? (y/n): ")
+			this.sendApprovalResponse(approved)
+			return { handled: true, response: approved ? "yesButtonClicked" : "noButtonClicked" }
+		} catch {
+			this.outputManager.output("[Defaulting to: no]")
+			this.sendApprovalResponse(false)
+			return { handled: true, response: "noButtonClicked" }
+		}
+	}
+
+	// ===========================================================================
+	// Response Helpers
+	// ===========================================================================
+
+	/**
+	 * Send a followup response (text answer) to the extension.
+	 */
+	private sendFollowupResponse(text: string): void {
+		this.sendMessage({ type: "askResponse", askResponse: "messageResponse", text })
+	}
+
+	/**
+	 * Send an approval response (yes/no) to the extension.
+	 */
+	private sendApprovalResponse(approved: boolean): void {
+		this.sendMessage({
+			type: "askResponse",
+			askResponse: approved ? "yesButtonClicked" : "noButtonClicked",
+		})
+	}
+
+	/**
+	 * Resolve a numbered suggestion selection.
+	 */
+	private resolveNumberedSuggestion(
+		input: string,
+		suggestions: Array<{ answer: string; mode?: string | null }>,
+	): string {
+		const num = parseInt(input, 10)
+		if (!isNaN(num) && num >= 1 && num <= suggestions.length) {
+			const selectedSuggestion = suggestions[num - 1]
+			if (selectedSuggestion) {
+				const selected = selectedSuggestion.answer || String(selectedSuggestion)
+				this.outputManager.output(`Selected: ${selected}`)
+				return selected
+			}
+		}
+		return input
+	}
+}

apps/cli/src/agent/events.ts

@@ -0,0 +1,372 @@
+/**
+ * Event System for Agent State Changes
+ *
+ * This module provides a strongly-typed event emitter specifically designed
+ * for tracking agent state changes. It uses Node.js EventEmitter under the hood
+ * but provides type safety for all events.
+ */
+
+import { EventEmitter } from "events"
+
+import { ClineMessage, ClineAsk } from "@roo-code/types"
+
+import type { AgentStateInfo } from "./agent-state.js"
+
+// =============================================================================
+// Event Types
+// =============================================================================
+
+/**
+ * All events that can be emitted by the client.
+ *
+ * Design note: We use a string literal union type for event names to ensure
+ * type safety when subscribing to events. The payload type is determined by
+ * the event name.
+ */
+export interface ClientEventMap {
+	/**
+	 * Emitted whenever the agent state changes.
+	 * This is the primary event for tracking state.
+	 */
+	stateChange: AgentStateChangeEvent
+
+	/**
+	 * Emitted when a new message is added to the message list.
+	 */
+	message: ClineMessage
+
+	/**
+	 * Emitted when an existing message is updated (e.g., partial -> complete).
+	 */
+	messageUpdated: ClineMessage
+
+	/**
+	 * Emitted when the agent starts waiting for user input.
+	 * Convenience event - you can also use stateChange.
+	 */
+	waitingForInput: WaitingForInputEvent
+
+	/**
+	 * Emitted when the agent stops waiting and resumes running.
+	 */
+	resumedRunning: void
+
+	/**
+	 * Emitted when the agent starts streaming content.
+	 */
+	streamingStarted: void
+
+	/**
+	 * Emitted when streaming ends.
+	 */
+	streamingEnded: void
+
+	/**
+	 * Emitted when a task completes (either successfully or with error).
+	 */
+	taskCompleted: TaskCompletedEvent
+
+	/**
+	 * Emitted when a task is cleared/cancelled.
+	 */
+	taskCleared: void
+
+	/**
+	 * Emitted when the current mode changes.
+	 */
+	modeChanged: ModeChangedEvent
+
+	/**
+	 * Emitted on any error during message processing.
+	 */
+	error: Error
+}
+
+/**
+ * Event payload for state changes.
+ */
+export interface AgentStateChangeEvent {
+	/** The previous state info */
+	previousState: AgentStateInfo
+	/** The new/current state info */
+	currentState: AgentStateInfo
+	/** Whether this is a significant state transition (state enum changed) */
+	isSignificantChange: boolean
+}
+
+/**
+ * Event payload when agent starts waiting for input.
+ */
+export interface WaitingForInputEvent {
+	/** The specific ask type */
+	ask: ClineAsk
+	/** Full state info for context */
+	stateInfo: AgentStateInfo
+	/** The message that triggered this wait */
+	message: ClineMessage
+}
+
+/**
+ * Event payload when a task completes.
+ */
+export interface TaskCompletedEvent {
+	/** Whether the task completed successfully */
+	success: boolean
+	/** The final state info */
+	stateInfo: AgentStateInfo
+	/** The completion message if available */
+	message?: ClineMessage
+}
+
+/**
+ * Event payload when mode changes.
+ */
+export interface ModeChangedEvent {
+	/** The previous mode (undefined if first mode set) */
+	previousMode: string | undefined
+	/** The new/current mode */
+	currentMode: string
+}
+
+// =============================================================================
+// Typed Event Emitter
+// =============================================================================
+
+/**
+ * Type-safe event emitter for client events.
+ *
+ * Usage:
+ * ```typescript
+ * const emitter = new TypedEventEmitter()
+ *
+ * // Type-safe subscription
+ * emitter.on('stateChange', (event) => {
+ *   console.log(event.currentState) // TypeScript knows this is AgentStateChangeEvent
+ * })
+ *
+ * // Type-safe emission
+ * emitter.emit('stateChange', { previousState, currentState, isSignificantChange })
+ * ```
+ */
+export class TypedEventEmitter {
+	private emitter = new EventEmitter()
+
+	/**
+	 * Subscribe to an event.
+	 *
+	 * @param event - The event name
+	 * @param listener - The callback function
+	 * @returns Function to unsubscribe
+	 */
+	on<K extends keyof ClientEventMap>(event: K, listener: (payload: ClientEventMap[K]) => void): () => void {
+		this.emitter.on(event, listener)
+		return () => this.emitter.off(event, listener)
+	}
+
+	/**
+	 * Subscribe to an event, but only once.
+	 *
+	 * @param event - The event name
+	 * @param listener - The callback function
+	 */
+	once<K extends keyof ClientEventMap>(event: K, listener: (payload: ClientEventMap[K]) => void): void {
+		this.emitter.once(event, listener)
+	}
+
+	/**
+	 * Unsubscribe from an event.
+	 *
+	 * @param event - The event name
+	 * @param listener - The callback function to remove
+	 */
+	off<K extends keyof ClientEventMap>(event: K, listener: (payload: ClientEventMap[K]) => void): void {
+		this.emitter.off(event, listener)
+	}
+
+	/**
+	 * Emit an event.
+	 *
+	 * @param event - The event name
+	 * @param payload - The event payload
+	 */
+	emit<K extends keyof ClientEventMap>(event: K, payload: ClientEventMap[K]): void {
+		this.emitter.emit(event, payload)
+	}
+
+	/**
+	 * Remove all listeners for an event, or all events.
+	 *
+	 * @param event - Optional event name. If not provided, removes all listeners.
+	 */
+	removeAllListeners<K extends keyof ClientEventMap>(event?: K): void {
+		if (event) {
+			this.emitter.removeAllListeners(event)
+		} else {
+			this.emitter.removeAllListeners()
+		}
+	}
+
+	/**
+	 * Get the number of listeners for an event.
+	 */
+	listenerCount<K extends keyof ClientEventMap>(event: K): number {
+		return this.emitter.listenerCount(event)
+	}
+}
+
+// =============================================================================
+// State Change Detector
+// =============================================================================
+
+/**
+ * Helper to determine if a state change is "significant".
+ *
+ * A significant change is when the AgentLoopState enum value changes,
+ * as opposed to just internal state updates within the same state.
+ */
+export function isSignificantStateChange(previous: AgentStateInfo, current: AgentStateInfo): boolean {
+	return previous.state !== current.state
+}
+
+/**
+ * Helper to determine if we transitioned to waiting for input.
+ */
+export function transitionedToWaiting(previous: AgentStateInfo, current: AgentStateInfo): boolean {
+	return !previous.isWaitingForInput && current.isWaitingForInput
+}
+
+/**
+ * Helper to determine if we transitioned from waiting to running.
+ */
+export function transitionedToRunning(previous: AgentStateInfo, current: AgentStateInfo): boolean {
+	return previous.isWaitingForInput && !current.isWaitingForInput && current.isRunning
+}
+
+/**
+ * Helper to determine if streaming started.
+ */
+export function streamingStarted(previous: AgentStateInfo, current: AgentStateInfo): boolean {
+	return !previous.isStreaming && current.isStreaming
+}
+
+/**
+ * Helper to determine if streaming ended.
+ */
+export function streamingEnded(previous: AgentStateInfo, current: AgentStateInfo): boolean {
+	return previous.isStreaming && !current.isStreaming
+}
+
+/**
+ * Helper to determine if task completed.
+ */
+export function taskCompleted(previous: AgentStateInfo, current: AgentStateInfo): boolean {
+	const completionAsks = ["completion_result", "resume_completed_task"]
+	const wasNotComplete = !previous.currentAsk || !completionAsks.includes(previous.currentAsk)
+	const isNowComplete = current.currentAsk !== undefined && completionAsks.includes(current.currentAsk)
+	return wasNotComplete && isNowComplete
+}
+
+// =============================================================================
+// Observable Pattern (Alternative API)
+// =============================================================================
+
+/**
+ * Subscription function type for observable pattern.
+ */
+export type Observer<T> = (value: T) => void
+
+/**
+ * Unsubscribe function type.
+ */
+export type Unsubscribe = () => void
+
+/**
+ * Simple observable for state.
+ *
+ * This provides an alternative to the event emitter pattern
+ * for those who prefer a more functional approach.
+ *
+ * Usage:
+ * ```typescript
+ * const stateObservable = new Observable<AgentStateInfo>()
+ *
+ * const unsubscribe = stateObservable.subscribe((state) => {
+ *   console.log('New state:', state)
+ * })
+ *
+ * // Later...
+ * unsubscribe()
+ * ```
+ */
+export class Observable<T> {
+	private observers: Set<Observer<T>> = new Set()
+	private currentValue: T | undefined
+
+	/**
+	 * Create an observable with an optional initial value.
+	 */
+	constructor(initialValue?: T) {
+		this.currentValue = initialValue
+	}
+
+	/**
+	 * Subscribe to value changes.
+	 *
+	 * @param observer - Function called when value changes
+	 * @returns Unsubscribe function
+	 */
+	subscribe(observer: Observer<T>): Unsubscribe {
+		this.observers.add(observer)
+
+		// Immediately emit current value if we have one
+		if (this.currentValue !== undefined) {
+			observer(this.currentValue)
+		}
+
+		return () => {
+			this.observers.delete(observer)
+		}
+	}
+
+	/**
+	 * Update the value and notify all subscribers.
+	 */
+	next(value: T): void {
+		this.currentValue = value
+		for (const observer of this.observers) {
+			try {
+				observer(value)
+			} catch (error) {
+				console.error("Error in observer:", error)
+			}
+		}
+	}
+
+	/**
+	 * Get the current value without subscribing.
+	 */
+	getValue(): T | undefined {
+		return this.currentValue
+	}
+
+	/**
+	 * Check if there are any subscribers.
+	 */
+	hasSubscribers(): boolean {
+		return this.observers.size > 0
+	}
+
+	/**
+	 * Get the number of subscribers.
+	 */
+	getSubscriberCount(): number {
+		return this.observers.size
+	}
+
+	/**
+	 * Remove all subscribers.
+	 */
+	clear(): void {
+		this.observers.clear()
+	}
+}