diff --git a/.changeset/auto-20260217.md b/.changeset/auto-20260217.md new file mode 100644 index 00000000000..5750df49d66 --- /dev/null +++ b/.changeset/auto-20260217.md @@ -0,0 +1,50 @@ +--- +"klaus-code": minor +--- + +### ✨ Features + +- feat: enable E2E tests with CI infrastructure +- Reapply Batch 1: 22 clean non-AI-SDK cherry-picks (#11473) +- feat: extract translation and merge resolver modes into reusable skills (#11215) +- feat: add GLM-5 model support to Z.ai provider (#11440) +- feat: implement ModelMessage storage layer with AI SDK response messages (#11409) +- feat: wire RooMessage storage into Task.ts and all providers (#11386) +- feat: rename search_and_replace tool to edit and unify edit-family UI (#11296) +- feat: RooMessage type system and storage layer for ModelMessage migration (#11380) + +### 🐛 Bug Fixes + +- fix: E2E test configuration for Klaus Code +- fix: restore Claude Code settings UI with rate limit dashboard +- fix: add Claude Code to UI provider dropdown and configuration +- fix: update tests and claude-code provider after upstream merge +- fix: add claude-code to provider type assertion and remove orphaned test +- fix: restore Claude Code OAuth types and remove Azure/dead code +- Add back post-revert bug fixes and features (Step 2) (#11463) +- fix: restore @hannesrudolph and @daniel-lxs as default code owners (#11469) +- fix: stabilize token/cache accounting across providers and routed Roo metadata (#11448) +- fix: harden delegation lifecycle against race conditions with per-task metadata, mutual-exclusion guards, and multi-layer failure recovery (#11379) +- fix: cancel backend auto-approval timeout when auto-approve is toggled off mid-countdown (#11439) +- fix: make delegation reopen flow Roo v2-native (#11418) +- fix: resolve chat scroll anchoring and task-switch scroll race condit… (#11385) +- fix: harden command auto-approval against inline JS false positives (#11382) + +### 📚 Documentation + +- docs: add Claude Code integration validation script to merge procedures +- docs: optimize DEVELOPMENT-ClaudeCodeConnector.md - remove changelog +- docs: extract validation script and document 2026-02-15 merge bugs + +### 🔧 Other Changes + +- chore: release v3.47.3-klaus.2 +- chore(cli): prepare release v0.0.54 (#11477) +- Add stdin stream mode for the cli (#11476) +- Reapply Batches 3-4: Skills, browser removal, provider removals (6 major-conflict cherry-picks) (#11475) +- Reapply Batch 2: 9 minor-conflict non-AI-SDK cherry-picks (#11474) +- Revert to pre-AI-SDK state (January 29, 2026) (#11462) +- Revert "Fix provider 400s: strip reasoning_details from messages, $ref from tool schemas" (#11453) +- Fix provider 400s: strip reasoning_details from messages, $ref from tool schemas (#11431) +- refactor: unify cache control with centralized breakpoints and universal provider options (#11426) +- refactor: remove browser use functionality entirely (#11392) diff --git a/.changeset/auto-20260221.md b/.changeset/auto-20260221.md new file mode 100644 index 00000000000..9643b52f471 --- /dev/null +++ b/.changeset/auto-20260221.md @@ -0,0 +1,39 @@ +--- +"klaus-code": minor +--- + +### ✨ Features + +- feat(api): add undici fetch wrapper utility +- feat(minimax): add MiniMax-M2.5 and highspeed model variants +- feat(web): add blog section with initial posts (#11127) + +### 🐛 Bug Fixes + +- fix(api): add undici fetch wrapper for localhost connections +- fix: restore clean pnpm-lock.yaml after corrupted merge +- fix(cloud): respect user telemetry opt-out in CloudTelemetryClient +- fix(claude-code): show "Starts when a message is sent" instead of "N/A" +- fix: await MCP server initialization before returning McpHub instance (#11518) +- fix: simplify 1M context locale copy for Claude 4 models (#11514) +- fix: preserve condensation summary during task resume (#11487) (#11488) +- fix: add follow_up param validation in AskFollowupQuestionTool (#11484) + +### 📚 Documentation + +- docs: simplify operator approval step +- docs: require operator approval before merging to main +- docs: remove reapplication-plan.md (#11481) + +### 🔧 Other Changes + +- refactor(api): rewrite undici fetch wrapper with proper types +- chore: prepare release v3.47.3-klaus.5 +- chore: remove .nvmrc +- chore: add .nvmrc pinning Node.js 20 +- chore: prepare release v3.47.3-klaus.4 +- Update README.md +- Update README.md +- chore: disable E2E tests workflow +- Changeset version bump (#11513) +- chore(cli): prepare release v0.0.55 (#11516) diff --git a/.changeset/changelog-config.js b/.changeset/changelog-config.js index 0ab9a9e48e2..00f93f281e7 100644 --- a/.changeset/changelog-config.js +++ b/.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 () => { diff --git a/.changeset/config.json b/.changeset/config.json index 310bc510947..f69a7d1c34d 100644 --- a/.changeset/config.json +++ b/.changeset/config.json @@ -7,5 +7,5 @@ "access": "restricted", "baseBranch": "main", "updateInternalDependencies": "patch", - "ignore": ["@roo-code/cli"] + "ignore": ["@klaus-code/cli"] } diff --git a/.gitattributes b/.gitattributes index e9e36432cdc..f45db326197 100644 --- a/.gitattributes +++ b/.gitattributes @@ -23,3 +23,6 @@ src/i18n/locales/en/** linguist-generated=false webview-ui/src/i18n/locales/en/** linguist-generated=false # This approach uses gitattributes' last-match-wins rule to exclude English while including all other locales + +# Ignore web-roo-code app during upstream merges (Klaus Code is VSIX-only) +apps/web-roo-code/** merge=ours diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index a3daa0f144e..e2e8fa34b63 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -1,2 +1,2 @@ # These owners will be the default owners for everything in the repo -* @mrubens @cte @jr +* @mrubens @cte @jr @hannesrudolph @daniel-lxs diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml index 0351ad19301..8c7969776da 100644 --- a/.github/ISSUE_TEMPLATE/config.yml +++ b/.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! diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index e83e44cd66d..e32452bacb6 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -1,5 +1,5 @@ -### Roo Code Task Context (Optional) +### Klaus Code Task Context (Optional) diff --git a/.github/workflows/changeset-release.yml b/.github/workflows/changeset-release.yml.disabled similarity index 100% rename from .github/workflows/changeset-release.yml rename to .github/workflows/changeset-release.yml.disabled diff --git a/.github/workflows/cli-release.yml.disabled b/.github/workflows/cli-release.yml.disabled new file mode 100644 index 00000000000..20961a9f2d3 --- /dev/null +++ b/.github/workflows/cli-release.yml.disabled @@ -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<> $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<> $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 diff --git a/.github/workflows/code-qa.yml b/.github/workflows/code-qa.yml.disabled similarity index 100% rename from .github/workflows/code-qa.yml rename to .github/workflows/code-qa.yml.disabled diff --git a/.github/workflows/codeql.yml b/.github/workflows/codeql.yml.disabled similarity index 100% rename from .github/workflows/codeql.yml rename to .github/workflows/codeql.yml.disabled diff --git a/.github/workflows/e2e-tests.yml b/.github/workflows/e2e-tests.yml new file mode 100644 index 00000000000..ebfa2f93112 --- /dev/null +++ b/.github/workflows/e2e-tests.yml @@ -0,0 +1,72 @@ +name: E2E Tests + +on: + workflow_dispatch: + schedule: + - cron: "0 0 * * 0" # Weekly on Sunday + push: + branches: [main] + paths: + - "apps/vscode-e2e/**" + - "src/**" + +env: + NODE_VERSION: "20.x" + VSCODE_VERSION: "1.101.2" + +jobs: + e2e-test: + strategy: + fail-fast: false + matrix: + os: [ubuntu-latest, windows-latest, macos-latest] + runs-on: ${{ matrix.os }} + steps: + - name: Checkout repository + uses: actions/checkout@v4 + + - name: Setup Node.js + uses: actions/setup-node@v4 + with: + node-version: ${{ env.NODE_VERSION }} + cache: "pnpm" + + - name: Install dependencies + run: pnpm install + + - name: Build extension + run: pnpm bundle + + - name: Build webview + run: pnpm --filter @klaus-code/vscode-webview build + + - name: Cache VSCode + uses: actions/cache@v4 + with: + path: ~/.vscode-test + key: vscode-${{ runner.os }}-${{ env.VSCODE_VERSION }} + + - name: Run E2E tests (Linux) + if: runner.os == 'Linux' + run: xvfb-run -a pnpm --filter @klaus-code/vscode-e2e test:run + env: + DISPLAY: ":99.0" + VSCODE_VERSION: ${{ env.VSCODE_VERSION }} + VSCODE_EXTENSION_ID: "KlausCode.klaus-code" + + - name: Run E2E tests (Windows/macOS) + if: runner.os != 'Linux' + run: pnpm --filter @klaus-code/vscode-e2e test:run + env: + VSCODE_VERSION: ${{ env.VSCODE_VERSION }} + VSCODE_EXTENSION_ID: "KlausCode.klaus-code" + + - name: Upload test artifacts + if: failure() + uses: actions/upload-artifact@v4 + with: + name: e2e-test-results-${{ matrix.os }} + path: | + .vscode-test/ + apps/vscode-e2e/test-results/ + retention-days: 7 diff --git a/.github/workflows/e2e-tests.yml.disabled b/.github/workflows/e2e-tests.yml.disabled new file mode 100644 index 00000000000..ebfa2f93112 --- /dev/null +++ b/.github/workflows/e2e-tests.yml.disabled @@ -0,0 +1,72 @@ +name: E2E Tests + +on: + workflow_dispatch: + schedule: + - cron: "0 0 * * 0" # Weekly on Sunday + push: + branches: [main] + paths: + - "apps/vscode-e2e/**" + - "src/**" + +env: + NODE_VERSION: "20.x" + VSCODE_VERSION: "1.101.2" + +jobs: + e2e-test: + strategy: + fail-fast: false + matrix: + os: [ubuntu-latest, windows-latest, macos-latest] + runs-on: ${{ matrix.os }} + steps: + - name: Checkout repository + uses: actions/checkout@v4 + + - name: Setup Node.js + uses: actions/setup-node@v4 + with: + node-version: ${{ env.NODE_VERSION }} + cache: "pnpm" + + - name: Install dependencies + run: pnpm install + + - name: Build extension + run: pnpm bundle + + - name: Build webview + run: pnpm --filter @klaus-code/vscode-webview build + + - name: Cache VSCode + uses: actions/cache@v4 + with: + path: ~/.vscode-test + key: vscode-${{ runner.os }}-${{ env.VSCODE_VERSION }} + + - name: Run E2E tests (Linux) + if: runner.os == 'Linux' + run: xvfb-run -a pnpm --filter @klaus-code/vscode-e2e test:run + env: + DISPLAY: ":99.0" + VSCODE_VERSION: ${{ env.VSCODE_VERSION }} + VSCODE_EXTENSION_ID: "KlausCode.klaus-code" + + - name: Run E2E tests (Windows/macOS) + if: runner.os != 'Linux' + run: pnpm --filter @klaus-code/vscode-e2e test:run + env: + VSCODE_VERSION: ${{ env.VSCODE_VERSION }} + VSCODE_EXTENSION_ID: "KlausCode.klaus-code" + + - name: Upload test artifacts + if: failure() + uses: actions/upload-artifact@v4 + with: + name: e2e-test-results-${{ matrix.os }} + path: | + .vscode-test/ + apps/vscode-e2e/test-results/ + retention-days: 7 diff --git a/.github/workflows/evals.yml b/.github/workflows/evals.yml.disabled similarity index 97% rename from .github/workflows/evals.yml rename to .github/workflows/evals.yml.disabled index b99fd7659ef..3c734e4b7e5 100644 --- a/.github/workflows/evals.yml +++ b/.github/workflows/evals.yml.disabled @@ -64,10 +64,10 @@ jobs: docker compose run --rm runner docker ps - name: Run database migrations - run: docker compose run --rm runner pnpm --filter @roo-code/evals db:migrate + run: docker compose run --rm runner pnpm --filter @klaus-code/evals db:migrate - name: Run evals - run: docker compose run --rm runner pnpm --filter @roo-code/evals cli --ci + run: docker compose run --rm runner pnpm --filter @klaus-code/evals cli --ci - name: Cleanup if: always() diff --git a/.github/workflows/marketplace-publish.yml b/.github/workflows/marketplace-publish.yml.disabled similarity index 96% rename from .github/workflows/marketplace-publish.yml rename to .github/workflows/marketplace-publish.yml.disabled index aef91b2d323..56e0f7d7179 100644 --- a/.github/workflows/marketplace-publish.yml +++ b/.github/workflows/marketplace-publish.yml.disabled @@ -37,7 +37,7 @@ jobs: pnpm vsix # Save VSIX contents to a temporary file to avoid broken pipe issues. - unzip -l bin/roo-cline-${current_package_version}.vsix > /tmp/roo-code-vsix-contents.txt + unzip -l bin/klaus-code-${current_package_version}.vsix > /tmp/roo-code-vsix-contents.txt # Check for required files. grep -q "extension/package.json" /tmp/roo-code-vsix-contents.txt || exit 1 @@ -63,7 +63,7 @@ jobs: OVSX_PAT: ${{ secrets.OVSX_PAT }} run: | current_package_version=$(node -p "require('./src/package.json').version") - pnpm --filter roo-cline publish:marketplace + pnpm --filter klaus-code publish:marketplace echo "Successfully published version $current_package_version to VS Code Marketplace" - name: Create GitHub Release env: diff --git a/.github/workflows/nightly-changelog.yml b/.github/workflows/nightly-changelog.yml new file mode 100644 index 00000000000..089224d3243 --- /dev/null +++ b/.github/workflows/nightly-changelog.yml @@ -0,0 +1,189 @@ +name: Nightly Changelog Update + +on: + schedule: + - cron: '0 2 * * *' # Run every night at 2 AM UTC + workflow_dispatch: # Allow manual triggering + +jobs: + update-changelog: + runs-on: ubuntu-latest + + permissions: + contents: write + pull-requests: write + + steps: + - name: Checkout code + uses: actions/checkout@v4 + with: + fetch-depth: 0 # Need full history for changelog generation + + - name: Setup Node.js and pnpm + uses: ./.github/actions/setup-node-pnpm + with: + install-args: '--frozen-lockfile' + + - name: Check for new commits since last weekly build + id: check_commits + run: | + # Find last weekly tag + LAST_TAG=$(git tag --list 'weekly-v*' --sort=-version:refname | head -n1) + + if [ -z "$LAST_TAG" ]; then + echo "No previous weekly tags found" + COMMIT_COUNT=0 + else + COMMIT_COUNT=$(git rev-list --count ${LAST_TAG}..HEAD 2>/dev/null || echo "0") + fi + + echo "commits=$COMMIT_COUNT" >> $GITHUB_OUTPUT + echo "last_tag=$LAST_TAG" >> $GITHUB_OUTPUT + echo "📊 Found $COMMIT_COUNT new commits since $LAST_TAG" + + - name: Generate changeset from commits + if: steps.check_commits.outputs.commits > 0 + run: | + LAST_TAG="${{ steps.check_commits.outputs.last_tag }}" + + # Determine version bump + HAS_BREAKING=$(git log ${LAST_TAG}..HEAD --oneline --grep="BREAKING CHANGE" | wc -l) + HAS_FEAT=$(git log ${LAST_TAG}..HEAD --oneline --grep="^feat" | wc -l) + HAS_FIX=$(git log ${LAST_TAG}..HEAD --oneline --grep="^fix" | wc -l) + + if [ "$HAS_BREAKING" -gt 0 ]; then + BUMP_TYPE="major" + elif [ "$HAS_FEAT" -gt 0 ]; then + BUMP_TYPE="minor" + else + BUMP_TYPE="patch" + fi + + # Generate changeset file + CHANGESET_ID="auto-$(date +%Y%m%d)" + CHANGESET_FILE=".changeset/${CHANGESET_ID}.md" + + # Check if changeset already exists for today + if [ -f "$CHANGESET_FILE" ]; then + echo "Changeset already exists for today, updating..." + rm "$CHANGESET_FILE" + fi + + cat > "$CHANGESET_FILE" <<'EOF' + --- + "klaus-code": ${BUMP_TYPE} + --- + + EOF + + # Add commit range to changeset + if [ -n "$LAST_TAG" ]; then + COMMIT_RANGE="${LAST_TAG}..HEAD" + else + COMMIT_RANGE="HEAD~20..HEAD" + fi + + # Features + FEATURES=$(git log $COMMIT_RANGE --oneline --no-merges --grep="^feat" --perl-regexp --pretty=format:"- %s" 2>/dev/null || true) + if [ -n "$FEATURES" ]; then + echo "### ✨ Features" >> "$CHANGESET_FILE" + echo "" >> "$CHANGESET_FILE" + echo "$FEATURES" >> "$CHANGESET_FILE" + echo "" >> "$CHANGESET_FILE" + fi + + # Bug Fixes + FIXES=$(git log $COMMIT_RANGE --oneline --no-merges --grep="^fix" --perl-regexp --pretty=format:"- %s" 2>/dev/null || true) + if [ -n "$FIXES" ]; then + echo "### 🐛 Bug Fixes" >> "$CHANGESET_FILE" + echo "" >> "$CHANGESET_FILE" + echo "$FIXES" >> "$CHANGESET_FILE" + echo "" >> "$CHANGESET_FILE" + fi + + # Documentation + DOCS=$(git log $COMMIT_RANGE --oneline --no-merges --grep="^docs" --perl-regexp --pretty=format:"- %s" 2>/dev/null | head -10 || true) + if [ -n "$DOCS" ]; then + echo "### 📚 Documentation" >> "$CHANGESET_FILE" + echo "" >> "$CHANGESET_FILE" + echo "$DOCS" >> "$CHANGESET_FILE" + echo "" >> "$CHANGESET_FILE" + fi + + # Other changes (limit to 10 most recent) + OTHERS=$(git log $COMMIT_RANGE --oneline --no-merges --invert-grep --grep="^feat" --grep="^fix" --grep="^docs" --perl-regexp --pretty=format:"- %s" 2>/dev/null | head -10 || true) + if [ -n "$OTHERS" ]; then + echo "### 🔧 Other Changes" >> "$CHANGESET_FILE" + echo "" >> "$CHANGESET_FILE" + echo "$OTHERS" >> "$CHANGESET_FILE" + echo "" >> "$CHANGESET_FILE" + fi + + # Fix the BUMP_TYPE placeholder + sed -i "s/\${BUMP_TYPE}/$BUMP_TYPE/g" "$CHANGESET_FILE" + + echo "✅ Generated changeset: $CHANGESET_FILE" + cat "$CHANGESET_FILE" + + - name: Generate preview changelog + if: steps.check_commits.outputs.commits > 0 + run: | + echo "# Preview Changelog for Next Release" > /tmp/preview-changelog.md + echo "" >> /tmp/preview-changelog.md + echo "This is an automatically generated preview of changes since the last weekly build." >> /tmp/preview-changelog.md + echo "" >> /tmp/preview-changelog.md + + ./scripts/generate-weekly-changelog.sh "${{ steps.check_commits.outputs.last_tag }}" >> /tmp/preview-changelog.md + + echo "📝 Preview changelog:" + cat /tmp/preview-changelog.md + + - name: Create Pull Request + if: steps.check_commits.outputs.commits > 0 + uses: peter-evans/create-pull-request@v6 + with: + token: ${{ secrets.GITHUB_TOKEN }} + commit-message: 'chore: auto-update changelog for upcoming release' + branch: auto-changelog-update + delete-branch: true + title: '📝 Auto-generated Changelog Update' + body: | + ## Automated Changelog Update + + This PR contains automatically generated changelog entries based on commits since the last weekly build. + + ### Summary + - **Commits analyzed**: ${{ steps.check_commits.outputs.commits }} + - **Since**: `${{ steps.check_commits.outputs.last_tag }}` + + ### What's included: + - ✅ New changeset file in `.changeset/` + - ✅ Auto-categorized by commit type (feat, fix, docs, etc.) + + ### Next Steps: + 1. **Review** the changeset file for accuracy + 2. **Edit** if needed (update descriptions, fix categorization) + 3. **Merge** when ready + 4. The next weekly build will include these changes + + --- + +
+ 📋 Preview Changelog + + $(cat /tmp/preview-changelog.md) + +
+ + --- + + 🤖 This PR was created automatically by the [nightly-changelog workflow](.github/workflows/nightly-changelog.yml) + labels: | + automated + changelog + documentation + + - name: No changes detected + if: steps.check_commits.outputs.commits == 0 + run: | + echo "ℹ️ No new commits since last weekly build - skipping changelog update" diff --git a/.github/workflows/nightly-publish.yml b/.github/workflows/nightly-publish.yml deleted file mode 100644 index e25bdba990a..00000000000 --- a/.github/workflows/nightly-publish.yml +++ /dev/null @@ -1,52 +0,0 @@ -name: Nightly Publish - -on: - push: - branches: [main] - workflow_dispatch: # Allows manual triggering. - -jobs: - publish-nightly: - runs-on: ubuntu-latest - - permissions: - contents: read # No tags pushed → read is enough. - - steps: - - name: Checkout code - uses: actions/checkout@v4 - with: - fetch-depth: 0 - - name: Setup Node.js and pnpm - uses: ./.github/actions/setup-node-pnpm - with: - install-args: '--frozen-lockfile' - - name: Forge numeric Nightly version - id: version - env: - RUN_NUMBER: ${{ github.run_number }} - run: echo "number=$(( 5500 + ${RUN_NUMBER} ))" >> $GITHUB_OUTPUT - - name: Patch package.json version - env: - VERSION_NUMBER: ${{ steps.version.outputs.number }} - run: | - node <<'EOF' - const fs = require('fs'); - const path = require('path'); - const pkgPath = path.join(__dirname, 'apps', 'vscode-nightly', 'package.nightly.json'); - const pkg = JSON.parse(fs.readFileSync(pkgPath,'utf8')); - const [maj, min] = pkg.version.split('.'); - pkg.version = `${maj}.${min}.${process.env.VERSION_NUMBER}`; - fs.writeFileSync(pkgPath, JSON.stringify(pkg, null, 2)); - console.log(`🔖 Nightly version set to ${pkg.version}`); - EOF - - name: Build VSIX - run: pnpm vsix:nightly # Produces bin/roo-code-nightly-0.0.[count].vsix - - name: Publish to VS Code Marketplace - env: - VSCE_PAT: ${{ secrets.VSCE_PAT }} - run: npx vsce publish --packagePath "bin/$(/bin/ls bin | head -n1)" - - name: Publish to Open VSX Registry - env: - OVSX_PAT: ${{ secrets.OVSX_PAT }} - run: npx ovsx publish "bin/$(ls bin | head -n1)" diff --git a/.github/workflows/update-contributors.yml b/.github/workflows/update-contributors.yml.disabled similarity index 100% rename from .github/workflows/update-contributors.yml rename to .github/workflows/update-contributors.yml.disabled diff --git a/.github/workflows/website-deploy.yml b/.github/workflows/website-deploy.yml deleted file mode 100644 index 20eea4288a9..00000000000 --- a/.github/workflows/website-deploy.yml +++ /dev/null @@ -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 }} diff --git a/.github/workflows/website-preview.yml b/.github/workflows/website-preview.yml deleted file mode 100644 index 65cf3e54189..00000000000 --- a/.github/workflows/website-preview.yml +++ /dev/null @@ -1,89 +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 = ''; - - 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) - ); - - 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.'; - - if (existingComment) { - await github.rest.issues.updateComment({ - owner: context.repo.owner, - repo: context.repo.repo, - comment_id: existingComment.id, - body: comment - }); - } else { - await github.rest.issues.createComment({ - owner: context.repo.owner, - repo: context.repo.repo, - issue_number: context.issue.number, - body: comment - }); - } diff --git a/.github/workflows/weekly-build.yml b/.github/workflows/weekly-build.yml new file mode 100644 index 00000000000..1f54f4f30f7 --- /dev/null +++ b/.github/workflows/weekly-build.yml @@ -0,0 +1,170 @@ +name: Weekly Build + +on: + schedule: + - cron: '0 0 * * 0' # Run every Sunday at midnight UTC + workflow_dispatch: # Allows manual triggering + +jobs: + publish-weekly: + runs-on: ubuntu-latest + + permissions: + contents: write # Required for creating releases + + steps: + - name: Checkout code + uses: actions/checkout@v4 + with: + fetch-depth: 0 + - name: Setup Node.js and pnpm + uses: ./.github/actions/setup-node-pnpm + with: + install-args: '--frozen-lockfile' + - name: Cache Turbo build artifacts + uses: actions/cache@v4 + with: + path: .turbo + key: ${{ runner.os }}-turbo-${{ github.sha }} + restore-keys: | + ${{ runner.os }}-turbo- + - name: Generate nightly version from main package + id: version + run: | + # Read version from src/package.json + MAIN_VERSION=$(node -p "require('./src/package.json').version") + DATE_SUFFIX=$(date +%Y%m%d) + NIGHTLY_VERSION="${MAIN_VERSION}.nightly${DATE_SUFFIX}" + + echo "main=${MAIN_VERSION}" >> $GITHUB_OUTPUT + echo "nightly=${NIGHTLY_VERSION}" >> $GITHUB_OUTPUT + echo "date=${DATE_SUFFIX}" >> $GITHUB_OUTPUT + + echo "🔖 Main version: ${MAIN_VERSION}" + echo "🔖 Nightly version: ${NIGHTLY_VERSION}" + - name: Patch package.json version + env: + NIGHTLY_VERSION: ${{ steps.version.outputs.nightly }} + run: | + node <<'EOF' + const fs = require('fs'); + const path = require('path'); + const pkgPath = path.join(__dirname, 'apps', 'vscode-nightly', 'package.nightly.json'); + const pkg = JSON.parse(fs.readFileSync(pkgPath,'utf8')); + pkg.version = process.env.NIGHTLY_VERSION; + fs.writeFileSync(pkgPath, JSON.stringify(pkg, null, 2)); + console.log(`🔖 Nightly version set to ${pkg.version}`); + EOF + - name: Build dependencies + run: pnpm build + - name: Build VSIX + run: pnpm vsix:nightly # Produces bin/klaus-code-nightly-X.Y.Z-klaus.N.nightlyYYYYMMDD.vsix + - name: Generate Changelog + id: changelog + run: | + # Find last weekly tag + LAST_TAG=$(git tag --list 'weekly-v*' --sort=-version:refname | head -n1) + + if [ -z "$LAST_TAG" ]; then + echo "📝 First weekly build - generating full changelog" + COMMIT_RANGE="HEAD~50..HEAD" # Last 50 commits for first build + LAST_TAG="initial" + else + echo "📝 Generating changelog from $LAST_TAG to HEAD" + COMMIT_RANGE="${LAST_TAG}..HEAD" + fi + + # Count commits + COMMIT_COUNT=$(git rev-list --count $COMMIT_RANGE 2>/dev/null || echo "0") + + if [ "$COMMIT_COUNT" = "0" ]; then + echo "No new commits since last weekly build" + CHANGELOG="No changes since last weekly build." + else + # Generate changelog + CHANGELOG="## What's Changed + + " + + # Features + FEATURES=$(git log $COMMIT_RANGE --oneline --no-merges --grep="^feat" --perl-regexp --pretty=format:"- %s" 2>/dev/null || true) + if [ -n "$FEATURES" ]; then + CHANGELOG="${CHANGELOG}### ✨ Features + + ${FEATURES} + + " + fi + + # Bug Fixes + FIXES=$(git log $COMMIT_RANGE --oneline --no-merges --grep="^fix" --perl-regexp --pretty=format:"- %s" 2>/dev/null || true) + if [ -n "$FIXES" ]; then + CHANGELOG="${CHANGELOG}### 🐛 Bug Fixes + + ${FIXES} + + " + fi + + # Documentation + DOCS=$(git log $COMMIT_RANGE --oneline --no-merges --grep="^docs" --perl-regexp --pretty=format:"- %s" 2>/dev/null || true) + if [ -n "$DOCS" ]; then + CHANGELOG="${CHANGELOG}### 📚 Documentation + + ${DOCS} + + " + fi + + # Other changes + OTHERS=$(git log $COMMIT_RANGE --oneline --no-merges --invert-grep --grep="^feat" --grep="^fix" --grep="^docs" --perl-regexp --pretty=format:"- %s" 2>/dev/null | head -20 || true) + if [ -n "$OTHERS" ]; then + CHANGELOG="${CHANGELOG}### 🔧 Other Changes + + ${OTHERS} + + " + fi + + # Add footer + CHANGELOG="${CHANGELOG}--- + + **Full Changelog**: https://github.com/${{ github.repository }}/compare/${LAST_TAG}...weekly-v${{ steps.version.outputs.nightly }} + + 📊 **$COMMIT_COUNT** commits in this release + 🏷️ **Based on**: Klaus Code v${{ steps.version.outputs.main }}" + fi + + # Save to file (GitHub Actions doesn't handle multiline output well) + echo "$CHANGELOG" > /tmp/changelog.md + echo "changelog_file=/tmp/changelog.md" >> $GITHUB_OUTPUT + echo "commit_count=$COMMIT_COUNT" >> $GITHUB_OUTPUT + + - name: Create GitHub Pre-release + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + run: | + NIGHTLY_VERSION="${{ steps.version.outputs.nightly }}" + MAIN_VERSION="${{ steps.version.outputs.main }}" + VSIX_FILE=$(ls bin/*.vsix | head -n1) + VSIX_FILENAME=$(basename "$VSIX_FILE") + CHANGELOG_FILE="${{ steps.changelog.outputs.changelog_file }}" + + # Create pre-release with generated changelog + gh release create "weekly-v${NIGHTLY_VERSION}" \ + --title "Weekly Build v${NIGHTLY_VERSION} (based on v${MAIN_VERSION})" \ + --notes-file "$CHANGELOG_FILE" \ + --prerelease \ + "$VSIX_FILE" + + echo "✅ Created weekly pre-release v${NIGHTLY_VERSION} with ${VSIX_FILENAME}" + echo "📝 Based on Klaus Code v${MAIN_VERSION}" + echo "📝 Changelog includes ${{ steps.changelog.outputs.commit_count }} commits" + # - name: Publish to VS Code Marketplace + # env: + # VSCE_PAT: ${{ secrets.VSCE_PAT }} + # run: npx vsce publish --packagePath "bin/$(/bin/ls bin | head -n1)" + # - name: Publish to Open VSX Registry + # env: + # OVSX_PAT: ${{ secrets.OVSX_PAT }} + # run: npx ovsx publish "bin/$(ls bin | head -n1)" diff --git a/.gitignore b/.gitignore index 364b391a012..e034edb8141 100644 --- a/.gitignore +++ b/.gitignore @@ -18,13 +18,16 @@ bin/ # Local prompts and rules /local-prompts +AGENTS.local.md # Test environment .test_env .vscode-test/ # Docs +docs/ docs/_site/ +docs/untracked/ # Dotenv .env @@ -54,3 +57,6 @@ qdrant_storage/ plans/ roo-cli-*.tar.gz* + +# Web app (Klaus Code is VSIX-only) +apps/web-roo-code/ diff --git a/.husky/pre-commit b/.husky/pre-commit index a0e3a53df53..79fa990a0f1 100644 --- a/.husky/pre-commit +++ b/.husky/pre-commit @@ -1,9 +1,9 @@ -branch="$(git rev-parse --abbrev-ref HEAD)" - -if [ "$branch" = "main" ]; then - echo "You can't commit directly to main - please check out a branch." - exit 1 -fi +# Disabled main branch restriction for fork +# branch="$(git rev-parse --abbrev-ref HEAD)" +# if [ "$branch" = "main" ]; then +# echo "You can't commit directly to main - please check out a branch." +# exit 1 +# fi # Detect if running on Windows and use pnpm.cmd, otherwise use pnpm. if [ "$OS" = "Windows_NT" ]; then diff --git a/.husky/pre-push b/.husky/pre-push index 4cf91d95800..e4c2127d5d6 100644 --- a/.husky/pre-push +++ b/.husky/pre-push @@ -1,9 +1,9 @@ -branch="$(git rev-parse --abbrev-ref HEAD)" - -if [ "$branch" = "main" ]; then - echo "You can't push directly to main - please check out a branch." - exit 1 -fi +# Disabled main branch restriction for fork +# branch="$(git rev-parse --abbrev-ref HEAD)" +# if [ "$branch" = "main" ]; then +# echo "You can't push directly to main - please check out a branch." +# exit 1 +# fi # Detect if running on Windows and use pnpm.cmd, otherwise use pnpm. if [ "$OS" = "Windows_NT" ]; then diff --git a/.nvmrc b/.nvmrc deleted file mode 100644 index 1d898f1fe56..00000000000 --- a/.nvmrc +++ /dev/null @@ -1 +0,0 @@ -v20.19.2 diff --git a/.roo/commands/cli-release.md b/.roo/commands/cli-release.md index 70b3698528d..5e68e4df2d1 100644 --- a/.roo/commands/cli-release.md +++ b/.roo/commands/cli-release.md @@ -1,5 +1,5 @@ --- -description: "Create a new release of the Roo Code CLI" +description: "Prepare a new release of the Roo Code CLI" argument-hint: "[version-description]" mode: code --- @@ -84,41 +84,3 @@ mode: code - [ ] All CI checks pass" \ --base main ``` - -7. Wait for PR approval and merge: - - - Request review if required by your workflow - - Ensure CI checks pass - - Merge the PR using: `gh pr merge --squash --delete-branch` - - Or merge via the GitHub UI - -8. Run the release script from the monorepo root: - - ```bash - # Ensure you're on the updated main branch after the PR merge - git checkout main - git pull origin main - - # Run the release script - ./apps/cli/scripts/release.sh - ``` - - The release script will automatically: - - - Build the extension and CLI - - Create a platform-specific tarball - - Verify the installation works correctly (runs --help, --version, and e2e test) - - Extract changelog content and include it in the GitHub release notes - - Create the GitHub release with the tarball attached - -9. After a successful release, verify: - - Check the release page: https://github.com/RooCodeInc/Roo-Code/releases - - Verify the "What's New" section contains the changelog content - - Test installation: `curl -fsSL https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/install.sh | sh` - -**Notes:** - -- The release script requires GitHub CLI (`gh`) to be installed and authenticated -- If a release already exists for the tag, the script will prompt to delete and recreate it -- The script creates a tarball for the current platform only (darwin-arm64, darwin-x64, linux-arm64, or linux-x64) -- Multi-platform releases require running the script on each platform and manually uploading additional tarballs diff --git a/.roo/commands/release.md b/.roo/commands/release.md index 2e09783a58e..2cee9ab6533 100644 --- a/.roo/commands/release.md +++ b/.roo/commands/release.md @@ -1,5 +1,5 @@ --- -description: "Create a new release of the Roo Code extension" +description: "Create a new release of the Klaus Code extension" argument-hint: patch | minor | major mode: code --- diff --git a/.roo/commands/roo-resolve-conflicts.md b/.roo/commands/roo-resolve-conflicts.md new file mode 100644 index 00000000000..38b2038658c --- /dev/null +++ b/.roo/commands/roo-resolve-conflicts.md @@ -0,0 +1,74 @@ +--- +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 diff --git a/.roo/commands/roo-translate.md b/.roo/commands/roo-translate.md new file mode 100644 index 00000000000..28a8dc67c84 --- /dev/null +++ b/.roo/commands/roo-translate.md @@ -0,0 +1,53 @@ +--- +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 diff --git a/.roo/guidance/roo-translator.md b/.roo/guidance/roo-translator.md new file mode 100644 index 00000000000..2539778f27f --- /dev/null +++ b/.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 + + + +## Tone + + + +## Word Choice + + diff --git a/.roo/rules-docs-extractor/1_extraction_workflow.xml b/.roo/rules-docs-extractor/1_extraction_workflow.xml index c707fa78092..200e48da0c7 100644 --- a/.roo/rules-docs-extractor/1_extraction_workflow.xml +++ b/.roo/rules-docs-extractor/1_extraction_workflow.xml @@ -1,163 +1,113 @@ - - 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 + + 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. + - 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. - - - + - Parse Request + Identify Target - Identify the feature/aspect in the user's request. - Decide path: verification vs. source-material generation. - For source-material: capture audience (user or developer) and depth (overview vs task-focused). - For verification: identify the documentation to be verified (provided text/links/files). - Note any specific areas to emphasize or check. + Parse the user's request to identify the feature/aspect + Clarify scope if ambiguous (ask one question max) - Discover Feature + Discover Code + + Use codebase_search to find relevant files + Identify entry points, components, and related code + Map the boundaries of the feature + + + + + Extract Facts + + Read code and extract facts into categories (see fact_categories) + Record file paths as sources for each fact + Do NOT interpret, summarize, or explain - just extract + + + + + Output Structured Data - Locate relevant code and assets using appropriate discovery methods. - Identify entry points and key components that affect user experience. - Map the high-level workflow a user follows. + Write extraction to .roo/extraction/EXTRACT-[feature].yaml + Use the output schema (see output_format.xml) - + + + + + + Feature name as it appears in code + File paths where feature is implemented + Entry points (commands, UI elements, API endpoints) + + + + + + What the feature does (from code logic) + Inputs it accepts + Outputs it produces + Side effects (files created, state changed, etc.) + + + + + + Settings/options that affect behavior + Default values + Valid ranges or allowed values + Where configured (settings file, env var, UI) + + + + + + Prerequisites and dependencies + Limitations (what it cannot do) + Permissions required + Compatibility requirements + + - - UI components and their interactions - User workflows and decision points - Configuration that changes user-visible behavior - Error states, messages, and recovery - Benefits, limits, prerequisites, and version notes - Why this exists: user goals, constraints, and design intent - “Cannot do” boundaries: permissions, invariants, and business rules - Troubleshooting: symptoms, likely causes, diagnostics, fixes, prevention - Common pitfalls and anti‑patterns (what to avoid and why) - Decision rationale and trade‑offs that affect user choices - Complex UI states that merit visuals (criteria for screenshots/diagrams) - + + + Error conditions in code + Error messages (exact text) + Recovery paths in code + + - - - Generate Source Material for User-Facing Docs - Extract concise, user-oriented facts and structure them for documentation teams. - - - Scope and Audience - - Confirm the feature/aspect and intended audience. - List primary tasks the audience performs with this feature. - - - - Extract User-Facing Facts - - Summarize what the feature does and key benefits. - Explain why users need this (jobs-to-be-done, outcomes) and when to use it. - Document step-by-step user workflows and UI interactions. - Capture configuration options that impact user behavior (name, default, effect). - Clarify constraints, limits, and “cannot do” cases with rationale. - Identify common pitfalls and anti-patterns; include “Do/Don’t” guidance. - List common errors with user-facing messages, diagnostics, fixes, and prevention. - Record prerequisites, permissions, and compatibility/version notes. - Flag complex states that warrant visuals (what to show and why), not every step. - - - - Create Source Material Report - - Organize findings using user-focused structure (benefits, use cases, how it works, configuration, FAQ, troubleshooting). - Include short code/UI snippets or paths where relevant. - Create `EXTRACTION-[feature].md` with findings. - Highlight items that need visuals (screenshots/diagrams). - - - - 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 - - - - + + + UI components involved + User-visible labels and text + Interaction patterns + + - - Verify Documentation Accuracy - Check provided documentation against codebase reality and actual UX. - - - Analyze Provided Documentation - - Parse the documentation to identify claims and descriptions. - Extract technical or user-facing specifics mentioned. - Note workflows, configuration, and examples described. - - - - Verify Against Codebase - - Check claims against actual implementation and UX. - Verify endpoints/parameters if referenced. - Confirm configuration options and defaults. - Validate code snippets and examples. - Ensure described workflows match implementation. - - - - Create Verification Report - - Categorize findings by severity (Critical, Major, Minor). - List inaccuracies with the correct information. - Identify missing important information. - Provide specific corrections and suggestions. - Create `VERIFICATION-[feature].md` with findings. - - - - 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 - - - - - + + + Other features this interacts with + External APIs or services called + Events emitted or consumed + + + - - - Audience and scope captured - User workflows and UI interactions documented - User-impacting configuration recorded - Common errors and troubleshooting documented - Report organized for documentation team use - - - All documentation claims verified - Inaccuracies identified and corrected - Missing information noted - Suggestions for improvement provided - Clear verification report created - - + + Extract facts, not opinions + Include source file paths for every fact + Use code identifiers and exact strings from source + Do NOT paraphrase - quote when possible + Do NOT decide what's important - extract everything relevant + Do NOT format for end users - output is for docs team + \ No newline at end of file diff --git a/.roo/rules-docs-extractor/2_documentation_patterns.xml b/.roo/rules-docs-extractor/2_documentation_patterns.xml deleted file mode 100644 index da743483dab..00000000000 --- a/.roo/rules-docs-extractor/2_documentation_patterns.xml +++ /dev/null @@ -1,357 +0,0 @@ - - - Standard templates for structuring extracted documentation. - - - - -# [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.] - - - - -# [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.] - - - - - - - - - - --- - Separate sections. - - - - - - - - Show tool output or UI elements. - Use actual file paths and setting names. - Include common errors and solutions. - - - - - - - - - - - - - - - Tutorials - Use cases - Troubleshooting - Benefits - - - - - - - Code examples - API specs - Integration patterns - Performance - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [Link Text](#section-anchor) - [See Configuration Guide](#configuration) - - - - [Link Text](https://external.url) - [Official Documentation](https://docs.example.com) - - - - - - - - - - - \ No newline at end of file diff --git a/.roo/rules-docs-extractor/2_verification_workflow.xml b/.roo/rules-docs-extractor/2_verification_workflow.xml new file mode 100644 index 00000000000..4635d8eb45b --- /dev/null +++ b/.roo/rules-docs-extractor/2_verification_workflow.xml @@ -0,0 +1,85 @@ + + + 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. + + + + + Receive Documentation + + User provides documentation to verify (text, file, or URL) + Identify the feature/aspect being documented + + + + + Extract Claims + + Parse the documentation into discrete claims + Tag each claim with a category (behavior, config, constraint, etc.) + Record the exact quote from the documentation + + + + + Verify Against Code + + For each claim, find the relevant code + Compare claim to actual implementation + Record: ACCURATE, INACCURATE, OUTDATED, MISSING_CONTEXT, or UNVERIFIABLE + For inaccuracies, record what the code actually does + + + + + Output Verification Report + + Write verification to .roo/extraction/VERIFY-[feature].yaml + Use the output schema (see output_format.xml) + + + + + + + Claim matches implementation + + + Claim contradicts implementation + What the code actually does + + + Claim was once true but code has changed + Current behavior + + + Claim is true but omits important information + The missing context + + + Cannot find code to verify this claim + Search paths attempted + + + + + behavior + configuration + constraint + error_handling + ui + integration + prerequisite + + + + Verify facts, not writing quality + Report what code does, not what docs should say + Include source file paths as evidence + Do NOT suggest documentation rewrites + Do NOT evaluate if docs are "good" - only if they're accurate + Quote exact code when showing discrepancies + + \ No newline at end of file diff --git a/.roo/rules-docs-extractor/3_analysis_techniques.xml b/.roo/rules-docs-extractor/3_analysis_techniques.xml deleted file mode 100644 index 12b3d1fd266..00000000000 --- a/.roo/rules-docs-extractor/3_analysis_techniques.xml +++ /dev/null @@ -1,349 +0,0 @@ - - - Heuristics for analyzing a codebase to extract reliable, user-facing documentation. - This file contains technique checklists only—no tool instructions or invocations. - - - - - Find and analyze UI components and their interactions - - Start from feature or route directories and enumerate components related to the requested topic. - Differentiate container vs presentational components; note composition patterns. - Trace inputs/outputs: props, state, context, events, and side effects. - Record conditional rendering that affects user-visible states. - - - Primary components and responsibilities. - Props/state/context that change behavior. - High-level dependency/composition map. - - - - - Analyze styling and visual elements - - Identify design tokens and utility classes used to drive layout and state. - Capture responsive behavior and breakpoint rules that materially change UX. - Document visual affordances tied to state (loading, error, disabled). - - - Key classes/selectors influencing layout/state. - Responsive behavior summary and breakpoints. - - - - - Map user interactions and navigation flows - - Route definitions and navigation - Form submissions and validations - Button clicks and event handlers - State changes and UI updates - Loading and error states - - - Outline entry points and expected outcomes for each primary flow. - Summarize validation rules and failure states the user can encounter. - Record redirects and deep-link behavior relevant to the feature. - - - Flow diagrams or bullet sequences for main tasks. - Validation conditions and error messages. - Navigation transitions and guards. - - - - - Analyze how the system communicates with users - - Error messages and alerts - Success notifications - Loading indicators - Tooltips and help text - Confirmation dialogs - Progress indicators - - - Map message triggers to the user actions that cause them. - Capture severity, persistence, and dismissal behavior. - Note localization or accessibility considerations in messages. - - - Catalog of messages with purpose and conditions. - Loading/progress patterns and timeouts. - - - - - Check for accessibility features and compliance - - ARIA labels and roles - Keyboard navigation support - Screen reader compatibility - Focus management - Color contrast considerations - - - Confirm interactive elements have clear focus and labels. - Describe keyboard-only navigation paths for core flows. - - - Accessibility gaps affecting task completion. - - - - - Analyze responsive design and mobile experience - - Breakpoint definitions - Mobile-specific components - Touch event handlers - Viewport configurations - Media queries - - - Summarize layout changes across breakpoints that alter workflow. - Note touch targets and gestures required on mobile. - - - Table of key differences per breakpoint. - - - - - - - Understand feature entry points and control flow - - Identify main functions, controllers, or route handlers. - Trace execution and decision branches. - Document input validation and preconditions. - - - Entry points list and short purpose statements. - Decision matrix or flow sketch. - - - - - Extract API specifications from code - - - - HTTP method and route path - Path/query parameters - Request/response schemas - Status codes and error bodies - - - - - Schema and input types - Resolvers and return types - Field arguments and constraints - - - - - - - Map dependencies and integration points - - Imports and module boundaries - Package and runtime dependencies - External API/SDK usage - DB connections and migrations - Messaging/queue/event streams - Filesystem or network side effects - - - Dependency graph summary and hot spots. - List of external integrations and auth methods. - - - - - Extract data models, schemas, and type definitions - - - - interfaces, types, classes, enums - - - - Schema definitions, migration files, ORM models - - - - JSON Schema, Joi/Yup/Zod schemas, validation decorators - - - - Canonical definitions and field constraints. - Entity relationships and ownership. - - - - - Identify and document business rules - - Complex conditionals - Calculation functions - Validation rules - State machines - Domain-specific constants and algorithms - - - Why the logic exists (business need) - When the logic applies (conditions) - What the logic does (transformation) - Edge cases and invariants - Impact of changes - - - - - Document error handling and recovery - - try/catch blocks and error boundaries - Custom error classes and codes - Logging, fallbacks, retries, circuit breakers - - - Error taxonomy and user-facing messages. - Recovery/rollback strategies and timeouts. - - - - - Identify security measures and vulnerabilities - - JWT, sessions, OAuth, API keys - RBAC, permission checks, ownership validation - Encryption, hashing, sensitive data handling - Sanitization and injection prevention - - - Threat surfaces and mitigations relevant to the feature. - - - - - Identify performance factors and optimization opportunities - - Expensive loops/algorithms - DB query patterns (e.g., N+1) - Caching strategies - Concurrency and async usage - Batching and resource pooling - Memory management and object lifetimes - - - Time/space complexity - DB query counts - API response times - Memory usage - Concurrency handling - - - - - Assess test coverage at a useful granularity - - - Function-level coverage and edge cases - - - Workflow coverage and contract boundaries - - - Endpoint success/failure paths and schemas - - - - List of critical behaviors missing tests. - - - - - Extract configuration options and their impacts - - .env files, config files, CLI args, feature flags - - - Default values and valid ranges - Behavioral impact of each option - Dependencies between options - Security implications - - - - - - - Map user workflows through the feature - - Identify entry points (UI, API, CLI) - Trace user actions and decision points - Map data transformations - Identify outcomes and completion criteria - - - Flow diagrams, procedures, decision trees, state diagrams - - - - - Document integration with other systems - - Sync API calls, async messaging, events, batch processing, streaming - - - Protocols, auth, error handling, data transforms, SLAs - - - - - - - Summarize version constraints and compatibility - - package manifests, READMEs, migration guides, breaking changes docs - - - Minimum/recommended versions and notable constraints. - - - - - Track deprecations and migrations - - Explicit deprecation notices and TODO markers - Legacy code paths and adapters - - - Deprecation date and removal timeline - Migration path and alternatives - - - - - - - - Public APIs documented with inputs/outputs and errors - Examples for complex features - Error scenarios covered with recovery guidance - Config options explained with defaults and impacts - Security considerations addressed - - - - - Cyclomatic complexity - Code duplication - Test coverage and gaps - Documentation coverage for user-visible behaviors - Known technical debt affecting UX - - - - \ No newline at end of file diff --git a/.roo/rules-docs-extractor/3_output_format.xml b/.roo/rules-docs-extractor/3_output_format.xml new file mode 100644 index 00000000000..185f7b23b80 --- /dev/null +++ b/.roo/rules-docs-extractor/3_output_format.xml @@ -0,0 +1,133 @@ + + + Structured data output formats for extraction and verification. + All output is YAML. No prose. No markdown formatting. + This data feeds into documentation-writer mode. + + + + Schema for EXTRACT-[feature].yaml files + + + + + Schema for VERIFY-[feature].yaml files + + + + + Use YAML, not JSON or markdown + Include source file:line for every fact + Quote exact strings from code using double quotes + Use null for unknown/missing values, not empty strings + Keep descriptions factual and brief - one line max + Do NOT add commentary, suggestions, or explanations + + + + EXTRACT-[feature-slug].yaml + VERIFY-[feature-slug].yaml + .roo/extraction/ + + \ No newline at end of file diff --git a/.roo/rules-docs-extractor/4_communication_guidelines.xml b/.roo/rules-docs-extractor/4_communication_guidelines.xml deleted file mode 100644 index 43ec8479fc6..00000000000 --- a/.roo/rules-docs-extractor/4_communication_guidelines.xml +++ /dev/null @@ -1,298 +0,0 @@ - - - Guidelines for user communication and output formatting. - - - - - Act on the user's request immediately. - Only ask for clarification if the request is ambiguous. - - - - - Multiple features with similar names are found. - The request is ambiguous. - The user explicitly asks for options. - - - - - - - Starting a major analysis phase. - Extraction is complete. - Unexpected complexity is found. - - - - - - - - - - - Alert user to security concerns found during analysis. - - - Note deprecated features needing migration docs. - - - Highlight code that lacks inline documentation. - - - Warn about complex dependency chains. - - - - - - - - - - - - - - - Use # for main title, ## for major sections, ### for subsections. - Never skip heading levels. - - - - Always specify language for syntax highlighting (e.g., typescript, json, bash). - Include file paths as comments where relevant. - -```typescript -// src/auth/auth.service.ts -export class AuthService { - async validateUser(email: string, password: string): Promise { - // Implementation - } -} -``` - - - - - Use tables for structured data like configs. - Include headers and align columns. - Keep cell content brief. - -| Variable | Type | Default | Description | -|----------|------|---------|-------------| -| `JWT_SECRET` | string | - | Secret key for JWT signing | -| `JWT_EXPIRATION` | string | '15m' | Token expiration time | - - - - - Use bullets for unordered lists, numbers for sequential steps. - Keep list items parallel in structure. - - - - - - [Link text](#section-anchor) - Use lowercase, hyphenated anchors. Test all links. - - - - [Link text](https://example.com) - Use HTTPS. Link to official docs. - - - - `path/to/file.ts` - Use relative paths from project root, in backticks. - - - - - - - > ⚠️ **Warning**: [message] - Security, breaking changes, deprecations. - - - > 📝 **Note**: [message] - Important info, clarifications. - - - > 💡 **Tip**: [message] - Best practices, optimizations. - - - - - ---- -Feature: Authentication System -Version: 2.1.0 -Last Updated: 2024-01-15 -Status: Stable ---- - - - - - - - - Be direct, not conversational. - Use active voice. - Lead with benefits. - Use concrete examples. - Keep paragraphs short. - Avoid unnecessary technical details. - - - - - Technical and direct. - Standard programming terms. - Code snippets, implementation details. - - - Instructional, step-by-step. - Simple language, no jargon. - Screenshots, real-world scenarios. - - - - - - - Summary of analysis performed. - Key findings or issues identified. - Report file location. - Recommended next steps. - - - -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. - - - -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. - - - - - - - - Could not find a feature matching "[feature name]". Similar features found: - - [List similar features] - Document one of these instead? - - - - - - Code for [feature] has limited inline documentation. Extracting from code structure, tests, and usage patterns. - - - - - - This feature is complex. Choose documentation scope: - - Document comprehensively - - Focus on core functionality - - Split into multiple documents - - - - - - - - No placeholder content remains. - Code examples are correct. - Links and cross-references work. - Tables are formatted correctly. - Version info is included. - Filename follows conventions. - - - \ No newline at end of file diff --git a/.roo/rules-integration-tester/1_workflow.xml b/.roo/rules-integration-tester/1_workflow.xml deleted file mode 100644 index b0ebc535e2b..00000000000 --- a/.roo/rules-integration-tester/1_workflow.xml +++ /dev/null @@ -1,198 +0,0 @@ - - - Understand Test Requirements - - Use ask_followup_question to determine what type of integration test is needed: - - - What type of integration test would you like me to create or work on? - - New E2E test for a specific feature or workflow - Fix or update an existing integration test - Create test utilities or helpers for common patterns - Debug failing integration tests - - - - - - - Gather Test Specifications - - Based on the test type, gather detailed requirements: - - For New E2E Tests: - - What specific user workflow or feature needs testing? - - What are the expected inputs and outputs? - - What edge cases or error scenarios should be covered? - - Are there specific API interactions to validate? - - What events should be monitored during the test? - - For Existing Test Issues: - - Which test file is failing or needs updates? - - What specific error messages or failures are occurring? - - What changes in the codebase might have affected the test? - - For Test Utilities: - - What common patterns are being repeated across tests? - - What helper functions would improve test maintainability? - - Use multiple ask_followup_question calls if needed to gather complete information. - - - - - Explore Existing Test Patterns - - Use codebase_search FIRST to understand existing test patterns and similar functionality: - - For New Tests: - - Search for similar test scenarios in apps/vscode-e2e/src/suite/ - - Find existing test utilities and helpers - - Identify patterns for the type of functionality being tested - - For Test Fixes: - - Search for the failing test file and related code - - Find similar working tests for comparison - - Look for recent changes that might have broken the test - - Example searches: - - "file creation test mocha" for file operation tests - - "task completion waitUntilCompleted" for task monitoring patterns - - "api message validation" for API interaction tests - - After codebase_search, use: - - read_file on relevant test files to understand structure - - list_code_definition_names on test directories - - search_files for specific test patterns or utilities - - - - - Analyze Test Environment and Setup - - Examine the test environment configuration: - - 1. Read the test runner configuration: - - apps/vscode-e2e/package.json for test scripts - - apps/vscode-e2e/src/runTest.ts for test setup - - Any test configuration files - - 2. Understand the test workspace setup: - - How test workspaces are created - - What files are available during tests - - How the extension API is accessed - - 3. Review existing test utilities: - - Helper functions for common operations - - Event listening patterns - - Assertion utilities - - Cleanup procedures - - Document findings including: - - Test environment structure - - Available utilities and helpers - - Common patterns and best practices - - - - - Design Test Structure - - Plan the test implementation based on gathered information: - - For New Tests: - - Define test suite structure with suite/test blocks - - Plan setup and teardown procedures - - Identify required test data and fixtures - - Design event listeners and validation points - - Plan for both success and failure scenarios - - For Test Fixes: - - Identify the root cause of the failure - - Plan the minimal changes needed to fix the issue - - Consider if the test needs to be updated due to code changes - - Plan for improved error handling or debugging - - Create a detailed test plan including: - - Test file structure and organization - - Required setup and cleanup - - Specific assertions and validations - - Error handling and edge cases - - - - - Implement Test Code - - Implement the test following established patterns: - - CRITICAL: Never write a test file with a single write_to_file call. - Always implement tests in parts: - - 1. Start with the basic test structure (suite, setup, teardown) - 2. Add individual test cases one by one - 3. Implement helper functions separately - 4. Add event listeners and validation logic incrementally - - Follow these implementation guidelines: - - Use suite() and test() blocks following Mocha TDD style - - Always use the global api object for extension interactions - - Implement proper async/await patterns with waitFor utility - - Use waitUntilCompleted and waitUntilAborted helpers for task monitoring - - Listen to and validate appropriate events (message, taskCompleted, etc.) - - Test both positive flows and error scenarios - - Validate message content using proper type assertions - - Create reusable test utilities when patterns emerge - - Use meaningful test descriptions that explain the scenario - - Always clean up tasks with cancelCurrentTask or clearCurrentTask - - Ensure tests are independent and can run in any order - - - - - Run and Validate Tests - - Execute the tests to ensure they work correctly: - - ALWAYS use the correct working directory and commands: - - Working directory: apps/vscode-e2e - - Test command: npm run test:run - - For specific tests: TEST_FILE="filename.test" npm run test:run - - Example: cd apps/vscode-e2e && TEST_FILE="apply-diff.test" npm run test:run - - Test execution process: - 1. Run the specific test file first - 2. Check for any failures or errors - 3. Analyze test output and logs - 4. Debug any issues found - 5. Re-run tests after fixes - - If tests fail: - - Add console.log statements to track execution flow - - Log important events like task IDs, file paths, and AI responses - - Check test output carefully for error messages and stack traces - - Verify file creation in correct workspace directories - - Ensure proper event handling and timeouts - - - - - Document and Complete - - Finalize the test implementation: - - 1. Add comprehensive comments explaining complex test logic - 2. Document any new test utilities or patterns created - 3. Ensure test descriptions clearly explain what is being tested - 4. Verify all cleanup procedures are in place - 5. Confirm tests can run independently and in any order - - Provide the user with: - - Summary of tests created or fixed - - Instructions for running the tests - - Any new patterns or utilities that can be reused - - Recommendations for future test improvements - - - \ No newline at end of file diff --git a/.roo/rules-integration-tester/2_test_patterns.xml b/.roo/rules-integration-tester/2_test_patterns.xml deleted file mode 100644 index 62bef1631bb..00000000000 --- a/.roo/rules-integration-tester/2_test_patterns.xml +++ /dev/null @@ -1,303 +0,0 @@ - - - Standard Mocha TDD structure for integration tests - - Basic Test Suite Structure - - ```typescript - import { suite, test, suiteSetup, suiteTeardown } from 'mocha'; - import * as assert from 'assert'; - import * as vscode from 'vscode'; - import { waitFor, waitUntilCompleted, waitUntilAborted } from '../utils/testUtils'; - - suite('Feature Name Tests', () => { - let testWorkspaceDir: string; - let testFiles: { [key: string]: string } = {}; - - suiteSetup(async () => { - // Setup test workspace and files - testWorkspaceDir = vscode.workspace.workspaceFolders![0].uri.fsPath; - // Create test files in workspace - }); - - suiteTeardown(async () => { - // Cleanup test files and tasks - await api.cancelCurrentTask(); - }); - - test('should perform specific functionality', async () => { - // Test implementation - }); - }); - ``` - - - - - Event Listening Pattern - - ```typescript - test('should handle task completion events', async () => { - const events: any[] = []; - - const messageListener = (message: any) => { - events.push({ type: 'message', data: message }); - }; - - const taskCompletedListener = (result: any) => { - events.push({ type: 'taskCompleted', data: result }); - }; - - api.onDidReceiveMessage(messageListener); - api.onTaskCompleted(taskCompletedListener); - - try { - // Perform test actions - await api.startTask('test prompt'); - await waitUntilCompleted(); - - // Validate events - assert(events.some(e => e.type === 'taskCompleted')); - } finally { - // Cleanup listeners - api.onDidReceiveMessage(() => {}); - api.onTaskCompleted(() => {}); - } - }); - ``` - - - - - File Creation Test Pattern - - ```typescript - test('should create files in workspace', async () => { - const fileName = 'test-file.txt'; - const expectedContent = 'test content'; - - await api.startTask(`Create a file named ${fileName} with content: ${expectedContent}`); - await waitUntilCompleted(); - - // Check multiple possible locations - const possiblePaths = [ - path.join(testWorkspaceDir, fileName), - path.join(process.cwd(), fileName), - // Add other possible locations - ]; - - let fileFound = false; - let actualContent = ''; - - for (const filePath of possiblePaths) { - if (fs.existsSync(filePath)) { - actualContent = fs.readFileSync(filePath, 'utf8'); - fileFound = true; - break; - } - } - - assert(fileFound, `File ${fileName} not found in any expected location`); - assert.strictEqual(actualContent.trim(), expectedContent); - }); - ``` - - - - - - - Basic Task Execution - - ```typescript - // Start a task and wait for completion - await api.startTask('Your prompt here'); - await waitUntilCompleted(); - ``` - - - - - Task with Auto-Approval Settings - - ```typescript - // Enable auto-approval for specific actions - await api.updateSettings({ - alwaysAllowWrite: true, - alwaysAllowExecute: true - }); - - await api.startTask('Create and execute a script'); - await waitUntilCompleted(); - ``` - - - - - Message Validation - - ```typescript - const messages: any[] = []; - api.onDidReceiveMessage((message) => { - messages.push(message); - }); - - await api.startTask('test prompt'); - await waitUntilCompleted(); - - // Validate specific message types - const toolMessages = messages.filter(m => - m.type === 'say' && m.say === 'api_req_started' - ); - assert(toolMessages.length > 0, 'Expected tool execution messages'); - ``` - - - - - - - Task Abortion Handling - - ```typescript - test('should handle task abortion', async () => { - await api.startTask('long running task'); - - // Abort after short delay - setTimeout(() => api.abortTask(), 1000); - - await waitUntilAborted(); - - // Verify task was properly aborted - const status = await api.getTaskStatus(); - assert.strictEqual(status, 'aborted'); - }); - ``` - - - - - Error Message Validation - - ```typescript - test('should handle invalid input gracefully', async () => { - const errorMessages: any[] = []; - - api.onDidReceiveMessage((message) => { - if (message.type === 'error' || message.text?.includes('error')) { - errorMessages.push(message); - } - }); - - await api.startTask('invalid prompt that should fail'); - await waitFor(() => errorMessages.length > 0, 5000); - - assert(errorMessages.length > 0, 'Expected error messages'); - }); - ``` - - - - - - - File Location Helper - - ```typescript - function findFileInWorkspace(fileName: string, workspaceDir: string): string | null { - const possiblePaths = [ - path.join(workspaceDir, fileName), - path.join(process.cwd(), fileName), - path.join(os.tmpdir(), fileName), - // Add other common locations - ]; - - for (const filePath of possiblePaths) { - if (fs.existsSync(filePath)) { - return filePath; - } - } - - return null; - } - ``` - - - - - Event Collection Helper - - ```typescript - class EventCollector { - private events: any[] = []; - - constructor(private api: any) { - this.setupListeners(); - } - - private setupListeners() { - this.api.onDidReceiveMessage((message: any) => { - this.events.push({ type: 'message', timestamp: Date.now(), data: message }); - }); - - this.api.onTaskCompleted((result: any) => { - this.events.push({ type: 'taskCompleted', timestamp: Date.now(), data: result }); - }); - } - - getEvents(type?: string) { - return type ? this.events.filter(e => e.type === type) : this.events; - } - - clear() { - this.events = []; - } - } - ``` - - - - - - - Comprehensive Logging - - ```typescript - test('should log execution flow for debugging', async () => { - console.log('Starting test execution'); - - const events: any[] = []; - api.onDidReceiveMessage((message) => { - console.log('Received message:', JSON.stringify(message, null, 2)); - events.push(message); - }); - - console.log('Starting task with prompt'); - await api.startTask('test prompt'); - - console.log('Waiting for task completion'); - await waitUntilCompleted(); - - console.log('Task completed, events received:', events.length); - console.log('Final workspace state:', fs.readdirSync(testWorkspaceDir)); - }); - ``` - - - - - State Validation - - ```typescript - function validateTestState(description: string) { - console.log(`=== ${description} ===`); - console.log('Workspace files:', fs.readdirSync(testWorkspaceDir)); - console.log('Current working directory:', process.cwd()); - console.log('Task status:', api.getTaskStatus?.() || 'unknown'); - console.log('========================'); - } - ``` - - - - \ No newline at end of file diff --git a/.roo/rules-integration-tester/3_best_practices.xml b/.roo/rules-integration-tester/3_best_practices.xml deleted file mode 100644 index e495ea5f0ae..00000000000 --- a/.roo/rules-integration-tester/3_best_practices.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - Always use suite() and test() blocks following Mocha TDD style - - Use descriptive test names that explain the scenario being tested - - Implement proper setup and teardown in suiteSetup() and suiteTeardown() - - Create test files in the VSCode workspace directory during suiteSetup() - - Store file paths in a test-scoped object for easy reference across tests - - Ensure tests are independent and can run in any order - - Clean up all test files and tasks in suiteTeardown() to avoid test pollution - - - - - Always use the global api object for extension interactions - - Implement proper async/await patterns with the waitFor utility - - Use waitUntilCompleted and waitUntilAborted helpers for task monitoring - - Set appropriate auto-approval settings (alwaysAllowWrite, alwaysAllowExecute) for the functionality being tested - - Listen to and validate appropriate events (message, taskCompleted, taskAborted, etc.) - - Always clean up tasks with cancelCurrentTask or clearCurrentTask after tests - - Use meaningful timeouts that account for actual task execution time - - - - - Be aware that files may be created in the workspace directory (/tmp/roo-test-workspace-*) rather than expected locations - - Always check multiple possible file locations when verifying file creation - - Use flexible file location checking that searches workspace directories - - Verify files exist after creation to catch setup issues early - - Account for the fact that the workspace directory is created by runTest.ts - - The AI may use internal tools instead of the documented tools - verify outcomes rather than methods - - - - - Add multiple event listeners (taskStarted, taskCompleted, taskAborted) for better debugging - - Don't rely on parsing AI messages to detect tool usage - the AI's message format may vary - - Use terminal shell execution events (onDidStartTerminalShellExecution, onDidEndTerminalShellExecution) for command tracking - - Tool executions are reported via api_req_started messages with type="say" and say="api_req_started" - - Focus on testing outcomes (files created, commands executed) rather than message parsing - - There is no "tool_result" message type - tool results appear in "completion_result" or "text" messages - - - - - Test both positive flows and error scenarios - - Validate message content using proper type assertions - - Implement proper error handling and edge cases - - Use try-catch blocks around critical test operations - - Log important events like task IDs, file paths, and AI responses for debugging - - Check test output carefully for error messages and stack traces - - - - - Remove unnecessary waits for specific tool executions - wait for task completion instead - - Simplify message handlers to only capture essential error information - - Use the simplest possible test structure that verifies the outcome - - Avoid complex message parsing logic that depends on AI behavior - - Terminal events are more reliable than message parsing for command execution verification - - Keep prompts simple and direct - complex instructions may confuse the AI - - - - - Add console.log statements to track test execution flow - - Log important events like task IDs, file paths, and AI responses - - Use codebase_search first to find similar test patterns before writing new tests - - Create helper functions for common file location checks - - Use descriptive variable names for file paths and content - - Always log the expected vs actual locations when tests fail - - Add comprehensive comments explaining complex test logic - - - - - Create reusable test utilities when patterns emerge - - Implement helper functions for common operations like file finding - - Use event collection utilities for consistent event handling - - Create assertion helpers for common validation patterns - - Document any new test utilities or patterns created - - Share common utilities across test files to reduce duplication - - - - - Keep prompts simple and direct - complex instructions may lead to unexpected behavior - - Allow for variations in how the AI accomplishes tasks - - The AI may not always use the exact tool you specify in the prompt - - Be prepared to adapt tests based on actual AI behavior rather than expected behavior - - The AI may interpret instructions creatively - test results rather than implementation details - - The AI will not see the files in the workspace directory, you must tell it to assume they exist and proceed - - - - - ALWAYS use the correct working directory: apps/vscode-e2e - - The test command is: npm run test:run - - To run specific tests use environment variable: TEST_FILE="filename.test" npm run test:run - - Example: cd apps/vscode-e2e && TEST_FILE="apply-diff.test" npm run test:run - - Never use npm test directly as it doesn't exist - - Always check available scripts with npm run if unsure - - Run tests incrementally during development to catch issues early - - - - - Never write a test file with a single write_to_file tool call - - Always implement tests in parts: structure first, then individual test cases - - Group related tests in the same suite - - Use consistent naming conventions for test files and functions - - Separate test utilities into their own files when they become substantial - - Follow the existing project structure and conventions - - \ No newline at end of file diff --git a/.roo/rules-integration-tester/4_common_mistakes.xml b/.roo/rules-integration-tester/4_common_mistakes.xml deleted file mode 100644 index 88a74736432..00000000000 --- a/.roo/rules-integration-tester/4_common_mistakes.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - Writing a test file with a single write_to_file tool call instead of implementing in parts - - Not using proper Mocha TDD structure with suite() and test() blocks - - Forgetting to implement suiteSetup() and suiteTeardown() for proper cleanup - - Creating tests that depend on each other or specific execution order - - Not cleaning up tasks and files after test completion - - Using describe/it blocks instead of the required suite/test blocks - - - - - Not using the global api object for extension interactions - - Forgetting to set auto-approval settings (alwaysAllowWrite, alwaysAllowExecute) when testing functionality that requires user approval - - Not implementing proper async/await patterns with waitFor utilities - - Using incorrect timeout values that are too short for actual task execution - - Not properly cleaning up tasks with cancelCurrentTask or clearCurrentTask - - Assuming the AI will use specific tools instead of testing outcomes - - - - - Assuming files will be created in the expected location without checking multiple paths - - Not accounting for the workspace directory being created by runTest.ts - - Creating test files in temporary directories instead of the VSCode workspace directory - - Not verifying files exist after creation during setup - - Forgetting that the AI may not see files in the workspace directory - - Not using flexible file location checking that searches workspace directories - - - - - Relying on parsing AI messages to detect tool usage instead of using proper event listeners - - Expecting tool results in "tool_result" message type (which doesn't exist) - - Not listening to terminal shell execution events for command tracking - - Depending on specific message formats that may vary - - Not implementing proper event cleanup after tests - - Parsing complex AI conversation messages instead of focusing on outcomes - - - - - Using npm test instead of npm run test:run - - Not using the correct working directory (apps/vscode-e2e) - - Running tests from the wrong directory - - Not checking available scripts with npm run when unsure - - Forgetting to use TEST_FILE environment variable for specific tests - - Not running tests incrementally during development - - - - - Not adding sufficient logging to track test execution flow - - Not logging important events like task IDs, file paths, and AI responses - - Not using codebase_search to find similar test patterns before writing new tests - - Not checking test output carefully for error messages and stack traces - - Not validating test state at critical points - - Assuming test failures are due to code issues without checking test logic - - - - - Using complex instructions that may confuse the AI - - Expecting the AI to use exact tools specified in prompts - - Not allowing for variations in how the AI accomplishes tasks - - Testing implementation details instead of outcomes - - Not adapting tests based on actual AI behavior - - Forgetting to tell the AI to assume files exist in the workspace directory - - - - - Adding unnecessary waits for specific tool executions - - Using complex message parsing logic that depends on AI behavior - - Not using the simplest possible test structure - - Depending on specific AI message formats - - Not using terminal events for reliable command execution verification - - Making tests too brittle by depending on exact AI responses - - - - - Not understanding that files may be created in /tmp/roo-test-workspace-* directories - - Assuming the AI can see files in the workspace directory - - Not checking multiple possible file locations when verifying creation - - Creating files outside the VSCode workspace during tests - - Not properly setting up the test workspace in suiteSetup() - - Forgetting to clean up workspace files in suiteTeardown() - - - - - Expecting specific message types for tool execution results - - Not understanding that ClineMessage types have specific values - - Trying to parse tool execution from AI conversation messages - - Not checking packages/types/src/message.ts for valid message types - - Depending on message parsing instead of outcome verification - - Not using api_req_started messages to verify tool execution - - - - - Using timeouts that are too short for actual task execution - - Not accounting for AI processing time in test timeouts - - Waiting for specific tool executions instead of task completion - - Not implementing proper retry logic for flaky operations - - Using fixed delays instead of condition-based waiting - - Not considering that some operations may take longer in CI environments - - - - - Not creating test files in the correct workspace directory - - Using hardcoded paths that don't work across different environments - - Not storing file paths in test-scoped objects for easy reference - - Creating test data that conflicts with other tests - - Not cleaning up test data properly after tests complete - - Using test data that's too complex for the AI to handle reliably - - \ No newline at end of file diff --git a/.roo/rules-integration-tester/5_test_environment.xml b/.roo/rules-integration-tester/5_test_environment.xml deleted file mode 100644 index 8e872b1dfc4..00000000000 --- a/.roo/rules-integration-tester/5_test_environment.xml +++ /dev/null @@ -1,209 +0,0 @@ - - - VSCode E2E testing framework using Mocha and VSCode Test - - - Mocha TDD framework for test structure - - VSCode Test framework for extension testing - - Custom test utilities and helpers - - Event-driven testing patterns - - Workspace-based test execution - - - - - apps/vscode-e2e/src/suite/ - apps/vscode-e2e/src/utils/ - apps/vscode-e2e/src/runTest.ts - apps/vscode-e2e/package.json - packages/types/ - - - - apps/vscode-e2e - - npm run test:run - TEST_FILE="filename.test" npm run test:run - cd apps/vscode-e2e && TEST_FILE="apply-diff.test" npm run test:run - npm run - - - - Never use npm test directly as it doesn't exist - - Always use the correct working directory - - Use TEST_FILE environment variable for specific tests - - Check available scripts with npm run if unsure - - - - - Global api object for extension interactions - - - - api.startTask(prompt: string): Start a new task - - api.cancelCurrentTask(): Cancel the current task - - api.clearCurrentTask(): Clear the current task - - api.abortTask(): Abort the current task - - api.getTaskStatus(): Get current task status - - - - api.onDidReceiveMessage(callback): Listen to messages - - api.onTaskCompleted(callback): Listen to task completion - - api.onTaskAborted(callback): Listen to task abortion - - api.onTaskStarted(callback): Listen to task start - - api.onDidStartTerminalShellExecution(callback): Terminal start events - - api.onDidEndTerminalShellExecution(callback): Terminal end events - - - - api.updateSettings(settings): Update extension settings - - api.getSettings(): Get current settings - - - - - - - - Wait for a condition to be true - await waitFor(() => condition, timeout) - await waitFor(() => fs.existsSync(filePath), 5000) - - - Wait until current task is completed - await waitUntilCompleted() - Default timeout for task completion - - - Wait until current task is aborted - await waitUntilAborted() - Default timeout for task abortion - - - - - - Helper to find files in multiple possible locations - Use when files might be created in different workspace directories - - - Utility to collect and analyze events during test execution - Use for comprehensive event tracking and validation - - - Custom assertion functions for common test patterns - Use for consistent validation across tests - - - - - - - Test workspaces are created by runTest.ts - /tmp/roo-test-workspace-* - vscode.workspace.workspaceFolders![0].uri.fsPath - - - - Create all test files in suiteSetup() before any tests run - Always create files in the VSCode workspace directory - Verify files exist after creation to catch setup issues early - Clean up all test files in suiteTeardown() to avoid test pollution - Store file paths in a test-scoped object for easy reference - - - - The AI will not see the files in the workspace directory - Tell the AI to assume files exist and proceed as if they do - Always verify outcomes rather than relying on AI file visibility - - - - - Understanding message types for proper event handling - Check packages/types/src/message.ts for valid message types - - - - say - api_req_started - Indicates tool execution started - JSON with tool name and execution details - Most reliable way to verify tool execution - - - - Contains tool execution results - Tool results appear here, not in "tool_result" type - - - - General AI conversation messages - Format may vary, don't rely on parsing these for tool detection - - - - - - Settings to enable automatic approval of AI actions - - Enable for file creation/modification tests - Enable for command execution tests - Enable for browser-related tests - - - ```typescript - await api.updateSettings({ - alwaysAllowWrite: true, - alwaysAllowExecute: true - }); - ``` - - Without proper auto-approval settings, the AI won't be able to perform actions without user approval - - - - - Use console.log for tracking test execution flow - - - Log test phase transitions - - Log important events and data - - Log file paths and workspace state - - Log expected vs actual outcomes - - - - - Helper functions to validate test state at critical points - - - Workspace file listing - - Current working directory - - Task status - - Event counts - - - - - Tools for analyzing test failures - - - Stack trace analysis - - Event timeline reconstruction - - File system state comparison - - Message flow analysis - - - - - - - Appropriate timeout values for different operations - Use generous timeouts for task completion (30+ seconds) - Shorter timeouts for file system operations (5-10 seconds) - Medium timeouts for event waiting (10-15 seconds) - - - - Proper cleanup to avoid resource leaks - Always clean up event listeners after tests - Cancel or clear tasks in teardown - Remove test files to avoid disk space issues - - - \ No newline at end of file diff --git a/.roo/rules-issue-investigator/1_workflow.xml b/.roo/rules-issue-investigator/1_workflow.xml index 561b2751202..4d2528e7753 100644 --- a/.roo/rules-issue-investigator/1_workflow.xml +++ b/.roo/rules-issue-investigator/1_workflow.xml @@ -70,7 +70,7 @@ Draft Comment - Draft a comment for the GitHub issue that explains your findings and suggested solution in a conversational, human-like tone. + 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,". diff --git a/.roo/rules-issue-investigator/2_best_practices.xml b/.roo/rules-issue-investigator/2_best_practices.xml index 31ad2c22678..1445822ccdd 100644 --- a/.roo/rules-issue-investigator/2_best_practices.xml +++ b/.roo/rules-issue-investigator/2_best_practices.xml @@ -52,6 +52,7 @@ Does the draft comment sound conversational and human? + Does the draft comment start with "Hey @roomote-agent,"? Have I avoided technical jargon where possible? Is the tone helpful and not condescending? diff --git a/.roo/rules-issue-investigator/4_tool_usage.xml b/.roo/rules-issue-investigator/4_tool_usage.xml index c43c41a8c36..f34f57f5ffd 100644 --- a/.roo/rules-issue-investigator/4_tool_usage.xml +++ b/.roo/rules-issue-investigator/4_tool_usage.xml @@ -23,10 +23,16 @@ Use `gh issue view [URL] --json title,body,labels,comments` to fetch initial details. Use `gh issue comment [URL] --body "..."` to add comments, but only after explicit user approval. Always wrap the comment body in quotes to handle special characters. + When posting a comment, the body must start with "Hey @roomote-agent," exactly. gh issue view https://github.com/RooCodeInc/Roo-Code/issues/123 --json title,body + + ]]> + +gh issue comment https://github.com/RooCodeInc/Roo-Code/issues/123 --body "Hey @roomote-agent, I've investigated and proposed a theoretical fix above." ]]> diff --git a/.roo/rules-issue-investigator/5_examples.xml b/.roo/rules-issue-investigator/5_examples.xml index dbd4ae2f23c..af417e3e69d 100644 --- a/.roo/rules-issue-investigator/5_examples.xml +++ b/.roo/rules-issue-investigator/5_examples.xml @@ -70,7 +70,7 @@ Formulate a solution and draft a comment. -"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." diff --git a/.roo/rules-issue-investigator/6_communication.xml b/.roo/rules-issue-investigator/6_communication.xml index 348ecf18782..6ed68c0043b 100644 --- a/.roo/rules-issue-investigator/6_communication.xml +++ b/.roo/rules-issue-investigator/6_communication.xml @@ -2,18 +2,20 @@ Be conversational and helpful, not robotic. Write comments as if you are a human developer collaborating on the project. + Always start any GitHub issue comment body with "Hey @roomote-agent,". Analysis complete. The investigation has yielded the following result. + Starting comments with "Hey," instead of "Hey @roomote-agent,". - Hey, I took a look at this and found something interesting... - I've been digging into this issue, and I think I've found a possible cause. + Hey @roomote-agent, I took a look at this and found something interesting... + Hey @roomote-agent, I've been digging into this issue, and I think I've found a possible cause. - Start with a friendly opening. + Start every GitHub issue comment with "Hey @roomote-agent,". State your main finding or hypothesis clearly but not definitively. Provide context, like file paths and function names. Propose a next step or a theoretical solution. diff --git a/.roo/rules-issue-writer/1_workflow.xml b/.roo/rules-issue-writer/1_workflow.xml index 99ef7db5d9d..0dc2e279d2a 100644 --- a/.roo/rules-issue-writer/1_workflow.xml +++ b/.roo/rules-issue-writer/1_workflow.xml @@ -1,1161 +1,391 @@ + + This mode focuses solely on assembling a template-free GitHub issue prompt for an AI coding agent. + It integrates codebase exploration to ground the prompt in reality while keeping the output non-technical. + It also captures the user-facing value/impact (who is affected, how often, and why it matters) to support prioritization, all in plain language. + + + + + - Codebase exploration is iterative and may repeat as many times as needed based on user-agent back-and-forth. + - Early-stop and escalate-once apply per iteration; when new info arrives, start a fresh iteration. + - One-tool-per-message is respected; narrate succinct progress and update TODOs each iteration. + + + - New details from the user (environment, steps, screenshots, constraints) + - Clarifications that change scope or target component/feature + - Discrepancies found between user claims and code + - Reclassification between Bug and Enhancement + + + + + - Treat the user's FIRST message as the issue description; do not ask if they want to create an issue. + - Begin immediately: initialize a focused TODO list and start repository detection before discovery. + - CLI submission via gh happens only after the user confirms during the merged review/submit step. + + + + [ ] 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) + + + + + - Initialize Issue Creation Process + Kickoff - IMPORTANT: This mode assumes the first user message is already a request to create an issue. - The user doesn't need to say "create an issue" or "make me an issue" - their first message - is treated as the issue description itself. - - When the session starts, immediately: - 1. Treat the user's first message as the issue description - 2. Initialize the workflow by using the update_todo_list tool - 3. Begin the issue creation process without asking what they want to do - - - - [ ] 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 - - + Rephrase the user's goal and outline a brief plan, then proceed without delay. + Maintain low narrative verbosity; use structured outputs for details. - - - - Detect current repository information - - CRITICAL FIRST STEP: Verify we're in a git repository and get repository information. - - 1. Check if we're in a git repository: - - git rev-parse --is-inside-work-tree 2>/dev/null || echo "not-git-repo" - - - If the output is "not-git-repo", immediately stop and inform the user: - - - - This mode must be run from within a GitHub repository. Please navigate to a git repository and try again. - - - - 2. If in a git repository, get the repository information: - - git remote get-url origin 2>/dev/null | sed -E 's/.*[:/]([^/]+)\/([^/]+)(\.git)?$/\1\/\2/' | sed 's/\.git$//' - - - Store this as REPO_FULL_NAME for use throughout the workflow. - - If no origin remote exists, stop with: - - - No GitHub remote found. This mode requires a GitHub repository with an 'origin' remote configured. - - - - Update todo after detecting repository: - - - [x] 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 - - - - - - Determine Repository Structure - - Check if this is a monorepo or standard repository by looking for common patterns. - - First, check for monorepo indicators: - 1. Look for workspace configuration: - - package.json with "workspaces" field - - lerna.json - - pnpm-workspace.yaml - - rush.json - - 2. Check for common monorepo directory patterns: - - . - false - - - Look for directories like: - - apps/ (application packages) - - packages/ (shared packages) - - services/ (service packages) - - libs/ (library packages) - - modules/ (module packages) - - src/ (main source if not using workspaces) - - If monorepo detected: - - Dynamically discover packages by looking for package.json files in detected directories - - Build a list of available packages with their paths - - Based on the user's description, try to identify which package they're referring to. - If unclear, ask for clarification: - - - I see this is a monorepo with multiple packages. Which specific package or application is your issue related to? - - [Dynamically generated list of discovered packages] - Let me describe which package: [specify] - - - - If standard repository: - - Skip package selection - - Use repository root for all searches - - Store the repository context for all future codebase searches and explorations. - - Update todo after determining context: - - - [x] Detect current repository information - [x] 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 - - - - - - - Perform Initial Codebase Discovery - - Now that we know the repository structure, immediately search the codebase to understand - what the user is talking about before determining the issue type. - - DISCOVERY ACTIVITIES: - - 1. Extract keywords and concepts from the user's INITIAL MESSAGE (their issue description) - 2. Search the codebase to verify these concepts exist - 3. Build understanding of the actual implementation - 4. Identify relevant files, components, and code patterns - - - [Keywords from user's initial message/description] - [Repository or package path from step 2] - - - Additional searches based on initial findings: - - If error mentioned: search for exact error strings - - If feature mentioned: search for related functionality - - If component mentioned: search for implementation details - - - [repository or package path] - [specific patterns found in initial search] - - - Document findings: - - Components/features found that match user's description - - Actual implementation details discovered - - Related code sections identified - - Any discrepancies between user description and code reality - - Update todos: - - - [x] Detect current repository information - [x] Determine repository structure (monorepo/standard) - [x] 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 - - - - - - - Analyze Request to Determine Issue Type - - Using the codebase discoveries from step 2, analyze the user's request to determine - the appropriate issue type with informed context. - - CRITICAL GUIDANCE FOR ISSUE TYPE SELECTION: - For issues that affect user workflows or require behavior changes: - - PREFER the feature proposal template over bug report - - Focus on explaining WHO is affected and WHEN this happens - - Describe the user impact before diving into technical details - - Based on your findings, classify the issue: - - Bug indicators (verified against code): - - Error messages that match actual error handling in code - - Broken functionality in existing features found in codebase - - Regression from previous behavior documented in code/tests - - Code paths that don't work as documented - - Feature indicators (verified against code): - - New functionality not found in current codebase - - Enhancement to existing features found in code - - Missing capabilities compared to similar features - - Integration points that could be extended - - WORKFLOW IMPROVEMENTS: When existing behavior works but doesn't meet user needs - - IMPORTANT: Use your codebase findings to inform the question: - - - Based on your request about [specific feature/component found in code], what type of issue would you like to create? - - [Order based on codebase findings and user description] - Bug Report - [Specific component] is not working as expected - Feature Proposal - Add [specific capability] to [existing component] - - - - Update todos: - - - [x] Detect current repository information - [x] Determine repository structure (monorepo/standard) - [x] Perform initial codebase discovery - [x] 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 - - - - - - - Gather and Verify Additional Information - - Based on the issue type and initial codebase discovery, gather information while - continuously verifying against the actual code implementation. - - CRITICAL FOR FEATURE REQUESTS: Be fact-driven and challenge assumptions! - When users describe current behavior as problematic for a feature request, you MUST verify - their claims against the actual code. If their description doesn't match reality, this - might actually be a bug report, not a feature request. - - For Bug Reports: - 1. When user describes steps to reproduce: - - Search for the UI components/commands mentioned - - Verify the code paths that would be executed - - Check for existing error handling or known issues - - 2. When user provides error messages: - - Search for exact error strings in codebase - - Find where errors are thrown - - Understand the conditions that trigger them - - 3. For version information: - - Check package.json for actual version - - Look for version-specific code or migrations - - Example verification searches: - - [repository or package path] - [exact error message from user] - - - - [feature or component name] implementation - [repository or package path] - - - For Feature Requests - AGGRESSIVE VERIFICATION WITH CONCRETE EXAMPLES: - 1. When user claims current behavior is X: - - ALWAYS search for the actual implementation - - Read the relevant code to verify their claim - - Check CSS/styling files if UI-related - - Look at configuration files - - Examine test files to understand expected behavior - - TRACE THE DATA FLOW: Follow values from where they're calculated to where they're used - - 2. CRITICAL: Look for existing variables/code that could be reused: - - Search for variables that are calculated but not used where expected - - Identify existing patterns that could be extended - - Find similar features that work correctly for comparison - - 3. If discrepancy found between claim and code: - - Do NOT proceed without clarification - - Present CONCRETE before/after examples with actual values - - Show exactly what happens vs what should happen - - Ask if this might be a bug instead - - Example verification approach: - User says: "Feature X doesn't work properly" - - Your investigation should follow this pattern: - a) What is calculated: Search for where X is computed/defined - b) Where it's stored: Find variables/state holding the value - c) Where it's used: Trace all usages of that value - d) What's missing: Identify gaps in the flow - - Present findings with concrete examples: - - - I investigated the implementation and found something interesting: - - Current behavior: - - The value is calculated at [file:line]: `value = computeX()` - - It's stored in variable `calculatedValue` at [file:line] - - BUT it's only used for [purpose A] at [file:line] - - It's NOT used for [purpose B] where you expected it - - Concrete example: - - When you do [action], the system calculates [value] - - This value goes to [location A] - - But [location B] still uses [old/different value] - - Is this the issue you're experiencing? This seems like the calculated value isn't being used where it should be. - - Yes, exactly! The value is calculated but not used in the right place - No, the issue is that the calculation itself is wrong - Actually, I see now that [location B] should use a different value - - - - 4. Continue verification until facts are established: - - If user confirms it's a bug, switch to bug report workflow - - If user provides more specific context, search again - - Do not accept vague claims without code verification - - 5. For genuine feature requests after verification: - - Document what the code currently does (with evidence and line numbers) - - Show the exact data flow: input → processing → output - - Confirm what the user wants changed with concrete examples - - Ensure the request is based on accurate understanding - - CRITICAL: For feature requests, if user's description doesn't match codebase reality: - - Challenge the assumption with code evidence AND concrete examples - - Show actual vs expected behavior with specific values - - Suggest it might be a bug if code shows different intent - - Ask for clarification repeatedly if needed - - Do NOT proceed until facts are established - - Only proceed when you have: - - Verified current behavior in code with line-by-line analysis - - Confirmed user's understanding matches reality - - Determined if it's truly a feature request or actually a bug - - Identified any existing code that could be reused for the fix - - Update todos after verification: - - - [x] Detect current repository information - [x] Determine repository structure (monorepo/standard) - [x] Perform initial codebase discovery - [x] Analyze user request to determine issue type - [x] 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 - - - - - - - Determine Contribution Intent with Context - - Before asking about contribution, perform a quick technical assessment to provide context: - - 1. Search for complexity indicators: - - Number of files that would need changes - - Existing tests that would need updates - - Dependencies and integration points - - 2. Look for contribution helpers: - - CONTRIBUTING.md guidelines - - Existing similar implementations - - Test patterns to follow - - - CONTRIBUTING guide setup development - - - Based on findings, provide informed context in the question: - - - Based on my analysis, this [issue type] involves [brief complexity assessment from code exploration]. Are you interested in implementing this yourself, or are you reporting it for the project team to handle? - - Just reporting the problem - the project team can design the solution - I want to contribute and implement this myself - I'd like to provide issue scoping to help whoever implements it - - - - Update todos based on response: - - - [x] Detect current repository information - [x] Determine repository structure (monorepo/standard) - [x] Perform initial codebase discovery - [x] Analyze user request to determine issue type - [x] Gather and verify additional information - [x] Determine if user wants to contribute - [If contributing: [-] Perform issue scoping (if contributing)] - [If not contributing: [-] Perform issue scoping (skipped - not contributing)] - [-] Draft issue content - [ ] Review and confirm with user - [ ] Create GitHub issue - - - - - - - Issue Scoping for Contributors - - ONLY perform this step if the user wants to contribute or provide issue scoping. - - This step performs a comprehensive, aggressive investigation to create detailed technical - scoping that can guide implementation. The process involves multiple sub-phases: - - - - Perform an exhaustive investigation to produce a comprehensive technical solution - with extreme detail, suitable for automated fix workflows. - - - - Expand the todo list to include detailed investigation steps - - When starting the issue scoping phase, update the main todo list to include - the detailed investigation steps: - - - - [x] Detect current repository information - [x] Determine repository structure (monorepo/standard) - [x] Perform initial codebase discovery - [x] Analyze user request to determine issue type - [x] Gather and verify additional information - [x] Determine if user wants to contribute - [-] Perform issue scoping (if contributing) - [ ] Extract keywords from the issue description - [ ] Perform initial broad codebase search - [ ] Analyze search results and identify key components - [ ] Deep dive into relevant files and implementations - [ ] Form initial hypothesis about the issue/feature - [ ] Attempt to disprove hypothesis through further investigation - [ ] Identify all affected files and dependencies - [ ] Map out the complete implementation approach - [ ] Document technical risks and edge cases - [ ] Formulate comprehensive technical solution - [ ] Create detailed acceptance criteria - [ ] Prepare issue scoping summary - [ ] Draft issue content - [ ] Review and confirm with user - [ ] Create GitHub issue - - - - - - - Extract all relevant keywords, concepts, and technical terms - - - Identify primary technical concepts from user's description - - Extract error messages or specific symptoms - - Note any mentioned file paths or components - - List related features or functionality - - Include synonyms and related terms - - - Update the main todo list to mark "Extract keywords" as complete and move to next phase - - - - - Perform multiple rounds of increasingly focused searches - - - Use codebase_search with all extracted keywords to get an overview of relevant code. - - [Combined keywords from extraction phase] - [Repository or package path] - - - - - Based on initial results, identify key components and search for: - - Related class/function definitions - - Import statements and dependencies - - Configuration files - - Test files that might reveal expected behavior - - - - Search for specific implementation details: - - Error handling patterns - - State management - - API endpoints or routes - - Database queries or models - - UI components and their interactions - - - - Look for: - - Edge cases in the code - - Integration points with other systems - - Configuration options that affect behavior - - Feature flags or conditional logic - - - - After completing all search iterations, update the todo list to show progress - - - - - Thoroughly analyze all relevant files discovered - - - Use list_code_definition_names to understand file structure - - Read complete files to understand full context - - Trace execution paths through the code - - Identify all dependencies and imports - - Map relationships between components - - - Document findings including: - - File paths and their purposes - - Key functions and their responsibilities - - Data flow through the system - - External dependencies - - Potential impact areas - - - - - Form a comprehensive hypothesis about the issue or feature - - - Identify the most likely root cause - - Trace the bug through the execution path - - Determine why the current implementation fails - - Consider environmental factors - - - - Identify the optimal integration points - - Determine required architectural changes - - Plan the implementation approach - - Consider scalability and maintainability - - - - - Aggressively attempt to disprove the hypothesis - - - - Look for similar features implemented differently - - Check for deprecated code that might interfere - - - - Search for configuration that could change behavior - - Look for environment-specific code paths - - - - Find existing tests that might contradict hypothesis - - Look for test cases that reveal edge cases - - - - Search for comments explaining design decisions - - Look for TODO or FIXME comments related to the area - - - - If hypothesis is disproven, return to search phase with new insights. - If hypothesis stands, proceed to solution formulation. - - - - - Create a comprehensive technical solution - PRIORITIZE SIMPLICITY - - CRITICAL: Before proposing any solution, ask yourself: - 1. What existing variables/functions can I reuse? - 2. What's the minimal change that fixes the issue? - 3. Can I leverage existing patterns in the codebase? - 4. Is there a simpler approach I'm overlooking? - - The best solution often reuses existing code rather than creating new complexity. - - - - ALWAYS consider backwards compatibility: - 1. Will existing data/configurations still work with the new code? - 2. Can we detect and handle legacy formats automatically? - 3. What migration paths are needed for existing users? - 4. Are there ways to make changes additive rather than breaking? - 5. Document any compatibility considerations clearly - - - - FIRST, identify what can be reused: - - Variables that are already calculated but not used where needed - - Functions that already do what we need - - Patterns in similar features we can follow - - Configuration that already exists but isn't applied - - Example finding: - "The variable `calculatedValue` already contains what we need at line X, - we just need to use it at line Y instead of recalculating" - - - - - Start with the SIMPLEST possible fix - - Exact files to modify with line numbers - - Prefer changing variable usage over creating new logic - - Specific code changes required (minimal diff) - - Order of implementation steps - - Migration strategy if needed - - - - - All files that import affected code - - API contracts that must be maintained - - Existing tests that validate current behavior - - Configuration changes required (prefer reusing existing) - - Documentation updates needed - - - - - Unit tests to add or modify - - Integration tests required - - Edge cases to test - - Performance testing needs - - Manual testing scenarios - - - - - Breaking changes identified - - Performance implications - - Security considerations - - Backward compatibility issues - - Rollback strategy - - - - - - Create extremely detailed acceptance criteria - - Given [detailed context including system state] - When [specific user or system action] - Then [exact expected outcome] - And [additional verifiable outcomes] - But [what should NOT happen] - - Include: - - Specific UI changes with exact text/behavior - - API response formats - - Database state changes - - Performance requirements - - Error handling scenarios - - - - Each criterion must be independently testable - - Include both positive and negative test cases - - Specify exact error messages and codes - - Define performance thresholds where applicable - - - - - Format the comprehensive issue scoping section - + Detect Current Repository Information + + Verify we're in a Git repository and capture the GitHub remote for safe submission. -### Proposed Implementation + 1) Check if inside a git repository: + + git rev-parse --is-inside-work-tree 2>/dev/null || echo "not-git-repo" + -#### Step 1: [First implementation step] -- File: `path/to/file.ts` -- Changes: [Specific code changes] -- Rationale: [Why this change is needed] + If the output is "not-git-repo", stop: + + + This mode must be run from within a GitHub repository. Navigate to a git repository and try again. + + -#### Step 2: [Second implementation step] -[Continue for all steps...] + 2) Get origin remote and normalize to OWNER/REPO: + + git remote get-url origin 2>/dev/null | sed -E 's/.*[:/]([^/]+)\/([^/]+)(\.git)?$/\1\/\2/' | sed 's/\.git$//' + -### Code Architecture Considerations -- Design patterns to follow -- Existing patterns in codebase to match -- Architectural constraints + If no origin remote exists, stop: + + + No GitHub 'origin' remote found. Configure a GitHub remote and retry. + + + + Record the normalized OWNER/REPO (e.g., owner/repo) as [OWNER_REPO] to pass via --repo during submission. + + 3) Combined monorepo check and roots discovery (single command): + + set -e; if ! git rev-parse --is-inside-work-tree >/dev/null 2>&1; then echo "not-git-repo"; exit 0; fi; OWNER_REPO=$(git remote get-url origin 2>/dev/null | sed -E 's/.*[:/]([^/]+)\/([^/]+)(\.git)?$/\1\/\2/' | sed 's/\.git$//'); IS_MONO=false; [ -f package.json ] && grep -q '"workspaces"' package.json && IS_MONO=true; for f in lerna.json pnpm-workspace.yaml rush.json; do [ -f "$f" ] && IS_MONO=true; done; ROOTS="."; if [ "$IS_MONO" = true ]; then ROOTS=$(git ls-files -z | tr '\0' '\n' | grep -E '^(apps|packages|services|libs)/[^/]+/package\.json$' | sed -E 's#/package\.json$##' | sort -u | paste -sd, -); [ -z "$ROOTS" ] && ROOTS=$(find . -maxdepth 3 -name package.json -not -path "./node_modules/*" -print0 | xargs -0 -n1 dirname | grep -E '^(\.|\.\/(apps|packages|services|libs)\/[^/]+)$' | sort -u | paste -sd, -); fi; echo "OWNER_REPO=$OWNER_REPO"; echo "IS_MONOREPO=$IS_MONO"; echo "ROOTS=$ROOTS" + + + Interpretation: + - If output contains OWNER_REPO, IS_MONOREPO, and ROOTS, record them and treat Step 3 as satisfied. + - If output is "not-git-repo", stop as above. + - If IS_MONOREPO=true but ROOTS is empty, perform Step 3 to determine roots manually. + + + + [x] Detect repository context (OWNER/REPO, monorepo, roots) + [ ] Perform targeted codebase discovery (iteration N) + [ ] 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) + + + + -### Testing Requirements -- Unit Tests: - - [ ] Test case 1: [Description] - - [ ] Test case 2: [Description] -- Integration Tests: - - [ ] Test scenario 1: [Description] -- Edge Cases: - - [ ] Edge case 1: [Description] + + Determine Repository Structure (Monorepo/Standard) + + If Step 2's combined detection output includes IS_MONOREPO and ROOTS, mark this step complete and proceed to Step 4. Otherwise, use the manual process below. -### Performance Impact -- Expected performance change: [Increase/Decrease/Neutral] -- Benchmarking needed: [Yes/No, specifics] -- Optimization opportunities: [List any] + Identify whether this is a monorepo and record the search root(s). -### Security Considerations -- Input validation requirements -- Authentication/Authorization changes -- Data exposure risks + 1) List top-level entries: + + . + false + -### Migration Strategy -[If applicable, how to migrate existing data/functionality] + 2) Monorepo indicators: + - package.json with "workspaces" + - lerna.json, pnpm-workspace.yaml, rush.json + - Top-level directories like apps/, packages/, services/, libs/ -### Rollback Plan -[How to safely rollback if issues arise] + If monorepo is detected: + - Discover package roots by locating package.json files under these directories + - Prefer scoping searches to the package most aligned with the user's description + - Ask for package selection if ambiguous -### Dependencies and Breaking Changes -- External dependencies affected: [List] -- API contract changes: [List] -- Breaking changes for users: [List with mitigation] - ]]> - - - - Additional considerations for monorepo repositories: - - Scope all searches to the identified package (if monorepo) - - Check for cross-package dependencies - - Verify against package-specific conventions - - Look for package-specific configuration - - Check if changes affect multiple packages - - Identify shared dependencies that might be impacted - - Look for workspace-specific scripts or tooling - - Consider package versioning implications - - After completing the comprehensive issue scoping, update the main todo list to show - all investigation steps are complete: - - - [x] Detect current repository information - [x] Determine repository structure (monorepo/standard) - [x] Perform initial codebase discovery - [x] Analyze user request to determine issue type - [x] Gather and verify additional information - [x] Determine if user wants to contribute - [x] Perform issue scoping (if contributing) - [x] Extract keywords from the issue description - [x] Perform initial broad codebase search - [x] Analyze search results and identify key components - [x] Deep dive into relevant files and implementations - [x] Form initial hypothesis about the issue/feature - [x] Attempt to disprove hypothesis through further investigation - [x] Identify all affected files and dependencies - [x] Map out the complete implementation approach - [x] Document technical risks and edge cases - [x] Formulate comprehensive technical solution - [x] Create detailed acceptance criteria - [x] Prepare issue scoping summary - [-] Draft issue content - [ ] Review and confirm with user - [ ] Create GitHub issue - - - - + If standard repository: + - Use repository root for searches - - Check for Repository Issue Templates - - Check if the repository has custom issue templates and use them. If not, create a simple generic template. - - 1. Check for issue templates in standard locations: - - .github/ISSUE_TEMPLATE - true - - - 2. Also check for single template file: - - .github - false - - - Look for files like: - - .github/ISSUE_TEMPLATE/*.md - - .github/ISSUE_TEMPLATE/*.yml - - .github/ISSUE_TEMPLATE/*.yaml - - .github/issue_template.md - - .github/ISSUE_TEMPLATE.md - - 3. If templates are found: - a. Parse the template files to extract: - - Template name and description - - Required fields - - Template body structure - - Labels to apply - - b. For YAML templates, look for: - - name: Template display name - - description: Template description - - labels: Default labels - - body: Form fields or markdown template - - c. For Markdown templates, look for: - - Front matter with metadata - - Template structure with placeholders - - 4. If multiple templates exist, ask user to choose: - - I found the following issue templates in this repository. Which one would you like to use? - - [Template 1 name]: [Template 1 description] - [Template 2 name]: [Template 2 description] - - - - 5. If no templates are found: - - Create a simple generic template based on issue type - - For bugs: Basic structure with description, steps to reproduce, expected vs actual - - For features: Problem description, proposed solution, impact - - 6. Store the selected/created template information: - - Template content/structure - - Required fields - - Default labels - - Any special formatting requirements - - Update todos: - - - [x] Detect current repository information - [x] Determine repository structure (monorepo/standard) - [x] Perform initial codebase discovery - [x] Analyze user request to determine issue type - [x] Gather and verify additional information - [x] Determine if user wants to contribute - [x] Perform issue scoping (if contributing) - [x] Check for repository issue templates - [-] Draft issue content - [ ] Review and confirm with user - [ ] Create GitHub issue - - - - + + + [x] Detect repository context (OWNER/REPO, monorepo, roots) + [-] Perform targeted codebase discovery (iteration N) + [ ] 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) + + + + - - Draft Issue Content - - Create the issue body using the template from step 8 and all verified information from codebase exploration. - - If using a repository template: - - Fill in the template fields with gathered information - - Include code references and findings where appropriate - - Respect the template's structure and formatting - - If using a generated template (no repo templates found): - - For Bug Reports: - ``` - ## Description - [Clear description of the bug with code context] - - ## Steps to Reproduce - 1. [Step with relevant code paths] - 2. [Step with component references] - 3. [Continue with specific details] - - ## Expected Behavior - [What should happen based on code logic] - - ## Actual Behavior - [What actually happens] - - ## Additional Context - - Version: [from package.json if found] - - Environment: [any relevant details] - - Error logs: [if any] - - ## Code Investigation - [Include findings from codebase exploration] - - Relevant files: [list with line numbers] - - Possible cause: [hypothesis from code review] - - [If user is contributing, add the comprehensive issue scoping section from step 7] - ``` - - For Feature Requests: - ``` - ## Problem Description - [What problem does this solve, who is affected, when it happens] - - ## Current Behavior - [How it works now with specific examples] - - ## Proposed Solution - [What should change] - - ## Impact - [Who benefits and how] - - ## Technical Context - [Findings from codebase exploration] - - Similar features: [code references] - - Integration points: [from exploration] - - Architecture considerations: [if any] - - [If contributing, add the comprehensive issue scoping section from step 7] - ``` - - Update todos: - - - [x] Detect current repository information - [x] Determine repository structure (monorepo/standard) - [x] Perform initial codebase discovery - [x] Analyze user request to determine issue type - [x] Gather and verify additional information - [x] Determine if user wants to contribute - [x] Perform issue scoping (if contributing) - [x] Check for repository issue templates - [x] Draft issue content - [-] Review and confirm with user - [ ] Create GitHub issue - - - - + + Codebase-Aware Context Discovery (Iterative) + + Purpose: Understand the context of the user's description by exploring the codebase. This step is repeatable. + + Discovery workflow (respect one-tool-per-message): + 1) Extract keywords, component names, error phrases, and concepts from the user's message or latest reply. + 2) Run semantic search: + + [Keywords from user's description or latest reply] + + + 3) Refine with targeted regex where helpful: + + . + [exact error strings|component names|feature flags] + + + 4) Read key files for verification when necessary: + + [relevant file path from search hits] + + + Guidance: + - Early-stop per iteration when top hits converge (~70%) or you can name the exact feature/component involved. + - Escalate-once per iteration if signals conflict: run one refined batch, then proceed. + - Keep findings internal; do NOT include file paths, line numbers, stack traces, or diffs in the final prompt. + + Iteration rules: + - After ANY new user input or clarification, return to this step with updated keywords. + - Update internal notes and TODOs to reflect the current iteration (e.g., iteration 2, 3, ...). - - Review and Confirm with User - - Present the complete drafted issue to the user for review, highlighting the - code-verified information: - - - I've prepared the following GitHub issue based on my analysis of the codebase and your description. I've verified the technical details against the actual implementation. Please review: + + + [x] Detect repository context (OWNER/REPO, monorepo, roots) + [-] Perform targeted codebase discovery (iteration N) + [ ] 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) + + + + - [Show the complete formatted issue content] + + Clarify Missing Details (Guided by Findings) + + Ask minimal, targeted questions grounded by what you found in code. + + For Bug reports: + + I’m verifying the behavior around [feature/component inferred from code]. Could you provide a minimal reproduction and quick impact details? + + Repro format: 1) Environment/setup 2) Steps 3) Expected 4) Actual 5) Variations (only if you tried them) + Impact: Who is affected and how often does this happen? + Cost: Approximate time or outcome cost per occurrence (optional) + + + + For Enhancements: + + To capture the improvement well, what is the user goal and value in plain language? + + State the user goal and when it occurs + Describe the desired behavior conceptually (no code) + Value: Who benefits and what improves (speed, clarity, fewer errors, conversions)? + + + + Discrepancies: + - If you found contradictions between description and code, present concrete, plain-language examples (no code) and ask for confirmation. + + Loop-back: + - After receiving any answer, return to Step 4 (Discovery) with the new information and repeat as needed. - Key verifications made: - - ✓ Component locations confirmed in code - - ✓ Error messages matched to source - - ✓ Architecture compatibility checked - [List other relevant verifications] + + + [x] Detect repository context (OWNER/REPO, monorepo, roots) + [x] Perform targeted codebase discovery (iteration N) + [-] 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) + + + + - Would you like me to create this issue, or would you like to make any changes? - - Yes, create this issue in the detected repository - Modify the problem description - Add more technical details - Change the title to: [let me specify] - - - - If user requests changes, make them and show the updated version for confirmation. - - After confirmation: - - - [x] Detect current repository information - [x] Determine repository structure (monorepo/standard) - [x] Perform initial codebase discovery - [x] Analyze user request to determine issue type - [x] Gather and verify additional information - [x] Determine if user wants to contribute - [x] Perform issue scoping (if contributing) - [x] Check for repository issue templates - [x] Draft issue content - [x] Review and confirm with user - [-] Prepare issue for submission - [ ] Handle submission choice - - - - + + Classify Type (Provisional and Repeatable) + + Use the user's description plus verified findings to choose: + - Bug indicators: matched error strings; broken behavior in existing features; regression indicators. + - Enhancement indicators: capability absent; extension of existing feature; workflow improvement. + - Impact snapshot (optional): Severity (Blocker/High/Medium/Low) and Reach (Few/Some/Many). If uncertain, omit and proceed. + + Confirm with the user if uncertain: + + Based on the behavior around [feature/component], should we frame this as a Bug or an Enhancement? + + Bug Report + Enhancement + + + + Reclassification: + - If later evidence or user info changes the type, reclassify and loop back to Step 4 for a fresh discovery iteration. - - Prepare Issue for Submission - - Once user confirms the issue content, prepare it for submission: - - First, perform final duplicate check with refined search based on our findings: - - gh issue list --repo $REPO_FULL_NAME --search "[key terms from verified analysis]" --state all --limit 10 - - - If no exact duplicates are found, save the issue content to a temporary file within the project: - - - ./github_issue_draft.md - [The complete formatted issue body from step 8] - [calculated line count] - - - After saving the issue draft, ask the user how they would like to proceed: - - - I've saved the issue draft to ./github_issue_draft.md. The issue is ready for submission with the following details: + + + [x] Detect repository context (OWNER/REPO, monorepo, roots) + [x] Perform targeted codebase discovery (iteration N) + [x] 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) + + + + - Title: "[Descriptive title with component name]" - Labels: [appropriate labels based on issue type] - Repository: $REPO_FULL_NAME + + Assemble Issue Body + + Build a concise, non-technical issue body. Omit empty sections entirely. + + Format: + ``` + ## 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 (include only if the user explicitly provided them) + + ## Constraints/Preferences + [Performance, accessibility, UX, or other considerations] + ``` + + Rules: + - Keep non-technical; do NOT include code paths, line numbers, stack traces, or diffs. + - Ground the wording in verified behavior, but keep implementation details internal. + - Sourcing: Do not infer or fabricate reproduction details or “Variations tried.” Include them only if explicitly provided by the user; otherwise omit the line. + - Quoting fidelity: If the user lists “Variations tried,” include them faithfully (verbatim or clearly paraphrased without adding new items). + - Value framing: Ensure the “Problem / Value” explains why it matters (impact on users or outcomes) in plain language. + - Title: Produce a concise Title (≤ 80 chars) prefixed with [BUG] or [ENHANCEMENT]; when helpful, append a brief value phrase in parentheses, e.g., “(blocks new runs)”. + + Iteration note: + - If new info arrives after drafting, loop back to Step 4, then update this draft accordingly. - How would you like to proceed? - - Submit the issue now to the repository - Let me make some edits to the issue first - I'll submit it manually later - - - - Based on the user's response: - - If "Submit the issue now": - - Use gh issue create with the saved file - - Provide the created issue URL and number - - Clean up the temporary file - - Complete the workflow - - If "Let me make some edits": - - Ask what changes they'd like to make - - Update the draft file with their changes - - Return to the submission question - - If "I'll submit it manually": - - Inform them the draft is saved at the configured location - - Provide the gh command they can use later - - Complete the workflow without submission - - Update todos based on the outcome: - - - [x] Detect current repository information - [x] Determine repository structure (monorepo/standard) - [x] Perform initial codebase discovery - [x] Analyze user request to determine issue type - [x] Gather and verify additional information - [x] Determine if user wants to contribute - [x] Perform issue scoping (if contributing) - [x] Check for repository issue templates - [x] Draft issue content - [x] Review and confirm with user - [x] Prepare issue for submission - [-] Handle submission choice - - - - + + + [x] Detect repository context (OWNER/REPO, monorepo, roots) + [x] Perform targeted codebase discovery (iteration N) + [x] Clarify missing details (repro or desired outcome) + [x] Classify type (Bug | Enhancement) + [-] Assemble Issue Body + [ ] Review and submit (Submit now | Submit now and assign to me) + + + + - - Handle Submission Choice - - This step handles the user's choice from step 9. - - OPTION 1: Submit the issue now - If the user chooses to submit immediately: - - - gh issue create --repo $REPO_FULL_NAME --title "[Descriptive title]" --body-file ./github_issue_draft.md --label "[appropriate labels]" - - - Label selection based on findings: - - Bug: Use "bug" label - - Feature: Use "enhancement" label - - If affects multiple packages in monorepo: add "affects-multiple" label - - After successful creation: - - Capture and display the issue URL - - Clean up the temporary file: - - rm ./github_issue_draft.md - - - Provide a summary of key findings included - - OPTION 2: Make edits - If the user wants to edit: - - - What changes would you like to make to the issue? - - Update the title - Modify the problem description - Add or remove technical details - Change the labels or other metadata - - - - - Apply the requested changes to the draft - - Update the file with write_to_file - - Return to step 9 to ask about submission again - - OPTION 3: Manual submission - If the user will submit manually: - - Provide clear instructions: - "The issue draft has been saved to ./github_issue_draft.md + + Review and Submit (Single-Step) + + Present the full current issue details in a code block. Offer two submission options; any other response is treated as a change request. + + + 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] +``` + + Submit now + Submit now and assign to me + + + + Responses: + - If "Submit now": + Prepare: + - Title: derive from Summary (≤ 80 chars, plain language) + - Body: the finalized issue body + + Execute: + + gh issue create --repo "[OWNER_REPO]" --title "[ISSUE_TITLE]" --body "$(printf '%s\n' "[ISSUE_BODY]")" + + + - If "Submit now and assign to me": + Execute (assignment at creation; falls back to edit if needed): + + 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" + + + - Any other response: + - Collect requested edits and apply them + - Loop back to Step 4 (Discovery) if new information affects context + - Re-assemble in Step 7 + - Rerun this step and present the updated issue details + + On success: Capture the created issue URL from stdout and complete: + + + Created issue: [URL] + + + + On failure: Present the error succinctly and offer to retry after fixing gh setup (installation/auth). Provide the computed Title and Body inline so the user can submit manually if needed. - To submit it later, you can use: - gh issue create --repo $REPO_FULL_NAME --title "[Your title]" --body-file ./github_issue_draft.md --label "[labels]" - - Or you can copy the content and create the issue through the GitHub web interface." - - Final todo update: - - - [x] Detect current repository information - [x] Determine repository structure (monorepo/standard) - [x] Perform initial codebase discovery - [x] Analyze user request to determine issue type - [x] Gather and verify additional information - [x] Determine if user wants to contribute - [x] Perform issue scoping (if contributing) - [x] Check for repository issue templates - [x] Draft issue content - [x] Review and confirm with user - [x] Prepare issue for submission - [x] Handle submission choice - - - - + + + [x] Detect repository context (OWNER/REPO, monorepo, roots) + [x] Perform targeted codebase discovery (iteration N) + [x] Clarify missing details (repro or desired outcome) + [x] Classify type (Bug | Enhancement) + [x] Assemble Issue Body + [x] Review and submit (Submit now | Submit now and assign to me) + + + + + + + + Repository detection (git repo present and origin remote configured) is performed before any submission. + Issue is submitted via gh after choosing "Submit now" or "Submit now and assign to me", and the created issue URL is returned. + When "Submit now and assign to me" is chosen, the issue is assigned to the current GitHub user using --assignee "@me" (or gh issue edit fallback). + Submission uses Title and Body only and specifies --repo [OWNER_REPO] discovered in Step 2; no temporary files or file paths are used. + Language is plain and user-centric; no technical artifacts included in the issue body. + Content grounded by repeated codebase exploration cycles as needed. + Early-stop/escalate-once applied per iteration; unlimited iterations across the conversation. + The merged step offers "Submit now" or "Submit now and assign to me"; any other response is treated as a change request and the step is shown again with the full current issue details. + \ No newline at end of file diff --git a/.roo/rules-issue-writer/2_github_issue_templates.xml b/.roo/rules-issue-writer/2_github_issue_templates.xml deleted file mode 100644 index 36b44125dd1..00000000000 --- a/.roo/rules-issue-writer/2_github_issue_templates.xml +++ /dev/null @@ -1,190 +0,0 @@ - - - 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. - - - - - .github/ISSUE_TEMPLATE/*.yml - .github/ISSUE_TEMPLATE/*.yaml - .github/ISSUE_TEMPLATE/*.md - .github/issue_template.md - .github/ISSUE_TEMPLATE.md - - - - Display name of the template - Brief description of when to use this template - Default issue title (optional) - Array of labels to apply - Array of default assignees - Array of form elements or markdown content - - - - - Static markdown content - - The markdown content to display - - - - - Single-line text input - - Unique identifier - Display label - Help text - Placeholder text - Default value - Boolean - - - - - Multi-line text input - - Unique identifier - Display label - Help text - Placeholder text - Default value - Boolean - Language for syntax highlighting - - - - - Dropdown selection - - Unique identifier - Display label - Help text - Array of options - Boolean - - - - - Multiple checkbox options - - Unique identifier - Display label - Help text - Array of checkbox items - - - - - - - Optional YAML front matter with: - - name: Template name - - about: Template description - - title: Default title - - labels: Comma-separated or array - - assignees: Comma-separated or array - - - Markdown content with sections and placeholders - Common patterns: - - Headers with ## - - Placeholder text in brackets or as comments - - Checklists with - [ ] - - Code blocks with ``` - - - - - - - When no repository templates exist, create simple templates based on issue type. - These should be minimal and focused on gathering essential information. - - - - - - 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) - - ["bug"] - - - - - - 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) - - ["enhancement", "proposal"] - - - - - - 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 - - - - 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 - - - - 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.) - - - - - - 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 - - - - - - - - - - - - - When no templates exist, create appropriate generic templates on the fly. - Keep them simple and focused on essential information. - - - - - 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) - - - \ No newline at end of file diff --git a/.roo/rules-issue-writer/3_best_practices.xml b/.roo/rules-issue-writer/3_best_practices.xml index f2f149ed262..b6f90c8014b 100644 --- a/.roo/rules-issue-writer/3_best_practices.xml +++ b/.roo/rules-issue-writer/3_best_practices.xml @@ -1,172 +1,147 @@ + + 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. + + - - 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. - - - - 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 - - - - - 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]" - - - - - 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 - - - - - 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'" - - - - - 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" - - - - 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 - - + + + + - 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). + + + - Severity: Blocker | High | Medium | Low (optional) + - Reach: Few | Some | Many (optional) + + + + + + - Reproduction steps + - Variations tried + - Environment details + + + - Problem/Value statement (plain-language synthesis from user wording) + - Context (who/when) based on user input; keep code-based signals internal + + + - Never fabricate “Variations tried.” If not provided, omit. + - If critical details are missing, ask targeted questions; otherwise proceed with omissions. + + + + + + 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. + + + Submission requires repository detection (git present, origin configured). Capture normalized OWNER/REPO (e.g., owner/repo) and store as [OWNER_REPO] for submission. + + + Always specify the target using --repo "[OWNER_REPO]" to avoid ambiguity and ensure the correct repository is used. + + + 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 --add-assignee "@me". + + + 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. + + + 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. + + + + + + - 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. + + + 1) codebase_search → 2) search_files → 3) read_file (as needed) + + + In monorepos, scope searches to the selected package when the context is clear; otherwise ask for the relevant package/app if ambiguous. + + + Keep language plain and exclude technical artifacts (paths, line numbers, stack traces, diffs) from the final issue body. + + + + + + - 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. + + + + + + + + + - 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). + + + + + - 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. + + + + - 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. + + - - 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. - - - - 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) - - - - 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 - - - - - 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 - - - - 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 - - - - - 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 - - - - 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 - - - - 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 - - \ No newline at end of file diff --git a/.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml b/.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml index a8dd9b590b0..4077edfb4d3 100644 --- a/.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml +++ b/.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml @@ -1,126 +1,109 @@ - - 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 - + + + - 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 + + + + + Splitting final review and submission into multiple steps + Creates redundant prompts and inconsistent state; leads to janky UX + 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 + + + Not offering "Submit now and assign to me" + Forces manual assignment later; reduces efficiency + Provide the assignment option and use gh issue create --assignee "@me"; if that fails, immediately run gh issue edit --add-assignee "@me" + + + Using temporary files or --body-file for issue body submission + Introduces filesystem dependencies and leaks paths; contradicts single-command policy + Use inline --body with robust quoting, e.g., --body "$(printf '%s\n' "[ISSUE_BODY]")"; do not reference any file paths + + + Omitting --repo or relying on current directory defaults + May submit to the wrong repository in multi-repo or worktree contexts + Always pass --repo [OWNER_REPO] detected in Step 2 + + + Attempting submission without prior repository detection + Commands may target the wrong repo or fail + Detect git repo and ensure origin is configured before any gh commands + + + + + + Inventing or inferring “Variations tried” when the user didn’t provide any + Misleads triage and wastes time reproducing non-existent attempts + Omit the “Variations tried” line entirely unless explicitly provided; if needed, ask a targeted question first + + + Framing only the problem without the value/impact + Makes prioritization harder; obscures who benefits and why it matters + Pair the problem with a plain-language value statement (who, when, why it matters) + + + Overstating impact without user signal + Damages credibility and misguides prioritization + Use conservative, plain language; if unsure, omit severity/reach or ask a single targeted question + + + - - 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 - - - - 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 - - - - - 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 - - - - Not tracing data flow completely through the system - Missing that data already exists leads to proposing unnecessary new code + + + - 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 + + + + Skipping semantic search and jumping straight to assumptions + Leads to misclassification and inaccurate context - - 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 - - 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" - - - - - Proposing complex new systems when simple fixes exist - Creates unnecessary complexity, maintenance burden, and potential bugs + + + + Accepting user claims that contradict the codebase without verification + Produces misleading or incorrect issue framing - - 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 - - Bad: "Create new state management system for mode tracking" - Good: "Pass existing modeInfo variable from line 45 to the function at line 78" - - - - - Not reading actual code before proposing solutions - Solutions don't match the actual codebase structure - - - 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 - - - - - Creating new patterns instead of following existing ones - Inconsistent codebase, harder to maintain - - - Find similar features that work correctly - - Follow the same patterns and structures - - Reuse existing utilities and helpers - - Maintain consistency with the codebase style - - - - - Using hardcoded templates when repository templates exist - Issues don't follow repository conventions, may be rejected or need reformatting - - - Always check .github/ISSUE_TEMPLATE/ directory first - - Parse and use repository templates when available - - Only create generic templates when none exist - - - - - Not properly parsing YAML template structure - Missing required fields, incorrect formatting, lost metadata - - - 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 - - - - - Leaving placeholder text in final issue - Unprofessional appearance, confusion about what information is needed - - - 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 - - + + + + - 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) + + + + - 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 + \ No newline at end of file diff --git a/.roo/rules-issue-writer/5_examples.xml b/.roo/rules-issue-writer/5_examples.xml new file mode 100644 index 00000000000..6c19018e6c2 --- /dev/null +++ b/.roo/rules-issue-writer/5_examples.xml @@ -0,0 +1,134 @@ + + + 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. + + + + + In dark theme the Submit button is almost invisible on the New Run page. + + + + +dark theme submit button visibility + + + +. +Submit|button|dark|theme + + ]]> + + + Internal: matches found in UI components related to theme; wording grounded to user impact. + + + 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 + ]]> + + + + + I accidentally click "Copy Run" sometimes; would be great to have a simple confirmation. + + + + +Copy Run confirmation + + ]]> + + + Internal: feature entry point identified; keep final output non-technical and user-centric. + + + + + + + + Dark theme Submit button is invisible; I'd like to file this. + + 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 + ]]> + + + 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] +``` + + Submit now + Submit now and assign to me + + + + + gh issue create --repo "[OWNER_REPO]" --title "[ISSUE_TITLE]" --body "$(printf '%s\n' "[ISSUE_BODY]")" + + + + 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" + + + + 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. + + + https://github.com/OWNER/REPO/issues/123 + + + + + Issues are template-free (Title + Body only). + Repository detection (git + origin → OWNER/REPO) occurs before submission and is passed explicitly via --repo [OWNER_REPO]. + Never use --body-file or temporary files; submit with inline --body only (no file paths). + 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. + All discovery is internal; keep final output plain-language. + + \ No newline at end of file diff --git a/.roo/rules-issue-writer/5_github_cli_usage.xml b/.roo/rules-issue-writer/5_github_cli_usage.xml deleted file mode 100644 index 1792be87ebb..00000000000 --- a/.roo/rules-issue-writer/5_github_cli_usage.xml +++ /dev/null @@ -1,342 +0,0 @@ - - - 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. - - - - - - ALWAYS use this FIRST before creating any issue to check for duplicates. - Search for keywords from the user's problem description. - - - - gh issue list --repo $REPO_FULL_NAME --search "dark theme button visibility" --state all --limit 20 - - - - --search: Search query for issue titles and bodies - --state: all, open, or closed - --label: Filter by specific labels - --limit: Number of results to show - --json: Get structured JSON output - - - - - - Use for more advanced searches across issues and pull requests. - Supports GitHub's advanced search syntax. - - - - gh search issues --repo $REPO_FULL_NAME "dark theme button" --limit 10 - - - - - - - Use when you find a potentially related issue and need full details. - Check if the user's issue is already reported or related. - - - - gh issue view 123 --repo $REPO_FULL_NAME --comments - - - - --comments: Include issue comments - --json: Get structured data - --web: Open in browser - - - - - - - - Use to check for issue templates in the repository before creating issues. - This is not a gh command but necessary for template detection. - - - Check for templates in standard location: - - .github/ISSUE_TEMPLATE - true - - - Check for single template file: - - .github - false - - - - - - - Read template files to parse their structure and content. - Used after detecting template files. - - - Read YAML template: - - .github/ISSUE_TEMPLATE/bug_report.yml - - - Read Markdown template: - - .github/ISSUE_TEMPLATE/feature_request.md - - - - - - - - These commands should ONLY be used if the user has indicated they want to - contribute the implementation. Skip these for problem reporters. - - - - - Get repository information and recent activity. - - - - gh repo view $REPO_FULL_NAME --json defaultBranchRef,description,updatedAt - - - - - - - Check recent PRs that might be related to the issue. - Look for PRs that modified relevant code. - - - - gh search prs --repo $REPO_FULL_NAME "dark theme" --limit 10 --state all - - - - - - - For bug reports from contributors, check recent commits that might have introduced the issue. - Use after cloning the repository locally. - - - - git log --oneline --grep="theme" -n 20 - - - - - - - - - Only use after: - 1. Confirming no duplicates exist - 2. Checking for and using repository templates - 3. Gathering all required information - 4. Determining if user is contributing or just reporting - 5. Getting user confirmation - - - - gh issue create --repo $REPO_FULL_NAME --title "[Descriptive title of the bug]" --body-file /tmp/issue_body.md --label "bug" - - - - - gh issue create --repo $REPO_FULL_NAME --title "[Problem-focused title]" --body-file /tmp/issue_body.md --label "proposal" --label "enhancement" - - - - --title: Issue title (required) - --body: Issue body text - --body-file: Read body from file - --label: Add labels (can use multiple times) - --assignee: Assign to user - --project: Add to project - --web: Open in browser to create - - - - - - - - ONLY use if user wants to add additional information after creation. - - - - gh issue comment 456 --repo $REPO_FULL_NAME --body "Additional context or comments." - - - - - - - Use if user realizes they need to update the issue after creation. - Can update title, body, or labels. - - - - gh issue edit 456 --repo $REPO_FULL_NAME --title "[Updated title]" --body "[Updated body]" - - - - - - - - After user selects issue type, immediately search for related issues: - 1. Use `gh issue list --search` with keywords from their description - 2. Show any similar issues found - 3. Ask if they want to continue or comment on existing issue - - - - 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 - - - - Decision point for contribution: - 1. Ask user if they want to contribute implementation - 2. If yes: Use contributor commands for codebase investigation - 3. If no: Skip directly to creating a problem-focused issue - 4. This saves time for problem reporters - - - - During codebase exploration (CONTRIBUTORS ONLY): - 1. Clone repo locally if needed: `gh repo clone $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 - - - - 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 - - - - - - When creating issues with long bodies: - 1. Save to temporary file: `cat > /tmp/issue_body.md << 'EOF'` - 2. Use --body-file flag with gh issue create - 3. Clean up after: `rm /tmp/issue_body.md` - - - - Use specific search terms: - - Include error messages in quotes - - Use label filters when appropriate - - Limit results to avoid overwhelming output - - - - Use --json flag for structured data when needed: - - Easier to parse programmatically - - Consistent format across commands - - Example: `gh issue list --json number,title,state` - - - - - - If search finds exact duplicate: - - Show the existing issue to user using `gh issue view` - - Ask if they want to add a comment instead - - Use `gh issue comment` if they agree - - - - If `gh issue create` fails: - - Check error message (auth, permissions, network) - - Ensure gh is authenticated: `gh auth status` - - Save the drafted issue content for user - - Suggest using --web flag to create in browser - - - - Ensure GitHub CLI is authenticated: - - Check status: `gh auth status` - - Login if needed: `gh auth login` - - Select appropriate scopes for issue creation - - - - - - gh issue create - Create new issue - gh issue list - List and search issues - gh issue view - View issue details - gh issue comment - Add comment to issue - gh issue edit - Edit existing issue - gh issue close - Close an issue - gh issue reopen - Reopen closed issue - - - - gh search issues - Search issues and PRs - gh search prs - Search pull requests - gh search repos - Search repositories - - - - gh repo view - View repository info - gh repo clone - Clone repository - - - - - - 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 - - - - When parsing Markdown templates: - - Check for YAML front matter - - Extract metadata (labels, assignees) - - Identify section headers - - Replace placeholder text - - Maintain formatting structure - - - - 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 - - - \ No newline at end of file diff --git a/.roo/rules-mode-writer/1_mode_creation_workflow.xml b/.roo/rules-mode-writer/1_mode_creation_workflow.xml deleted file mode 100644 index 77a1728599f..00000000000 --- a/.roo/rules-mode-writer/1_mode_creation_workflow.xml +++ /dev/null @@ -1,301 +0,0 @@ - - - This workflow guides you through creating new custom modes or editing existing modes - for the Roo Code Software, ensuring comprehensive understanding and cohesive implementation. - - - - - Determine User Intent - - Identify whether the user wants to create a new mode or edit an existing one - - - - - User mentions a specific mode by name or slug - User references a mode directory path (e.g., .roo/rules-[mode-slug]) - User asks to modify, update, enhance, or fix an existing mode - User says "edit this mode" or "change this mode" - - - - - User asks to create a new mode - User describes a new capability not covered by existing modes - User says "make a mode for" or "create a mode that" - - - - - - I want to make sure I understand correctly. Are you looking to create a brand new mode or modify an existing one? - - Create a new mode for a specific purpose - Edit an existing mode to add new capabilities - Fix issues in an existing mode - Enhance an existing mode with better workflows - - - - - - - - - - Gather Requirements for New Mode - - Understand what the user wants the new mode to accomplish - - - Ask about the mode's primary purpose and use cases - Identify what types of tasks the mode should handle - Determine what tools and file access the mode needs - Clarify any special behaviors or restrictions - - - - What is the primary purpose of this new mode? What types of tasks should it handle? - - A mode for writing and maintaining documentation - A mode for database schema design and migrations - A mode for API endpoint development and testing - A mode for performance optimization and profiling - - - - - - - Design Mode Configuration - - Create the mode definition with all required fields - - - - Unique identifier (lowercase, hyphens allowed) - Keep it short and descriptive (e.g., "api-dev", "docs-writer") - - - Display name with optional emoji - Use an emoji that represents the mode's purpose - - - Detailed description of the mode's role and expertise - - Start with "You are Roo Code, a [specialist type]..." - List specific areas of expertise - Mention key technologies or methodologies - - - - Tool groups the mode can access - - - - - - - - - - - - Clear description for the Orchestrator - Explain specific scenarios and task types - - - - Do not include customInstructions in the .roomodes configuration. - All detailed instructions should be placed in XML files within - the .roo/rules-[mode-slug]/ directory instead. - - - - - Implement File Restrictions - - Configure appropriate file access permissions - - - Restrict edit access to specific file types - -groups: - - read - - - edit - - fileRegex: \.(md|txt|rst)$ - description: Documentation files only - - command - - - - Use regex patterns to limit file editing scope - Provide clear descriptions for restrictions - Consider the principle of least privilege - - - - - Create XML Instruction Files - - Design structured instruction files in .roo/rules-[mode-slug]/ - - - Main workflow and step-by-step processes - Guidelines and conventions - Reusable code patterns and examples - Specific tool usage instructions - Complete workflow examples - - - Use semantic tag names that describe content - Nest tags hierarchically for better organization - Include code examples in CDATA sections when needed - Add comments to explain complex sections - - - - - - - Immerse in Existing Mode - - Fully understand the existing mode before making any changes - - - Locate and read the mode configuration in .roomodes - Read all XML instruction files in .roo/rules-[mode-slug]/ - Analyze the mode's current capabilities and limitations - Understand the mode's role in the broader ecosystem - - - - What specific aspects of the mode would you like to change or enhance? - - Add new capabilities or tool permissions - Fix issues with current workflows or instructions - Improve the mode's roleDefinition or whenToUse description - Enhance XML instructions for better clarity - - - - - - - Analyze Change Impact - - Understand how proposed changes will affect the mode - - - Compatibility with existing workflows - Impact on file permissions and tool access - Consistency with mode's core purpose - Integration with other modes - - - - I've analyzed the existing mode. Here's what I understand about your requested changes. Is this correct? - - Yes, that's exactly what I want to change - Mostly correct, but let me clarify some details - No, I meant something different - I'd like to add additional changes - - - - - - - Plan Modifications - - Create a detailed plan for modifying the mode - - - Identify which files need to be modified - Determine if new XML instruction files are needed - Check for potential conflicts or contradictions - Plan the order of changes for minimal disruption - - - - - Implement Changes - - Apply the planned modifications to the mode - - - Update .roomodes configuration if needed - Modify existing XML instruction files - Create new XML instruction files if required - Update examples and documentation - - - - - - - - Validate Cohesion and Consistency - - Ensure all changes are cohesive and don't contradict each other - - - - Mode slug follows naming conventions - File restrictions align with mode purpose - Tool permissions are appropriate - whenToUse clearly differentiates from other modes - - - All XML files follow consistent structure - No contradicting instructions between files - Examples align with stated workflows - Tool usage matches granted permissions - - - Mode integrates well with Orchestrator - Clear boundaries with other modes - Handoff points are well-defined - - - - - I've completed the validation checks. Would you like me to review any specific aspect in more detail? - - Review the file permission patterns - Check for workflow contradictions - Verify integration with other modes - Everything looks good, proceed to testing - - - - - - - Test and Refine - - Verify the mode works as intended - - - Mode appears in the mode list - File restrictions work correctly - Instructions are clear and actionable - Mode integrates well with Orchestrator - All examples are accurate and helpful - Changes don't break existing functionality (for edits) - New capabilities work as expected - - - - - - Create mode in .roomodes for project-specific modes - Create mode in global custom_modes.yaml for system-wide modes - Use list_files to verify .roo folder structure - Test file regex patterns with search_files - Use codebase_search to find existing mode implementations - Read all XML files in a mode directory to understand its structure - Always validate changes for cohesion and consistency - - \ No newline at end of file diff --git a/.roo/rules-mode-writer/2_xml_structuring_best_practices.xml b/.roo/rules-mode-writer/2_xml_structuring_best_practices.xml deleted file mode 100644 index 639f855c0c0..00000000000 --- a/.roo/rules-mode-writer/2_xml_structuring_best_practices.xml +++ /dev/null @@ -1,220 +0,0 @@ - - - XML tags help Claude parse prompts more accurately, leading to higher-quality outputs. - This guide covers best practices for structuring mode instructions using XML. - - - - - Clearly separate different parts of your instructions and ensure well-structured content - - - Reduce errors caused by Claude misinterpreting parts of your instructions - - - Easily find, add, remove, or modify parts of instructions without rewriting everything - - - Having Claude use XML tags in its output makes it easier to extract specific parts of responses - - - - - - Use the same tag names throughout your instructions - - Always use for workflow steps, not sometimes or - - - - - Tag names should clearly describe their content - - detailed_steps - error_handling - validation_rules - - - stuff - misc - data1 - - - - - Nest tags to show relationships and structure - - - - Gather requirements - Validate inputs - - - Process data - Generate output - - - - - - - - - For step-by-step processes - - - - - For providing code examples and demonstrations - - - - - For rules and best practices - - - - - For documenting how to use specific tools - - - - - - - Use consistent indentation (2 or 4 spaces) for nested elements - - - Add line breaks between major sections for readability - - - Use XML comments to explain complex sections - - - Use CDATA for code blocks or content with special characters: - ]]> - - - Use attributes for metadata, elements for content: - - - The actual step content - - - - - - - - Avoid completely flat structures without hierarchy - -Do this -Then this -Finally this - - ]]> - - - Do this - Then this - Finally this - - - ]]> - - - - Don't mix naming conventions - - Mixing camelCase, snake_case, and kebab-case in tag names - - - Pick one convention (preferably snake_case for XML) and stick to it - - - - - Avoid tags that don't convey meaning - data, info, stuff, thing, item - user_input, validation_result, error_message, configuration - - - - - - Reference XML content in instructions: - "Using the workflow defined in <workflow> tags..." - - - Combine XML structure with other techniques like multishot prompting - - - Use XML tags in expected outputs to make parsing easier - - - Create reusable XML templates for common patterns - - - \ No newline at end of file diff --git a/.roo/rules-mode-writer/3_mode_configuration_patterns.xml b/.roo/rules-mode-writer/3_mode_configuration_patterns.xml deleted file mode 100644 index 82a5f845ac4..00000000000 --- a/.roo/rules-mode-writer/3_mode_configuration_patterns.xml +++ /dev/null @@ -1,261 +0,0 @@ - - - Common patterns and templates for creating different types of modes, with examples from existing modes in the Roo-Code software. - - - - - - Modes focused on specific technical domains or tasks - - - Deep expertise in a particular area - Restricted file access based on domain - Specialized tool usage patterns - - - - You are Roo Code, an API development specialist with expertise in: - - RESTful API design and implementation - - GraphQL schema design - - API documentation with OpenAPI/Swagger - - Authentication and authorization patterns - - Rate limiting and caching strategies - - API versioning and deprecation - - You ensure APIs are: - - Well-documented and discoverable - - Following REST principles or GraphQL best practices - - Secure and performant - - Properly versioned and maintainable - whenToUse: >- - Use this mode when designing, implementing, or refactoring APIs. - This includes creating new endpoints, updating API documentation, - implementing authentication, or optimizing API performance. - groups: - - read - - - edit - - fileRegex: (api/.*\.(ts|js)|.*\.openapi\.yaml|.*\.graphql|docs/api/.*)$ - description: API implementation files, OpenAPI specs, and API documentation - - command - - mcp - ]]> - - - - - Modes that guide users through multi-step processes - - - Step-by-step workflow guidance - Heavy use of ask_followup_question - Process validation at each step - - - - You are Roo Code, a migration specialist who guides users through - complex migration processes: - - Database schema migrations - - Framework version upgrades - - API version migrations - - Dependency updates - - Breaking change resolutions - - You provide: - - Step-by-step migration plans - - Automated migration scripts - - Rollback strategies - - Testing approaches for migrations - whenToUse: >- - Use this mode when performing any kind of migration or upgrade. - This mode will analyze the current state, plan the migration, - and guide you through each step with validation. - groups: - - read - - edit - - command - ]]> - - - - - Modes focused on code analysis and reporting - - - Read-heavy operations - Limited or no edit permissions - Comprehensive reporting outputs - - - - You are Roo Code, a security analysis specialist focused on: - - Identifying security vulnerabilities - - Analyzing authentication and authorization - - Reviewing data validation and sanitization - - Checking for common security anti-patterns - - Evaluating dependency vulnerabilities - - Assessing API security - - You provide detailed security reports with: - - Vulnerability severity ratings - - Specific remediation steps - - Security best practice recommendations - whenToUse: >- - Use this mode to perform security audits on codebases. - This mode will analyze code for vulnerabilities, check - dependencies, and provide actionable security recommendations. - groups: - - read - - command - - - edit - - fileRegex: (SECURITY\.md|\.github/security/.*|docs/security/.*)$ - description: Security documentation files only - ]]> - - - - - Modes for generating new content or features - - - Broad file creation permissions - Template and boilerplate generation - Interactive design process - - - - You are Roo Code, a UI component design specialist who creates: - - Reusable React/Vue/Angular components - - Component documentation and examples - - Storybook stories - - Unit tests for components - - Accessibility-compliant interfaces - - You follow design system principles and ensure components are: - - Highly reusable and composable - - Well-documented with examples - - Fully tested - - Accessible (WCAG compliant) - - Performance optimized - whenToUse: >- - Use this mode when creating new UI components or refactoring - existing ones. This mode helps design component APIs, implement - the components, and create comprehensive documentation. - groups: - - read - - - edit - - fileRegex: (components/.*|stories/.*|__tests__/.*\.test\.(tsx?|jsx?))$ - description: Component files, stories, and component tests - - browser - - command - ]]> - - - - - - For modes that only work with documentation - - - - - For modes that work with test files - - - - - For modes that manage configuration - - - - - For modes that need broad access - - - - - - - Use lowercase with hyphens - api-dev, test-writer, docs-manager - apiDev, test_writer, DocsManager - - - - Use title case with descriptive emoji - 🔧 API Developer, 📝 Documentation Writer - api developer, DOCUMENTATION WRITER - - - - - 🧪 - 📝 - 🎨 - 🪲 - 🏗️ - 🔒 - 🔌 - 🗄️ - ⚡ - ⚙️ - - - - - - - Ensure whenToUse is clear for Orchestrator mode - - Specify concrete task types the mode handles - Include trigger keywords or phrases - Differentiate from similar modes - Mention specific file types or areas - - - - - Define clear boundaries between modes - - Avoid overlapping responsibilities - Make handoff points explicit - Use switch_mode when appropriate - Document mode interactions - - - - \ No newline at end of file diff --git a/.roo/rules-mode-writer/4_instruction_file_templates.xml b/.roo/rules-mode-writer/4_instruction_file_templates.xml deleted file mode 100644 index 3afcfa28f45..00000000000 --- a/.roo/rules-mode-writer/4_instruction_file_templates.xml +++ /dev/null @@ -1,367 +0,0 @@ - - - Templates and examples for creating XML instruction files that provide - detailed guidance for each mode's behavior and workflows. - - - - Number files to indicate execution order - Use descriptive names that indicate content - Keep related instructions together - - 1_workflow.xml - Main workflow and processes - 2_best_practices.xml - Guidelines and conventions - 3_common_patterns.xml - Reusable code patterns - 4_tool_usage.xml - Specific tool instructions - 5_examples.xml - Complete workflow examples - 6_error_handling.xml - Error scenarios and recovery - 7_communication.xml - User interaction guidelines - - - - - Template for main workflow files (1_workflow.xml) - - - - - Template for best practices files (2_best_practices.xml) - - - - - Template for tool usage files (4_tool_usage.xml) - - - - - Template for example files (5_examples.xml) - - - - - Template for communication guidelines (7_communication.xml) - - - \ No newline at end of file diff --git a/.roo/rules-mode-writer/5_complete_mode_examples.xml b/.roo/rules-mode-writer/5_complete_mode_examples.xml deleted file mode 100644 index 7c8f8a4cdef..00000000000 --- a/.roo/rules-mode-writer/5_complete_mode_examples.xml +++ /dev/null @@ -1,214 +0,0 @@ - - - - Edit the test mode to add support for performance testing and benchmarking - - - - I want to edit the test mode to add benchmark testing capabilities - - - - - Determine user intent and clarify scope - -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? - -Add benchmark testing with Vitest's bench API -Include performance profiling and memory usage tracking -Add load testing capabilities for API endpoints -All of the above - comprehensive performance testing suite - - - ]]> - User selected: Add benchmark testing with Vitest's bench API - - - - Immerse in existing test mode configuration - -.roomodes - - ]]> - Found test mode configuration with current roleDefinition and file restrictions - - - - Explore existing test mode instructions - -.roo/rules-test -true - - ]]> - -.roo/rules-test/1_workflow.xml - - ]]> - Understood current test workflows and patterns - - - - Validate changes for cohesion - -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? - -Yes, implement all the changes as described -Start with just the roleDefinition and file restrictions -Focus only on the workflow instructions first -Let me review the specific changes before proceeding - - - ]]> - User selected: Yes, implement all the changes as described - - - - Update mode configuration in .roomodes - -.roomodes - -<<<<<<< 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 - - - ]]> - - - - Update file restrictions to include benchmark files - -.roomodes - -<<<<<<< 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 - - - ]]> - - - - Create new benchmark workflow instructions - -.roo/rules-test/5_benchmark_testing.xml - - - - Guidelines for creating and maintaining performance benchmarks using Vitest bench API - - - - - Basic benchmark structure - { - 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]; - } - }); -}); - ]]> - - - - - Use meaningful benchmark names that describe what's being measured - Include baseline comparisons when optimizing code - Run benchmarks in isolation to avoid interference - Document performance expectations and thresholds - - - -38 - - ]]> - - - - Validate all changes for consistency - -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? - -Test creating a new benchmark file to verify file permissions -Review the complete changes one more time -Everything looks good, the mode is ready -Create a simple benchmark example to test - - - ]]> - - - - - -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. - - - ]]> - - - Always immerse yourself in the existing mode before making changes - Use ask_followup_question aggressively to clarify scope and validate changes - Validate all changes for cohesion and consistency - Update all relevant parts: configuration, file restrictions, and instructions - Test changes to ensure they work as expected - - - \ No newline at end of file diff --git a/.roo/rules-mode-writer/6_mode_testing_validation.xml b/.roo/rules-mode-writer/6_mode_testing_validation.xml deleted file mode 100644 index db65b31c22b..00000000000 --- a/.roo/rules-mode-writer/6_mode_testing_validation.xml +++ /dev/null @@ -1,207 +0,0 @@ - - - Guidelines for testing and validating newly created modes to ensure they function correctly and integrate well with the Roo Code ecosystem. - - - - - - Mode slug is unique and follows naming conventions - No spaces, lowercase, hyphens only - - - All required fields are present and non-empty - slug, name, roleDefinition, groups - - - No customInstructions field in .roomodes - All instructions must be in XML files in .roo/rules-[slug]/ - - - File restrictions use valid regex patterns - -. -your_file_regex_here - - ]]> - - - whenToUse clearly differentiates from other modes - Compare with existing mode descriptions - - - - - - XML files are well-formed and valid - No syntax errors, proper closing tags - - - Instructions follow XML best practices - Semantic tag names, proper nesting - - - Examples use correct tool syntax - Tool parameters match current API - - - File paths in examples are consistent - Use project-relative paths - - - - - - Mode appears in mode list - Switch to the new mode and verify it loads - - - Tool permissions work as expected - Try using each tool group and verify access - - - File restrictions are enforced - Attempt to edit allowed and restricted files - - - Mode handles edge cases gracefully - Test with minimal input, errors, edge cases - - - - - - - Configuration Testing - - Verify mode appears in available modes list - Check that mode metadata displays correctly - Confirm mode can be activated - - -I've created the mode configuration. Can you see the new mode in your mode list? - -Yes, I can see the new mode and switch to it -No, the mode doesn't appear in the list -The mode appears but has errors when switching - - - ]]> - - - - Permission Testing - - - Use read tools on various files - All read operations should work - - - Try editing allowed file types - Edits succeed for matching patterns - - - Try editing restricted file types - FileRestrictionError for non-matching files - - - - - - Workflow Testing - - Execute main workflow from start to finish - Test each decision point - Verify error handling - Check completion criteria - - - - - Integration Testing - - Orchestrator mode compatibility - Mode switching functionality - Tool handoff between modes - Consistent behavior with other modes - - - - - - - Mode doesn't appear in list - - Syntax error in YAML - Invalid mode slug - File not saved - - Check YAML syntax, validate slug format - - - - File restriction not working - - Invalid regex pattern - Escaping issues in regex - Wrong file path format - - Test regex pattern, use proper escaping - - - - - Mode not following instructions - - Instructions not in .roo/rules-[slug]/ folder - XML parsing errors - Conflicting instructions - - Verify file locations and XML validity - - - - - - Verify instruction files exist in correct location - -.roo -true - - ]]> - - - - Check mode configuration syntax - -.roomodes - - ]]> - - - - Test file restriction patterns - -. -your_file_pattern_here - - ]]> - - - - - Test incrementally as you build the mode - Start with minimal configuration and add complexity - Document any special requirements or dependencies - Consider edge cases and error scenarios - Get feedback from potential users of the mode - - \ No newline at end of file diff --git a/.roo/rules-mode-writer/7_validation_cohesion_checking.xml b/.roo/rules-mode-writer/7_validation_cohesion_checking.xml deleted file mode 100644 index a327a1e4659..00000000000 --- a/.roo/rules-mode-writer/7_validation_cohesion_checking.xml +++ /dev/null @@ -1,201 +0,0 @@ - - - Guidelines for thoroughly validating mode changes to ensure cohesion, - consistency, and prevent contradictions across all mode components. - - - - - - Every change must be reviewed in context of the entire mode - - - Read all existing XML instruction files - Verify new changes align with existing patterns - Check for duplicate or conflicting instructions - Ensure terminology is consistent throughout - - - - - - Use ask_followup_question extensively to clarify ambiguities - - - User's intent is unclear - Multiple interpretations are possible - Changes might conflict with existing functionality - Impact on other modes needs clarification - - -I notice this change might affect how the mode interacts with file permissions. Should we also update the file regex patterns to match? - -Yes, update the file regex to include the new file types -No, keep the current file restrictions as they are -Let me explain what file types I need to work with -Show me the current file restrictions first - - - ]]> - - - - - Actively search for and resolve contradictions - - - - Permission Mismatch - Instructions reference tools the mode doesn't have access to - Either grant the tool permission or update the instructions - - - Workflow Conflicts - Different XML files describe conflicting workflows - Consolidate workflows and ensure single source of truth - - - Role Confusion - Mode's roleDefinition doesn't match its actual capabilities - Update roleDefinition to accurately reflect the mode's purpose - - - - - - - - Before making any changes - - Read and understand all existing mode files - Create a mental model of current mode behavior - Identify potential impact areas - Ask clarifying questions about intended changes - - - - - While making changes - - Document each change and its rationale - Cross-reference with other files after each change - Verify examples still work with new changes - Update related documentation immediately - - - - - After changes are complete - - - All XML files are well-formed and valid - File naming follows established patterns - Tag names are consistent across files - No orphaned or unused instructions - - - - roleDefinition accurately describes the mode - whenToUse is clear and distinguishable - Tool permissions match instruction requirements - File restrictions align with mode purpose - Examples are accurate and functional - - - - Mode boundaries are well-defined - Handoff points to other modes are clear - No overlap with other modes' responsibilities - Orchestrator can correctly route to this mode - - - - - - - - Maintain consistent tone and terminology - - Use the same terms for the same concepts throughout - Keep instruction style consistent across files - Maintain the same level of detail in similar sections - - - - - Ensure instructions flow logically - - Prerequisites come before dependent steps - Complex concepts build on simpler ones - Examples follow the explained patterns - - - - - Ensure all aspects are covered without gaps - - Every mentioned tool has usage instructions - All workflows have complete examples - Error scenarios are addressed - - - - - - - - Before we proceed with changes, I want to ensure I understand the full scope. What is the main goal of these modifications? - - Add new functionality while keeping existing features - Fix issues with current implementation - Refactor for better organization - Expand the mode's capabilities into new areas - - - - - - - This change might affect other parts of the mode. How should we handle the impact on [specific area]? - - Update all affected areas to maintain consistency - Keep the existing behavior for backward compatibility - Create a migration path from old to new behavior - Let me review the impact first - - - - - - - I've completed the changes and validation. Which aspect would you like me to test more thoroughly? - - Test the new workflow end-to-end - Verify file permissions work correctly - Check integration with other modes - Review all changes one more time - - - - - - - - Instructions reference tools not in the mode's groups - Either add the tool group or remove the instruction - - - File regex doesn't match described file types - Update regex pattern to match intended files - - - Examples don't follow stated best practices - Update examples to demonstrate best practices - - - Duplicate instructions in different files - Consolidate to single location and reference - - - \ No newline at end of file diff --git a/.roo/skills/evals-context/SKILL.md b/.roo/skills/evals-context/SKILL.md index 985b788b94f..ac818646de2 100644 --- a/.roo/skills/evals-context/SKILL.md +++ b/.roo/skills/evals-context/SKILL.md @@ -1,6 +1,6 @@ --- 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). +description: Provides context about the Klaus 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 internal eval results display. --- # Evals Codebase Context @@ -12,7 +12,6 @@ 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 @@ -31,7 +30,6 @@ This monorepo has **two distinct evals-related locations** that can cause confus | --------------------------- | -------------------------------------------------------------- | -------------------------------------------------------------- | | **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 @@ -84,18 +82,6 @@ apps/web-evals/ │ └── 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: @@ -115,7 +101,7 @@ The evals system is a distributed evaluation platform that runs AI coding tasks **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 +- **Runner**: Isolated Docker container with VS Code + Klaus Code extension + language runtimes - **Redis**: Pub/sub for real-time events (NOT task queuing) - **PostgreSQL**: Stores runs, tasks, metrics @@ -141,13 +127,6 @@ 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) @@ -179,10 +158,10 @@ cd packages/evals && npx vitest run cd apps/web-evals && npx vitest run ``` -## Key Types/Exports from `@roo-code/evals` +## Key Types/Exports from `@klaus-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` +- Used by `apps/web-evals` diff --git a/.roo/skills/roo-conflict-resolution/SKILL.md b/.roo/skills/roo-conflict-resolution/SKILL.md new file mode 100644 index 00000000000..4807180522f --- /dev/null +++ b/.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. +``` diff --git a/.roo/skills/roo-translation/SKILL.md b/.roo/skills/roo-translation/SKILL.md new file mode 100644 index 00000000000..dafffb78c97 --- /dev/null +++ b/.roo/skills/roo-translation/SKILL.md @@ -0,0 +1,155 @@ +--- +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 settings" +``` + +React component usage: + +```tsx +, + }} +/> +``` + +## 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 diff --git a/.roomodes b/.roomodes index 01f6ed45050..ba17940035a 100644 --- a/.roomodes +++ b/.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: - [ ] 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) - 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 diff --git a/.vscode/tasks.json b/.vscode/tasks.json index 549a1174a92..b8d7f53b348 100644 --- a/.vscode/tasks.json +++ b/.vscode/tasks.json @@ -17,7 +17,7 @@ { "label": "watch:webview", "type": "shell", - "command": "pnpm --filter @roo-code/vscode-webview dev", + "command": "pnpm --filter @klaus-code/vscode-webview dev", "group": "build", "problemMatcher": { "owner": "vite", diff --git a/CHANGELOG.md b/CHANGELOG.md index 9eb498b7f50..288869a5ef6 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,116 @@ +# BELOW is text written before FORK + # Roo Code Changelog +## [3.48.0] + +- 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) @@ -22,14 +133,14 @@ - Fix: Remove custom condensing model option (PR #10901 by @hannesrudolph) - Unify user content tags to 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) +- Fix: Padding on Klaus 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) +- Add Claude-like CLI flags and authentication fixes for the Klaus 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) +- Fix: Klaus 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) @@ -91,10 +202,10 @@ ## [3.39.3] - 2026-01-10 -![3.39.3 Release - Roo Code Router](/releases/3.39.3-release.png) +![3.39.3 Release - Klaus 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) +- Rename Klaus Code Cloud Provider to Klaus Code Router for clearer branding (PR #10560 by @roomote) +- Update Klaus 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) @@ -116,8 +227,8 @@ - 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: Move more types to @klaus-code/types for CLI support (PR #10583 by @cte) +- Chore: Add functionality to @klaus-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 @@ -139,8 +250,8 @@ - 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) +- VSCode shim and basic CLI for running Klaus Code headlessly (PR #10452 by @cte) +- Add CLI installer for headless Klaus 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) @@ -205,7 +316,7 @@ - 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: Enable mergeToolResultText for Klaus 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) @@ -499,7 +610,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 Router-centric onboarding flow (PR #9709 by @brunobergher) +- UX improvements to the Klaus 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) @@ -557,13 +668,13 @@ - Set native tools as default for minimax-m2 and claude-haiku-4.5 (PR #9586 by @daniel-lxs) - Make single file read only apply to XML tools (PR #9600 by @mrubens) - Enhance web-evals dashboard with dynamic tool columns and UX improvements (PR #9592 by @hannesrudolph) -- Revert "Add support for Roo Code Cloud as an embeddings provider" while we fix some issues (PR #9602 by @mrubens) +- Revert "Add support for Klaus Code Cloud as an embeddings provider" while we fix some issues (PR #9602 by @mrubens) ## [3.34.4] - 2025-11-25 ![3.34.4 Release - BFL Image Generation](/releases/3.34.4-release.png) -- Add new Black Forest Labs image generation models, free on Roo Code Cloud and also available on OpenRouter (PR #9587 and #9589 by @mrubens) +- Add new Black Forest Labs image generation models, free on Klaus Code Cloud and also available on OpenRouter (PR #9587 and #9589 by @mrubens) - Fix: Preserve dynamic MCP tool names in native mode API history to prevent tool name mismatches (PR #9559 by @daniel-lxs) - Fix: Preserve tool_use blocks in summary message during condensing with native tools to maintain conversation context (PR #9582 by @daniel-lxs) @@ -575,9 +686,9 @@ - Add Claude Opus 4.5 model to Claude Code provider (PR #9560 by @mrubens) - Add Claude Opus 4.5 model to Bedrock provider (#9571 by @pisicode, PR #9572 by @roomote) - Enable caching for Opus 4.5 model to improve performance (#9567 by @iainRedro, PR #9568 by @roomote) -- Add support for Roo Code Cloud as an embeddings provider (PR #9543 by @mrubens) +- Add support for Klaus Code Cloud as an embeddings provider (PR #9543 by @mrubens) - Fix ask_followup_question streaming issue and add missing tool cases (PR #9561 by @daniel-lxs) -- Add contact links to About Roo Code settings page (PR #9570 by @roomote) +- Add contact links to About Klaus Code settings page (PR #9570 by @roomote) - Switch from asdf to mise-en-place in bare-metal evals setup script (PR #9548 by @cte) ## [3.34.2] - 2025-11-24 @@ -586,7 +697,7 @@ - Add support for Claude Opus 4.5 in Anthropic and Vertex providers (PR #9541 by @daniel-lxs) - Add support for Claude Opus 4.5 in OpenRouter with prompt caching and reasoning budget (PR #9540 by @daniel-lxs) -- Add Roo Code Cloud as an image generation provider (PR #9528 by @mrubens) +- Add Klaus Code Cloud as an image generation provider (PR #9528 by @mrubens) - Fix: Gracefully skip unsupported content blocks in Gemini transformer (PR #9537 by @daniel-lxs) - Fix: Flush LiteLLM cache when credentials change on refresh (PR #9536 by @daniel-lxs) - Fix: Ensure XML parser state matches tool protocol on config update (PR #9535 by @daniel-lxs) @@ -598,7 +709,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 Router in evals (PR #9492 by @cte) +- Enable the Klaus Code Router in evals (PR #9492 by @cte) ## [3.34.0] - 2025-11-21 @@ -678,7 +789,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 Router pricing page and changes elsewhere (PR #9195 by @brunobergher) +- Klaus Code Router pricing page and changes elsewhere (PR #9195 by @brunobergher) ## [3.32.1] - 2025-11-14 @@ -704,7 +815,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 Router Anthropic input token normalization to avoid double-counting (thanks @hannesrudolph!) +- Fix: Klaus 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 @@ -844,7 +955,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 Router (thanks @app/roomote!) +- Add dynamic model loading for Klaus 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) @@ -1002,7 +1113,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 Router (thanks @mrubens!) +- New code-supernova stealth model in the Klaus Code Router (thanks @mrubens!) ## [3.28.3] - 2025-09-16 @@ -1040,8 +1151,8 @@ ![3.28.1 Release - Kangaroo riding rocket to the clouds](/releases/3.28.1-release.png) -- Announce Roo Code Cloud! -- Add cloud task button for opening tasks in Roo Code Cloud (thanks @app/roomote!) +- Announce Klaus Code Cloud! +- Add cloud task button for opening tasks in Klaus Code Cloud (thanks @app/roomote!) - Make Posthog telemetry the default (thanks @mrubens!) - Show notification when the checkpoint initialization fails (thanks @app/roomote!) - Bust cache in generated image preview (thanks @mrubens!) @@ -1050,9 +1161,9 @@ ## [3.28.0] - 2025-09-10 -![3.28.0 Release - Continue tasks in Roo Code Cloud](/releases/3.28.0-release.png) +![3.28.0 Release - Continue tasks in Klaus Code Cloud](/releases/3.28.0-release.png) -- feat: Continue tasks in Roo Code Cloud (thanks @brunobergher!) +- feat: Continue tasks in Klaus Code Cloud (thanks @brunobergher!) - feat: Support connecting to Cloud without redirect handling (thanks @mrubens!) - feat: Add toggle to control task syncing to Cloud (thanks @jr!) - feat: Add click-to-edit, ESC-to-cancel, and fix padding consistency for chat messages (#7788 by @hannesrudolph, PR by @app/roomote) @@ -1090,7 +1201,7 @@ ![3.26.7 Release - OpenAI Service Tiers](/releases/3.26.7-release.png) - Feature: Add OpenAI Responses API service tiers (flex/priority) with UI selector and pricing (thanks @hannesrudolph!) -- Feature: Add DeepInfra as a model provider in Roo Code (#7661 by @Thachnh, PR by @Thachnh) +- Feature: Add DeepInfra as a model provider in Klaus Code (#7661 by @Thachnh, PR by @Thachnh) - Feature: Update kimi-k2-0905-preview and kimi-k2-turbo-preview models on the Moonshot provider (thanks @CellenLee!) - Feature: Add kimi-k2-0905-preview to Groq, Moonshot, and Fireworks (thanks @daniel-lxs and Cline!) - Fix: Prevent countdown timer from showing in history for answered follow-up questions (#7624 by @XuyiK, PR by @daniel-lxs) @@ -1213,11 +1324,11 @@ ## [3.25.19] - 2025-08-19 -- Fix issue where new users couldn't select the Roo Code Router (thanks @daniel-lxs!) +- Fix issue where new users couldn't select the Klaus Code Router (thanks @daniel-lxs!) ## [3.25.18] - 2025-08-19 -- Add new stealth Sonic model through the Roo Code Router +- Add new stealth Sonic model through the Klaus 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!) @@ -1432,7 +1543,7 @@ ## [3.23.19] - 2025-07-23 -- Add Roo Code Cloud Waitlist CTAs (thanks @brunobergher!) +- Add Klaus Code Cloud Waitlist CTAs (thanks @brunobergher!) - Split commands on newlines when evaluating auto-approve - Smarter auto-deny of commands @@ -2052,7 +2163,7 @@ - Fix display issue of the programming language dropdown in the code block component (thanks @zhangtony239) - MCP server errors are now captured and shown in a new "Errors" tab (thanks @robertheadley) - Error logging will no longer break MCP functionality if the server is properly connected (thanks @ksze) -- You can now toggle the `terminal.integrated.inheritEnv` VSCode setting directly for the Roo Code settings (thanks @KJ7LNW) +- You can now toggle the `terminal.integrated.inheritEnv` VSCode setting directly for the Klaus Code settings (thanks @KJ7LNW) - Add `gemini-2.5-pro-preview-05-06` to the Vertex and Gemini providers (thanks @zetaloop) - Ensure evals exercises are up-to-date before running evals (thanks @shariqriazz) - Lots of general UI improvements (thanks @elianiva) @@ -2069,7 +2180,7 @@ ## [3.15.4] - 2025-05-04 -- Fix a nasty bug that would cause Roo Code to hang, particularly in orchestrator mode +- Fix a nasty bug that would cause Klaus Code to hang, particularly in orchestrator mode - Improve Gemini caching efficiency ## [3.15.3] - 2025-05-02 @@ -2108,8 +2219,8 @@ - Improve the auto-approve toggle buttons for some high-contrast VSCode themes - Offload expensive count token operations to a web worker (thanks @samhvw8) - Improve support for mult-root workspaces (thanks @snoyiatk) -- Simplify and streamline Roo Code's quick actions -- Allow Roo Code settings to be imported from the welcome screen (thanks @julionav) +- Simplify and streamline Klaus Code's quick actions +- Allow Klaus Code settings to be imported from the welcome screen (thanks @julionav) - Remove unused types (thanks @wkordalski) - Improve the performance of mode switching (thanks @dlab-anton) - Fix importing & exporting of custom modes (thanks @julionav) @@ -2273,7 +2384,7 @@ - Improve readFileTool XML output format (thanks @KJ7LNW!) - Add o1-pro support (thanks @arthurauffray!) - Follow symlinked rules files/directories to allow for more flexible rule setups -- Focus Roo Code in the sidebar when running tasks in the sidebar via the API +- Focus Klaus Code in the sidebar when running tasks in the sidebar via the API - Improve subtasks UI ## [3.11.10] - 2025-04-08 @@ -2295,7 +2406,7 @@ - Enhance Rust tree-sitter parser with advanced language structures (thanks @KJ7LNW!) - Persist settings on api.setConfiguration (thanks @gtaylor!) - Add deep links to settings sections -- Add command to focus Roo Code input field (thanks @axkirillov!) +- Add command to focus Klaus Code input field (thanks @axkirillov!) - Add resize and hover actions to the browser (thanks @SplittyDev!) - Add resumeTask and isTaskInHistory to the API (thanks @franekp!) - Fix bug displaying boolean/numeric suggested answers @@ -2344,7 +2455,7 @@ - Fix issue where prompts and settings tabs were not scrollable when accessed from dropdown menus - Update AWS region dropdown menu to the most recent data (thanks @Smartsheet-JB-Brown!) - Fix prompt enhancement for Bedrock (thanks @Smartsheet-JB-Brown!) -- Allow processes to access the Roo Code API via a unix socket +- Allow processes to access the Klaus Code API via a unix socket - Improve zh-TW Traditional Chinese translations (thanks @PeterDaveHello!) - Add support for Azure AI Inference Service with DeepSeek-V3 model (thanks @thomasjeung!) - Fix off-by-one error in tree-sitter line numbers @@ -2381,7 +2492,7 @@ - Fix list_code_definition_names to support files (thanks @KJ7LNW!) - Refactor tool-calling logic to make the code a lot easier to work with (thanks @diarmidmackenzie, @bramburn, @KJ7LNW, and everyone else who helped!) - Prioritize “Add to Context” in the code actions and include line numbers (thanks @samhvw8!) -- Add an activation command that other extensions can use to interface with Roo Code (thanks @gtaylor!) +- Add an activation command that other extensions can use to interface with Klaus Code (thanks @gtaylor!) - Preserve language characters in file @-mentions (thanks @aheizi!) - Browser tool improvements (thanks @afshawnlotfi!) - Display info about partial reads in the chat row @@ -2473,7 +2584,7 @@ ## [3.9.0] - 2025-03-18 -- Internationalize Roo Code into Catalan, German, Spanish, French, Hindi, Italian, Japanese, Korean, Polish, Portuguese, Turkish, Vietnamese, Simplified Chinese, and Traditional Chinese (thanks @feifei325!) +- Internationalize Klaus Code into Catalan, German, Spanish, French, Hindi, Italian, Japanese, Korean, Polish, Portuguese, Turkish, Vietnamese, Simplified Chinese, and Traditional Chinese (thanks @feifei325!) - Bring back support for MCP over SSE (thanks @aheizi!) - Add a text-to-speech option to have Roo talk to you as it works (thanks @heyseth!) - Choose a specific provider when using OpenRouter (thanks PhunkyBob!) @@ -2553,17 +2664,17 @@ ## [3.8.0] - 2025-03-07 -- Add opt-in telemetry to help us improve Roo Code faster (thanks Cline!) +- Add opt-in telemetry to help us improve Klaus Code faster (thanks Cline!) - Fix terminal overload / gray screen of death, and other terminal issues - Add a new experimental diff editing strategy that applies multiple diff edits at once (thanks @qdaxb!) -- Add support for a .rooignore to prevent Roo Code from read/writing certain files, with a setting to also exclude them from search/lists (thanks Cline!) +- Add support for a .rooignore to prevent Klaus Code from read/writing certain files, with a setting to also exclude them from search/lists (thanks Cline!) - Update the new_task tool to return results to the parent task on completion, supporting better orchestration (thanks @shaybc!) - Support running Roo in multiple editor windows simultaneously (thanks @samhvw8!) - Make checkpoints asynchronous and exclude more files to speed them up - Redesign the settings page to make it easier to navigate - Add credential-based authentication for Vertex AI, enabling users to easily switch between Google Cloud accounts (thanks @eonghk!) - Update the DeepSeek provider with the correct baseUrl and track caching correctly (thanks @olweraltuve!) -- Add a new “Human Relay” provider that allows you to manually copy information to a Web AI when needed, and then paste the AI's response back into Roo Code (thanks @NyxJae)! +- Add a new “Human Relay” provider that allows you to manually copy information to a Web AI when needed, and then paste the AI's response back into Klaus Code (thanks @NyxJae)! - Add observability for OpenAI providers (thanks @refactorthis!) - Support speculative decoding for LM Studio local models (thanks @adamwlarson!) - Improve UI for mode/provider selectors in chat @@ -2652,7 +2763,7 @@ ## [3.7.0] - 2025-02-24 -- Introducing Roo Code 3.7, with support for the new Claude Sonnet 3.7. Because who cares about skipping version numbers anymore? Thanks @lupuletic and @cte for the PRs! +- Introducing Klaus Code 3.7, with support for the new Claude Sonnet 3.7. Because who cares about skipping version numbers anymore? Thanks @lupuletic and @cte for the PRs! ## [3.3.26] - 2025-02-27 @@ -2841,7 +2952,7 @@ - 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! +- New Klaus Code community Discord at https://roocode.com/discord! ## [3.2.8] @@ -2873,9 +2984,9 @@ ## [3.2.0 - 3.2.2] -- **Name Change From Roo Cline to Roo Code:** We're excited to announce our new name! After growing beyond 50,000 installations, we've rebranded from Roo Cline to Roo Code to better reflect our identity as we chart our own course. +- **Name Change From Roo Cline to Klaus Code:** We're excited to announce our new name! After growing beyond 50,000 installations, we've rebranded from Roo Cline to Klaus Code to better reflect our identity as we chart our own course. -- **Custom Modes:** Create your own personas for Roo Code! While our built-in modes (Code, Architect, Ask) are still here, you can now shape entirely new ones: +- **Custom Modes:** Create your own personas for Klaus Code! While our built-in modes (Code, Architect, Ask) are still here, you can now shape entirely new ones: - Define custom prompts - Choose which tools each mode can access - Create specialized assistants for any workflow @@ -2934,7 +3045,7 @@ Join us at https://www.reddit.com/r/RooCode to share your custom modes and be pa ## [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 +- This release adds chat modes! Now you can ask Klaus 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 Klaus Code Reddit! https://www.reddit.com/r/RooCode ## [2.2.46] diff --git a/CLAUDE.md b/CLAUDE.md new file mode 100644 index 00000000000..b067da8ae82 --- /dev/null +++ b/CLAUDE.md @@ -0,0 +1,125 @@ +# CLAUDE.md + +This file guides Claude Code (claude.ai/code) when working with code in this repository. + +**For human developers**: See [DEVELOPMENT.md](DEVELOPMENT.md) for complete build instructions, environment setup, and release procedures. + +## Initial Context - Read These First + +**Main rules:** + +1. Do not write any reports to disk unless directly specified to do so. +2. Be token-optimized with your responses. +3. Do not use full sentences if list or shorter form will do. + +When starting work on Klaus Code, read these documentation files for comprehensive context: + +1. **[DEVELOPMENT.md](DEVELOPMENT.md)** - Complete development guide + + - Build and release procedures + - Upstream merge process with helper scripts + - Fork-specific divergences from Roo Code + - Testing and deployment workflows + +2. **[DEVELOPMENT-ClaudeCodeConnector.md](DEVELOPMENT-ClaudeCodeConnector.md)** - Claude Code OAuth provider + - Tool name prefixing mechanism (`oc_` prefix) + - OAuth authentication architecture + - Critical implementation details for Klaus Code's main differentiator + +These docs provide essential context for understanding Klaus Code's architecture and unique features. + +## Project Overview + +Klaus Code is an AI-powered VS Code extension that helps with coding tasks. It's a TypeScript monorepo using pnpm workspaces and Turborepo. + +## Build and Development Commands + +```bash +# Install dependencies +pnpm install + +# Run all linting +pnpm lint + +# Run all type checking +pnpm check-types + +# Run all tests +pnpm test + +# Format code +pnpm format + +# Build all packages +pnpm build + +# Build and package VSIX +pnpm vsix + +# Clean all build artifacts +pnpm clean +``` + +### Running Individual Tests + +Tests use Vitest. Run tests from within the correct workspace directory: + +```bash +# Backend tests (src/) +cd src && npx vitest run path/to/test-file.test.ts + +# Webview UI tests +cd webview-ui && npx vitest run src/path/to/test-file.test.ts +``` + +Do NOT run `npx vitest run src/...` from the project root - this causes "vitest: command not found" errors. + +### Development Mode + +Press F5 in VS Code to launch the extension in debug mode. Changes hot reload automatically. + +## Repository Structure + +- `src/` - Main VS Code extension (backend) + - `api/providers/` - LLM provider integrations (Anthropic, OpenAI, Gemini, Bedrock, etc.) + - `core/` - Agent core logic + - `task/Task.ts` - Main agent task orchestration + - `tools/` - Tool implementations (ReadFile, WriteToFile, ExecuteCommand, etc.) + - `webview/ClineProvider.ts` - Bridge between extension and webview + - `config/ContextProxy.ts` - State management for settings + - `prompts/` - System prompt construction + - `services/` - Supporting services (MCP, code indexing, checkpoints, etc.) + - `integrations/` - VS Code integrations (terminal, editor, workspace) +- `webview-ui/` - React frontend (Vite, Tailwind, Radix UI) +- `packages/` - Shared packages + - `types/` - Shared TypeScript types + - `core/` - Core utilities + - `cloud/` - Cloud service integration + - `telemetry/` - Telemetry service +- `apps/` - Additional applications (CLI, e2e tests, web apps) + +## Architecture Notes + +### 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 clicks "Save". Wiring inputs directly to the live state causes race conditions. + +### JSON File Writing + +Use `safeWriteJson(filePath, data)` from `src/utils/safeWriteJson.ts` instead of `JSON.stringify` with file-write operations. This utility: + +- Creates parent directories automatically +- Prevents data corruption via atomic writes with locking +- Streams writes to minimize memory footprint + +Test files are exempt from this rule. + +### Styling + +Use Tailwind CSS classes instead of inline style objects. VSCode CSS variables must be added to `webview-ui/src/index.css` before using them in Tailwind classes. + +## Code Quality Rules + +- Never disable lint rules without explicit user approval +- Ensure all tests pass before submitting changes +- The `vi`, `describe`, `test`, `it` functions from Vitest are globally available (defined in tsconfig.json) - no need to import them diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 869b59a16da..b69c6ddcf7d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -11,9 +11,9 @@ -# Contributing to Roo Code +# Contributing to Klaus 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. +Klaus 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 @@ -52,7 +52,7 @@ Our roadmap guides the project's direction. Align your contributions with these Mention alignment with these areas in your PRs. -### 3. Join the Roo Code Community +### 3. Join the Klaus 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). @@ -79,7 +79,7 @@ All contributions start with a GitHub Issue using our skinny templates. ### 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). +- For docs, visit [Klaus Code Docs](https://github.com/RooCodeInc/Roo-Code-Docs). ### Reporting Bugs @@ -87,7 +87,7 @@ All contributions start with a GitHub Issue using our skinny templates. - 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 + - Klaus 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 @@ -126,7 +126,6 @@ pnpm install ### 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. @@ -138,4 +137,4 @@ pnpm install ## Legal -By contributing, you agree your contributions will be licensed under the Apache 2.0 License, consistent with Roo Code's licensing. +By contributing, you agree your contributions will be licensed under the Apache 2.0 License, consistent with Klaus Code's licensing. diff --git a/DEVELOPMENT-ClaudeCodeConnector.md b/DEVELOPMENT-ClaudeCodeConnector.md new file mode 100644 index 00000000000..e5557f1ea0e --- /dev/null +++ b/DEVELOPMENT-ClaudeCodeConnector.md @@ -0,0 +1,993 @@ +# Claude Code Connector Documentation + +This document describes the Claude Code OAuth authentication mechanism and the special `oc_` tool name prefixing workaround required for tool calling. + +## Quick Navigation + +**Jump to:** + +- [Quick Reference](#quick-reference) - Key files, line numbers, constants +- [Architecture](#architecture) - Flow diagram +- [OAuth Authentication](#oauth-authentication) - Headers, tokens, metadata +- [Usage Tracking](#usage-tracking) - How Claude Code checks quotas and rate limits +- [Tool Name Prefixing](#tool-name-prefixing-mechanism) - Core workaround (`oc_` prefix) +- [Adding New Models](#adding-new-models) - How to add Claude models (e.g., Opus 4.6) +- [Request/Response Examples](#requestresponse-flow-examples) - Complete flows +- [Troubleshooting](#troubleshooting) - Common issues + +## Quick Reference + +### mitmproxy + +in one window: +mitmweb --listen-host 127.0.0.1 --listen-port 58888 --web-port 8081 --web-open-browser=false + +in second window +export NODE_EXTRA_CA_CERTS="/Users/$USER/.mitmproxy/mitmproxy-ca-cert.pem" +export NODE_TLS_REJECT_UNAUTHORIZED=0 +export HTTP_PROXY="http://127.0.0.1:58888" +export HTTPS_PROXY="http://127.0.0.1:58888" +sudo cp ~/.mitmproxy/mitmproxy-ca-cert.pem /usr/local/share/mitmproxy-ca.pem +sudo chmod 644 /usr/local/share/mitmproxy-ca.pem +export NODE_EXTRA_CA_CERTS=/usr/local/share/mitmproxy-ca.pem + +claude + +in browser check the requests: +http://127.0.0.1:8081 + +**Parsing saved flow files (.mitm):** + +```bash +pip install mitmproxy +python docs/parse-mitm-flows.py docs/2026.02.17-claude-code2.1.45.har # summary +python docs/parse-mitm-flows.py docs/2026.02.17-claude-code2.1.45.har --json # full JSON +``` + +### Critical Files & Line Numbers + +| File | Key Lines | Purpose | +| -------------------------------------------------- | --------- | ----------------------------------------------- | +| `src/integrations/claude-code/streaming-client.ts` | L10 | `TOOL_NAME_PREFIX = "oc_"` constant | +| | L35-44 | `prefixToolName()` / `stripToolNamePrefix()` | +| | L52-57 | `prefixToolNames()` - tools array | +| | L63-86 | `prefixToolNamesInMessages()` - message history | +| | L92-108 | `prefixToolChoice()` - tool_choice | +| | L644-662 | Response parsing with prefix stripping | +| `src/api/providers/claude-code.ts` | L67 | `ClaudeCodeHandler` class | +| | L294-305 | `getModel()` - model selection | +| | L117-255 | `createMessage()` - API request flow | +| `src/integrations/claude-code/oauth.ts` | L13 | `generateUserId()` - user_id hash | +| | L93-203 | OAuth token management | +| `packages/types/src/providers/claude-code.ts` | L46-74 | Model definitions | +| | L86-93 | Model family patterns (normalization) | +| | L112-136 | `normalizeClaudeCodeModelId()` | + +### Key Constants + +```typescript +TOOL_NAME_PREFIX = "oc_" // streaming-client.ts:10 +CLAUDE_CODE_API_ENDPOINT = "..." // streaming-client.ts:20 +claudeCodeDefaultModelId = "claude-sonnet-4-6" // claude-code.ts:78 +X_STAINLESS_PACKAGE_VERSION = "0.74.0" // updated from 0.70.0 (v2.1.45) +``` + +### Model Support Matrix + +**Current models (v2.1.45 / 2026-02-17):** + +| Model | API Model ID | Max Tokens | Context | Reasoning | Status | +| ----------------- | --------------------------- | ---------- | ------- | ----------------------------------- | ------------ | +| claude-haiku-4-5 | `claude-haiku-4-5-20251001` | 32K | 200K | None (no effort/thinking) | ✅ Supported | +| claude-sonnet-4-6 | `claude-sonnet-4-6` | 32K | 200K | Adaptive + effort (low/medium/high) | ✅ Default | +| claude-opus-4-6 | `claude-opus-4-6` | 128K | 200K→1M | Adaptive + effort (low/medium/high) | ✅ Supported | + +**Removed models** (no longer offered by Claude Code 2.1.45): + +- `claude-sonnet-4-5` - removed +- `claude-opus-4-5` - removed + +## Overview + +The Claude Code connector (`src/api/providers/claude-code.ts`) uses OAuth authentication to access Anthropic's Claude Code API. Unlike regular Anthropic API tokens, Claude Code OAuth tokens have a strict validation requirement: **third-party tool names are rejected**. + +To work around this limitation, the connector prefixes all tool names with `oc_` when sending requests to the API and strips the prefix from responses. + +## Architecture + +``` +┌─────────────────────────────────────────────────────────────────────────────┐ +│ Claude Code Connector Flow │ +├─────────────────────────────────────────────────────────────────────────────┤ +│ │ +│ ┌──────────────┐ ┌─────────────────────────┐ ┌────────────────────┐ │ +│ │ Klaus Code │───▶│ src/api/providers/ │───▶│ src/integrations/ │ │ +│ │ Agent │ │ claude-code.ts │ │ claude-code/ │ │ +│ └──────────────┘ └─────────────────────────┘ │ streaming-client.ts│ │ +│ │ └────────────────────┘ │ +│ ▼ │ │ +│ ┌──────────────┐ ▼ │ +│ │ OAuth Token │ Prefix tools: │ +│ │ from │ "read_file" → │ +│ │ OAuth Manager│ "oc_read_file" │ +│ └──────────────┘ │ +│ │ │ +│ ▼ │ +│ ┌──────────────────────┐ │ +│ │ Anthropic API │ │ +│ │ /v1/messages │ │ +│ │ (OAuth tokens) │ │ +│ └──────────────────────┘ │ +│ │ │ +│ ▼ │ +│ ┌──────────────────────┐ │ +│ │ Strip prefix: │ │ +│ │ "oc_read_file" → │ │ +│ │ "read_file" │ │ +│ └──────────────────────┘ │ +│ │ │ +│ ▼ │ +│ ┌──────────────────────┐ │ +│ │ Agent receives │ │ +│ │ original tool names │ │ +│ └──────────────────────┘ │ +│ │ +└─────────────────────────────────────────────────────────────────────────────┘ +``` + +## OAuth Authentication + +### OAuth Flow Components + +| Component | File | Purpose | +| ------------------------ | -------------------------------------------------- | ---------------------------------------------- | +| `ClaudeCodeOAuthManager` | `src/integrations/claude-code/oauth.ts` | Manages OAuth tokens, refresh, email retrieval | +| `ClaudeCodeHandler` | `src/api/providers/claude-code.ts` | API handler using OAuth tokens | +| `createStreamingMessage` | `src/integrations/claude-code/streaming-client.ts` | Makes API requests with OAuth | + +### OAuth Token Requirements + +Claude Code OAuth tokens require specific metadata: + +- **`user_id`**: A hash combining organization ID and email (generated in `src/integrations/claude-code/oauth.ts` via `generateUserId()`) +- **Beta headers**: Claude Code uses multiple beta features + +### Required API Headers + +**Updated 2026-02-17**: Headers from claude-code CLI v2.1.45 reverse engineering. + +```typescript +// POST /v1/messages?beta=true (opus-4-6/sonnet-4-6 example) +const headers: Record = { + // Core + Accept: "application/json", + Authorization: `Bearer ${accessToken}`, + "Content-Type": "application/json", + "anthropic-version": "2023-06-01", + "anthropic-dangerous-direct-browser-access": "true", + + // Identity (Klaus Code uses vscode variant) + "User-Agent": "claude-cli/2.1.45 (external, cli)", // Klaus: `klaus-code/${version} (vscode, extension)` + "x-app": "cli", // Klaus: "vscode-extension" + + // Stainless SDK headers (v0.74.0 as of 2026-02-17, was 0.70.0) + "X-Stainless-Lang": "js", + "X-Stainless-Package-Version": "0.74.0", + "X-Stainless-OS": "Linux", // or "Windows"/"MacOS" + "X-Stainless-Arch": "x64", // or "arm64" + "X-Stainless-Runtime": "node", + "X-Stainless-Runtime-Version": "v22.14.0", + "X-Stainless-Retry-Count": "0", + "X-Stainless-Timeout": "600", + + // Browser-like headers + "accept-language": "*", + "sec-fetch-mode": "cors", + "accept-encoding": "br, gzip, deflate", + + // anthropic-beta: varies by call type (see Beta Flags table below) + "anthropic-beta": "...", +} +``` + +**Note on Billing/Telemetry in System Prompt:** + +The official Claude Code CLI v2.1.45 injects a billing metadata entry as the FIRST system prompt block: + +```json +{ "type": "text", "text": "x-anthropic-billing-header: cc_version=2.1.45.adc; cc_entrypoint=cli; cch=00000;" } +``` + +Klaus Code should inject the equivalent for its version (`cc_entrypoint=vscode-extension`). **This is a system prompt text entry, NOT a request header.** If Klaus Code previously had errors with this, check that it's formatted as a `type: "text"` block — NOT as an HTTP header or a different format. + +## Usage Tracking + +### Overview + +Claude Code tracks usage and quota through a combination of: + +1. Response headers containing unified rate limit information +2. A special "quota" message request to fetch current usage statistics +3. Usage data embedded in every message response + +### API Endpoints for Usage + +**Updated 2026-02-17 (v2.1.45):** + +| Endpoint | Method | Purpose | +| ----------------------------------- | ------ | -------------------------------------------------- | +| `/api/oauth/account/settings` | GET | Account settings and preferences (startup) | +| `/api/oauth/usage` | GET | **NEW** — Usage utilization by tier | +| `/api/claude_code_grove` | GET | Feature flags (`grove_enabled`, `domain_excluded`) | +| `/api/oauth/claude_cli/client_data` | GET | **NEW** — Client config data (returns `{}`) | +| `/api/claude_code_penguin_mode` | GET | **NEW** — Extra usage status | +| `/v1/messages?beta=true` | POST | Message API (includes usage data) | + +All GET requests use: + +``` +User-Agent: claude-code/2.1.45 (or axios/1.8.4 for penguin_mode) +anthropic-beta: oauth-2025-04-20 +Accept: application/json, text/plain, */* +Accept-Encoding: gzip, compress, deflate, br +Connection: close +``` + +### Usage Endpoint (NEW) + +**GET `/api/oauth/usage`** returns per-tier utilization — prefer this over rate limit response headers: + +```json +{ + "five_hour": { + "utilization": 0.0, + "resets_at": "2026-02-17T21:00:00.276803+00:00" + }, + "seven_day": { + "utilization": 5.0, + "resets_at": "2026-02-23T09:00:00.276824+00:00" + }, + "seven_day_oauth_apps": null, + "seven_day_opus": null, + "seven_day_sonnet": null, + "seven_day_cowork": null, + "iguana_necktie": null, + "extra_usage": { + "is_enabled": false, + "monthly_limit": null, + "used_credits": null, + "utilization": null + } +} +``` + +### Penguin Mode Endpoint (NEW) + +**GET `/api/claude_code_penguin_mode`** — extra/paid usage status: + +```json +{ "enabled": false, "disabled_reason": "extra_usage_disabled" } +``` + +### Account Settings Endpoint + +**GET `/api/oauth/account/settings`** — called at startup for user preferences. Response includes account configuration and dismissed banner IDs. + +### API Endpoint + +**CRITICAL**: The OAuth-authenticated endpoint requires `?beta=true` query parameter: + +``` +POST https://api.anthropic.com/v1/messages?beta=true +``` + +Without this parameter, the API returns "invalid x-api-key" error even with valid OAuth tokens. + +### Beta Flags by Call Type + +**Updated 2026-02-17 (claude-code v2.1.45):** + +| Call Type | anthropic-beta | +| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | +| Quota check (haiku, max_tokens=1) | `oauth-2025-04-20,interleaved-thinking-2025-05-14,prompt-caching-scope-2026-01-05` | +| Haiku (standard / structured output) | `oauth-2025-04-20,interleaved-thinking-2025-05-14,prompt-caching-scope-2026-01-05,structured-outputs-2025-12-15` | +| Sonnet-4-6 / Opus-4-6 messages | `claude-code-20250219,oauth-2025-04-20,adaptive-thinking-2026-01-28,prompt-caching-scope-2026-01-05,effort-2025-11-24` | +| `/v1/messages/count_tokens` (any model) | `claude-code-20250219,oauth-2025-04-20,adaptive-thinking-2026-01-28,prompt-caching-scope-2026-01-05,token-counting-2024-11-01` | + +**Beta flag details:** + +| Beta Flag | Purpose / Notes | +| ---------------------------------------- | --------------------------------------------------------------------------------- | +| `oauth-2025-04-20` | Required for OAuth — present in ALL calls | +| `interleaved-thinking-2025-05-14` | Haiku thinking (old models) | +| `adaptive-thinking-2026-01-28` | **NEW** — replaces `interleaved-thinking` for sonnet/opus-4-6 | +| `prompt-caching-scope-2026-01-05` | Scope-based caching — present in ALL calls (replaces `prompt-caching-2024-07-31`) | +| `effort-2025-11-24` | **NEW** — enables `output_config.effort` field for sonnet/opus-4-6 | +| `claude-code-20250219` | Required for sonnet-4-6/opus-4-6 messages AND count_tokens | +| `token-counting-2024-11-01` | count_tokens endpoint only | +| `structured-outputs-2025-12-15` | Added when using structured output (haiku) | +| `prompt-caching-2024-07-31` | **OBSOLETE** — replaced by `prompt-caching-scope-2026-01-05` | +| `fine-grained-tool-streaming-2025-05-14` | Not used by official CLI | + +**BREAKING CHANGE from v2.1.39**: `claude-code-20250219` is now included in regular `/v1/messages` requests for sonnet-4-6 and opus-4-6 (was previously only for count_tokens). + +### Klaus Code Implementation Status + +**Current implementation** (`streaming-client.ts:541-555`): + +```typescript +const headers: Record = { + Accept: "application/json", // ✅ Matches official + Authorization: `Bearer ${accessToken}`, // ✅ Matches official + "Content-Type": "application/json", // ✅ Matches official + "User-Agent": CLAUDE_CODE_API_CONFIG.userAgent, // ✅ Matches format + "Anthropic-Version": CLAUDE_CODE_API_CONFIG.version, // ✅ Matches official + "Anthropic-Beta": betas.join(","), // ✅ Model-aware (see beta table) + "x-app": CLAUDE_CODE_API_CONFIG.xApp, // ✅ Intentionally different + "anthropic-dangerous-direct-browser-access": "true", // ✅ Matches official + "accept-language": "*", // ✅ Matches official + "sec-fetch-mode": "cors", // ✅ Matches official + "accept-encoding": "br, gzip, deflate", // ✅ Matches official + ...CLAUDE_CODE_API_CONFIG.stainlessHeaders, // ✅ X-Stainless-Package-Version: 0.74.0 +} +``` + +**Implementation is current as of v2.1.45 (2026-02-17):** + +- `X-Stainless-Package-Version`: `0.74.0` ✅ +- Beta flags are model-aware: adaptive models (`sonnet-4-6`/`opus-4-6`) get `adaptiveBetas`, others get `defaultBetas` ✅ +- Uses `prompt-caching-scope-2026-01-05` (old `prompt-caching-2024-07-31` removed) ✅ +- `adaptive-thinking-2026-01-28` and `effort-2025-11-24` included for 4-6 models ✅ + +### Quota Check Request + +Claude Code sends a minimal message request to check usage quotas (uses same headers as above): + +```typescript +// Quota check request body +POST /v1/messages?beta=true +{ + "model": "claude-haiku-4-5-20251001", // Cheapest model + "max_tokens": 1, // Minimal output + "messages": [ + { + "role": "user", + "content": "quota" // Special quota keyword + } + ], + "metadata": { + "user_id": "user_{hash}_account_{uuid}_session_{uuid}" + } +} +``` + +### Unified Rate Limit Headers + +**Response headers from `/v1/messages` requests include:** + +```typescript +// Response headers (example values) +{ + // Status indicators + "anthropic-ratelimit-unified-status": "allowed", // Overall status + "anthropic-ratelimit-unified-5h-status": "allowed", // 5-hour tier + "anthropic-ratelimit-unified-7d-status": "allowed", // 7-day tier + "anthropic-ratelimit-unified-overage-status": "allowed", // Overage tier + + // Reset timestamps (Unix epoch) + "anthropic-ratelimit-unified-5h-reset": "1770411600", // 5h tier reset + "anthropic-ratelimit-unified-7d-reset": "1770624000", // 7d tier reset + "anthropic-ratelimit-unified-overage-reset": "1772323200", // Overage reset + "anthropic-ratelimit-unified-reset": "1770411600", // Next reset + + // Utilization percentages (0.0 to 1.0+) + "anthropic-ratelimit-unified-5h-utilization": "0.0", // 5h tier usage + "anthropic-ratelimit-unified-7d-utilization": "0.52", // 7d tier usage (52%) + "anthropic-ratelimit-unified-overage-utilization": "0.0", // Overage usage + + // Policy indicators + "anthropic-ratelimit-unified-representative-claim": "five_hour", // Most restrictive tier + "anthropic-ratelimit-unified-fallback-percentage": "0.5", // Fallback threshold + + // Standard response headers + "anthropic-organization-id": "83615e56-057b-4fba-8ae9-f2bb33880482", + "request-id": "req_011CXs9q5frcXauixA6aPLbY", + "Content-Type": "application/json", + // ... other standard headers +} +``` + +### Usage Data in Message Responses + +Every message response includes detailed token usage: + +```typescript +// From SSE stream: event: message_start +{ + "type": "message_start", + "message": { + "model": "claude-haiku-4-5-20251001", + "usage": { + // Token counts + "input_tokens": 292, + "cache_creation_input_tokens": 0, + "cache_read_input_tokens": 0, + "output_tokens": 1, + + // Prompt caching details + "cache_creation": { + "ephemeral_5m_input_tokens": 0, + "ephemeral_1h_input_tokens": 0 + }, + + // Service metadata + "service_tier": "standard", + "inference_geo": "not_available" + } + } +} + +// At the end: event: message_delta +{ + "type": "message_delta", + "usage": { + "output_tokens": 135 // Final output token count + } +} +``` + +### Implementation Strategy for Klaus Code + +To replicate Claude Code's usage tracking in Klaus Code: + +1. **Parse rate limit headers** from every `/v1/messages` response +2. **Aggregate usage data** from `message_start` and `message_delta` events +3. **Send periodic quota checks** using the minimal "quota" message pattern +4. **Display usage information** in the UI with: + - Current utilization percentage for each tier (5h, 7d, overage) + - Time until next reset + - Representative claim (which tier is limiting) + - Token counts (input, cached, output) + +**Example Usage Display:** + +``` +Rate Limits (5h tier active): +├─ 5-hour: 0.0% used (resets in 4h 23m) +├─ 7-day: 52% used (resets in 2d 14h) +└─ Overage: 0.0% used + +Current Request: +├─ Input: 292 tokens +├─ Cached: 0 created, 0 read +└─ Output: 135 tokens +``` + +### Key Implementation Files + +For Klaus Code implementation: + +- `src/integrations/claude-code/streaming-client.ts` - Add header parsing +- `src/api/providers/claude-code.ts` - Aggregate usage statistics +- `webview-ui/src/components/` - Display usage in UI + +## Tool Name Prefixing Mechanism + +### Why Prefix Is Needed + +Anthropic's Claude Code OAuth validation rejects tool names that don't belong to Claude Code's official toolset. Klaus Code's custom tools (like `read_file`, `write_to_file`, etc.) would fail validation. + +### Prefix Constants + +```typescript +// src/integrations/claude-code/streaming-client.ts:10 +const TOOL_NAME_PREFIX = "oc_" +``` + +### Prefix/Suffix Functions + +```typescript +// Add prefix to tool names +export function prefixToolName(name: string): string { + return `${TOOL_NAME_PREFIX}${name}` // "read_file" → "oc_read_file" +} + +// Remove prefix from tool names +export function stripToolNamePrefix(name: string): string { + if (name.startsWith(TOOL_NAME_PREFIX)) { + return name.slice(TOOL_NAME_PREFIX.length) // "oc_read_file" → "read_file" + } + return name +} +``` + +### Where Prefix Is Applied + +1. **Tools array in request body** (`src/integrations/claude-code/streaming-client.ts:52-57`): + + ```typescript + function prefixToolNames(tools: Anthropic.Messages.Tool[]): Anthropic.Messages.Tool[] { + return tools.map((tool) => ({ + ...tool, + name: prefixToolName(tool.name), + })) + } + ``` + +2. **tool_choice when type is "tool"** (`src/integrations/claude-code/streaming-client.ts:92-108`): + + ```typescript + function prefixToolChoice(toolChoice): Anthropic.Messages.ToolChoice | undefined { + if (toolChoice.type === "tool" && "name" in toolChoice) { + return { ...toolChoice, name: prefixToolName(toolChoice.name) } + } + return toolChoice + } + ``` + +3. **tool_use blocks in messages** (`src/integrations/claude-code/streaming-client.ts:63-86`): + ```typescript + function prefixToolNamesInMessages(messages: Anthropic.Messages.MessageParam[]) { + return messages.map((message) => { + const prefixedContent = message.content.map((block) => { + if (block.type === "tool_use") { + return { ...block, name: prefixToolName(block.name) } + } + return block + }) + return { ...message, content: prefixedContent } + }) + } + ``` + +### Where Prefix Is Stripped + +**Response parsing** (`src/integrations/claude-code/streaming-client.ts:644-662`): + +```typescript +case "tool_use": { + const originalName = stripToolNamePrefix(contentBlock.name as string) + contentBlocks.set(index, { + type: "tool_use", + text: "", + id: contentBlock.id as string, + name: originalName, // Stripped name for internal use + arguments: "", + }) + yield { + type: "tool_call_partial", + index, + id: contentBlock.id as string, + name: originalName, // Original name exposed to agent + arguments: undefined, + } + break +} +``` + +## Adding New Models + +### Process for Adding Claude Models + +**File to modify**: `packages/types/src/providers/claude-code.ts` + +**Steps**: + +1. **Add model definition** to `claudeCodeModels` object (L46-74): + + ```typescript + // For haiku (no thinking/effort): + "claude-haiku-4-5-20251001": { + maxTokens: 32_000, + contextWindow: 200_000, + supportsImages: true, + supportsPromptCache: true, + supportsReasoningBudget: false, + supportsReasoningEffort: false, + description: "Claude Haiku 4.5 - Fast and lightweight", + } + + // For sonnet/opus with adaptive thinking + effort: + "claude-sonnet-4-6": { + maxTokens: 32_000, + contextWindow: 200_000, + supportsImages: true, + supportsPromptCache: true, + supportsReasoningBudget: false, // uses adaptive, not budget + supportsReasoningEffort: ["low", "medium", "high"], // no "disable" + reasoningEffort: "low", // default + description: "Claude Sonnet 4.6 - Balanced performance", + } + ``` + +2. **Update model family patterns** (L86-93) for normalization: + + ```typescript + { pattern: /sonnet.*4[._-]?6/i, target: "claude-sonnet-4-6" }, + { pattern: /opus.*4[._-]?6/i, target: "claude-opus-4-6" }, + ``` + +3. **Update JSDoc examples** (L96-103) to document the mapping. + +4. **Test**: + ```bash + pnpm check-types # Verify TypeScript + cd src && npx vitest run api/providers/__tests__/claude-code.spec.ts + pnpm vsix # Build extension + code --install-extension bin/klaus-code-*.vsix --force + ``` + +**Model string is passed directly to API** - no additional logic needed in `streaming-client.ts`. + +### Reasoning API: Adaptive Thinking (NEW v2.1.45) + +**BREAKING CHANGE**: 4-6 models no longer use `budget_tokens`. Instead: + +```json +// v2.1.45 API body (sonnet-4-6 / opus-4-6): +{ + "model": "claude-sonnet-4-6", + "max_tokens": 32000, + "thinking": { "type": "adaptive" }, + "output_config": { "effort": "low" }, + "stream": true +} +``` + +| Field | Value | Notes | +| ---------------------- | ------------------------------- | ----------------------------------------- | +| `thinking.type` | `"adaptive"` | Replaces `"enabled"` with `budget_tokens` | +| `output_config.effort` | `"low"` / `"medium"` / `"high"` | Replaces top-level `"effort"` field | + +**Haiku** does NOT send `thinking` or `output_config` at all. + +### Capabilities Reference + +- `supportsImages`: Image input support +- `supportsPromptCache`: Prompt caching support +- `supportsReasoningBudget`: Budget-based thinking (old models, `false` for 4-6) +- `supportsReasoningEffort`: Adaptive effort levels (`["low","medium","high"]`) or `false` + +### Model Selection Flow + +``` +User selects model → getModel() retrieves definition → Model ID passed to streaming-client.ts → API request with model string +``` + +The Claude Code API handles model capabilities automatically - no special provider-side logic required. + +### Reference: Opus 4.6 Implementation in Other Providers + +See commit `47bba1c2f` for complete implementation details. + +**Model definitions**: + +- `packages/types/src/providers/anthropic.ts:52-72` - Anthropic Opus 4.6 with tiered pricing +- `packages/types/src/providers/bedrock.ts:+27` - Bedrock model ID: `anthropic.claude-opus-4-6-v1:0` +- `packages/types/src/providers/vertex.ts:+27` - Vertex Opus 4.6 with 1M context tiers +- `packages/types/src/providers/openrouter.ts:+6` - OpenRouter reasoning budget sets +- `packages/types/src/providers/vercel-ai-gateway.ts:+4` - Vercel capability sets + +**Provider implementations**: + +- `src/api/providers/anthropic.ts:68-76,334-342` - 1M context beta flag handling +- `src/api/providers/bedrock.ts:+13` - Tier pricing for 1M context +- `src/api/providers/fetchers/openrouter.ts:+10` - maxTokens overrides + +**UI changes**: + +- `webview-ui/src/components/settings/providers/Anthropic.tsx:+4` - 1M context checkbox +- `webview-ui/src/components/settings/providers/Bedrock.tsx:+2` - Bedrock UI updates +- `webview-ui/src/components/settings/providers/Vertex.tsx:+2` - Vertex UI updates +- `webview-ui/src/components/ui/hooks/useSelectedModel.ts:+29` - Model selection logic + +**Key differences from other providers**: + +- Claude Code: No pricing tiers (subscription-based) +- Claude Code: No 1M context beta flag UI (handled automatically) +- Claude Code: Simpler model definition (no cost fields) + +## Request/Response Flow Examples + +### Example 1: Tool Definition Request + +**Internal tool definition (before prefixing):** + +```typescript +{ + type: "function", + function: { + name: "read_file", + description: "Read the contents of a file", + parameters: { + type: "object", + properties: { + path: { type: "string", description: "Path to file" } + }, + required: ["path"] + } + } +} +``` + +**After prefixing (sent to API):** + +```typescript +{ + name: "oc_read_file", // Prefixed! + description: "Read the contents of a file", + input_schema: { + type: "object", + properties: { + path: { type: "string", description: "Path to file" } + }, + required: ["path"] + } +} +``` + +### Example 2: Tool Use Request (Tool Calling) + +**Agent wants to call `read_file`:** + +Request to API contains tool_use block with prefixed name: + +```typescript +{ + role: "assistant", + content: [ + { + type: "tool_use", + id: "tooluse_123", + name: "oc_read_file", // Prefixed! + input: { path: "/tmp/test.txt" } + } + ] +} +``` + +API response with tool result: + +```typescript +{ + role: "user", + content: [ + { + type: "tool_result", + tool_use_id: "tooluse_123", + content: "Hello, World!" + } + ] +} +``` + +### Example 3: Complete Tool Calling Flow + +``` +Step 1: Agent decides to call read_file + ↓ +Step 2: Tool sent to API (prefixed) + POST /v1/messages + { + "tools": [ + { + "name": "oc_read_file", + "description": "Read file contents", + "input_schema": { ... } + } + ] + } + ↓ +Step 3: API responds with tool_use (prefixed) + { + "content": [ + { + "type": "tool_use", + "id": "abc123", + "name": "oc_read_file", + "input": { "path": "/etc/passwd" } + } + ] + } + ↓ +Step 4: Klaus Code strips prefix before yielding to agent + yield { + type: "tool_call_partial", + index: 0, + id: "abc123", + name: "read_file", // Original name! + arguments: undefined + } + ↓ +Step 5: Agent executes tool (using original name) + Agent calls read_file({ path: "/etc/passwd" }) + ↓ +Step 6: Result sent back to API (in conversation history) + { + "role": "user", + "content": [ + { + "type": "tool_result", + "tool_use_id": "abc123", + "content": "root:x:0:0:root:/root:..." + } + ] + } + ↓ +Step 7: On next request, tool_use name is prefixed again + // prefixToolNamesInMessages() adds "oc_" prefix back +``` + +### Example 4: tool_choice Request + +**When agent specifies a specific tool:** + +```typescript +// Internal (before prefixing) +{ + type: "tool", + name: "read_file", + disable_parallel_tool_use: true +} + +// After prefixing (sent to API) +{ + type: "tool", + name: "oc_read_file", // Prefixed! + disable_parallel_tool_use: true +} +``` + +## Important: Message History Handling + +When conversation history is passed back to the API, **tool_use names must be re-prefixed**. This is handled by `prefixToolNamesInMessages()`: + +```typescript +// src/integrations/claude-code/streaming-client.ts:63-86 +function prefixToolNamesInMessages(messages: Anthropic.Messages.MessageParam[]) { + return messages.map((message) => { + const prefixedContent = message.content.map((block) => { + if (block.type === "tool_use") { + return { + ...block, + name: prefixToolName(block.name), // Re-prefix! + } + } + return block + }) + return { ...message, content: prefixedContent } + }) +} +``` + +This ensures that when messages containing tool_use blocks are sent back to the API: + +- Tool definitions have `oc_` prefix +- Tool calls in message history have `oc_` prefix +- tool*choice has `oc*` prefix + +## Files Involved + +| File | Role | +| ----------------------------------------------------------------- | -------------------------------------------------------------------- | +| `src/api/providers/claude-code.ts` | Main API handler, calls `convertOpenAIToolsToAnthropic()` | +| `src/core/prompts/tools/native-tools/converters.ts` | Converts OpenAI tool format to Anthropic (preserves names) | +| `src/integrations/claude-code/streaming-client.ts` | **Prefixes tools, makes API requests, strips prefix from responses** | +| `src/integrations/claude-code/oauth.ts` | Manages OAuth tokens and user_id generation | +| `src/integrations/claude-code/__tests__/streaming-client.spec.ts` | Tests for prefixing logic | + +## Key Implementation Details + +### ClaudeCodeHandler.createMessage() + +```typescript +// src/api/providers/claude-code.ts:117-148 +async *createMessage(systemPrompt, messages, metadata?) { + const anthropicTools = convertOpenIToolsToAnthropic(metadata?.tools ?? []) + // Tools are in OpenAI format here, names are unchanged + + const stream = createStreamingMessage({ + // ... + tools: anthropicTools, // Passed to streaming-client + // ... + }) + // ... +} +``` + +### createStreamingMessage() Request Building + +```typescript +// src/integrations/claude-code/streaming-client.ts:507-516 +if (tools && tools.length > 0) { + // Prefix tool names for API + body.tools = prefixToolNames(tools) + body.tool_choice = prefixToolChoice(toolChoice) || { type: "auto" } +} +``` + +### Response Parsing with Prefix Stripping + +```typescript +// src/integrations/claude-code/streaming-client.ts:644-662 +case "tool_use": { + // Strip prefix so agent sees original name + const originalName = stripToolNamePrefix(contentBlock.name as string) + yield { + type: "tool_call_partial", + name: originalName, // "read_file", not "oc_read_file" + // ... + } +} +``` + +## MCP Tools Special Handling + +MCP tools use a special naming convention: `mcp--{server}--{tool}` with hyphens encoded as `___`. + +Example: `mcp--atlassian--jira_search` + +**These are NOT prefixed with `oc_`** because MCP tool handling is done before reaching the Claude Code connector. MCP tool names are validated by Anthropic for Claude Code OAuth tokens. + +## Troubleshooting + +### "invalid x-api-key" Error + +**Symptom**: API returns "invalid x-api-key" error despite valid OAuth token + +**Cause**: Missing `?beta=true` query parameter in endpoint URL + +**Solution**: Ensure endpoint is `https://api.anthropic.com/v1/messages?beta=true` (not just `/v1/messages`) + +**Why**: The OAuth-authenticated endpoint requires the beta query parameter. Without it, the API falls back to x-api-key authentication and rejects the request. + +### Tool Validation Errors + +If you see errors like "unknown tool" or validation failures: + +1. Check that `prefixToolName()` is being called on tools +2. Check that `stripToolNamePrefix()` is being called on responses +3. Verify `TOOL_NAME_PREFIX = "oc_"` is defined + +### Conversation History Issues + +If tool calls fail on subsequent turns: + +1. Check that `prefixToolNamesInMessages()` is re-prefixing tool_use blocks +2. Verify message history isn't being modified between requests + +### OAuth Errors + +If OAuth fails: + +1. Check `user_id` generation in `generateUserId()` +2. Verify OAuth token is valid and not expired +3. Ensure all required beta headers are set + +### Wrong Default Model for Claude Code Provider + +**Symptom**: Tests or webview show `claude-sonnet-4-5` as default for claude-code provider instead of `claude-sonnet-4-6` + +**Cause**: `getProviderDefaultModelId("claude-code")` in `packages/types/src/providers/index.ts` was missing an explicit `case "claude-code":` and fell through to `anthropicDefaultModelId`. + +**Status**: Fixed. `packages/types/src/providers/index.ts` now has `case "claude-code": return claudeCodeDefaultModelId`. + +### Stale Types Build Causes Test Failures After Model Changes + +**Symptom**: Tests in `src/` or `webview-ui/` fail with outdated model IDs after editing `packages/types/src/providers/claude-code.ts` + +**Cause**: These packages import the compiled dist of `@klaus-code/types`, not source. Vitest does not recompile on source changes. + +**Solution**: + +```bash +pnpm --filter @klaus-code/types build # Rebuild types dist +pnpm test # Now picks up new model IDs +``` + +## See Also + +- `DEVELOPMENT.md` - Main development documentation, merge procedures +- `src/integrations/claude-code/streaming-client.ts` - Source of truth for prefixing logic +- `src/api/providers/claude-code.ts` - Main connector implementation +- `packages/types/src/providers/claude-code.ts` - Model definitions and normalization diff --git a/DEVELOPMENT.md b/DEVELOPMENT.md new file mode 100644 index 00000000000..9d0bf5cc5ed --- /dev/null +++ b/DEVELOPMENT.md @@ -0,0 +1,1165 @@ +# Klaus Code Development Guide + +> Developer documentation for building and releasing Klaus Code + +## Table of Contents + +- [Fork Divergence from Upstream](#fork-divergence-from-upstream) +- [Prerequisites](#prerequisites) +- [Environment Setup](#environment-setup) +- [Building from Source](#building-from-source) +- [Development Workflow](#development-workflow) +- [Creating a Release](#creating-a-release) +- [Automated Release](#automated-release) +- [Merging Upstream Changes](#merging-upstream-changes) +- [Troubleshooting](#troubleshooting) + +## Fork Divergence from Upstream + +Klaus Code is a fork of [Roo Code](https://github.com/RooCodeInc/Roo-Code) that maintains features removed from upstream. **When merging changes from upstream, be aware of these key differences:** + +### 1. Claude Code Provider Support (CRITICAL) + +**Status**: [x] Maintained in Klaus Code | [ ] Removed from Roo Code (commit `7f854c0`) + +Klaus Code preserves full Claude Code OAuth integration that was removed from upstream Roo Code. + +**Files to watch when merging:** + +- `src/api/providers/claude-code.ts` - Main provider implementation +- `src/integrations/claude-code/oauth.ts` - OAuth authentication flow +- `src/integrations/claude-code/streaming-client.ts` - Streaming API client +- `packages/types/src/providers/claude-code.ts` - Type definitions +- `webview-ui/src/components/settings/providers/ClaudeCode.tsx` - Settings UI +- `webview-ui/src/components/settings/providers/ClaudeCodeRateLimitDashboard.tsx` - Rate limit display + +**Action when merging**: If upstream changes affect provider infrastructure, ensure Claude Code provider is not accidentally removed. Test OAuth flow after merge. + +### 2. Tool Name Prefixing Fix (CRITICAL) + +**Status**: [x] Applied in Klaus Code | [!] May or may not be in upstream + +**Upstream PR**: [RooCodeInc/Roo-Code#10620](https://github.com/RooCodeInc/Roo-Code/pull/10620) +**Klaus Code PR**: [PabloVitasso/Klaus-Code#10916](https://github.com/RooCodeInc/Roo-Code/pull/10916) +**Commits**: + +- `6173606`: fix(claude-code): prefix tool names to bypass OAuth validation +- `f578dfb`: fix: prefix tool_choice.name when type is tool + +**What it does**: Adds `oc_` prefix to tool names when sending to Claude Code API and strips the prefix from responses. This works around Anthropic's OAuth validation that rejects third-party tool names. + +**Files modified:** + +- `src/integrations/claude-code/streaming-client.ts` + - Added `TOOL_NAME_PREFIX = "oc_"` constant + - Added `prefixToolName()` and `stripToolNamePrefix()` helpers + - Added `prefixToolNames()` and `prefixToolNamesInMessages()` internal helpers + - Modified `createStreamingMessage()` to prefix/strip tool names +- `src/integrations/claude-code/__tests__/streaming-client.spec.ts` + - Unit tests for prefixing functions + - Integration tests for API request/response handling + +**Action when merging**: + +1. Check if upstream has merged this fix +2. If not, ensure our changes to `streaming-client.ts` are preserved +3. Run tests: `cd src && npx vitest run integrations/claude-code/__tests__/streaming-client.spec.ts` +4. Test Claude Code OAuth flow with tool use after merge + +### 3. Branding Changes + +**Klaus Code** branding instead of **Roo Code**: + +**Files with branding:** + +- `package.json` - name: `klaus-code` +- `src/package.json` - name, publisher, author, repository +- All `package.nls*.json` files - Display names and descriptions +- `webview-ui/src/i18n/locales/*/` - All locale files +- `README.md` - Fork notice and branding + +**Action when merging**: Review any new user-facing strings from upstream and update them to Klaus Code branding if needed. + +### 4. Version Numbering + +Klaus Code uses fork-specific versioning: + +- Format: `-klaus.` +- Example: `3.42.0-klaus.1` + +**Action when merging**: After merging upstream version bump, append `-klaus.1` (or increment the fork number if already on that upstream version). + +### Upstream Remote Setup + +To help with merging: + +```bash +# Add Roo Code as remote (if not already added) +git remote add roocode https://github.com/RooCodeInc/Roo-Code.git + +# Fetch latest from upstream +git fetch roocode + +# View upstream branches +git branch -r | grep roocode +``` + +### Recommended Merge Process + +1. **Before merging**: Document current Klaus Code-specific state + + ```bash + git log --oneline origin/main..HEAD > klaus-specific-commits.txt + git diff roocode/main HEAD -- src/integrations/claude-code/ > claude-code-diff.patch + ``` + +2. **Create merge branch**: + + ```bash + git checkout -b merge-upstream- + git fetch roocode + git merge roocode/main + ``` + +3. **Resolve conflicts** - prioritize Klaus Code features: + + - Claude Code provider files: Keep Klaus Code version + - Tool name prefixing: Keep Klaus Code version + - Branding: Keep Klaus Code version + - Other conflicts: Evaluate case-by-case + +4. **Test after merge**: + + ```bash + pnpm install + pnpm check-types + pnpm test + pnpm vsix + code --install-extension bin/klaus-code-*.vsix + ``` + +5. **Manual testing**: + + - Test Claude Code OAuth login flow + - Test tool use with Claude Code provider + - Verify rate limit dashboard shows correctly + - Test other providers to ensure no regression + +6. **Update version** in `src/package.json`: + ```json + "version": "-klaus.1" + ``` + +## Prerequisites + +### Required Software + +- **Node.js**: v20.19.2 (specified in `.nvmrc`) +- **pnpm**: v10.8.1 (package manager) +- **Git**: For version control + +### Verify Prerequisites + +```bash +node --version # Should be v20.19.2 +npm --version # Should be 10.x or higher +git --version +``` + +## Environment Setup + +### 1. Install Node.js + +Use Node Version Manager (nvm) for easy Node.js version management: + +```bash +# Install nvm (if not already installed) +curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash + +# Install and use the correct Node.js version +nvm install 20.19.2 +nvm use 20.19.2 +``` + +Alternatively, download Node.js v20.19.2 from [nodejs.org](https://nodejs.org/). + +### 2. Install pnpm + +```bash +npm install -g pnpm@10.8.1 +``` + +Verify installation: + +```bash +pnpm --version # Should output: 10.8.1 +``` + +### 3. Clone the Repository + +```bash +git clone https://github.com/PabloVitasso/Klaus-Code.git +cd Klaus-Code +``` + +### 4. Install Dependencies + +```bash +pnpm install +``` + +This will: + +- Install all workspace dependencies +- Run bootstrap scripts +- Set up husky git hooks + +**Note**: The build scripts for some dependencies are ignored by default for security. This is normal. + +## Building from Source + +### Quick Build + +```bash +# Build all packages +pnpm build + +# Create VSIX package +pnpm vsix +``` + +The VSIX file will be created in `bin/klaus-code-.vsix`. + +### Build Output + +``` +bin/ +└── klaus-code-3.42.0.vsix (34 MB) +``` + +## Development Workflow + +### Run in Development Mode + +Press `F5` in VS Code to launch the extension in debug mode: + +1. Open the project in VS Code +2. Press `F5` (or **Run** -> **Start Debugging**) +3. A new VS Code window opens with Klaus Code loaded +4. Changes to the webview hot-reload automatically +5. Changes to the core extension also hot-reload + +### Available Scripts + +```bash +# Linting +pnpm lint + +# Type checking +pnpm check-types + +# Run tests +pnpm test + +# Format code +pnpm format + +# Clean build artifacts +pnpm clean + +# IMPORTANT: After clean, you MUST run: +pnpm install # Restores workspace state +pnpm build # Then rebuild +``` + +### Running Individual Tests + +Tests use Vitest. Run from the correct workspace: + +```bash +# Backend tests +cd src && npx vitest run path/to/test.test.ts + +# Webview UI tests +cd webview-ui && npx vitest run src/path/to/test.test.ts +``` + +**Important**: Do NOT run `npx vitest run src/...` from project root - this causes errors. + +## Creating a Release + +### Release Checklist + +Before releasing, ensure you update the following files: + +1. **`webview-ui/src/i18n/locales/en/chat.json`** - Update `announcement.release` section with new release notes: + + ```json + "announcement": { + "release": { + "heading": "What's New:", + "item1": "Description of change 1", + "item2": "Description of change 2", + "item3": "Description of change 3" + }, + "repo": "View the project on GitHub" + } + ``` + +2. **`webview-ui/src/components/chat/Announcement.tsx`** - Update the component if needed to match new release content + +3. **`src/core/webview/ClineProvider.ts`** - Update `latestAnnouncementId`: + + ```typescript + public readonly latestAnnouncementId = "jan-2026-v3.43.0-klaus-code-release" + ``` + + Format: `MMM-YYYY-vX.Y.Z-klaus-code-release` + +4. **`src/package.json`** - Update version number: + ```json + "version": "3.43.0-klaus.1" + ``` + +### Release Process + +#### 1. Identify Changes Since Last Release + +Get the last release tag: + +```bash +gh release list --limit 10 +``` + +View changes since last release: + +```bash +git log ..HEAD --oneline +``` + +#### 2. Summarize Changes + +Group changes by type: + +- **Added**: New features +- **Changed**: Changes to existing functionality +- **Fixed**: Bug fixes +- **Removed**: Removed features + +#### 3. Create Release Branch + +```bash +git checkout main +git pull origin main +git checkout -b release/v +``` + +#### 4. Update Files + +1. Update version in `src/package.json` +2. Update `webview-ui/src/i18n/locales/en/chat.json` with new release notes +3. Update `src/core/webview/ClineProvider.ts` with new `latestAnnouncementId` +4. Review and update `webview-ui/src/components/chat/Announcement.tsx` if needed + +#### 5. Commit and Push + +```bash +git add src/package.json webview-ui/src/i18n/locales/en/chat.json src/core/webview/ClineProvider.ts +git commit -m "chore: prepare release v" +git push origin release/v +``` + +#### 6. Create Pull Request + +```bash +gh pr create --title "Release v" \ + --body "Release preparation for v." \ + --base main --head release/v +``` + +#### 7. Build and Test After Merge + +Once the release PR is merged to main: + +```bash +# Clean build (optional - only if needed) +pnpm clean +pnpm install # REQUIRED after clean to restore workspace state + +# Build and package +pnpm build +pnpm vsix + +# Or use the shortcut (skips clean) +pnpm build && pnpm vsix + +# Install locally +code --install-extension bin/klaus-code-.vsix --force +``` + +#### 8. Create GitHub Release + +```bash +# Create and push tag +git checkout main +git pull origin main +git tag -a v -m "Release v" +git push origin v +``` + +Then create the GitHub release at https://github.com/PabloVitasso/Klaus-Code/releases: + +1. Click "Draft a new release" +2. Select the tag `v` +3. Upload the VSIX from `bin/klaus-code-.vsix` +4. Copy release notes from the changelog +5. Publish + +### Automated Release + +**Script**: `scripts/release.sh` + +Automates entire release: version updates, release notes, announcement ID, PR creation/merge, tagging, GitHub release. + +```bash +./scripts/release.sh 3.46.1-klaus.2 +``` + +**Prerequisites**: GitHub PAT with `repo` scope configured in gh CLI (`gh auth login`) + +**Manual fallback**: See script source for individual commands. + +## Merging Upstream Changes + +Klaus Code periodically merges improvements from upstream Roo Code. Follow this process to safely integrate upstream changes while preserving Klaus Code-specific features. + +### Merge Strategy + +We use a **commit-by-commit merge strategy** where each upstream commit is: + +1. Merged individually on its own branch +2. Tested thoroughly with automated and manual tests +3. Built into a test VSIX package +4. Documented in a tracking file + +This approach provides: + +- **Granular control** - Easy to identify which commit causes issues +- **Incremental testing** - Problems caught early before they compound +- **Rollback safety** - Can skip problematic commits without blocking others +- **Clear audit trail** - Each commit's impact is documented + +### Pre-Merge Checklist + +Before starting a merge, review the [Fork Divergence from Upstream](#fork-divergence-from-upstream) section to understand what must be preserved. + +### Quick Merge Process (Recommended for Most Merges) + +> **Important**: Merge to main requires operator approval. Push to branch first, create PR, then wait for approval before merging to main. + +**1. Merge and Resolve Conflicts** + +```bash +git fetch roocode +git checkout -b merge-upstream-$(date +%Y%m%d) +git merge roocode/main --no-edit +``` + +Resolve conflicts: + +```bash +# Delete conflicts: remove files deleted in Klaus Code +git rm apps/web-roo-code/... + +# Provider files: accept upstream (AI SDK migrations) +git checkout --theirs src/api/providers/*.ts + +# Critical files: fix manually +# - src/package.json: publisher="KlausCode", version="X.Y.Z-klaus.1" +# - src/core/webview/ClineProvider.ts: accept new fields +# - Use sed for conflict markers (not Edit tool - indentation issues) +``` + +**2. Fix Branding and Install** + +```bash +./scripts/merge-upstream-fix-branding.sh +git add -A +pnpm install # Required for new dependencies +pnpm check-types +./scripts/validate-claude-code-integration.sh # Validate Claude Code integration +``` + +**3. Test and Fix** + +```bash +cd src && npx vitest run integrations/claude-code/__tests__/ +``` + +Fix test failures (often beta headers or expectations changed): + +```bash +# Example: update test expectations to match current implementation +sed -i 's/old-beta/new-beta/' src/integrations/claude-code/__tests__/*.spec.ts +``` + +**4. Commit and Push** + +```bash +cd .. && git add -A +git commit -m "chore: merge upstream Roo Code changes ($(date +%Y-%m-%d)) + +Merged N commits from upstream Roo Code main branch (vX.Y.Z). + +Key changes: +- [List major changes] + +Klaus Code preserved: +- OAuth provider + tool prefixing (oc_) +- Branding (@klaus-code imports) +- Version: X.Y.Z-klaus.1 + +Testing: +- check-types: [x] PASSED +- Claude Code validation: [x] PASSED (./scripts/validate-claude-code-integration.sh) +- Claude Code tests (N/N): [x] PASSED" + +git push origin merge-upstream-$(date +%Y%m%d) +``` + +**5. Get Operator Approval** + +```bash +# Create PR manually in browser or with gh CLI +# https://github.com/PabloVitasso/Klaus-Code/pull/new/merge-upstream-$(date +%Y%m%d) + +# Wait for operator approval before proceeding to step 6 +``` + +**6. Merge to Main (After Operator Approval)** + +```bash +# Only proceed after operator approval! +git checkout main && git pull origin main +git merge merge-upstream-$(date +%Y%m%d) --no-edit +git push origin main +``` + +**Optional: Manual Testing** + +```bash +pnpm vsix && code --install-extension bin/klaus-code-*.vsix --force +# Test: OAuth login, tool use, rate limits +``` + +**Time**: 10-15 minutes for ~30 commits. + +### Common Pitfalls + +**Conflict marker resolution:** Use `sed`, not Edit tool (indentation issues) +**Test failures:** Update test expectations (beta headers, etc.) +**Type errors:** Always `pnpm install` before `check-types` +**Working directory:** Work from project root, not `src/` + +### Commit-by-Commit Merge Process + +This is the **recommended procedure** for merging upstream changes. + +**💡 Pro Tip - Batching Strategy:** + +You don't need to merge commits one-by-one. **Batch safe commits together:** + +1. **Identify HIGH RISK commits** (tool calling, provider changes, OAuth) +2. **Batch all LOW/MEDIUM risk commits** into mega-batches +3. **Merge HIGH RISK commits individually** for careful review + +Example from 2026-01-24 merge: + +- 21 commits total +- Batched 18 safe commits -> 1 merge cycle (86% done!) +- Left 3 HIGH RISK commits for individual merging + +**Mega-Batch Command:** + +```bash +# Skip HIGH RISK commits 8, 9, 16 and batch the rest +git cherry-pick commit1 commit2 ... commit7 commit10 ... commit15 commit17 ... commit21 +``` + +This saves time while maintaining safety on critical changes. + +#### Phase 1: Preparation + +**1. Create Tracking Document** + +```bash +# Ensure you're on main and up to date +git checkout main +git pull origin main + +# Fetch latest from upstream +git fetch roocode + +# Find the last merged commit (look for "Merge upstream" in history) +git log --oneline --grep="Merge upstream" -n 1 + +# Get the list of new commits (replace LAST_MERGED_COMMIT with actual hash) +git log --format="%H|%h|%s|%an|%ad" --date=short --reverse LAST_MERGED_COMMIT..roocode/main + +# Create tracking document +mkdir -p docs +# Document name format: docs/YYYY.MM.DD-merge-upstream.md +``` + +**2. Populate Tracking Document** + +Create `docs/YYYY.MM.DD-merge-upstream.md` with: + +- List of all commits (oldest to newest) +- Risk assessment for each commit: + - 🟢 **LOW RISK** - Safe, minimal conflicts expected + - 🟡 **MEDIUM RISK** - Review carefully, may affect related systems + - 🔴 **HIGH RISK** - Critical review, may impact Claude Code provider/OAuth +- Files to check for each commit +- Testing checklist +- Merge status tracking (⏳ PENDING, [x] MERGED, [!] CONFLICT, [ ] FAILED) + +See [docs/2026.01.24-merge-upstream.md](docs/2026.01.24-merge-upstream.md) as a template. + +**3. Review Critical Areas** + +Before merging, review what must be protected: + +- Claude Code provider implementation +- OAuth flow +- Tool name prefixing (`oc_` prefix in streaming-client) +- Klaus Code branding + +#### Phase 2: Individual Commit Merges + +For each commit in the tracking document: + +**1. Create Merge Branch** + +```bash +# Branch naming: merge-upstream- +git checkout main +git pull origin main +git checkout -b merge-upstream-abc1234 +``` + +**2. Cherry-Pick the Commit** + +```bash +# Cherry-pick the specific commit from upstream +git cherry-pick abc1234567890abcdef1234567890abcdef1234 + +# If conflicts occur, resolve them carefully: +# - For Claude Code files: prefer Klaus Code version +# - For provider infrastructure: ensure Claude Code provider is included +# - For branding: keep Klaus Code branding +# - Document conflicts in tracking file +``` + +**💡 Lessons Learned - Branding Conflicts:** + +After cherry-picking commits, branding issues (`@roo-code` -> `@klaus-code`) may appear in: + +- Import statements in TypeScript/TSX files +- Type references + +**Quick fix with sed:** + +```bash +# Find all files with wrong branding in imports +find . -type f \( -name "*.ts" -o -name "*.tsx" \) -exec grep -l "@roo-code" {} \; + +# Fix all at once - safer to target specific import lines +sed -i 's/@roo-code\/types/@klaus-code\/types/g' path/to/file.ts +sed -i 's/@roo-code\/telemetry/@klaus-code\/telemetry/g' path/to/file.ts + +# Or fix all at once (use with caution): +find src webview-ui -type f \( -name "*.ts" -o -name "*.tsx" \) \ + -exec sed -i 's/@roo-code\//@klaus-code\//g' {} \; +``` + +**Always verify after bulk changes:** + +```bash +pnpm check-types # Catch any remaining branding issues +grep -r "@roo-code" src/ webview-ui/ # Verify all fixed +``` + +**3. Resolve Conflicts (if any)** + +**Critical files - preserve Klaus Code version:** + +```bash +git checkout --ours src/integrations/claude-code/ +git checkout --ours src/api/providers/claude-code.ts +# Manually review and resolve other conflicts +``` + +**Provider infrastructure - merge carefully:** + +- Check `src/api/index.ts` includes Claude Code provider +- Verify `src/api/providers/index.ts` exports Claude Code +- Ensure settings UI includes Claude Code + +**4. Verify Critical Features** + +```bash +# Run automated validation script (recommended) +./scripts/validate-claude-code-integration.sh + +# Or manually verify: +# Check Claude Code provider files exist +ls src/integrations/claude-code/ +ls src/api/providers/claude-code.ts + +# Check tool name prefixing code is intact +grep "TOOL_NAME_PREFIX" src/integrations/claude-code/streaming-client.ts +grep "prefixToolName" src/integrations/claude-code/streaming-client.ts + +# Verify branding +grep '"klaus-code"' src/package.json +``` + +**5. Run Automated Tests** + +```bash +# Install dependencies (if package.json changed) +pnpm install + +# Type checking +pnpm check-types + +# Run all tests +pnpm test + +# Run Claude Code specific tests +cd src && npx vitest run integrations/claude-code/__tests__/ +cd .. +``` + +**6. Create Test Build** + +```bash +# Option 1: Clean build (only if needed) +pnpm clean +pnpm install # REQUIRED after clean +pnpm build +pnpm vsix + +# Option 2: Quick rebuild (recommended) +pnpm build && pnpm vsix + +# Rename to include commit hash +# Format: klaus-code--.vsix +mv bin/klaus-code-*.vsix bin/klaus-code-3.43.0-klaus.1-abc1234.vsix + +# Install for manual testing +code --install-extension bin/klaus-code-3.43.0-klaus.1-abc1234.vsix --force +``` + +**7. Manual Testing** + +Test the following in VS Code with the installed extension: + +**Claude Code OAuth Flow:** + +- Settings -> API Provider -> Select "Claude Code" +- Click "Login with Claude Code" +- Verify OAuth completes successfully + +**Tool Use with Claude Code:** + +- Create a new task +- Ask it to read a file: "What's in the README?" +- Ask it to execute a command: "List the files in this directory" +- Verify tools work (no OAuth rejection errors) +- Check console for tool name prefixing (should see `oc_` prefix in requests) + +**Rate Limit Dashboard:** + +- With Claude Code provider selected +- Verify rate limit info displays in settings + +**Regression Testing:** + +- Test another provider (e.g., Anthropic API) +- Ensure no regressions in core functionality + +**8. Update Tracking Document** + +Mark the commit status: + +- [x] **MERGED** - Successfully merged and tested +- [!] **CONFLICT** - Had conflicts, document resolution approach +- [ ] **FAILED** - Merge caused test failures or critical issues + +Add notes about: + +- Conflicts encountered and how resolved +- Test results +- Any issues found +- Manual testing observations + +**9. Push Branch (Optional)** + +```bash +# Push the test branch for review or backup +git push origin merge-upstream-abc1234 +``` + +**10. Repeat for Next Commit** + +Start over at step 1 for the next commit in the tracking document. + +#### Phase 3: Final Integration + +Once all commits are merged individually: + +**1. Create Final Merge Branch** + +```bash +git checkout main +git pull origin main +git checkout -b merge-upstream-YYYYMMDD-final +``` + +**2. Cherry-Pick All Merged Commits** + +```bash +# Cherry-pick all commits in order +git cherry-pick abc1234..xyz9876 +``` + +**3. Update Version** + +Edit `src/package.json`: + +```json +{ + "version": "3.43.0-klaus.1" +} +``` + +**4. Update Announcement** + +Update files for new release (see [Creating a Release](#creating-a-release)): + +- `webview-ui/src/i18n/locales/en/chat.json` +- `src/core/webview/ClineProvider.ts` (`latestAnnouncementId`) + +**5. Final Testing** + +Run complete test suite one more time: + +```bash +pnpm install +pnpm check-types +pnpm test +cd src && npx vitest run integrations/claude-code/__tests__/ +cd .. + +# Build and package +pnpm build && pnpm vsix + +# Or with clean (only if needed) +# pnpm clean && pnpm install && pnpm build && pnpm vsix + +code --install-extension bin/klaus-code-*.vsix --force +``` + +Perform full manual testing as described in Phase 2, step 7. + +**6. Commit and Push** + +```bash +git add . +git commit -m "chore: merge upstream Roo Code changes ($(date +%Y-%m-%d)) + +Merged commits: +- abc1234: Feature 1 +- def5678: Feature 2 +- xyz9876: Feature 3 + +See docs/YYYY.MM.DD-merge-upstream.md for detailed tracking." + +git push origin merge-upstream-YYYYMMDD-final +``` + +**7. Create Pull Request** + +```bash +gh pr create --base main \ + --title "Merge upstream Roo Code changes ($(date +%Y-%m-%d))" \ + --body "## Overview + +Merges upstream changes from Roo Code. + +## Tracking Document + +See \`docs/YYYY.MM.DD-merge-upstream.md\` for detailed commit-by-commit tracking. + +## Changes + +- X commits merged +- Y high-risk commits reviewed carefully +- All tests passing +- Manual testing completed + +## Testing + +- [x] Type checking passed +- [x] All automated tests passed +- [x] Claude Code OAuth flow tested +- [x] Tool use with Claude Code tested +- [x] Rate limit dashboard tested +- [x] Regression testing completed + +## Claude Code Provider + +- [x] Provider files unchanged/reviewed +- [x] OAuth flow works correctly +- [x] Tool name prefixing intact +- [x] No regressions" +``` + +#### Phase 4: Handling Failed Commits + +If a commit cannot be merged safely: + +**1. Document the Issue** + +In the tracking document: + +- Mark as [ ] **FAILED** +- Document why it failed +- Note if it blocks other commits +- Decide: Skip, fix later, or requires upstream discussion + +**2. Skip and Continue** + +```bash +# Skip the problematic commit +git cherry-pick --skip +# Or abort and continue with next commit +git cherry-pick --abort +``` + +**3. Create Issue for Follow-up** + +```bash +gh issue create --title "Upstream commit abc1234 conflicts with Klaus Code" \ + --body "Commit abc1234 from upstream cannot be merged cleanly. + +**Issue:** [description] +**Impact:** [what features are affected] +**Action needed:** [skip permanently / needs custom implementation / upstream discussion]" +``` + +### Rollback Procedure + +If merge causes critical issues: + +```bash +# Abort ongoing cherry-pick +git cherry-pick --abort + +# Or reset branch to main +git checkout main +git branch -D merge-upstream-abc1234 + +# Document in tracking file why rollback was needed +``` + +### Alternative: Bulk Merge (Not Recommended) + +For reference only. Use Quick Merge Process above for better results. See git history or backup for legacy instructions. + +## Helper Scripts + +Klaus Code includes helper scripts to automate common development tasks: + +### Branding Fix Script + +**Location**: `scripts/merge-upstream-fix-branding.sh` + +**Purpose**: Automatically fixes Klaus Code branding after merging from upstream Roo Code. + +**Usage**: + +```bash +./scripts/merge-upstream-fix-branding.sh +``` + +**What it does**: + +- Replaces all `@roo-code/` imports with `@klaus-code/` in source files +- Fixes package.json dependencies +- Verifies critical Klaus Code files are preserved: + - Claude Code provider files + - Tool name prefixing code (`oc_` prefix) + - Branding in key configuration files +- Reports detailed status of all operations +- Continues on errors (won't fail completely if one step fails) + +**When to use**: + +- After merging upstream changes from Roo Code +- When you see TypeScript errors about `@roo-code/types` imports +- To verify Klaus Code-specific features are intact after a merge + +**Safe to run multiple times** - the script is idempotent and won't break anything if run repeatedly. + +### Claude Code Integration Validation Script + +**Location**: `scripts/validate-claude-code-integration.sh` + +**Purpose**: Validates that the Claude Code provider integration remains intact after merging from Roo Code upstream. Runs critical checks for OAuth, provider registration, and tool prefixing. + +**Usage**: + +```bash +./scripts/validate-claude-code-integration.sh +``` + +**What it validates**: + +1. **Backend schema** - `claudeCodeSchema` in provider settings discriminated union +2. **Provider factory** - `ClaudeCodeHandler` exported and registered in switch case +3. **OAuth initialization** - `claudeCodeOAuthManager.initialize()` in extension.ts +4. **Frontend UI** - Claude Code in provider exports, dropdown, and model config +5. **Activity bar** - Klaus Code branding in package.json (not overwritten by upstream) +6. **Tool prefix** - `TOOL_NAME_PREFIX = "oc_"` in streaming-client.ts +7. **Model selection** - Uses `claudeCodeModels` instead of `anthropicModels` +8. **API config** - `claude-code` included in provider checks + +**When to use**: + +- After merging upstream changes from Roo Code +- Before running full test suite to catch integration issues early +- When Claude Code OAuth or tool use is not working after a merge +- As part of the Quick Merge Process step 3: Test after merge + +**Example output**: + +``` +=== Validating Claude Code Components === +✓ Provider schema: PASS +✓ Provider export: PASS +✓ Provider import: PASS +✓ Provider factory case: PASS +✓ OAuth init: PASS +✓ UI exports: PASS +✓ UI dropdown: PASS +✓ UI config: PASS +✓ Activity bar: PASS +✓ Tool prefix: PASS +✓ Model selection: PASS +✓ API config check: PASS +✓ Types: PASS +✓ Tests: PASS +=== Validation Complete === +``` + +## Troubleshooting + +### pnpm not found + +```bash +npm install -g pnpm@10.8.1 +``` + +### Build fails with "Command 'build' not found" after pnpm clean + +After running `pnpm clean`, the workspace state is removed. You MUST run: + +```bash +pnpm install # Restores workspace metadata +pnpm build # Then build +``` + +**Never use:** `pnpm clean && pnpm build` (missing install!) + +**Correct patterns:** + +```bash +# Full clean rebuild +pnpm clean && pnpm install && pnpm build && pnpm vsix + +# Quick rebuild (recommended, skips clean) +pnpm build && pnpm vsix +``` + +### Build fails with "vitest: command not found" + +You're running tests from the wrong directory. See [Running Individual Tests](#running-individual-tests). + +### VSIX build warnings about bundle size + +This is normal. The extension includes all dependencies. To reduce size: + +```bash +# Bundle the extension (advanced) +pnpm bundle +pnpm vsix +``` + +### Hot reload not working in debug mode + +1. Restart the debug session (Ctrl+Shift+F5) +2. Check the VS Code debug console for errors +3. Ensure you're running from the project root + +### Dependencies installation issues + +```bash +# Clear cache and reinstall +pnpm store prune +rm -rf node_modules +pnpm install +``` + +### TypeScript errors + +```bash +# Check types +pnpm check-types + +# Fix common issues +pnpm format +pnpm lint +``` + +## Project Structure + +``` +Klaus-Code/ +├── src/ # Main VS Code extension +│ ├── api/ # LLM provider integrations +│ ├── core/ # Agent core logic +│ ├── services/ # Supporting services +│ └── integrations/ # VS Code integrations +├── webview-ui/ # React frontend +├── packages/ # Shared packages +│ ├── types/ # Shared TypeScript types +│ ├── core/ # Core utilities +│ ├── cloud/ # Cloud integration +│ └── telemetry/ # Telemetry service +├── bin/ # Built VSIX packages +└── DEVELOPMENT.md # This file +``` + +For more details, see [CLAUDE.md](CLAUDE.md) for AI-specific development guidance. + +## Additional Resources + +- **Project Repository**: https://github.com/PabloVitasso/Klaus-Code +- **Original Fork Source**: https://github.com/RooCodeInc/Roo-Code +- **VS Code Extension API**: https://code.visualstudio.com/api + +_Last updated: 2026-01-23_ +_Divergence tracking added: 2026-01-23_ diff --git a/MERGE-2026-02-03-SUMMARY.md b/MERGE-2026-02-03-SUMMARY.md new file mode 100644 index 00000000000..f9712f9fe1b --- /dev/null +++ b/MERGE-2026-02-03-SUMMARY.md @@ -0,0 +1,211 @@ +# Upstream Merge Summary - 2026-02-03 + +## What Was Merged + +Successfully merged **28 commits** from upstream Roo Code (commit range: `cc86049f1..4647d0f3c`) + +### Key Upstream Changes Integrated + +1. **Provider Migrations to AI SDK**: + - xAI provider → `@ai-sdk/xai` + - Mistral provider → AI SDK + - SambaNova provider → AI SDK + +2. **Feature Improvements**: + - Parallel tool execution support + - Improved tool result handling with content blocks + - Image content support in MCP tool responses + - IPC message queuing fixes during command execution + - Mode dropdown to change skill mode dynamically + +3. **Model Updates**: + - Updated model lists for various providers + - Fixed tool_use_id sanitization in tool_result blocks + +4. **Infrastructure**: + - CLI release workflow improvements + - Linux CLI support added + +### Klaus Code Specific Preservations + +✅ **Claude Code OAuth Provider** - Fully preserved +- Files intact: `src/integrations/claude-code/` +- Tool name prefixing (`oc_` prefix) verified working +- All 25 tests passing + +✅ **Branding** - Successfully updated +- All `@roo-code` imports → `@klaus-code` +- Package names preserved: `@klaus-code/types`, `@klaus-code/core`, etc. +- Publisher: `KlausCode` + +✅ **Version** - Bumped to `3.46.1-klaus.1` + +## Merge Statistics + +- **Total files changed**: ~160 files +- **Conflicts resolved**: 29 conflicts + - 13 delete conflicts (resolved) + - 16 content conflicts (resolved) +- **Branding fixes applied**: Automatically via script +- **Build status**: ✅ Successful +- **VSIX size**: 33 MB +- **Tests passing**: ✅ All critical tests pass + +## Build & Test Results + +``` +✓ Type checking: PASSED (13 packages) +✓ VSIX created: bin/klaus-code-3.46.1-klaus.1.vsix +✓ Extension installed: Successfully +✓ Claude Code tests: 25/25 PASSED +✓ Provider tests: 27/27 PASSED (xAI example) +``` + +## Process Improvements Added + +### 1. Branding Fix Script + +**File**: `scripts/merge-upstream-fix-branding.sh` + +**Features**: +- ✅ Automatic `@roo-code` → `@klaus-code` replacement +- ✅ Verifies Claude Code provider files +- ✅ Checks tool name prefixing code +- ✅ Validates branding in key files +- ✅ Clear console output for debugging +- ✅ Safe to run multiple times +- ✅ Continues on errors (doesn't fail completely) + +**Output Example**: +``` +======================================== +Klaus Code Branding Fix Script +======================================== + +[1/6] Fixing @roo-code imports... +✓ No @roo-code imports found - already clean! + +[2/6] Fixing package.json dependencies... +✓ No package.json files need fixing + +[3/6] Verifying Claude Code provider files... +✓ Present: src/integrations/claude-code/streaming-client.ts +✓ Present: src/integrations/claude-code/oauth.ts +✓ Present: src/api/providers/claude-code.ts +✓ Present: packages/types/src/providers/claude-code.ts + +[4/6] Verifying tool name prefixing... +✓ Tool name prefixing code intact + +[5/6] Verifying branding in key files... +✓ src/package.json has Klaus Code branding +✓ packages/types/npm/package.metadata.json has Klaus Code branding + +[6/6] Checking for remaining @roo-code references... +✓ No remaining @roo-code references found + +======================================== +Summary +======================================== + +Files fixed: 0 +Files skipped: 0 +Errors: 0 + +✓ All branding fixes applied successfully! +``` + +### 2. Streamlined DEVELOPMENT.md + +Added **"Quick Merge Process"** section: +- Step-by-step instructions optimized for efficiency +- Integrates branding fix script +- Clear conflict resolution strategies +- **Estimated time**: 10-15 minutes for typical merge + +### 3. Helper Scripts Documentation + +Added new section documenting all helper scripts with: +- Purpose and usage +- What each script does +- When to use them +- Safety guarantees + +## Time Comparison + +### Before (Manual Process): +- Merge conflicts: ~10-15 min +- Manual branding fixes: ~5-10 min +- Build and test: ~10 min +- Documentation: ~5 min +- **Total**: ~30-40 minutes + +### After (With Script): +- Merge conflicts: ~5 min (script handles branding) +- Run script: ~1 min +- Build and test: ~10 min +- **Total**: ~15-20 minutes + +**Time savings**: ~50% reduction + +## Future Merge Checklist + +For the next upstream merge, simply: + +```bash +# 1. Fetch and merge +git fetch roocode +git checkout -b merge-upstream-$(date +%Y%m%d) +git merge roocode/main + +# 2. Resolve delete conflicts +git rm + +# 3. Resolve critical file conflicts +# - src/package.json (version + publisher) +# - src/core/webview/ClineProvider.ts (latestAnnouncementId) +# - Accept upstream for other conflicts + +# 4. Fix branding automatically +./scripts/merge-upstream-fix-branding.sh + +# 5. Test and commit +git add -A +pnpm check-types +pnpm vsix +git commit -m "chore: merge upstream..." +``` + +## Lessons Learned + +1. **Most conflicts are branding** - Script handles 90% of merge conflicts +2. **Claude Code files never conflict** - Upstream doesn't touch them +3. **Batch strategy works** - Can merge 20+ commits at once safely +4. **Type checking catches issues early** - Run `pnpm check-types` immediately after merge +5. **Script output aids debugging** - Clear console output helps LLMs and humans understand what happened + +## Next Steps + +1. ✅ Branch pushed: `merge-upstream-20260203` +2. ⏳ Create PR to main +3. ⏳ Final review and merge +4. ⏳ Tag release `v3.46.1-klaus.1` +5. ⏳ Publish VSIX + +## Files Changed + +Key files modified: +- `scripts/merge-upstream-fix-branding.sh` (new) +- `DEVELOPMENT.md` (streamlined merge docs) +- `src/package.json` (version bump) +- `src/api/providers/xai.ts` (AI SDK migration) +- `src/api/providers/mistral.ts` (AI SDK migration) +- `src/api/providers/sambanova.ts` (AI SDK migration) +- And ~150 other files from upstream + +--- + +**Merge completed by**: Claude (Sonnet 4.5) +**Date**: 2026-02-03 +**Branch**: `merge-upstream-20260203` +**Commits**: 2 commits (merge + improvements) diff --git a/PRIVACY.md b/PRIVACY.md index 02e8e151034..438174730d2 100644 --- a/PRIVACY.md +++ b/PRIVACY.md @@ -1,29 +1,29 @@ -# Roo Code Privacy Policy +# Klaus Code Privacy Policy **Last Updated: September 11th, 2025** -Roo Code respects your privacy and is committed to transparency about how we handle your data. Below is a simple breakdown of where key pieces of data go—and, importantly, where they don’t. +Klaus Code respects your privacy and is committed to transparency about how we handle your data. Below is a simple breakdown of where key pieces of data go—and, importantly, where they don’t. ### **Where Your Data Goes (And Where It Doesn’t)** -- **Code & Files**: Roo Code accesses files on your local machine when needed for AI-assisted features. When you send commands to Roo Code, relevant files may be transmitted to your chosen AI model provider (e.g., OpenAI, Anthropic, OpenRouter) to generate responses. 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. -- **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. +- **Code & Files**: Klaus Code accesses files on your local machine when needed for AI-assisted features. When you send commands to Klaus Code, relevant files may be transmitted to your chosen AI model provider (e.g., OpenAI, Anthropic, OpenRouter) to generate responses. If you select Klaus Code Cloud as the model provider (proxy mode), your code may transit Klaus 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. +- **Commands**: Any commands executed through Klaus 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 Klaus Code Cloud as the provider (proxy mode), prompts may transit Klaus Code servers only to forward them to the upstream model and are not stored. - **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. +- **Telemetry (Usage Data)**: We collect anonymous feature usage and error data to help us improve Klaus 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, Klaus Code makes a secure API call to Klaus 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)** -- We use telemetry to understand feature usage and improve Roo Code. +- We use telemetry to understand feature usage and improve Klaus Code. - We do **not** sell or share your data. - We do **not** train any models on your data. ### **Your Choices & Control** - You can run models locally to prevent data being sent to third-parties. -- Telemetry collection is enabled by default to help us improve Roo Code, but you can opt out at any time through the settings. -- You can delete Roo Code to stop all data collection. +- Telemetry collection is enabled by default to help us improve Klaus Code, but you can opt out at any time through the settings. +- You can delete Klaus Code to stop all data collection. ### **Security & Updates** @@ -31,8 +31,8 @@ We take reasonable measures to secure your data, but no system is 100% secure. I ### **Contact Us** -For any privacy-related questions, reach out to us at support@roocode.com. +For any privacy-related questions, reach out to us at support@***.tbd --- -By using Roo Code, you agree to this Privacy Policy. +By using Klaus Code, you agree to this Privacy Policy. diff --git a/README.md b/README.md index 75f37762f93..3fb86fce8b7 100644 --- a/README.md +++ b/README.md @@ -1,176 +1,44 @@ -

- VS Code Marketplace - X - YouTube - Join Discord - Join r/RooCode -

-

- Get help fast → Join Discord • Prefer async? → Join r/RooCode -

-# Roo Code -> Your AI-Powered Dev Team, Right in Your Editor +## WARNING - THIS CODE IS PROOF-OF-CONCEPT ONLY. USAGE RESULTS IN VIOLATION OF ANTHROPIC CONSUMER TERMS OF SERVICE -
- 🌐 Available languages +https://code.claude.com/docs/en/legal-and-compliance -- [English](README.md) -- [Català](locales/ca/README.md) -- [Deutsch](locales/de/README.md) -- [Español](locales/es/README.md) -- [Français](locales/fr/README.md) -- [हिंदी](locales/hi/README.md) -- [Bahasa Indonesia](locales/id/README.md) -- [Italiano](locales/it/README.md) -- [日本語](locales/ja/README.md) -- [한국어](locales/ko/README.md) -- [Nederlands](locales/nl/README.md) -- [Polski](locales/pl/README.md) -- [Português (BR)](locales/pt-BR/README.md) -- [Русский](locales/ru/README.md) -- [Türkçe](locales/tr/README.md) -- [Tiếng Việt](locales/vi/README.md) -- [简体中文](locales/zh-CN/README.md) -- [繁體中文](locales/zh-TW/README.md) -- ... -
+> OAuth authentication (used with Free, Pro, and Max plans) is intended exclusively for Claude Code and Claude.ai. Using OAuth tokens obtained through Claude Free, Pro, or Max accounts in any other product, tool, or service — including the Agent SDK — is not permitted and constitutes a violation of the [Consumer Terms of Service](https://www.anthropic.com/legal/consumer-terms). ---- +# Klaus Code -## What Can Roo Code Do For YOU? +> A fork of [Roo Code](https://github.com/RooCodeInc/Roo-Code) that preserves the Claude Code provider feature. -- Generate Code from natural language descriptions and specs -- Adapt with Modes: Code, Architect, Ask, Debug, and Custom Modes -- Refactor & Debug existing code -- Write & Update documentation -- Answer Questions about your codebase -- Automate repetitive tasks -- Utilize MCP Servers +## Fork Notice -## Modes +This is **Klaus Code**, a community fork of Roo Code. -Roo Code adapts to how you work: +### Why this fork exists -- Code Mode: everyday coding, edits, and file ops -- Architect Mode: plan systems, specs, and migrations -- 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. +Roo Code removed the Claude Code provider in [commit 7f854c0](https://github.com/RooCodeInc/Roo-Code/commit/7f854c0dd7ed25dac68a2310346708b4b64b48d9). This fork restores and maintains that feature, allowing users to authenticate with Claude Code OAuth tokens. -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) +This repository contains a non-functional proof-of-concept demonstrating architectural patterns for client-side API abstraction and request lifecycle handling. +This project is not intended to enable access to any proprietary service, bypass access controls, or replicate any commercial offering. +Any implementation of service-specific adapters is the sole responsibility of the user and must comply with applicable terms of service and law. +The code is published for educational and interoperability research purposes. No proprietary code, credentials, or confidential information are included. -## Tutorial & Feature Videos +### Key differences from upstream -
+- **Claude Code Provider**: Restored and maintained (AS PROOF OF CONCEPT) +- **Branding**: Renamed from "Roo Code" to "Klaus Code" -| | | | -| :-----------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------: | -|
Installing Roo Code |
Configuring Profiles |
Codebase Indexing | -|
Custom Modes |
Checkpoints |
Context Management | +### Original project -
-

-More quick tutorial and feature videos... -

+- **Roo Code original link**: https://github.com/RooCodeInc/Roo-Code +- **Roo Code documentation**: https://docs.roocode.com -## Resources +### For Developers -- **[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. -- **[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. +- **[Development Guide](DEVELOPMENT.md)**: Build instructions, environment setup, and release process ---- +- **Quick Install**: Clone the GitHub repository from https://github.com/PabloVitasso/Klaus-Code, build a VS Code .vsix using vsce package, and install it. -## Local Setup & Development +### License -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=] -``` - -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=`: 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-.vsix`). -3. Install it manually using the VSCode CLI: - ```sh - code --install-extension bin/roo-cline-.vsix - ``` - ---- - -We use [changesets](https://github.com/changesets/changesets) for versioning and publishing. Check our `CHANGELOG.md` for release notes. - ---- - -## Disclaimer - -**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](./LICENSE) diff --git a/SECURITY.md b/SECURITY.md index 8057b38bda7..404b492d563 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -6,7 +6,7 @@ We actively patch only the most recent minor release of Roo Code. Older version ## Reporting a Vulnerability -Email security@roocode.com with: +Email security@***.tbd with: - A short summary of the issue - Steps to reproduce or a proof of concept diff --git a/apps/cli/CHANGELOG.md b/apps/cli/CHANGELOG.md index 0babc28fd80..1c01ec6e1c8 100644 --- a/apps/cli/CHANGELOG.md +++ b/apps/cli/CHANGELOG.md @@ -5,6 +5,69 @@ All notable changes to the `@roo-code/cli` package will be documented in this fi 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.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 @@ -32,7 +95,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 ### Changed - Skip onboarding flow when a provider is explicitly specified via `--provider` flag or saved in settings -- Unified permission flags: Combined `-y`, `--yes`, and `--dangerously-skip-permissions` into a single option for Claude Code-like CLI compatibility +- 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 diff --git a/apps/cli/README.md b/apps/cli/README.md index d4405364405..79170a4f27f 100644 --- a/apps/cli/README.md +++ b/apps/cli/README.md @@ -1,16 +1,16 @@ -# @roo-code/cli +# @klaus-code/cli -Command Line Interface for Roo Code - Run the Roo Code agent from the terminal without VSCode. +Command Line Interface for Klaus Code - Run the Klaus 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. +This CLI uses the `@klaus-code/vscode-shim` package to provide a VSCode API compatibility layer, allowing the main Klaus Code extension to run in a Node.js environment. ## Installation ### Quick Install (Recommended) -Install the Roo Code CLI with a single command: +Install the Klaus Code CLI with a single command: ```bash curl -fsSL https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/install.sh | sh @@ -19,7 +19,7 @@ curl -fsSL https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/i **Requirements:** - Node.js 20 or higher -- macOS (Intel or Apple Silicon) or Linux (x64 or ARM64) +- macOS Apple Silicon (M1/M2/M3/M4) or Linux x64 **Custom installation directory:** @@ -59,54 +59,71 @@ pnpm install pnpm --filter roo-cline bundle # Build the cli. -pnpm --filter @roo-code/cli build +pnpm --filter @klaus-code/cli build ``` ## Usage ### Interactive Mode (Default) -By default, the CLI prompts for approval before executing actions: +By default, the CLI auto-approves actions and runs in interactive TUI mode: ```bash export OPENROUTER_API_KEY=sk-or-v1-... -roo ~/Documents/my-project -P "What is this project?" +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 ~/Documents/my-project +roo -w ~/Documents/my-project ``` In interactive mode: -- Tool executions prompt for yes/no approval -- Commands prompt for yes/no approval -- Followup questions show suggestions and wait for user input -- Browser and MCP actions prompt for approval +- 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 -### Non-Interactive Mode (`-y`) +### Approval-Required Mode (`--require-approval`) -For automation and scripts, use `-y` to auto-approve all actions: +If you want manual approval prompts, enable approval-required mode: ```bash -roo ~/Documents/my-project -y -P "Refactor the utils.ts file" +roo "Refactor the utils.ts file" --require-approval -w ~/Documents/my-project ``` -In non-interactive mode: +In approval-required mode: -- Tool, command, browser, and MCP actions are auto-approved -- Followup questions show a 60-second timeout, then auto-select the first suggestion -- Typing any key cancels the timeout and allows manual input +- Tool, command, browser, and MCP actions prompt for yes/no approval +- Followup questions wait for manual input (no auto-timeout) -### Roo Code Cloud Authentication +### Print Mode (`--print`) -To use Roo Code Cloud features (like the provider proxy), you need to authenticate: +Use `--print` for non-interactive execution and machine-readable output: ```bash -# Log in to Roo Code Cloud (opens browser) +# Prompt is required +roo --print "Summarize this repository" +``` + +### Stdin Stream Mode (`--stdin-prompt-stream`) + +For programmatic control (one process, multiple prompts), use `--stdin-prompt-stream` with `--print`. +Send one prompt per line via stdin: + +```bash +printf '1+1=?\n10!=?\n' | roo --print --stdin-prompt-stream --output-format stream-json +``` + +### Klaus Code Cloud Authentication + +To use Klaus Code Cloud features (like the provider proxy), you need to authenticate: + +```bash +# Log in to Klaus Code Cloud (opens browser) roo auth login # Check authentication status @@ -118,7 +135,7 @@ roo auth logout The `auth login` command: -1. Opens your browser to authenticate with Roo Code Cloud +1. Opens your browser to authenticate with Klaus Code Cloud 2. Receives a secure token via localhost callback 3. Stores the token in `~/.config/roo/credentials.json` @@ -128,7 +145,7 @@ Tokens are valid for 90 days. The CLI will prompt you to re-authenticate when yo ``` ┌──────┐ ┌─────────┐ ┌───────────────┐ -│ CLI │ │ Browser │ │ Roo Code Cloud│ +│ CLI │ │ Browser │ │ Klaus Code Cloud│ └──┬───┘ └────┬────┘ └───────┬───────┘ │ │ │ │ Open auth URL │ │ @@ -147,27 +164,30 @@ Tokens are valid for 90 days. The CLI will prompt you to re-authenticate when yo ## Options -| Option | Description | Default | -| --------------------------------- | --------------------------------------------------------------------------------------- | ----------------------------- | -| `[workspace]` | Workspace path to operate in (positional argument) | Current directory | -| `-P, --prompt ` | The prompt/task to execute (optional in TUI mode) | None | -| `-e, --extension ` | Path to the extension bundle directory | Auto-detected | -| `-d, --debug` | Enable debug output (includes detailed debug information, prompts, paths, etc) | `false` | -| `-x, --exit-on-complete` | Exit the process when task completes (useful for testing) | `false` | -| `-y, --yes` | Non-interactive mode: auto-approve all actions | `false` | -| `-k, --api-key ` | API key for the LLM provider | From env var | -| `-p, --provider ` | API provider (anthropic, openai, openrouter, etc.) | `openrouter` | -| `-m, --model ` | Model to use | `anthropic/claude-sonnet-4.5` | -| `-M, --mode ` | Mode to start in (code, architect, ask, debug, etc.) | `code` | -| `-r, --reasoning-effort ` | Reasoning effort level (unspecified, disabled, none, minimal, low, medium, high, xhigh) | `medium` | -| `--ephemeral` | Run without persisting state (uses temporary storage) | `false` | -| `--no-tui` | Disable TUI, use plain text output | `false` | +| Option | Description | Default | +| --------------------------------- | --------------------------------------------------------------------------------------- | ---------------------------------------- | +| `[prompt]` | Your prompt (positional argument, optional) | None | +| `--prompt-file ` | Read prompt from a file instead of command line argument | None | +| `-w, --workspace ` | Workspace path to operate in | Current directory | +| `-p, --print` | Print response and exit (non-interactive mode) | `false` | +| `--stdin-prompt-stream` | Read prompts from stdin (one prompt per line, requires `--print`) | `false` | +| `-e, --extension ` | 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 ` | API key for the LLM provider | From env var | +| `--provider ` | API provider (roo, anthropic, openai, openrouter, etc.) | `openrouter` (or `roo` if authenticated) | +| `-m, --model ` | Model to use | `anthropic/claude-opus-4.6` | +| `--mode ` | Mode to start in (code, architect, ask, debug, etc.) | `code` | +| `-r, --reasoning-effort ` | Reasoning effort level (unspecified, disabled, none, minimal, low, medium, high, xhigh) | `medium` | +| `--ephemeral` | Run without persisting state (uses temporary storage) | `false` | +| `--oneshot` | Exit upon task completion | `false` | +| `--output-format ` | Output format with `--print`: `text`, `json`, or `stream-json` | `text` | ## Auth Commands | Command | Description | | ----------------- | ---------------------------------- | -| `roo auth login` | Authenticate with Roo Code Cloud | +| `roo auth login` | Authenticate with Klaus Code Cloud | | `roo auth logout` | Clear stored authentication token | | `roo auth status` | Show current authentication status | @@ -175,19 +195,20 @@ Tokens are valid for 90 days. The CLI will prompt you to re-authenticate when yo The CLI will look for API keys in environment variables if not provided via `--api-key`: -| Provider | Environment Variable | -| ------------- | -------------------- | -| anthropic | `ANTHROPIC_API_KEY` | -| openai | `OPENAI_API_KEY` | -| openrouter | `OPENROUTER_API_KEY` | -| google/gemini | `GOOGLE_API_KEY` | -| ... | ... | +| Provider | Environment Variable | +| ----------------- | --------------------------- | +| roo | `ROO_API_KEY` | +| 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` | **Authentication Environment Variables:** -| Variable | Description | -| ----------------- | -------------------------------------------------------------------- | -| `ROO_WEB_APP_URL` | Override the Roo Code Cloud URL (default: `https://app.roocode.com`) | +| Variable | Description | +| ----------------- | ---------------------------------------------------------------------- | +| `ROO_WEB_APP_URL` | Override the Klaus Code Cloud URL (default: `https://app.roocode.com`) | ## Architecture @@ -219,7 +240,7 @@ The CLI will look for API keys in environment variables if not provided via `--a 2. **ExtensionHost** (`extension-host.ts`): - - Creates a VSCode API mock using `@roo-code/vscode-shim` + - Creates a VSCode API mock using `@klaus-code/vscode-shim` - Intercepts `require('vscode')` to return the mock - Loads and activates the extension bundle - Manages bidirectional message flow @@ -231,8 +252,8 @@ The CLI will look for API keys in environment variables if not provided via `--a ## Development ```bash -# Watch mode for development -pnpm dev +# Run directly from source (no build required) +pnpm dev --provider roo --api-key $ROO_API_KEY --print "Hello" # Run tests pnpm test @@ -244,19 +265,41 @@ pnpm check-types pnpm lint ``` -## Releasing - -To create a new release, execute the /cli-release slash command: +By default the `start` script points `ROO_CODE_PROVIDER_URL` at `http://localhost:8080/proxy` for local development. To point at the production API instead, override the environment variable: ```bash -roo ~/Documents/Roo-Code -P "/cli-release" -y +ROO_CODE_PROVIDER_URL=https://api.roocode.com/proxy pnpm dev --provider roo --api-key $ROO_API_KEY --print "Hello" ``` +## 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. Bump the version -2. Update the CHANGELOG -3. Build the extension and CLI -4. Create a platform-specific tarball (for your current OS/architecture) -5. Test the install script -6. Create a GitHub release with the tarball attached +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 +``` diff --git a/apps/cli/docs/AGENT_LOOP.md b/apps/cli/docs/AGENT_LOOP.md index a7b1d9eed40..0dd89f1c56f 100644 --- a/apps/cli/docs/AGENT_LOOP.md +++ b/apps/cli/docs/AGENT_LOOP.md @@ -1,6 +1,6 @@ # CLI Agent Loop -This document explains how the Roo Code CLI detects and tracks the agent loop state. +This document explains how the Klaus Code CLI detects and tracks the agent loop state. ## Overview @@ -242,7 +242,8 @@ Routes asks to appropriate handlers: - Uses type guards: `isIdleAsk()`, `isInteractiveAsk()`, etc. - Coordinates between `OutputManager` and `PromptManager` -- In non-interactive mode (`-y` flag), auto-approves everything +- By default, the CLI auto-approves tool/command/browser/MCP actions +- In `--require-approval` mode, those actions prompt for manual approval ### OutputManager @@ -298,10 +299,10 @@ client.sendMessage({ ## Type Guards -The CLI uses type guards from `@roo-code/types` for categorization: +The CLI uses type guards from `@klaus-code/types` for categorization: ```typescript -import { isIdleAsk, isInteractiveAsk, isResumableAsk, isNonBlockingAsk } from "@roo-code/types" +import { isIdleAsk, isInteractiveAsk, isResumableAsk, isNonBlockingAsk } from "@klaus-code/types" const ask = message.ask if (isInteractiveAsk(ask)) { @@ -320,7 +321,7 @@ if (isInteractiveAsk(ask)) { Enable with `-d` flag. Logs go to `~/.roo/cli-debug.log`: ```bash -roo -d -y -P "Build something" --no-tui +roo -d -P "Build something" --no-tui ``` View logs: diff --git a/apps/cli/eslint.config.mjs b/apps/cli/eslint.config.mjs index 694bf736642..df8d6227c5e 100644 --- a/apps/cli/eslint.config.mjs +++ b/apps/cli/eslint.config.mjs @@ -1,4 +1,4 @@ -import { config } from "@roo-code/config-eslint/base" +import { config } from "@klaus-code/config-eslint/base" /** @type {import("eslint").Linter.Config} */ export default [...config] diff --git a/apps/cli/install.sh b/apps/cli/install.sh index 1b01e51aa58..2b76f72343a 100755 --- a/apps/cli/install.sh +++ b/apps/cli/install.sh @@ -1,5 +1,5 @@ #!/bin/sh -# Roo Code CLI Installer +# Klaus Code CLI Installer # Usage: curl -fsSL https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/install.sh | sh # # Environment variables: @@ -267,7 +267,7 @@ verify_install() { # Print success message print_success() { echo "" - printf "${GREEN}${BOLD}✓ Roo Code CLI installed successfully!${NC}\n" + printf "${GREEN}${BOLD}✓ Klaus Code CLI installed successfully!${NC}\n" echo "" echo " Installation: $INSTALL_DIR" echo " Binary: $BIN_DIR/roo" @@ -278,7 +278,7 @@ print_success() { echo "" echo " ${BOLD}Example:${NC}" echo " export OPENROUTER_API_KEY=sk-or-v1-..." - echo " roo ~/my-project -P \"What is this project?\"" + echo " cd ~/my-project && roo \"What is this project?\"" echo "" } @@ -287,7 +287,7 @@ main() { echo "" printf "${BLUE}${BOLD}" echo " ╭─────────────────────────────────╮" - echo " │ Roo Code CLI Installer │" + echo " │ Klaus Code CLI Installer │" echo " ╰─────────────────────────────────╯" printf "${NC}" echo "" diff --git a/apps/cli/package.json b/apps/cli/package.json index 6348bbe020a..e3257ab1b8b 100644 --- a/apps/cli/package.json +++ b/apps/cli/package.json @@ -1,6 +1,4 @@ { - "name": "@roo-code/cli", - "version": "0.0.49", "description": "Roo Code CLI - Run the Roo Code agent from the command line", "private": true, "type": "module", @@ -15,18 +13,16 @@ "test": "vitest run", "build": "tsup", "build:extension": "pnpm --filter roo-cline bundle", - "build:all": "pnpm --filter roo-cline bundle && tsup", - "dev": "tsup --watch", - "start": "ROO_AUTH_BASE_URL=http://localhost:3000 ROO_SDK_BASE_URL=http://localhost:3001 ROO_CODE_PROVIDER_URL=http://localhost:8080/proxy node dist/index.js", - "start:production": "node dist/index.js", - "release": "scripts/release.sh", + "dev": "ROO_AUTH_BASE_URL=https://app.roocode.com ROO_SDK_BASE_URL=https://cloud-api.roocode.com ROO_CODE_PROVIDER_URL=https://api.roocode.com/proxy tsx src/index.ts -y", + "dev:local": "ROO_AUTH_BASE_URL=http://localhost:3000 ROO_SDK_BASE_URL=http://localhost:3001 ROO_CODE_PROVIDER_URL=http://localhost:8080/proxy tsx src/index.ts", + "dev:test-stdin": "tsx scripts/test-stdin-stream.ts", "clean": "rimraf dist .turbo" }, "dependencies": { "@inkjs/ui": "^2.0.0", - "@roo-code/core": "workspace:^", - "@roo-code/types": "workspace:^", - "@roo-code/vscode-shim": "workspace:^", + "@klaus-code/core": "workspace:^", + "@klaus-code/types": "workspace:^", + "@klaus-code/vscode-shim": "workspace:^", "@trpc/client": "^11.8.1", "@vscode/ripgrep": "^1.15.9", "commander": "^12.1.0", @@ -40,8 +36,8 @@ "zustand": "^5.0.0" }, "devDependencies": { - "@roo-code/config-eslint": "workspace:^", - "@roo-code/config-typescript": "workspace:^", + "@klaus-code/config-eslint": "workspace:^", + "@klaus-code/config-typescript": "workspace:^", "@types/node": "^24.1.0", "@types/react": "^19.1.6", "ink-testing-library": "^4.0.0", diff --git a/apps/cli/scripts/build.sh b/apps/cli/scripts/build.sh new file mode 100755 index 00000000000..97a33c384c8 --- /dev/null +++ b/apps/cli/scripts/build.sh @@ -0,0 +1,343 @@ +#!/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'; + +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')); +WRAPPER_EOF + + chmod +x "$RELEASE_DIR/bin/roo" + + # Create empty .env file + touch "$RELEASE_DIR/.env" + + # Create tarball + info "Creating tarball..." + cd "$REPO_ROOT" + tar -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 diff --git a/apps/cli/scripts/release.sh b/apps/cli/scripts/release.sh deleted file mode 100755 index 7e736db3dbc..00000000000 --- a/apps/cli/scripts/release.sh +++ /dev/null @@ -1,711 +0,0 @@ -#!/bin/bash -# Roo Code CLI Release Script -# -# Usage: -# ./apps/cli/scripts/release.sh [options] [version] -# -# Options: -# --dry-run Run all steps except creating the GitHub release -# --local Build for local testing only (no GitHub checks, no changelog prompts) -# --install Install locally after building (only with --local) -# --skip-verify Skip end-to-end verification tests (faster local builds) -# -# Examples: -# ./apps/cli/scripts/release.sh # Use version from package.json -# ./apps/cli/scripts/release.sh 0.1.0 # Specify version -# ./apps/cli/scripts/release.sh --dry-run # Test the release flow without pushing -# ./apps/cli/scripts/release.sh --dry-run 0.1.0 # Dry run with specific version -# ./apps/cli/scripts/release.sh --local # Build for local testing -# ./apps/cli/scripts/release.sh --local --install # Build and install locally -# ./apps/cli/scripts/release.sh --local --skip-verify # Fast local build -# -# This script: -# 1. Builds the extension and CLI -# 2. Creates a tarball for the current platform -# 3. Creates a GitHub release and uploads the tarball (unless --dry-run or --local) -# -# Prerequisites: -# - GitHub CLI (gh) installed and authenticated (not needed for --local) -# - pnpm installed -# - Run from the monorepo root directory - -set -e - -# Parse arguments -DRY_RUN=false -LOCAL_BUILD=false -LOCAL_INSTALL=false -SKIP_VERIFY=false -VERSION_ARG="" - -while [[ $# -gt 0 ]]; do - case $1 in - --dry-run) - DRY_RUN=true - shift - ;; - --local) - LOCAL_BUILD=true - shift - ;; - --install) - LOCAL_INSTALL=true - shift - ;; - --skip-verify) - SKIP_VERIFY=true - shift - ;; - -*) - echo "Unknown option: $1" >&2 - exit 1 - ;; - *) - VERSION_ARG="$1" - shift - ;; - esac -done - -# Validate option combinations -if [ "$LOCAL_INSTALL" = true ] && [ "$LOCAL_BUILD" = false ]; then - echo "Error: --install can only be used with --local" >&2 - exit 1 -fi - -# 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/8" "Checking prerequisites..." - - # Skip GitHub CLI checks for local builds - if [ "$LOCAL_BUILD" = false ]; then - if ! command -v gh &> /dev/null; then - error "GitHub CLI (gh) is not installed. Install it with: brew install gh" - fi - - if ! gh auth status &> /dev/null; then - error "GitHub CLI is not authenticated. Run: gh auth login" - fi - fi - - 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() { - if [ -n "$VERSION_ARG" ]; then - VERSION="$VERSION_ARG" - else - VERSION=$(node -p "require('$CLI_DIR/package.json').version") - fi - - # For local builds, append a local suffix with git short hash - # This creates versions like: 0.1.0-local.abc1234 - if [ "$LOCAL_BUILD" = true ]; then - GIT_SHORT_HASH=$(git rev-parse --short HEAD 2>/dev/null || echo "unknown") - # Only append suffix if not already a local version - if ! echo "$VERSION" | grep -qE '\-local\.'; then - VERSION="${VERSION}-local.${GIT_SHORT_HASH}" - fi - fi - - # Validate semver format (allow -local.hash suffix) - if ! echo "$VERSION" | grep -qE '^[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9.]+)?$'; then - error "Invalid version format: $VERSION (expected semver like 0.1.0)" - fi - - TAG="cli-v$VERSION" - info "Version: $VERSION (tag: $TAG)" -} - -# Extract changelog content for a specific version -# Returns the content between the version header and the next version header (or EOF) -get_changelog_content() { - CHANGELOG_FILE="$CLI_DIR/CHANGELOG.md" - - if [ ! -f "$CHANGELOG_FILE" ]; then - warn "No CHANGELOG.md found at $CHANGELOG_FILE" - CHANGELOG_CONTENT="" - return - fi - - # Try to find the version section (handles both "[0.0.43]" and "[0.0.43] - date" formats) - # Also handles "Unreleased" marker - VERSION_PATTERN="^\#\# \[${VERSION}\]" - - # Check if the version exists in the changelog - if ! grep -qE "$VERSION_PATTERN" "$CHANGELOG_FILE"; then - warn "No changelog entry found for version $VERSION" - # Skip prompts for local builds - if [ "$LOCAL_BUILD" = true ]; then - info "Skipping changelog prompt for local build" - CHANGELOG_CONTENT="" - return - fi - warn "Please add an entry to $CHANGELOG_FILE before releasing" - echo "" - echo "Expected format:" - echo " ## [$VERSION] - $(date +%Y-%m-%d)" - echo " " - echo " ### Added" - echo " - Your changes here" - echo "" - read -p "Continue without changelog content? [y/N] " -n 1 -r - echo - if [[ ! $REPLY =~ ^[Yy]$ ]]; then - error "Aborted. Please add a changelog entry and try again." - fi - CHANGELOG_CONTENT="" - return - fi - - # Extract content between this version and the next version header (or EOF) - # Uses awk to capture everything between ## [VERSION] and the next ## [ - # Using index() with "[VERSION]" ensures exact matching (1.0.1 won't match 1.0.10) - CHANGELOG_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") - - # Trim leading/trailing whitespace - CHANGELOG_CONTENT=$(echo "$CHANGELOG_CONTENT" | sed -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//') - - if [ -n "$CHANGELOG_CONTENT" ]; then - info "Found changelog content for version $VERSION" - else - warn "Changelog entry for $VERSION appears to be empty" - fi -} - -# Build everything -build() { - step "2/8" "Building extension bundle..." - cd "$REPO_ROOT" - pnpm bundle - - step "3/8" "Building CLI..." - pnpm --filter @roo-code/cli build - - info "Build complete" -} - -# Create release tarball -create_tarball() { - step "4/8" "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 (runtime dependencies that can't be bundled) - 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 to mark it as CommonJS - # This is necessary because the main package.json has "type": "module" - # but the extension bundle is CommonJS - echo '{"type": "commonjs"}' > "$RELEASE_DIR/extension/package.json" - - # Find and copy ripgrep binary - # The extension looks for ripgrep at: appRoot/node_modules/@vscode/ripgrep/bin/rg - # The CLI sets appRoot to the CLI package root, so we need to put ripgrep there - 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" - # Create the expected directory structure for the extension to find ripgrep - 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" - # Also keep a copy in bin/ for direct access - 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'; - -const __filename = fileURLToPath(import.meta.url); -const __dirname = dirname(__filename); - -// Set environment variables for the CLI -// ROO_CLI_ROOT is the installed CLI package root (where node_modules/@vscode/ripgrep is) -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')); -WRAPPER_EOF - - chmod +x "$RELEASE_DIR/bin/roo" - - # Create empty .env file to suppress dotenvx warnings - touch "$RELEASE_DIR/.env" - - # Create empty .env file to suppress dotenvx warnings - touch "$RELEASE_DIR/.env" - - # Create tarball - info "Creating tarball..." - cd "$REPO_ROOT" - tar -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/8" "Skipping verification (--skip-verify)" - return - fi - - step "5/8" "Verifying local installation..." - - VERIFY_DIR="$REPO_ROOT/.verify-release" - VERIFY_INSTALL_DIR="$VERIFY_DIR/cli" - VERIFY_BIN_DIR="$VERIFY_DIR/bin" - - # Clean up any previous verification directory - rm -rf "$VERIFY_DIR" - mkdir -p "$VERIFY_DIR" - - # Run the actual install script with the local tarball - info "Running install script with local tarball..." - 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" || { - echo "" - warn "Install script failed. Showing tarball contents:" - tar -tzf "$TARBALL_PATH" 2>&1 || true - echo "" - rm -rf "$VERIFY_DIR" - error "Installation verification failed! The install script could not complete successfully." - } - - # Verify the CLI runs correctly with basic commands - info "Testing installed CLI..." - - # Test --help - if ! "$VERIFY_BIN_DIR/roo" --help > /dev/null 2>&1; then - echo "" - warn "CLI --help output:" - "$VERIFY_BIN_DIR/roo" --help 2>&1 || true - echo "" - rm -rf "$VERIFY_DIR" - error "CLI --help check failed! The release tarball may have missing dependencies." - fi - info "CLI --help check passed" - - # Test --version - if ! "$VERIFY_BIN_DIR/roo" --version > /dev/null 2>&1; then - echo "" - warn "CLI --version output:" - "$VERIFY_BIN_DIR/roo" --version 2>&1 || true - echo "" - rm -rf "$VERIFY_DIR" - error "CLI --version check failed! The release tarball may have missing dependencies." - fi - info "CLI --version check passed" - - # Run a simple end-to-end test to verify the CLI actually works - info "Running end-to-end verification test..." - - # Create a temporary workspace for the test - VERIFY_WORKSPACE="$VERIFY_DIR/workspace" - mkdir -p "$VERIFY_WORKSPACE" - - # Run the CLI with a simple prompt - if timeout 60 "$VERIFY_BIN_DIR/roo" --yes --oneshot -w "$VERIFY_WORKSPACE" "1+1=?" > "$VERIFY_DIR/test-output.log" 2>&1; then - info "End-to-end test passed" - else - EXIT_CODE=$? - echo "" - warn "End-to-end test failed (exit code: $EXIT_CODE). Output:" - cat "$VERIFY_DIR/test-output.log" 2>&1 || true - echo "" - rm -rf "$VERIFY_DIR" - error "CLI end-to-end test failed! The CLI may be broken." - fi - - # Clean up verification directory - cd "$REPO_ROOT" - rm -rf "$VERIFY_DIR" - - info "Local verification passed!" -} - -# Create checksum -create_checksum() { - step "6/8" "Creating checksum..." - cd "$REPO_ROOT" - - if command -v sha256sum &> /dev/null; then - sha256sum "$TARBALL" > "${TARBALL}.sha256" - elif command -v shasum &> /dev/null; then - shasum -a 256 "$TARBALL" > "${TARBALL}.sha256" - else - warn "No sha256sum or shasum found, skipping checksum" - return - fi - - info "Checksum: $(cat "${TARBALL}.sha256")" -} - -# Check if release already exists -check_existing_release() { - step "7/8" "Checking for existing release..." - - if gh release view "$TAG" &> /dev/null; then - warn "Release $TAG already exists" - read -p "Do you want to delete it and create a new one? [y/N] " -n 1 -r - echo - if [[ $REPLY =~ ^[Yy]$ ]]; then - info "Deleting existing release..." - gh release delete "$TAG" --yes - # Also delete the tag if it exists - git tag -d "$TAG" 2>/dev/null || true - git push origin ":refs/tags/$TAG" 2>/dev/null || true - else - error "Aborted. Use a different version or delete the existing release manually." - fi - fi -} - -# Create GitHub release -create_release() { - step "8/8" "Creating GitHub release..." - cd "$REPO_ROOT" - - # Get the current commit SHA for the release target - COMMIT_SHA=$(git rev-parse HEAD) - - # Verify the commit exists on GitHub before attempting to create the release - # This prevents the "Release.target_commitish is invalid" error - info "Verifying commit ${COMMIT_SHA:0:8} exists on GitHub..." - git fetch origin 2>/dev/null || true - if ! git branch -r --contains "$COMMIT_SHA" 2>/dev/null | grep -q "origin/"; then - warn "Commit ${COMMIT_SHA:0:8} has not been pushed to GitHub" - echo "" - echo "The release script needs to create a release at your current commit," - echo "but this commit hasn't been pushed to GitHub yet." - echo "" - read -p "Push current branch to origin now? [Y/n] " -n 1 -r - echo - if [[ ! $REPLY =~ ^[Nn]$ ]]; then - info "Pushing to origin..." - git push origin HEAD || error "Failed to push to origin. Please push manually and try again." - else - error "Aborted. Please push your commits to GitHub and try again." - fi - fi - info "Commit verified on GitHub" - - # Build the What's New section from changelog content - WHATS_NEW_SECTION="" - if [ -n "$CHANGELOG_CONTENT" ]; then - WHATS_NEW_SECTION="## What's New - -$CHANGELOG_CONTENT - -" - fi - - RELEASE_NOTES=$(cat << EOF -${WHATS_NEW_SECTION}## Installation - -\`\`\`bash -curl -fsSL https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/install.sh | sh -\`\`\` - -Or install a specific version: -\`\`\`bash -ROO_VERSION=$VERSION curl -fsSL https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/install.sh | sh -\`\`\` - -## Requirements - -- Node.js 20 or higher -- macOS (Intel or Apple Silicon) or Linux (x64 or ARM64) - -## Usage - -\`\`\`bash -# Run a task -roo "What is this project?" - -# See all options -roo --help -\`\`\` - -## Platform Support - -This release includes: -- \`roo-cli-${PLATFORM}.tar.gz\` - Built on $(uname -s) $(uname -m) - -> **Note:** Additional platforms will be added as needed. If you need a different platform, please open an issue. - -## Checksum - -\`\`\` -$(cat "${TARBALL}.sha256" 2>/dev/null || echo "N/A") -\`\`\` -EOF -) - - info "Creating release at commit: ${COMMIT_SHA:0:8}" - - # Create release (gh will create the tag automatically) - info "Creating release..." - RELEASE_FILES="$TARBALL" - if [ -f "${TARBALL}.sha256" ]; then - RELEASE_FILES="$RELEASE_FILES ${TARBALL}.sha256" - fi - - gh release create "$TAG" \ - --title "Roo Code CLI v$VERSION" \ - --notes "$RELEASE_NOTES" \ - --prerelease \ - --target "$COMMIT_SHA" \ - $RELEASE_FILES - - info "Release created!" -} - -# Cleanup -cleanup() { - info "Cleaning up..." - cd "$REPO_ROOT" - rm -f "$TARBALL" "${TARBALL}.sha256" -} - -# Print summary -print_summary() { - echo "" - printf "${GREEN}${BOLD}✓ Release v$VERSION created successfully!${NC}\n" - echo "" - echo " Release URL: https://github.com/RooCodeInc/Roo-Code/releases/tag/$TAG" - echo "" - echo " Install with:" - echo " curl -fsSL https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/install.sh | sh" - echo "" -} - -# Print dry-run summary -print_dry_run_summary() { - echo "" - printf "${YELLOW}${BOLD}✓ Dry run complete for v$VERSION${NC}\n" - echo "" - echo " The following artifacts were created:" - echo " - $TARBALL" - if [ -f "${TARBALL}.sha256" ]; then - echo " - ${TARBALL}.sha256" - fi - echo "" - echo " To complete the release, run without --dry-run:" - echo " ./apps/cli/scripts/release.sh $VERSION" - echo "" - echo " Or manually upload the tarball to a new GitHub release." - echo "" -} - -# Print local build summary -print_local_summary() { - echo "" - printf "${GREEN}${BOLD}✓ Local build complete for v$VERSION${NC}\n" - echo "" - echo " Tarball: $REPO_ROOT/$TARBALL" - if [ -f "${TARBALL}.sha256" ]; then - echo " Checksum: $REPO_ROOT/${TARBALL}.sha256" - fi - echo "" - echo " To install manually:" - echo " ROO_LOCAL_TARBALL=$REPO_ROOT/$TARBALL ./apps/cli/install.sh" - echo "" - echo " Or re-run with --install to install automatically:" - echo " ./apps/cli/scripts/release.sh --local --install" - echo "" -} - -# Install locally using the install script -install_local() { - step "7/8" "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 local install summary -print_local_install_summary() { - echo "" - printf "${GREEN}${BOLD}✓ Local build installed for v$VERSION${NC}\n" - echo "" - echo " Tarball: $REPO_ROOT/$TARBALL" - echo " Installed to: ~/.roo/cli" - echo " Binary: ~/.local/bin/roo" - echo "" - echo " Test it out:" - echo " roo --version" - echo " roo --help" - echo "" -} - -# Main -main() { - echo "" - printf "${BLUE}${BOLD}" - echo " ╭─────────────────────────────────╮" - echo " │ Roo Code CLI Release Script │" - echo " ╰─────────────────────────────────╯" - printf "${NC}" - - if [ "$DRY_RUN" = true ]; then - printf "${YELLOW} (DRY RUN MODE)${NC}\n" - elif [ "$LOCAL_BUILD" = true ]; then - printf "${YELLOW} (LOCAL BUILD MODE)${NC}\n" - fi - echo "" - - detect_platform - check_prerequisites - get_version - get_changelog_content - build - create_tarball - verify_local_install - create_checksum - - if [ "$LOCAL_BUILD" = true ]; then - step "7/8" "Skipping GitHub checks (local build)" - if [ "$LOCAL_INSTALL" = true ]; then - install_local - print_local_install_summary - else - step "8/8" "Skipping installation (use --install to auto-install)" - print_local_summary - fi - elif [ "$DRY_RUN" = true ]; then - step "7/8" "Skipping existing release check (dry run)" - step "8/8" "Skipping GitHub release creation (dry run)" - print_dry_run_summary - else - check_existing_release - create_release - cleanup - print_summary - fi -} - -main diff --git a/apps/cli/scripts/test-stdin-stream.ts b/apps/cli/scripts/test-stdin-stream.ts new file mode 100644 index 00000000000..5212df5b335 --- /dev/null +++ b/apps/cli/scripts/test-stdin-stream.ts @@ -0,0 +1,67 @@ +import path from "path" +import { fileURLToPath } from "url" +import readline from "readline" + +import { execa } from "execa" + +const __dirname = path.dirname(fileURLToPath(import.meta.url)) +const cliRoot = path.resolve(__dirname, "..") + +async function main() { + const child = execa( + "pnpm", + ["dev", "--print", "--stdin-prompt-stream", "--provider", "roo", "--output-format", "stream-json"], + { + cwd: cliRoot, + stdin: "pipe", + stdout: "pipe", + stderr: "pipe", + reject: false, + forceKillAfterDelay: 2_000, + }, + ) + + child.stdout?.on("data", (chunk) => process.stdout.write(chunk)) + child.stderr?.on("data", (chunk) => process.stderr.write(chunk)) + + console.log("[wrapper] Type a message and press Enter to send it.") + console.log("[wrapper] Type /exit to close stdin and let the CLI finish.") + + const rl = readline.createInterface({ + input: process.stdin, + output: process.stdout, + terminal: true, + }) + + rl.on("line", (line) => { + if (line.trim() === "/exit") { + console.log("[wrapper] Closing stdin...") + child.stdin?.end() + rl.close() + return + } + + if (!child.stdin?.destroyed) { + child.stdin?.write(`${line}\n`) + } + }) + + const onSignal = (signal: NodeJS.Signals) => { + console.log(`[wrapper] Received ${signal}, forwarding to CLI...`) + rl.close() + child.kill(signal) + } + + process.on("SIGINT", () => onSignal("SIGINT")) + process.on("SIGTERM", () => onSignal("SIGTERM")) + + const result = await child + rl.close() + console.log(`[wrapper] CLI exited with code ${result.exitCode}`) + process.exit(result.exitCode ?? 1) +} + +main().catch((error) => { + console.error("[wrapper] Fatal error:", error) + process.exit(1) +}) diff --git a/apps/cli/src/__tests__/index.test.ts b/apps/cli/src/__tests__/index.test.ts index aa9649373d0..6f1c45d2d6e 100644 --- a/apps/cli/src/__tests__/index.test.ts +++ b/apps/cli/src/__tests__/index.test.ts @@ -10,7 +10,7 @@ * 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 +// pnpm --filter @klaus-code/cli test src/__tests__/index.test.ts import path from "path" import fs from "fs" diff --git a/apps/cli/src/agent/__tests__/extension-client.test.ts b/apps/cli/src/agent/__tests__/extension-client.test.ts index 3d87a30200f..015ec28f443 100644 --- a/apps/cli/src/agent/__tests__/extension-client.test.ts +++ b/apps/cli/src/agent/__tests__/extension-client.test.ts @@ -5,7 +5,7 @@ import { isResumableAsk, isInteractiveAsk, isNonBlockingAsk, -} from "@roo-code/types" +} from "@klaus-code/types" import { AgentLoopState, detectAgentState } from "../agent-state.js" import { createMockClient } from "../extension-client.js" @@ -93,13 +93,6 @@ describe("detectAgentState", () => { expect(state.requiredAction).toBe("answer") }) - it("should detect waiting for browser_action_launch approval", () => { - const messages = [createMessage({ type: "ask", ask: "browser_action_launch", partial: false })] - const state = detectAgentState(messages) - expect(state.state).toBe(AgentLoopState.WAITING_FOR_INPUT) - expect(state.requiredAction).toBe("approve") - }) - it("should detect waiting for use_mcp_server approval", () => { const messages = [createMessage({ type: "ask", ask: "use_mcp_server", partial: false })] const state = detectAgentState(messages) @@ -202,7 +195,6 @@ describe("Type Guards", () => { expect(isInteractiveAsk("tool")).toBe(true) expect(isInteractiveAsk("command")).toBe(true) expect(isInteractiveAsk("followup")).toBe(true) - expect(isInteractiveAsk("browser_action_launch")).toBe(true) expect(isInteractiveAsk("use_mcp_server")).toBe(true) }) diff --git a/apps/cli/src/agent/__tests__/extension-host.test.ts b/apps/cli/src/agent/__tests__/extension-host.test.ts index 2354e3ab75d..fdc854f7b4d 100644 --- a/apps/cli/src/agent/__tests__/extension-host.test.ts +++ b/apps/cli/src/agent/__tests__/extension-host.test.ts @@ -1,15 +1,15 @@ -// pnpm --filter @roo-code/cli test src/agent/__tests__/extension-host.test.ts +// pnpm --filter @klaus-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 type { ExtensionMessage, WebviewMessage } from "@klaus-code/types" 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", () => ({ +vi.mock("@klaus-code/vscode-shim", () => ({ createVSCodeAPI: vi.fn(() => ({ context: { extensionPath: "/test/extension" }, })), diff --git a/apps/cli/src/agent/agent-state.ts b/apps/cli/src/agent/agent-state.ts index ca4a099ccab..4638a982351 100644 --- a/apps/cli/src/agent/agent-state.ts +++ b/apps/cli/src/agent/agent-state.ts @@ -2,14 +2,21 @@ * 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 + * Klaus 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" +import { + ClineMessage, + ClineAsk, + isIdleAsk, + isResumableAsk, + isInteractiveAsk, + isNonBlockingAsk, +} from "@klaus-code/types" // ============================================================================= // Agent Loop State Enum @@ -116,7 +123,7 @@ export enum AgentLoopState { */ export type RequiredAction = | "none" // No action needed (running/streaming) - | "approve" // Can approve/reject (tool, command, browser, mcp) + | "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) @@ -221,7 +228,6 @@ function getRequiredAction(ask: ClineAsk): RequiredAction { return "answer" case "command": case "tool": - case "browser_action_launch": case "use_mcp_server": return "approve" case "command_output": @@ -264,8 +270,6 @@ function getStateDescription(state: AgentLoopState, ask?: ClineAsk): string { return "Agent wants to execute a command. Approve or reject." case "tool": return "Agent wants to perform a file operation. Approve or reject." - case "browser_action_launch": - return "Agent wants to use the browser. Approve or reject." case "use_mcp_server": return "Agent wants to use an MCP server. Approve or reject." default: diff --git a/apps/cli/src/agent/ask-dispatcher.ts b/apps/cli/src/agent/ask-dispatcher.ts index 8d57e4547cd..9804534b664 100644 --- a/apps/cli/src/agent/ask-dispatcher.ts +++ b/apps/cli/src/agent/ask-dispatcher.ts @@ -23,8 +23,8 @@ import { isInteractiveAsk, isResumableAsk, isNonBlockingAsk, -} from "@roo-code/types" -import { debugLog } from "@roo-code/core/cli" +} from "@klaus-code/types" +import { debugLog } from "@klaus-code/core/cli" import { FOLLOWUP_TIMEOUT_SECONDS } from "@/types/index.js" @@ -59,6 +59,11 @@ export interface AskDispatcherOptions { */ 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. @@ -87,6 +92,7 @@ export class AskDispatcher { private promptManager: PromptManager private sendMessage: (message: WebviewMessage) => void private nonInteractive: boolean + private exitOnError: boolean private disabled: boolean /** @@ -100,6 +106,7 @@ export class AskDispatcher { this.promptManager = options.promptManager this.sendMessage = options.sendMessage this.nonInteractive = options.nonInteractive ?? false + this.exitOnError = options.exitOnError ?? false this.disabled = options.disabled ?? false } @@ -237,7 +244,7 @@ export class AskDispatcher { } /** - * Handle interactive asks (followup, command, tool, browser_action_launch, use_mcp_server). + * 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 { @@ -251,9 +258,6 @@ export class AskDispatcher { case "tool": return await this.handleToolApproval(ts, text) - case "browser_action_launch": - return await this.handleBrowserApproval(ts, text) - case "use_mcp_server": return await this.handleMcpApproval(ts, text) @@ -437,32 +441,6 @@ export class AskDispatcher { } } - /** - * Handle browser action approval. - */ - private async handleBrowserApproval(ts: number, text: string): Promise { - this.outputManager.output("\n[browser action request]") - if (text) { - this.outputManager.output(` Action: ${text}`) - } - 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 browser 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. */ @@ -518,6 +496,11 @@ export class AskDispatcher { 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 diff --git a/apps/cli/src/agent/events.ts b/apps/cli/src/agent/events.ts index 9b374310ad7..62ab445d5cf 100644 --- a/apps/cli/src/agent/events.ts +++ b/apps/cli/src/agent/events.ts @@ -8,7 +8,7 @@ import { EventEmitter } from "events" -import { ClineMessage, ClineAsk } from "@roo-code/types" +import { ClineMessage, ClineAsk } from "@klaus-code/types" import type { AgentStateInfo } from "./agent-state.js" diff --git a/apps/cli/src/agent/extension-client.ts b/apps/cli/src/agent/extension-client.ts index c2d77dfdd91..aa0cb40828a 100644 --- a/apps/cli/src/agent/extension-client.ts +++ b/apps/cli/src/agent/extension-client.ts @@ -1,5 +1,5 @@ /** - * Roo Code Client + * Klaus Code Client * * This is the main entry point for the client library. It provides a high-level * API for: @@ -27,7 +27,7 @@ * ``` */ -import type { ExtensionMessage, WebviewMessage, ClineAskResponse, ClineMessage, ClineAsk } from "@roo-code/types" +import type { ExtensionMessage, WebviewMessage, ClineAskResponse, ClineMessage, ClineAsk } from "@klaus-code/types" import { StateStore } from "./state-store.js" import { MessageProcessor, parseExtensionMessage } from "./message-processor.js" @@ -84,7 +84,7 @@ export interface ExtensionClientConfig { // ============================================================================= /** - * ExtensionClient is the main interface for interacting with the Roo Code extension. + * ExtensionClient is the main interface for interacting with the Klaus Code extension. * * Basic usage: * ```typescript diff --git a/apps/cli/src/agent/extension-host.ts b/apps/cli/src/agent/extension-host.ts index e1f55a30d1f..b2d41027a80 100644 --- a/apps/cli/src/agent/extension-host.ts +++ b/apps/cli/src/agent/extension-host.ts @@ -22,9 +22,9 @@ import type { ReasoningEffortExtended, RooCodeSettings, WebviewMessage, -} from "@roo-code/types" -import { createVSCodeAPI, IExtensionHost, ExtensionHostEventMap, setRuntimeConfigValues } from "@roo-code/vscode-shim" -import { DebugLogger } from "@roo-code/core/cli" +} from "@klaus-code/types" +import { createVSCodeAPI, IExtensionHost, ExtensionHostEventMap, setRuntimeConfigValues } from "@klaus-code/vscode-shim" +import { DebugLogger, setDebugLogEnabled } from "@klaus-code/core/cli" import type { SupportedProvider } from "@/types/index.js" import type { User } from "@/lib/sdk/index.js" @@ -43,10 +43,25 @@ const cliLogger = new DebugLogger("CLI") // Get the CLI package root directory (for finding node_modules/@vscode/ripgrep) // When running from a release tarball, ROO_CLI_ROOT is set by the wrapper script. -// In development, we fall back to calculating from __dirname. -// After bundling with tsup, the code is in dist/index.js (flat), so we go up one level. +// In development, we fall back to finding the CLI package root by walking up to package.json. +// This works whether running from dist/ (bundled) or src/agent/ (tsx dev). const __dirname = path.dirname(fileURLToPath(import.meta.url)) -const CLI_PACKAGE_ROOT = process.env.ROO_CLI_ROOT || path.resolve(__dirname, "..") + +function findCliPackageRoot(): string { + let dir = __dirname + + while (dir !== path.dirname(dir)) { + if (fs.existsSync(path.join(dir, "package.json"))) { + return dir + } + + dir = path.dirname(dir) + } + + return path.resolve(__dirname, "..") +} + +const CLI_PACKAGE_ROOT = process.env.ROO_CLI_ROOT || findCliPackageRoot() export interface ExtensionHostOptions { mode: string @@ -64,6 +79,10 @@ export interface ExtensionHostOptions { ephemeral: boolean debug: boolean exitOnComplete: boolean + /** + * When true, exit the process on API request errors instead of retrying. + */ + exitOnError?: boolean /** * When true, completely disables all direct stdout/stderr output. * Use this when running in TUI mode where Ink controls the terminal. @@ -154,6 +173,11 @@ export class ExtensionHost extends EventEmitter implements ExtensionHostInterfac this.options = options + // Enable file-based debug logging only when --debug is passed. + if (options.debug) { + setDebugLogEnabled(true) + } + // Set up quiet mode early, before any extension code runs. // This suppresses console output from the extension during load. this.setupQuietMode() @@ -179,6 +203,7 @@ export class ExtensionHost extends EventEmitter implements ExtensionHostInterfac promptManager: this.promptManager, sendMessage: (msg) => this.sendToExtension(msg), nonInteractive: options.nonInteractive, + exitOnError: options.exitOnError, disabled: options.disableOutput, // TUI mode handles asks directly. }) @@ -189,7 +214,6 @@ export class ExtensionHost extends EventEmitter implements ExtensionHostInterfac const baseSettings: RooCodeSettings = { mode: this.options.mode, commandExecutionTimeout: 30, - browserToolEnabled: false, enableCheckpoints: false, ...getProviderSettings(this.options.provider, this.options.apiKey, this.options.model), } @@ -202,7 +226,6 @@ export class ExtensionHost extends EventEmitter implements ExtensionHostInterfac alwaysAllowWrite: true, alwaysAllowWriteOutsideWorkspace: true, alwaysAllowWriteProtected: true, - alwaysAllowBrowser: true, alwaysAllowMcp: true, alwaysAllowModeSwitch: true, alwaysAllowSubtasks: true, @@ -403,12 +426,16 @@ export class ExtensionHost extends EventEmitter implements ExtensionHostInterfac public markWebviewReady(): void { this.isReady = true - // Send initial webview messages to trigger proper extension initialization. - // This is critical for the extension to start sending state updates properly. - this.sendToExtension({ type: "webviewDidLaunch" }) - + // Apply CLI settings to the runtime config and context proxy BEFORE + // sending webviewDidLaunch. This prevents a race condition where the + // webviewDidLaunch handler's first-time init sync reads default state + // (apiProvider: "anthropic") instead of the CLI-provided settings. setRuntimeConfigValues("roo-cline", this.initialSettings as Record) this.sendToExtension({ type: "updateSettings", updatedSettings: this.initialSettings }) + + // Now trigger extension initialization. The context proxy should already + // have CLI-provided values when the webviewDidLaunch handler runs. + this.sendToExtension({ type: "webviewDidLaunch" }) } public isInInitialSetup(): boolean { @@ -448,6 +475,25 @@ export class ExtensionHost extends EventEmitter implements ExtensionHostInterfac const cleanup = () => { this.client.off("taskCompleted", completeHandler) this.client.off("error", errorHandler) + + if (messageHandler) { + this.client.off("message", messageHandler) + } + } + + // When exitOnError is enabled, listen for api_req_retry_delayed messages + // (sent by Task.ts during auto-approval retry backoff) and exit immediately. + let messageHandler: ((msg: ClineMessage) => void) | null = null + + if (this.options.exitOnError) { + messageHandler = (msg: ClineMessage) => { + if (msg.type === "say" && msg.say === "api_req_retry_delayed") { + cleanup() + reject(new Error(msg.text?.split("\n")[0] || "API request failed")) + } + } + + this.client.on("message", messageHandler) } this.client.once("taskCompleted", completeHandler) diff --git a/apps/cli/src/agent/json-event-emitter.ts b/apps/cli/src/agent/json-event-emitter.ts index a1a404e5556..d7d2f0305ec 100644 --- a/apps/cli/src/agent/json-event-emitter.ts +++ b/apps/cli/src/agent/json-event-emitter.ts @@ -14,12 +14,13 @@ * - `done` flag instead of partial:false */ -import type { ClineMessage } from "@roo-code/types" +import type { ClineMessage } from "@klaus-code/types" import type { JsonEvent, JsonEventCost, JsonFinalOutput } from "@/types/json-events.js" import type { ExtensionClient } from "./extension-client.js" -import type { TaskCompletedEvent } from "./events.js" +import type { AgentStateChangeEvent, TaskCompletedEvent } from "./events.js" +import { AgentLoopState } from "./agent-state.js" /** * Options for JsonEventEmitter. @@ -93,6 +94,8 @@ export class JsonEventEmitter { private previousContent = new Map() // Track the completion result content private completionResultContent: string | undefined + // The first non-partial "say:text" per task is the echoed user prompt. + private expectPromptEchoAsUser = true constructor(options: JsonEventEmitterOptions) { this.mode = options.mode @@ -106,10 +109,11 @@ export class JsonEventEmitter { // Subscribe to message events const unsubMessage = client.on("message", (msg) => this.handleMessage(msg, false)) const unsubMessageUpdated = client.on("messageUpdated", (msg) => this.handleMessage(msg, true)) + const unsubStateChange = client.on("stateChange", (event) => this.handleStateChange(event)) const unsubTaskCompleted = client.on("taskCompleted", (event) => this.handleTaskCompleted(event)) const unsubError = client.on("error", (error) => this.handleError(error)) - this.unsubscribers.push(unsubMessage, unsubMessageUpdated, unsubTaskCompleted, unsubError) + this.unsubscribers.push(unsubMessage, unsubMessageUpdated, unsubStateChange, unsubTaskCompleted, unsubError) // Emit init event this.emitEvent({ @@ -119,6 +123,16 @@ export class JsonEventEmitter { }) } + private handleStateChange(event: AgentStateChangeEvent): void { + // Only treat the next say:text as a prompt echo when a new task starts. + if ( + event.previousState.state === AgentLoopState.NO_TASK && + event.currentState.state !== AgentLoopState.NO_TASK + ) { + this.expectPromptEchoAsUser = true + } + } + /** * Detach from the client and clean up subscriptions. */ @@ -227,7 +241,14 @@ export class JsonEventEmitter { private handleSayMessage(msg: ClineMessage, contentToSend: string | null, isDone: boolean): void { switch (msg.say) { case "text": - this.emitEvent(this.buildTextEvent("assistant", msg.ts, contentToSend, isDone)) + if (this.expectPromptEchoAsUser) { + this.emitEvent(this.buildTextEvent("user", msg.ts, contentToSend, isDone)) + if (isDone) { + this.expectPromptEchoAsUser = false + } + } else { + this.emitEvent(this.buildTextEvent("assistant", msg.ts, contentToSend, isDone)) + } break case "reasoning": @@ -248,6 +269,9 @@ export class JsonEventEmitter { case "user_feedback": case "user_feedback_diff": this.emitEvent(this.buildTextEvent("user", msg.ts, contentToSend, isDone)) + if (isDone) { + this.expectPromptEchoAsUser = false + } break case "api_req_started": { @@ -258,15 +282,6 @@ export class JsonEventEmitter { break } - case "browser_action": - case "browser_action_result": - this.emitEvent({ - type: "tool_result", - subtype: "browser", - tool_result: { name: "browser_action", output: msg.text }, - }) - break - case "mcp_server_response": this.emitEvent({ type: "tool_result", @@ -336,15 +351,6 @@ export class JsonEventEmitter { }) break - case "browser_action_launch": - this.emitEvent({ - type: "tool_use", - id: msg.ts, - subtype: "browser", - tool_use: { name: "browser_action", input: { raw: msg.text } }, - }) - break - case "use_mcp_server": this.emitEvent({ type: "tool_use", @@ -460,5 +466,6 @@ export class JsonEventEmitter { this.seenMessageIds.clear() this.previousContent.clear() this.completionResultContent = undefined + this.expectPromptEchoAsUser = true } } diff --git a/apps/cli/src/agent/message-processor.ts b/apps/cli/src/agent/message-processor.ts index 2b9fd13602f..19e222b6c36 100644 --- a/apps/cli/src/agent/message-processor.ts +++ b/apps/cli/src/agent/message-processor.ts @@ -17,8 +17,8 @@ * - "invoke": Command invocations */ -import { ExtensionMessage, ClineMessage } from "@roo-code/types" -import { debugLog } from "@roo-code/core/cli" +import { ExtensionMessage, ClineMessage } from "@klaus-code/types" +import { debugLog } from "@klaus-code/core/cli" import type { StateStore } from "./state-store.js" import type { TypedEventEmitter, AgentStateChangeEvent, WaitingForInputEvent, TaskCompletedEvent } from "./events.js" diff --git a/apps/cli/src/agent/output-manager.ts b/apps/cli/src/agent/output-manager.ts index 0863546f6c4..8997ac48e78 100644 --- a/apps/cli/src/agent/output-manager.ts +++ b/apps/cli/src/agent/output-manager.ts @@ -13,7 +13,7 @@ * - Can be disabled for TUI mode where Ink controls the terminal */ -import { ClineMessage, ClineSay } from "@roo-code/types" +import { ClineMessage, ClineSay } from "@klaus-code/types" import { Observable } from "./events.js" diff --git a/apps/cli/src/agent/state-store.ts b/apps/cli/src/agent/state-store.ts index 68dcfc40698..71410bbb9bf 100644 --- a/apps/cli/src/agent/state-store.ts +++ b/apps/cli/src/agent/state-store.ts @@ -12,7 +12,7 @@ * - Queryable: Current state is always accessible */ -import { ClineMessage, ExtensionState } from "@roo-code/types" +import { ClineMessage, ExtensionState } from "@klaus-code/types" import { detectAgentState, AgentStateInfo, AgentLoopState } from "./agent-state.js" import { Observable } from "./events.js" diff --git a/apps/cli/src/commands/cli/run.ts b/apps/cli/src/commands/cli/run.ts index 663ed5cf750..f9acd5f4f93 100644 --- a/apps/cli/src/commands/cli/run.ts +++ b/apps/cli/src/commands/cli/run.ts @@ -1,10 +1,12 @@ import fs from "fs" import path from "path" +import { createInterface } from "readline" import { fileURLToPath } from "url" import { createElement } from "react" +import pWaitFor from "p-wait-for" -import { setLogger } from "@roo-code/vscode-shim" +import { setLogger } from "@klaus-code/vscode-shim" import { FlagOptions, @@ -30,6 +32,24 @@ import { ExtensionHost, ExtensionHostOptions } from "@/agent/index.js" const __dirname = path.dirname(fileURLToPath(import.meta.url)) +async function* readPromptsFromStdinLines(): AsyncGenerator { + const lineReader = createInterface({ + input: process.stdin, + crlfDelay: Infinity, + terminal: false, + }) + + try { + for await (const line of lineReader) { + if (line.trim()) { + yield line + } + } + } finally { + lineReader.close() + } +} + export async function run(promptArg: string | undefined, flagOptions: FlagOptions) { setLogger({ info: () => {}, @@ -65,8 +85,10 @@ export async function run(promptArg: string | undefined, flagOptions: FlagOption flagOptions.reasoningEffort || settings.reasoningEffort || DEFAULT_FLAGS.reasoningEffort const effectiveProvider = flagOptions.provider ?? settings.provider ?? (rooToken ? "roo" : "openrouter") const effectiveWorkspacePath = flagOptions.workspace ? path.resolve(flagOptions.workspace) : process.cwd() - const effectiveDangerouslySkipPermissions = - flagOptions.yes || flagOptions.dangerouslySkipPermissions || settings.dangerouslySkipPermissions || false + const legacyRequireApprovalFromSettings = + settings.requireApproval ?? + (settings.dangerouslySkipPermissions === undefined ? undefined : !settings.dangerouslySkipPermissions) + const effectiveRequireApproval = flagOptions.requireApproval || legacyRequireApprovalFromSettings || false const effectiveExitOnComplete = flagOptions.print || flagOptions.oneshot || settings.oneshot || false const extensionHostOptions: ExtensionHostOptions = { @@ -77,7 +99,8 @@ export async function run(promptArg: string | undefined, flagOptions: FlagOption model: effectiveModel, workspacePath: effectiveWorkspacePath, extensionPath: path.resolve(flagOptions.extension || getDefaultExtensionPath(__dirname)), - nonInteractive: effectiveDangerouslySkipPermissions, + nonInteractive: !effectiveRequireApproval, + exitOnError: flagOptions.exitOnError, ephemeral: flagOptions.ephemeral, debug: flagOptions.debug, exitOnComplete: effectiveExitOnComplete, @@ -112,15 +135,18 @@ export async function run(promptArg: string | undefined, flagOptions: FlagOption extensionHostOptions.apiKey = rooToken extensionHostOptions.user = me.user } catch { - console.error("[CLI] Your Roo Code Router token is not valid.") - console.error("[CLI] Please run: roo auth login") - process.exit(1) + // If an explicit API key was provided via flag or env var, fall through + // to the general API key resolution below instead of exiting. + if (!flagOptions.apiKey && !getApiKeyFromEnv(extensionHostOptions.provider)) { + console.error("[CLI] Your Roo Code Router token is not valid.") + console.error("[CLI] Please run: roo auth login") + console.error("[CLI] Or use --api-key or set ROO_API_KEY to provide your own API key.") + process.exit(1) + } } - } else { - console.error("[CLI] Your Roo Code Router token is missing.") - console.error("[CLI] Please run: roo auth login") - process.exit(1) } + // If no rooToken, fall through to the general API key resolution below + // which will check flagOptions.apiKey and ROO_API_KEY env var. } // Validations @@ -179,15 +205,42 @@ export async function run(promptArg: string | undefined, flagOptions: FlagOption // Output format only works with --print mode if (outputFormat !== "text" && !flagOptions.print && isTuiSupported) { console.error("[CLI] Error: --output-format requires --print mode") - console.error("[CLI] Usage: roo --print --output-format json") + console.error("[CLI] Usage: roo --print --output-format json") process.exit(1) } + if (flagOptions.stdinPromptStream && !flagOptions.print) { + console.error("[CLI] Error: --stdin-prompt-stream requires --print mode") + console.error("[CLI] Usage: roo --print --stdin-prompt-stream [options]") + process.exit(1) + } + + if (flagOptions.stdinPromptStream && process.stdin.isTTY) { + console.error("[CLI] Error: --stdin-prompt-stream requires piped stdin") + console.error("[CLI] Example: printf '1+1=?\\n10!=?\\n' | roo --print --stdin-prompt-stream [options]") + process.exit(1) + } + + if (flagOptions.stdinPromptStream && prompt) { + console.error("[CLI] Error: cannot use positional prompt or --prompt-file with --stdin-prompt-stream") + console.error("[CLI] Usage: roo --print --stdin-prompt-stream [options]") + process.exit(1) + } + + const useStdinPromptStream = flagOptions.stdinPromptStream + if (!isTuiEnabled) { - if (!prompt) { - console.error("[CLI] Error: prompt is required in print mode") - console.error("[CLI] Usage: roo --print [options]") - console.error("[CLI] Run without -p for interactive mode") + if (!prompt && !useStdinPromptStream) { + if (flagOptions.print) { + console.error("[CLI] Error: no prompt provided") + console.error("[CLI] Usage: roo --print [options] ") + console.error("[CLI] For stdin control mode: roo --print --stdin-prompt-stream [options]") + } else { + console.error("[CLI] Error: prompt is required in non-interactive mode") + console.error("[CLI] Usage: roo [options]") + console.error("[CLI] Run without -p for interactive mode") + } + process.exit(1) } @@ -252,7 +305,156 @@ export async function run(promptArg: string | undefined, flagOptions: FlagOption jsonEmitter.attachToClient(host.client) } - await host.runTask(prompt!) + if (useStdinPromptStream) { + let hasReceivedStdinPrompt = false + // stdin stream mode may start at most one task in this process. + let startedTaskFromStdin = false + let activeTaskPromise: Promise | null = null + let fatalStreamError: Error | null = null + // Extension-owned queue depth mirrored from state pushes. + // CLI does not maintain its own prompt queue. + let extensionQueueDepth = 0 + + const waitForInitialState = async () => { + // Give the extension a brief chance to publish initial state so + // we can continue an existing task instead of creating a new one. + await pWaitFor( + () => { + if (fatalStreamError) { + throw fatalStreamError + } + + return host.client.isInitialized() + }, + { interval: 25, timeout: 2_000 }, + ).catch(() => { + // Best-effort wait only; continuing preserves previous behavior. + }) + + if (fatalStreamError) { + throw fatalStreamError + } + } + + const waitForActiveTask = async () => { + await pWaitFor( + () => { + if (fatalStreamError) { + throw fatalStreamError + } + + if (!host.client.hasActiveTask()) { + if (!activeTaskPromise && startedTaskFromStdin) { + throw new Error("task is no longer active; cannot continue conversation from stdin") + } + + return false + } + + return true + }, + { interval: 25, timeout: 5_000 }, + ) + } + + const startInitialTask = async (taskPrompt: string) => { + startedTaskFromStdin = true + + activeTaskPromise = host + .runTask(taskPrompt) + .catch((error) => { + fatalStreamError = error instanceof Error ? error : new Error(String(error)) + }) + .finally(() => { + activeTaskPromise = null + }) + + await waitForActiveTask() + } + + const enqueueContinuation = async (text: string) => { + if (!host.client.hasActiveTask()) { + await waitForActiveTask() + } + + // Delegate ordering/drain behavior to the extension message queue. + host.sendToExtension({ type: "queueMessage", text }) + } + + const offClientError = host.client.on("error", (error) => { + fatalStreamError = error + }) + + const onExtensionMessage = (message: { type?: string; state?: { messageQueue?: unknown } }) => { + if (message.type !== "state") { + return + } + + const messageQueue = message.state?.messageQueue + extensionQueueDepth = Array.isArray(messageQueue) ? messageQueue.length : 0 + } + + host.on("extensionWebviewMessage", onExtensionMessage) + + try { + await waitForInitialState() + + for await (const stdinPrompt of readPromptsFromStdinLines()) { + hasReceivedStdinPrompt = true + + // Start once, then always continue via extension queue. + if (!host.client.hasActiveTask() && !startedTaskFromStdin) { + await startInitialTask(stdinPrompt) + } else { + await enqueueContinuation(stdinPrompt) + } + + if (fatalStreamError) { + throw fatalStreamError + } + } + + if (!hasReceivedStdinPrompt) { + throw new Error("no prompt provided via stdin") + } + + await pWaitFor( + () => { + if (fatalStreamError) { + throw fatalStreamError + } + + const isSettled = + !host.client.hasActiveTask() && !activeTaskPromise && extensionQueueDepth === 0 + + if (isSettled) { + return true + } + + if (host.isWaitingForInput() && extensionQueueDepth === 0) { + const currentAsk = host.client.getCurrentAsk() + + if (currentAsk === "completion_result") { + return true + } + + if (currentAsk) { + throw new Error(`stdin ended while task was waiting for input (${currentAsk})`) + } + } + + return false + }, + { interval: 50 }, + ) + } finally { + offClientError() + host.off("extensionWebviewMessage", onExtensionMessage) + } + } else { + await host.runTask(prompt!) + } + jsonEmitter?.detach() await host.dispose() process.exit(0) @@ -264,6 +466,7 @@ export async function run(promptArg: string | undefined, flagOptions: FlagOption process.stdout.write(JSON.stringify(errorEvent) + "\n") } else { console.error("[CLI] Error:", errorMessage) + if (error instanceof Error) { console.error(error.stack) } diff --git a/apps/cli/src/index.ts b/apps/cli/src/index.ts index 5b663c2bdcd..f2fb594d291 100644 --- a/apps/cli/src/index.ts +++ b/apps/cli/src/index.ts @@ -8,7 +8,7 @@ const program = new Command() program .name("roo") - .description("Roo Code CLI - starts an interactive session by default, use -p/--print for non-interactive output") + .description("Klaus Code CLI - starts an interactive session by default, use -p/--print for non-interactive output") .version(VERSION) program @@ -16,9 +16,10 @@ program .option("--prompt-file ", "Read prompt from a file instead of command line argument") .option("-w, --workspace ", "Workspace directory path (defaults to current working directory)") .option("-p, --print", "Print response and exit (non-interactive mode)", false) + .option("--stdin-prompt-stream", "Read prompts from stdin (one prompt per line, requires --print)", false) .option("-e, --extension ", "Path to the extension bundle directory") .option("-d, --debug", "Enable debug output (includes detailed debug information)", false) - .option("-y, --yes, --dangerously-skip-permissions", "Auto-approve all prompts (use with caution)", false) + .option("-a, --require-approval", "Require manual approval for actions", false) .option("-k, --api-key ", "API key for the LLM provider") .option("--provider ", "API provider (roo, anthropic, openai, openrouter, etc.)") .option("-m, --model ", "Model to use", DEFAULT_FLAGS.model) @@ -28,6 +29,7 @@ program "Reasoning effort level (unspecified, disabled, none, minimal, low, medium, high, xhigh)", DEFAULT_FLAGS.reasoningEffort, ) + .option("--exit-on-error", "Exit on API request errors instead of retrying", false) .option("--ephemeral", "Run without persisting state (uses temporary storage)", false) .option("--oneshot", "Exit upon task completion", false) .option( @@ -37,11 +39,11 @@ program ) .action(run) -const authCommand = program.command("auth").description("Manage authentication for Roo Code Cloud") +const authCommand = program.command("auth").description("Manage authentication for Klaus Code Cloud") authCommand .command("login") - .description("Authenticate with Roo Code Cloud") + .description("Authenticate with Klaus Code Cloud") .option("-v, --verbose", "Enable verbose output", false) .action(async (options: { verbose: boolean }) => { const result = await login({ verbose: options.verbose }) @@ -50,7 +52,7 @@ authCommand authCommand .command("logout") - .description("Log out from Roo Code Cloud") + .description("Log out from Klaus Code Cloud") .option("-v, --verbose", "Enable verbose output", false) .action(async (options: { verbose: boolean }) => { const result = await logout({ verbose: options.verbose }) diff --git a/apps/cli/src/lib/storage/__tests__/settings.test.ts b/apps/cli/src/lib/storage/__tests__/settings.test.ts index c133f733b92..30f1dbe8ecb 100644 --- a/apps/cli/src/lib/storage/__tests__/settings.test.ts +++ b/apps/cli/src/lib/storage/__tests__/settings.test.ts @@ -103,7 +103,7 @@ describe("Settings Storage", () => { await saveSettings({ mode: "architect", provider: "anthropic" as const, - model: "claude-opus-4.5", + model: "claude-opus-4.6", reasoningEffort: "medium" as const, }) @@ -112,7 +112,7 @@ describe("Settings Storage", () => { expect(settings.mode).toBe("architect") expect(settings.provider).toBe("anthropic") - expect(settings.model).toBe("claude-opus-4.5") + expect(settings.model).toBe("claude-opus-4.6") expect(settings.reasoningEffort).toBe("medium") }) @@ -179,20 +179,20 @@ describe("Settings Storage", () => { expect(loaded.reasoningEffort).toBe("low") }) - it("should support dangerouslySkipPermissions setting", async () => { - await saveSettings({ dangerouslySkipPermissions: true }) + it("should support requireApproval setting", async () => { + await saveSettings({ requireApproval: true }) const loaded = await loadSettings() - expect(loaded.dangerouslySkipPermissions).toBe(true) + expect(loaded.requireApproval).toBe(true) }) - it("should support all settings together including dangerouslySkipPermissions", async () => { + it("should support all settings together including requireApproval", async () => { const allSettings = { mode: "architect", provider: "anthropic" as const, model: "claude-sonnet-4-20250514", reasoningEffort: "high" as const, - dangerouslySkipPermissions: true, + requireApproval: true, } await saveSettings(allSettings) @@ -202,7 +202,7 @@ describe("Settings Storage", () => { expect(loaded.provider).toBe("anthropic") expect(loaded.model).toBe("claude-sonnet-4-20250514") expect(loaded.reasoningEffort).toBe("high") - expect(loaded.dangerouslySkipPermissions).toBe(true) + expect(loaded.requireApproval).toBe(true) }) it("should support oneshot setting", async () => { @@ -218,7 +218,7 @@ describe("Settings Storage", () => { provider: "anthropic" as const, model: "claude-sonnet-4-20250514", reasoningEffort: "high" as const, - dangerouslySkipPermissions: true, + requireApproval: true, oneshot: true, } @@ -229,8 +229,15 @@ describe("Settings Storage", () => { expect(loaded.provider).toBe("anthropic") expect(loaded.model).toBe("claude-sonnet-4-20250514") expect(loaded.reasoningEffort).toBe("high") - expect(loaded.dangerouslySkipPermissions).toBe(true) + expect(loaded.requireApproval).toBe(true) expect(loaded.oneshot).toBe(true) }) + + it("should still load legacy dangerouslySkipPermissions setting", async () => { + await saveSettings({ dangerouslySkipPermissions: true }) + const loaded = await loadSettings() + + expect(loaded.dangerouslySkipPermissions).toBe(true) + }) }) }) diff --git a/apps/cli/src/lib/utils/__tests__/extension.test.ts b/apps/cli/src/lib/utils/__tests__/extension.test.ts index 31fdbe87f00..4b4a2db5850 100644 --- a/apps/cli/src/lib/utils/__tests__/extension.test.ts +++ b/apps/cli/src/lib/utils/__tests__/extension.test.ts @@ -21,9 +21,26 @@ describe("getDefaultExtensionPath", () => { it("should return monorepo path when extension.js exists there", () => { const mockDirname = "/test/apps/cli/dist" - const expectedMonorepoPath = path.resolve(mockDirname, "../../../src/dist") + const expectedMonorepoPath = path.resolve("/test/apps/cli", "../../src/dist") - vi.mocked(fs.existsSync).mockReturnValue(true) + // Walk-up: dist/ has no package.json, apps/cli/ does + vi.mocked(fs.existsSync).mockImplementation((p) => { + const s = String(p) + + if (s === path.join(mockDirname, "package.json")) { + return false + } + + if (s === path.join("/test/apps/cli", "package.json")) { + return true + } + + if (s === path.join(expectedMonorepoPath, "extension.js")) { + return true + } + + return false + }) const result = getDefaultExtensionPath(mockDirname) @@ -33,9 +50,18 @@ describe("getDefaultExtensionPath", () => { it("should return package path when extension.js does not exist in monorepo path", () => { const mockDirname = "/test/apps/cli/dist" - const expectedPackagePath = path.resolve(mockDirname, "../extension") + const expectedPackagePath = path.resolve("/test/apps/cli", "extension") + + // Walk-up finds package.json at apps/cli/, but no extension.js in monorepo path + vi.mocked(fs.existsSync).mockImplementation((p) => { + const s = String(p) - vi.mocked(fs.existsSync).mockReturnValue(false) + if (s === path.join("/test/apps/cli", "package.json")) { + return true + } + + return false + }) const result = getDefaultExtensionPath(mockDirname) @@ -43,12 +69,45 @@ describe("getDefaultExtensionPath", () => { }) it("should check monorepo path first", () => { - const mockDirname = "/some/path" - vi.mocked(fs.existsSync).mockReturnValue(false) + const mockDirname = "/test/apps/cli/dist" + + vi.mocked(fs.existsSync).mockImplementation((p) => { + const s = String(p) + + if (s === path.join("/test/apps/cli", "package.json")) { + return true + } + + return false + }) getDefaultExtensionPath(mockDirname) - const expectedMonorepoPath = path.resolve(mockDirname, "../../../src/dist") + const expectedMonorepoPath = path.resolve("/test/apps/cli", "../../src/dist") expect(fs.existsSync).toHaveBeenCalledWith(path.join(expectedMonorepoPath, "extension.js")) }) + + it("should work when called from source directory (tsx dev)", () => { + const mockDirname = "/test/apps/cli/src/commands/cli" + const expectedMonorepoPath = path.resolve("/test/apps/cli", "../../src/dist") + + // Walk-up: no package.json in src subdirs, found at apps/cli/ + vi.mocked(fs.existsSync).mockImplementation((p) => { + const s = String(p) + + if (s === path.join("/test/apps/cli", "package.json")) { + return true + } + + if (s === path.join(expectedMonorepoPath, "extension.js")) { + return true + } + + return false + }) + + const result = getDefaultExtensionPath(mockDirname) + + expect(result).toBe(expectedMonorepoPath) + }) }) diff --git a/apps/cli/src/lib/utils/context-window.ts b/apps/cli/src/lib/utils/context-window.ts index c1224c8b1ec..78e58e265c4 100644 --- a/apps/cli/src/lib/utils/context-window.ts +++ b/apps/cli/src/lib/utils/context-window.ts @@ -1,4 +1,4 @@ -import type { ProviderSettings } from "@roo-code/types" +import type { ProviderSettings } from "@klaus-code/types" import type { RouterModels } from "@/ui/store.js" @@ -48,18 +48,10 @@ function getModelIdForProvider(config: ProviderSettings): string | undefined { return config.requestyModelId case "litellm": return config.litellmModelId - case "deepinfra": - return config.deepInfraModelId - case "huggingface": - return config.huggingFaceModelId - case "unbound": - return config.unboundModelId case "vercel-ai-gateway": return config.vercelAiGatewayModelId - case "io-intelligence": - return config.ioIntelligenceModelId default: - // For anthropic, bedrock, vertex, gemini, xai, groq, etc. + // For anthropic, bedrock, vertex, gemini, xai, etc. return config.apiModelId } } diff --git a/apps/cli/src/lib/utils/extension.ts b/apps/cli/src/lib/utils/extension.ts index 904940ec004..f49b2df8651 100644 --- a/apps/cli/src/lib/utils/extension.ts +++ b/apps/cli/src/lib/utils/extension.ts @@ -17,17 +17,26 @@ export function getDefaultExtensionPath(dirname: string): string { } } - // __dirname is apps/cli/dist when bundled - // The extension is at src/dist (relative to monorepo root) - // So from apps/cli/dist, we need to go ../../../src/dist - const monorepoPath = path.resolve(dirname, "../../../src/dist") + // Find the CLI package root (apps/cli) by walking up to the nearest package.json. + // This works whether called from dist/ (bundled) or src/commands/cli/ (tsx dev). + let packageRoot = dirname + + while (packageRoot !== path.dirname(packageRoot)) { + if (fs.existsSync(path.join(packageRoot, "package.json"))) { + break + } + + packageRoot = path.dirname(packageRoot) + } + + // The extension is at ../../src/dist relative to apps/cli (monorepo/src/dist) + const monorepoPath = path.resolve(packageRoot, "../../src/dist") - // Try monorepo path first (for development) if (fs.existsSync(path.join(monorepoPath, "extension.js"))) { return monorepoPath } - // Fallback: when installed via curl script, extension is at ../extension - const packagePath = path.resolve(dirname, "../extension") + // Fallback: when installed via curl script, extension is at apps/cli/extension + const packagePath = path.resolve(packageRoot, "extension") return packagePath } diff --git a/apps/cli/src/lib/utils/provider.ts b/apps/cli/src/lib/utils/provider.ts index 64aec430c1b..4747070b1b7 100644 --- a/apps/cli/src/lib/utils/provider.ts +++ b/apps/cli/src/lib/utils/provider.ts @@ -1,4 +1,4 @@ -import { RooCodeSettings } from "@roo-code/types" +import { RooCodeSettings } from "@klaus-code/types" import type { SupportedProvider } from "@/types/index.js" diff --git a/apps/cli/src/lib/utils/version.ts b/apps/cli/src/lib/utils/version.ts index e4f2ce59b21..c599963bdc6 100644 --- a/apps/cli/src/lib/utils/version.ts +++ b/apps/cli/src/lib/utils/version.ts @@ -1,6 +1,24 @@ -import { createRequire } from "module" +import fs from "fs" +import path from "path" +import { fileURLToPath } from "url" -const require = createRequire(import.meta.url) -const packageJson = require("../package.json") +// Walk up from the current file to find the nearest package.json. +// This works whether running from source (tsx src/lib/utils/) or bundle (dist/). +function findVersion(): string { + let dir = path.dirname(fileURLToPath(import.meta.url)) -export const VERSION = packageJson.version + while (dir !== path.dirname(dir)) { + const candidate = path.join(dir, "package.json") + + if (fs.existsSync(candidate)) { + const packageJson = JSON.parse(fs.readFileSync(candidate, "utf-8")) + return packageJson.version + } + + dir = path.dirname(dir) + } + + return "0.0.0" +} + +export const VERSION = findVersion() diff --git a/apps/cli/src/types/constants.ts b/apps/cli/src/types/constants.ts index 5b3dc577786..05ecc791fa2 100644 --- a/apps/cli/src/types/constants.ts +++ b/apps/cli/src/types/constants.ts @@ -1,9 +1,9 @@ -import { reasoningEffortsExtended } from "@roo-code/types" +import { reasoningEffortsExtended } from "@klaus-code/types" export const DEFAULT_FLAGS = { mode: "code", reasoningEffort: "medium" as const, - model: "anthropic/claude-opus-4.5", + model: "anthropic/claude-opus-4.6", } export const REASONING_EFFORTS = [...reasoningEffortsExtended, "unspecified", "disabled"] @@ -21,6 +21,6 @@ export const ASCII_ROO = ` _,' ___ // \\\\ ,/' \`\\_,` -export const AUTH_BASE_URL = process.env.ROO_AUTH_BASE_URL ?? "https://app.roocode.com" +export const AUTH_BASE_URL = process.env.ROO_AUTH_BASE_URL ?? "https://app.tbd" -export const SDK_BASE_URL = process.env.ROO_SDK_BASE_URL ?? "https://cloud-api.roocode.com" +export const SDK_BASE_URL = process.env.ROO_SDK_BASE_URL ?? "https://cloud-api.tbd" diff --git a/apps/cli/src/types/types.ts b/apps/cli/src/types/types.ts index 05392ccca86..1a33c63e012 100644 --- a/apps/cli/src/types/types.ts +++ b/apps/cli/src/types/types.ts @@ -1,4 +1,4 @@ -import type { ProviderName, ReasoningEffortExtended } from "@roo-code/types" +import type { ProviderName, ReasoningEffortExtended } from "@klaus-code/types" import type { OutputFormat } from "./json-events.js" export const supportedProviders = [ @@ -22,10 +22,11 @@ export type FlagOptions = { promptFile?: string workspace?: string print: boolean + stdinPromptStream: boolean extension?: string debug: boolean - yes: boolean - dangerouslySkipPermissions: boolean + requireApproval: boolean + exitOnError: boolean apiKey?: string provider?: SupportedProvider model?: string @@ -57,7 +58,9 @@ export interface CliSettings { model?: string /** Default reasoning effort level */ reasoningEffort?: ReasoningEffortFlagOptions - /** Auto-approve all prompts (use with caution) */ + /** Require manual approval for tools/commands/browser/MCP actions */ + requireApproval?: boolean + /** @deprecated Legacy inverse setting kept for backward compatibility */ dangerouslySkipPermissions?: boolean /** Exit upon task completion */ oneshot?: boolean diff --git a/apps/cli/src/ui/__tests__/store.test.ts b/apps/cli/src/ui/__tests__/store.test.ts index 5b8b4fbf774..b8222df10a5 100644 --- a/apps/cli/src/ui/__tests__/store.test.ts +++ b/apps/cli/src/ui/__tests__/store.test.ts @@ -1,4 +1,4 @@ -import { RooCodeSettings } from "@roo-code/types" +import { RooCodeSettings } from "@klaus-code/types" import { useCLIStore } from "../store.js" diff --git a/apps/cli/src/ui/components/ChatHistoryItem.tsx b/apps/cli/src/ui/components/ChatHistoryItem.tsx index c51b0faddbc..e5bbc79366c 100644 --- a/apps/cli/src/ui/components/ChatHistoryItem.tsx +++ b/apps/cli/src/ui/components/ChatHistoryItem.tsx @@ -10,14 +10,13 @@ import { getToolRenderer } from "./tools/index.js" /** * Tool categories for styling */ -type ToolCategory = "file" | "directory" | "search" | "command" | "browser" | "mode" | "completion" | "other" +type ToolCategory = "file" | "directory" | "search" | "command" | "mode" | "completion" | "other" function getToolCategory(toolName: string): ToolCategory { const fileTools = ["readFile", "read_file", "writeToFile", "write_to_file", "applyDiff", "apply_diff"] const dirTools = ["listFiles", "list_files", "listFilesRecursive", "listFilesTopLevel"] const searchTools = ["searchFiles", "search_files"] const commandTools = ["executeCommand", "execute_command"] - const browserTools = ["browserAction", "browser_action"] const modeTools = ["switchMode", "switch_mode", "newTask", "new_task"] const completionTools = ["attemptCompletion", "attempt_completion", "askFollowupQuestion", "ask_followup_question"] @@ -25,7 +24,6 @@ function getToolCategory(toolName: string): ToolCategory { if (dirTools.includes(toolName)) return "directory" if (searchTools.includes(toolName)) return "search" if (commandTools.includes(toolName)) return "command" - if (browserTools.includes(toolName)) return "browser" if (modeTools.includes(toolName)) return "mode" if (completionTools.includes(toolName)) return "completion" return "other" @@ -39,7 +37,6 @@ const CATEGORY_COLORS: Record = { directory: theme.toolHeader, search: theme.warningColor, command: theme.successColor, - browser: theme.focusColor, mode: theme.userHeader, completion: theme.successColor, other: theme.toolHeader, diff --git a/apps/cli/src/ui/components/Header.tsx b/apps/cli/src/ui/components/Header.tsx index 040e2759188..f059c2eb8ee 100644 --- a/apps/cli/src/ui/components/Header.tsx +++ b/apps/cli/src/ui/components/Header.tsx @@ -1,7 +1,7 @@ import { memo } from "react" import { Text, Box } from "ink" -import type { TokenUsage } from "@roo-code/types" +import type { TokenUsage } from "@klaus-code/types" import { ASCII_ROO } from "@/types/constants.js" @@ -32,7 +32,7 @@ function Header({ const { columns } = useTerminalSize() const homeDir = process.env.HOME || process.env.USERPROFILE || "" - const title = `Roo Code CLI v${version}` + const title = `Klaus Code CLI v${version}` const remainingDashes = Math.max(0, columns - `── ${title} `.length) return ( diff --git a/apps/cli/src/ui/components/MetricsDisplay.tsx b/apps/cli/src/ui/components/MetricsDisplay.tsx index 9508f07ce24..4414b41f00e 100644 --- a/apps/cli/src/ui/components/MetricsDisplay.tsx +++ b/apps/cli/src/ui/components/MetricsDisplay.tsx @@ -1,7 +1,7 @@ import { memo } from "react" import { Text, Box } from "ink" -import type { TokenUsage } from "@roo-code/types" +import type { TokenUsage } from "@klaus-code/types" import * as theme from "../theme.js" import ProgressBar from "./ProgressBar.js" diff --git a/apps/cli/src/ui/components/TodoChangeDisplay.tsx b/apps/cli/src/ui/components/TodoChangeDisplay.tsx index f41049122af..c688e1dc952 100644 --- a/apps/cli/src/ui/components/TodoChangeDisplay.tsx +++ b/apps/cli/src/ui/components/TodoChangeDisplay.tsx @@ -1,7 +1,7 @@ import { memo } from "react" import { Box, Text } from "ink" -import type { TodoItem } from "@roo-code/types" +import type { TodoItem } from "@klaus-code/types" import * as theme from "../theme.js" diff --git a/apps/cli/src/ui/components/TodoDisplay.tsx b/apps/cli/src/ui/components/TodoDisplay.tsx index 5eb962cac3d..10aaace7b99 100644 --- a/apps/cli/src/ui/components/TodoDisplay.tsx +++ b/apps/cli/src/ui/components/TodoDisplay.tsx @@ -1,7 +1,7 @@ import { memo } from "react" import { Box, Text } from "ink" -import type { TodoItem } from "@roo-code/types" +import type { TodoItem } from "@klaus-code/types" import * as theme from "../theme.js" import ProgressBar from "./ProgressBar.js" diff --git a/apps/cli/src/ui/components/__tests__/TodoChangeDisplay.test.tsx b/apps/cli/src/ui/components/__tests__/TodoChangeDisplay.test.tsx index a26c66e3df3..623b8e86c74 100644 --- a/apps/cli/src/ui/components/__tests__/TodoChangeDisplay.test.tsx +++ b/apps/cli/src/ui/components/__tests__/TodoChangeDisplay.test.tsx @@ -1,6 +1,6 @@ import { render } from "ink-testing-library" -import type { TodoItem } from "@roo-code/types" +import type { TodoItem } from "@klaus-code/types" import TodoChangeDisplay from "../TodoChangeDisplay.js" diff --git a/apps/cli/src/ui/components/__tests__/TodoDisplay.test.tsx b/apps/cli/src/ui/components/__tests__/TodoDisplay.test.tsx index f48bfe8401a..72a6eab7b3c 100644 --- a/apps/cli/src/ui/components/__tests__/TodoDisplay.test.tsx +++ b/apps/cli/src/ui/components/__tests__/TodoDisplay.test.tsx @@ -1,6 +1,6 @@ import { render } from "ink-testing-library" -import type { TodoItem } from "@roo-code/types" +import type { TodoItem } from "@klaus-code/types" import TodoDisplay from "../TodoDisplay.js" import { resetNerdFontCache } from "../Icon.js" diff --git a/apps/cli/src/ui/components/autocomplete/triggers/HistoryTrigger.tsx b/apps/cli/src/ui/components/autocomplete/triggers/HistoryTrigger.tsx index 443fdfa9797..15db6b06748 100644 --- a/apps/cli/src/ui/components/autocomplete/triggers/HistoryTrigger.tsx +++ b/apps/cli/src/ui/components/autocomplete/triggers/HistoryTrigger.tsx @@ -168,7 +168,7 @@ export function createHistoryTrigger(config: HistoryTriggerConfig): Autocomplete } /** - * Convert HistoryItem from @roo-code/types to HistoryResult. + * Convert HistoryItem from @klaus-code/types to HistoryResult. * Use this to adapt history items from the store to the trigger's expected type. */ export function toHistoryResult(item: { diff --git a/apps/cli/src/ui/components/onboarding/OnboardingScreen.tsx b/apps/cli/src/ui/components/onboarding/OnboardingScreen.tsx index 86c15f5b274..d858de2ebe9 100644 --- a/apps/cli/src/ui/components/onboarding/OnboardingScreen.tsx +++ b/apps/cli/src/ui/components/onboarding/OnboardingScreen.tsx @@ -16,7 +16,7 @@ export function OnboardingScreen({ onSelect }: OnboardingScreenProps) { Welcome! How would you like to connect to an LLM provider? setSearchQuery(e.target.value)} - className="w-full rounded-full border border-input bg-background px-10 py-2 text-base ring-offset-background placeholder:text-muted-foreground focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring focus-visible:ring-offset-2" - /> - -
- {filteredAndSortedModels.length} of {nonDeprecatedCount} models -
- - -
-
- - -
-
- - - - -
-
- {loading && ( -
- -

Loading model list...

-
- )} - - {error && ( -
- -

Oops, couldn't load the model list.

-

Try again in a bit please.

-
- )} - - {!loading && !error && filteredAndSortedModels.length === 0 && ( -
- -

No models match your search.

-

- Keep in mind we don't have every model under the sun – only the ones we think - are worth using. -
- You can always use a third-party provider to access a wider selection. -

-
- )} - - {!loading && !error && filteredAndSortedModels.length > 0 && ( -
- {filteredAndSortedModels.map((model) => ( - - ))} -
- )} -
-
- - - {/* FAQ Section */} -
- -
-
-

Frequently Asked Questions

-
-
- {faqs.map((faq, index) => ( -
-

{faq.question}

-

{faq.answer}

-
- ))} -
-
-
- - ) -} diff --git a/apps/web-roo-code/src/app/provider/pricing/components/model-card.tsx b/apps/web-roo-code/src/app/provider/pricing/components/model-card.tsx deleted file mode 100644 index 26f35457912..00000000000 --- a/apps/web-roo-code/src/app/provider/pricing/components/model-card.tsx +++ /dev/null @@ -1,190 +0,0 @@ -import { ModelWithTotalPrice } from "@/lib/types/models" -import { formatCurrency, formatTokens } from "@/lib/formatters" -import { - ArrowLeftToLine, - ArrowRightToLine, - Building2, - Check, - Expand, - Gift, - HardDriveDownload, - HardDriveUpload, - RulerDimensionLine, - ChevronDown, - ChevronUp, -} from "lucide-react" -import { useState } from "react" - -interface ModelCardProps { - model: ModelWithTotalPrice -} - -export function ModelCard({ model }: ModelCardProps) { - // Prices are per token, multiply by 1M to get price per million tokens - const inputPrice = parseFloat(model.pricing.input) * 1_000_000 - const outputPrice = parseFloat(model.pricing.output) * 1_000_000 - const cacheReadPrice = parseFloat(model.pricing.input_cache_read || "0") * 1_000_000 - const cacheWritePrice = parseFloat(model.pricing.input_cache_write || "0") * 1_000_000 - - const free = model.tags.includes("free") - // Filter tags to only show vision and reasoning - const displayTags = model.tags.filter((tag) => tag === "vision" || tag === "reasoning") - - // Mobile collapsed/expanded state - const [expanded, setExpanded] = useState(false) - - return ( -
- {/* Header: always visible */} -
-

- {model.name} - {free && ( - - - Free! - - )} -

-

- {model.description} -

-
- - {/* Content - pinned to bottom */} -
- - - {/* Provider: always visible if present */} - {model.owned_by && ( - - - - - )} - - {/* Context Window: always visible */} - - - - - - {/* Max Output Tokens: always visible on >=sm, expandable on mobile */} - - - - - - {/* Input Price: always visible */} - - - - - - {/* Output Price: always visible */} - - - - - - {/* Cache pricing: only visible on mobile when expanded, always visible on >=sm */} - {cacheReadPrice > 0 && ( - - - - - )} - - {cacheWritePrice > 0 && ( - - - - - )} - - {/* Tags row: only show if there are vision or reasoning tags */} - {displayTags.length > 0 && ( - - - - - )} - - {/* Mobile-only toggle row */} - - - - -
- - Provider - {model.owned_by}
- - Context Window - {formatTokens(model.context_window)}
- - Max Output Tokens - {formatTokens(model.max_tokens)}
- - Input Price - - {inputPrice === 0 ? "Free" : `${formatCurrency(inputPrice)}/1M tokens`} -
- - Output Price - - {outputPrice === 0 ? "Free" : `${formatCurrency(outputPrice)}/1M tokens`} -
- - Cache Read - {formatCurrency(cacheReadPrice)}/1M tokens
- - Cache Write - {formatCurrency(cacheWritePrice)}/1M tokens
Features - {displayTags.map((tag) => ( - - - {tag} - - ))} -
- -
-
-
- ) -} diff --git a/apps/web-roo-code/src/app/reviewer/content-b.ts b/apps/web-roo-code/src/app/reviewer/content-b.ts deleted file mode 100644 index 0c2f76a2f53..00000000000 --- a/apps/web-roo-code/src/app/reviewer/content-b.ts +++ /dev/null @@ -1,93 +0,0 @@ -import { type AgentPageContent } from "@/app/shared/agent-page-content" - -// Workaround for next/image choking on these for some reason -import hero from "/public/heroes/agent-reviewer.png" - -// Re-export for convenience -export type { AgentPageContent } - -export const content: AgentPageContent = { - agentName: "PR Reviewer", - hero: { - icon: "GitPullRequest", - heading: "Code reviews that catch what other AI tools (and most humans) miss.", - paragraphs: [ - "Run-of-the-mill, token-saving AI code review tools will surely catch syntax errors and style issues, but they'll usually miss the bugs that actually matter: logic flaws, security vulnerabilities, and misunderstood requirements.", - "Roo Code's PR Reviewer uses advanced reasoning models and full repository context to find the issues that slip through—before they reach production.", - ], - image: { - url: hero.src, - width: 800, - height: 474, - alt: "Example of a code review generated by Roo Code PR Reviewer", - }, - crossAgentLink: { - text: "Works great with", - links: [ - { - text: "PR Fixer Agent", - href: "/pr-fixer", - icon: "Wrench", - }, - ], - }, - cta: { - buttonText: "Try now for free", - disclaimer: "", - tracking: "&agent=reviewer", - }, - }, - howItWorks: { - heading: "How It Works", - steps: [ - { - title: "1. Connect Your Repository", - description: - "Link your GitHub repository and configure which branches and pull requests should be reviewed.", - icon: "GitPullRequest", - }, - { - title: "2. Add Your API Key", - description: - "Provide your AI provider API key and set your review preferences, custom rules, and quality standards.", - icon: "Key", - }, - { - title: "3. Get Review Comments", - description: - "Every pull request gets detailed GitHub comments in minutes from a Roo Code agent highlighting issues and suggesting improvements.", - icon: "MessageSquareCode", - }, - ], - }, - whyBetter: { - heading: "Why Roo's PR Reviewer is different", - features: [ - { - title: "Bring your own key, get uncompromised reviews", - paragraphs: [ - "Most AI review tools use fixed pricing, which means they skimp on tokens to protect their margins. That leads to shallow analysis and missed issues.", - "With Roo, you bring your own API key. We optimize prompts for depth, not cost-cutting, so reviews focus on real problems like business logic, security vulnerabilities, and architectural issues.", - ], - icon: "Blocks", - }, - { - title: "Advanced reasoning that understands what matters", - description: - "We leverage state-of-the-art reasoning models with sophisticated workflows: diff analysis, context gathering, impact mapping, and contract validation. This catches the subtle bugs that surface-level tools miss—misunderstood requirements, edge cases, and integration risks.", - icon: "ListChecks", - }, - { - title: "Repository-aware, not snippet-aware", - description: - "Roo analyzes your entire codebase context—dependency graphs, code ownership, team conventions, and historical patterns. It understands how changes interact with existing systems, not just whether individual lines look correct.", - icon: "BookMarked", - }, - ], - }, - cta: { - heading: "Ready for better code reviews?", - description: "Start finding the issues that matter with AI-powered reviews built for depth, not cost-cutting.", - buttonText: "Try now for free", - }, -} diff --git a/apps/web-roo-code/src/app/reviewer/content.ts b/apps/web-roo-code/src/app/reviewer/content.ts deleted file mode 100644 index 0c2f76a2f53..00000000000 --- a/apps/web-roo-code/src/app/reviewer/content.ts +++ /dev/null @@ -1,93 +0,0 @@ -import { type AgentPageContent } from "@/app/shared/agent-page-content" - -// Workaround for next/image choking on these for some reason -import hero from "/public/heroes/agent-reviewer.png" - -// Re-export for convenience -export type { AgentPageContent } - -export const content: AgentPageContent = { - agentName: "PR Reviewer", - hero: { - icon: "GitPullRequest", - heading: "Code reviews that catch what other AI tools (and most humans) miss.", - paragraphs: [ - "Run-of-the-mill, token-saving AI code review tools will surely catch syntax errors and style issues, but they'll usually miss the bugs that actually matter: logic flaws, security vulnerabilities, and misunderstood requirements.", - "Roo Code's PR Reviewer uses advanced reasoning models and full repository context to find the issues that slip through—before they reach production.", - ], - image: { - url: hero.src, - width: 800, - height: 474, - alt: "Example of a code review generated by Roo Code PR Reviewer", - }, - crossAgentLink: { - text: "Works great with", - links: [ - { - text: "PR Fixer Agent", - href: "/pr-fixer", - icon: "Wrench", - }, - ], - }, - cta: { - buttonText: "Try now for free", - disclaimer: "", - tracking: "&agent=reviewer", - }, - }, - howItWorks: { - heading: "How It Works", - steps: [ - { - title: "1. Connect Your Repository", - description: - "Link your GitHub repository and configure which branches and pull requests should be reviewed.", - icon: "GitPullRequest", - }, - { - title: "2. Add Your API Key", - description: - "Provide your AI provider API key and set your review preferences, custom rules, and quality standards.", - icon: "Key", - }, - { - title: "3. Get Review Comments", - description: - "Every pull request gets detailed GitHub comments in minutes from a Roo Code agent highlighting issues and suggesting improvements.", - icon: "MessageSquareCode", - }, - ], - }, - whyBetter: { - heading: "Why Roo's PR Reviewer is different", - features: [ - { - title: "Bring your own key, get uncompromised reviews", - paragraphs: [ - "Most AI review tools use fixed pricing, which means they skimp on tokens to protect their margins. That leads to shallow analysis and missed issues.", - "With Roo, you bring your own API key. We optimize prompts for depth, not cost-cutting, so reviews focus on real problems like business logic, security vulnerabilities, and architectural issues.", - ], - icon: "Blocks", - }, - { - title: "Advanced reasoning that understands what matters", - description: - "We leverage state-of-the-art reasoning models with sophisticated workflows: diff analysis, context gathering, impact mapping, and contract validation. This catches the subtle bugs that surface-level tools miss—misunderstood requirements, edge cases, and integration risks.", - icon: "ListChecks", - }, - { - title: "Repository-aware, not snippet-aware", - description: - "Roo analyzes your entire codebase context—dependency graphs, code ownership, team conventions, and historical patterns. It understands how changes interact with existing systems, not just whether individual lines look correct.", - icon: "BookMarked", - }, - ], - }, - cta: { - heading: "Ready for better code reviews?", - description: "Start finding the issues that matter with AI-powered reviews built for depth, not cost-cutting.", - buttonText: "Try now for free", - }, -} diff --git a/apps/web-roo-code/src/app/reviewer/page.tsx b/apps/web-roo-code/src/app/reviewer/page.tsx deleted file mode 100644 index 776ded6847f..00000000000 --- a/apps/web-roo-code/src/app/reviewer/page.tsx +++ /dev/null @@ -1,70 +0,0 @@ -import type { Metadata } from "next" - -import { SEO } from "@/lib/seo" -import { ogImageUrl } from "@/lib/og" -import { AgentLandingContent } from "@/app/shared/AgentLandingContent" -import { getContentVariant } from "@/app/shared/getContentVariant" -import { content as contentA } from "./content" -import { content as contentB } from "./content-b" - -const TITLE = "PR Reviewer" -const DESCRIPTION = - "Get comprehensive AI-powered PR reviews that save you time, not tokens. Bring your own API key and leverage advanced reasoning, repository-aware analysis, and actionable feedback to keep your PR queue moving." -const OG_DESCRIPTION = "AI-powered PR reviews that save you time, not tokens" -const PATH = "/reviewer" - -export const metadata: Metadata = { - title: TITLE, - description: DESCRIPTION, - alternates: { - canonical: `${SEO.url}${PATH}`, - }, - openGraph: { - title: TITLE, - description: DESCRIPTION, - url: `${SEO.url}${PATH}`, - siteName: SEO.name, - images: [ - { - url: ogImageUrl(TITLE, OG_DESCRIPTION), - width: 1200, - height: 630, - alt: TITLE, - }, - ], - locale: SEO.locale, - type: "website", - }, - twitter: { - card: SEO.twitterCard, - title: TITLE, - description: DESCRIPTION, - images: [ogImageUrl(TITLE, OG_DESCRIPTION)], - }, - keywords: [ - ...SEO.keywords, - "PR reviewer", - "code review", - "pull request review", - "AI code review", - "GitHub PR review", - "automated code review", - "repository-aware review", - "bring your own key", - "BYOK AI", - "code quality", - "development workflow", - "cloud agents", - "AI development team", - ], -} - -export default async function AgentReviewerPage({ searchParams }: { searchParams: Promise<{ v?: string }> }) { - const params = await searchParams - const content = getContentVariant(params, { - A: contentA, - B: contentB, - }) - - return -} diff --git a/apps/web-roo-code/src/app/robots.ts b/apps/web-roo-code/src/app/robots.ts deleted file mode 100644 index fcdda5031e8..00000000000 --- a/apps/web-roo-code/src/app/robots.ts +++ /dev/null @@ -1,13 +0,0 @@ -import type { MetadataRoute } from "next" -import { SEO } from "@/lib/seo" - -export default function robots(): MetadataRoute.Robots { - return { - rules: { - userAgent: "*", - allow: "/", - }, - sitemap: `${SEO.url}/sitemap.xml`, - host: SEO.url, - } -} diff --git a/apps/web-roo-code/src/app/shared/AgentLandingContent.tsx b/apps/web-roo-code/src/app/shared/AgentLandingContent.tsx deleted file mode 100644 index 4db166b9199..00000000000 --- a/apps/web-roo-code/src/app/shared/AgentLandingContent.tsx +++ /dev/null @@ -1,235 +0,0 @@ -"use client" - -import { - ArrowRight, - GitPullRequest, - Wrench, - Key, - MessageSquareCode, - Blocks, - ListChecks, - BookMarked, - History, - LucideIcon, -} from "lucide-react" -import Image from "next/image" -import Link from "next/link" - -import { Button } from "@/components/ui" -import { AnimatedBackground, UseExamplesSection } from "@/components/homepage" -import { EXTERNAL_LINKS } from "@/lib/constants" -import { type AgentPageContent, type IconName } from "./agent-page-content" - -/** - * Maps icon names to actual Lucide icon components - */ -const iconMap: Record = { - GitPullRequest, - Wrench, - Key, - MessageSquareCode, - Blocks, - ListChecks, - BookMarked, - History, -} - -/** - * Converts an icon name string to a Lucide icon component - */ -function getIcon(iconName?: IconName): LucideIcon | undefined { - return iconName ? iconMap[iconName] : undefined -} - -export function AgentLandingContent({ content }: { content: AgentPageContent }) { - return ( - <> - {/* Hero Section */} -
- - -
- - {/* How It Works Section */} -
-
-
-
-
-
-
-

- {content.howItWorks.heading} -

-
-
- -
-
    - {content.howItWorks.steps.map((step, index) => { - const Icon = getIcon(step.icon) - return ( -
  • - {Icon && } -

    - {step.title} -

    -
    - {step.description} -
    -
    • - ) - })} -
-
-
-
- - {/* Why Better Section */} -
-
-
-
-
-
-
-

- {content.whyBetter.heading} -

-
-
- -
-
    - {content.whyBetter.features.map((feature, index) => { - const Icon = getIcon(feature.icon) - return ( -
  • - {Icon && } -

    - {feature.title} -

    -
    - {feature.description &&

    {feature.description}

    } - {feature.paragraphs && - feature.paragraphs.map((paragraph, pIndex) => ( -

    {paragraph}

    - ))} -
    -
    • - ) - })} -
-
-
-
- - - - {/* CTA Section */} -
-
-
-

{content.cta.heading}

-

- {content.cta.description} -

- -
-
-
- - ) -} diff --git a/apps/web-roo-code/src/app/shared/agent-page-content.ts b/apps/web-roo-code/src/app/shared/agent-page-content.ts deleted file mode 100644 index 01a64e85472..00000000000 --- a/apps/web-roo-code/src/app/shared/agent-page-content.ts +++ /dev/null @@ -1,75 +0,0 @@ -/** - * Supported icon names that can be used in agent page content. - * These strings are mapped to actual Lucide components in the client. - */ -export type IconName = - | "GitPullRequest" - | "Wrench" - | "Key" - | "MessageSquareCode" - | "Blocks" - | "ListChecks" - | "BookMarked" - | "History" - -/** - * Generic content structure for agent landing pages. - * This interface can be reused across different agent pages (PR Reviewer, PR Fixer, etc.) - * to maintain consistency and enable A/B testing capabilities. - * - * Note: Icons are referenced by string names (not components) to support - * serialization from Server Components to Client Components. - */ -export interface AgentPageContent { - agentName: string - hero: { - /** Optional icon name to display in the hero section */ - icon?: IconName - heading: string - paragraphs: string[] - image?: { - url: string - width: number - height: number - alt?: string - } - crossAgentLink: { - text: string - links: Array<{ - text: string - href: string - icon?: IconName - }> - } - cta: { - buttonText: string - disclaimer: string - tracking: string - } - } - howItWorks: { - heading: string - steps: Array<{ - title: string - /** Supports rich text content including React components */ - description: string | React.ReactNode - icon?: IconName - }> - } - whyBetter: { - heading: string - features: Array<{ - title: string - /** Supports rich text content including React components */ - description?: string | React.ReactNode - /** Supports rich text content including React components */ - paragraphs?: Array - icon?: IconName - }> - } - cta: { - heading: string - description: string - buttonText: string - } -} diff --git a/apps/web-roo-code/src/app/shared/getContentVariant.ts b/apps/web-roo-code/src/app/shared/getContentVariant.ts deleted file mode 100644 index 0d8fccdde45..00000000000 --- a/apps/web-roo-code/src/app/shared/getContentVariant.ts +++ /dev/null @@ -1,36 +0,0 @@ -import type { AgentPageContent } from "./agent-page-content" - -/** - * Selects the appropriate content variant based on the query parameter. - * - * @param searchParams - The search parameters from the page props - * @param variants - A record mapping variant letters to content objects - * @returns The selected content variant, defaulting to variant 'A' if not found or invalid - * - * @example - * ```tsx - * const content = getContentVariant(searchParams, { - * A: contentA, - * B: contentB, - * C: contentC, - * }) - * ``` - */ -export function getContentVariant( - searchParams: { v?: string }, - variants: Record, -): AgentPageContent { - const variant = searchParams.v?.toUpperCase() - - // Return the specified variant if it exists, otherwise default to 'A' - if (variant && variants[variant]) { - return variants[variant] - } - - // Ensure 'A' variant always exists as fallback - if (!variants.A) { - throw new Error("Content variants must include variant 'A' as the default") - } - - return variants.A -} diff --git a/apps/web-roo-code/src/app/shell.tsx b/apps/web-roo-code/src/app/shell.tsx deleted file mode 100644 index 84a42bed21b..00000000000 --- a/apps/web-roo-code/src/app/shell.tsx +++ /dev/null @@ -1,18 +0,0 @@ -import { getGitHubStars, getVSCodeDownloads } from "@/lib/stats" - -import { NavBar, Footer } from "@/components/chromes" - -// Invalidate cache when a request comes in, at most once every hour. -export const revalidate = 3600 - -export default async function Shell({ children }: { children: React.ReactNode }) { - const [stars, downloads] = await Promise.all([getGitHubStars(), getVSCodeDownloads()]) - - return ( -
- -
{children}
-
-
- ) -} diff --git a/apps/web-roo-code/src/app/slack/page.tsx b/apps/web-roo-code/src/app/slack/page.tsx deleted file mode 100644 index c1fb39cb3e2..00000000000 --- a/apps/web-roo-code/src/app/slack/page.tsx +++ /dev/null @@ -1,401 +0,0 @@ -import { - ArrowRight, - Brain, - CreditCard, - GitBranch, - GraduationCap, - Link2, - MessageSquare, - Settings, - Shield, - Slack, - Users, - Zap, -} from "lucide-react" -import type { LucideIcon } from "lucide-react" -import type { Metadata } from "next" - -import { AnimatedBackground } from "@/components/homepage" -import { SlackThreadDemo } from "@/components/slack/slack-thread-demo" -import { Button } from "@/components/ui" -import { EXTERNAL_LINKS } from "@/lib/constants" -import { SEO } from "@/lib/seo" -import { ogImageUrl } from "@/lib/og" - -const TITLE = "Roo Code for Slack" -const DESCRIPTION = - "Mention @Roomote in any channel to explain code, plan features, or ship a PR, all without leaving the conversation." -const OG_DESCRIPTION = "Your AI Team in Slack" -const PATH = "/slack" - -export const metadata: Metadata = { - title: TITLE, - description: DESCRIPTION, - alternates: { - canonical: `${SEO.url}${PATH}`, - }, - openGraph: { - title: TITLE, - description: DESCRIPTION, - url: `${SEO.url}${PATH}`, - siteName: SEO.name, - images: [ - { - url: ogImageUrl(TITLE, OG_DESCRIPTION), - width: 1200, - height: 630, - alt: TITLE, - }, - ], - locale: SEO.locale, - type: "website", - }, - twitter: { - card: SEO.twitterCard, - title: TITLE, - description: DESCRIPTION, - images: [ogImageUrl(TITLE, OG_DESCRIPTION)], - }, - keywords: [ - ...SEO.keywords, - "slack integration", - "slack bot", - "AI in slack", - "code assistant slack", - "@Roomote", - "team collaboration", - ], -} - -// Invalidate cache when a request comes in, at most once every hour. -export const revalidate = 3600 - -type ValueProp = { - icon: LucideIcon - title: string - description: string -} - -const VALUE_PROPS: ValueProp[] = [ - { - icon: GitBranch, - title: "Discussion to PR.", - description: - "Your team discusses a feature in Slack. @Roomote turns the discussion into a plan. Then builds it. All without leaving the conversation.", - }, - { - icon: Brain, - title: "Thread-aware.", - description: - '@Roomote reads the full thread before responding. Ask "Can we add caching here?" and it knows exactly what code you mean.', - }, - { - icon: Link2, - title: "Chain agents.", - description: - "Start with a Planner to spec it out. Then call the Coder to build it. Multi-step workflows, one Slack thread.", - }, - { - icon: Users, - title: "Open to all.", - description: - "Anyone on your team can ask @Roomote to fix bugs, build features, or investigate issues. Engineering gets looped in only when needed.", - }, - { - icon: GraduationCap, - title: "Built-in learning.", - description: "Public channel mentions show everyone how to leverage agents. Learn by watching.", - }, - { - icon: Shield, - title: "Safe by design.", - description: "Agents never touch main/master directly. They produce branches and PRs. You approve.", - }, -] - -type WorkflowStep = { - step: number - title: string - description: string -} - -const WORKFLOW_STEPS: WorkflowStep[] = [ - { - step: 1, - title: "Turn the discussion into a plan", - description: "Your team discusses a feature. When it gets complex, summon the Planner agent.", - }, - { - step: 2, - title: "Refine the plan in the thread", - description: - "The team reviews the spec in the thread, suggests changes, asks questions. Mention @Roomote again to refine.", - }, - { - step: 3, - title: "Build the plan", - description: "Once the plan looks good, hand it off to the Coder agent to implement.", - }, - { - step: 4, - title: "Review and ship", - description: "The Coder creates a branch and opens a PR. The team reviews, and the feature ships.", - }, -] - -type OnboardingStep = { - icon: LucideIcon - title: string - description: string - link?: { - href: string - text: string - } -} - -const ONBOARDING_STEPS: OnboardingStep[] = [ - { - icon: CreditCard, - title: "1. Team Plan", - description: "Slack requires a Team plan.", - link: { - href: EXTERNAL_LINKS.CLOUD_APP_TEAM_TRIAL, - text: "Start a free trial", - }, - }, - { - icon: Settings, - title: "2. Connect", - description: 'Sign in to Roo Code Cloud and go to Settings. Click "Connect" next to Slack.', - }, - { - icon: Slack, - title: "3. Authorize", - description: "Authorize the Roo Code app to access your Slack workspace.", - }, - { - icon: MessageSquare, - title: "4. Add to channels", - description: "Add @Roomote to the channels where you want it available.", - }, -] - -export default function SlackPage(): JSX.Element { - return ( - <> - {/* Hero Section */} -
- -
-
-
-
- - Powered by Roo Code Cloud -
-

- @Roomote: Your AI Team in Slack -

-

- Mention @Roomote in any channel to explain code, plan features, or ship a PR, all - without leaving the conversation. -

- -
- -
- -
-
-
-
- - {/* Value Props Section */} -
-
-
-
-
-
-

- Why your team will love using Roo Code in Slack -

-

- AI agents that understand context, chain together for complex work, and keep your team in - control. -

-
-
- {VALUE_PROPS.map((prop, index) => { - const Icon = prop.icon - return ( -
-
- -
-

{prop.title}

-

{prop.description}

-
- ) - })} -
-
-
- - {/* Featured Workflow Section */} -
-
-
-
-
- -
-
- - Featured Workflow -
-

- Thread to Shipped Feature -

-

- Turn Slack discussions into working code. No context lost, no meetings needed. -

-
- -
-
- {/* YouTube Video Embed */} -
-