From f7afae7f987863e1bfd9e2e099332ed1622d2c3c Mon Sep 17 00:00:00 2001 From: DScoNOIZ Date: Fri, 24 Apr 2026 18:33:11 +0000 Subject: [PATCH] Delete .roo directory --- .roo/commands/cli-release.md | 86 --- .roo/commands/commit.md | 80 --- .roo/commands/release.md | 45 -- .roo/commands/roo-resolve-conflicts.md | 72 --- .roo/commands/roo-translate.md | 50 -- .roo/guidance/roo-translator.md | 15 - .roo/roomotes.yml | 6 - .roo/rules-code/use-safeWriteJson.md | 6 - .roo/rules-debug/cli.md | 67 --- .../1_extraction_workflow.xml | 113 ---- .../2_verification_workflow.xml | 85 --- .roo/rules-docs-extractor/3_output_format.xml | 133 ---- .roo/rules-issue-fixer/1_Workflow.xml | 566 ------------------ .roo/rules-issue-fixer/2_best_practices.xml | 19 - .roo/rules-issue-fixer/3_common_patterns.xml | 21 - .roo/rules-issue-fixer/4_github_cli_usage.xml | 245 -------- .../5_pull_request_workflow.xml | 52 -- .../6_testing_guidelines.xml | 10 - .../7_communication_style.xml | 8 - .../8_github_communication_guidelines.xml | 16 - .roo/rules-issue-fixer/9_pr_template.xml | 205 ------- .roo/rules-issue-investigator/1_workflow.xml | 98 --- .../2_best_practices.xml | 60 -- .../3_common_patterns.xml | 45 -- .../rules-issue-investigator/4_tool_usage.xml | 84 --- .roo/rules-issue-investigator/5_examples.xml | 99 --- .../6_communication.xml | 37 -- .roo/rules-issue-writer/1_workflow.xml | 391 ------------ .roo/rules-issue-writer/3_best_practices.xml | 147 ----- .../4_common_mistakes_to_avoid.xml | 109 ---- .roo/rules-issue-writer/5_examples.xml | 134 ----- .roo/rules-merge-resolver/1_workflow.xml | 157 ----- .../rules-merge-resolver/2_best_practices.xml | 165 ----- .roo/rules-merge-resolver/3_tool_usage.xml | 258 -------- .../4_complete_example.xml | 316 ---------- .roo/rules-merge-resolver/5_communication.xml | 153 ----- .roo/rules-pr-fixer/1_workflow.xml | 75 --- .roo/rules-pr-fixer/2_best_practices.xml | 75 --- .roo/rules-pr-fixer/3_common_patterns.xml | 136 ----- .roo/rules-pr-fixer/4_tool_usage.xml | 156 ----- .roo/rules-pr-fixer/5_examples.xml | 304 ---------- .roo/rules-translate/001-general-rules.md | 106 ---- .roo/rules-translate/instructions-de.md | 14 - .roo/rules-translate/instructions-zh-cn.md | 277 --------- .roo/rules-translate/instructions-zh-tw.md | 18 - .roo/rules/rules.md | 24 - .roo/skills/evals-context/SKILL.md | 188 ------ .roo/skills/roo-conflict-resolution/SKILL.md | 256 -------- .roo/skills/roo-translation/SKILL.md | 151 ----- 49 files changed, 5933 deletions(-) delete mode 100644 .roo/commands/cli-release.md delete mode 100644 .roo/commands/commit.md delete mode 100644 .roo/commands/release.md delete mode 100644 .roo/commands/roo-resolve-conflicts.md delete mode 100644 .roo/commands/roo-translate.md delete mode 100644 .roo/guidance/roo-translator.md delete mode 100644 .roo/roomotes.yml delete mode 100644 .roo/rules-code/use-safeWriteJson.md delete mode 100644 .roo/rules-debug/cli.md delete mode 100644 .roo/rules-docs-extractor/1_extraction_workflow.xml delete mode 100644 .roo/rules-docs-extractor/2_verification_workflow.xml delete mode 100644 .roo/rules-docs-extractor/3_output_format.xml delete mode 100644 .roo/rules-issue-fixer/1_Workflow.xml delete mode 100644 .roo/rules-issue-fixer/2_best_practices.xml delete mode 100644 .roo/rules-issue-fixer/3_common_patterns.xml delete mode 100644 .roo/rules-issue-fixer/4_github_cli_usage.xml delete mode 100644 .roo/rules-issue-fixer/5_pull_request_workflow.xml delete mode 100644 .roo/rules-issue-fixer/6_testing_guidelines.xml delete mode 100644 .roo/rules-issue-fixer/7_communication_style.xml delete mode 100644 .roo/rules-issue-fixer/8_github_communication_guidelines.xml delete mode 100644 .roo/rules-issue-fixer/9_pr_template.xml delete mode 100644 .roo/rules-issue-investigator/1_workflow.xml delete mode 100644 .roo/rules-issue-investigator/2_best_practices.xml delete mode 100644 .roo/rules-issue-investigator/3_common_patterns.xml delete mode 100644 .roo/rules-issue-investigator/4_tool_usage.xml delete mode 100644 .roo/rules-issue-investigator/5_examples.xml delete mode 100644 .roo/rules-issue-investigator/6_communication.xml delete mode 100644 .roo/rules-issue-writer/1_workflow.xml delete mode 100644 .roo/rules-issue-writer/3_best_practices.xml delete mode 100644 .roo/rules-issue-writer/4_common_mistakes_to_avoid.xml delete mode 100644 .roo/rules-issue-writer/5_examples.xml delete mode 100644 .roo/rules-merge-resolver/1_workflow.xml delete mode 100644 .roo/rules-merge-resolver/2_best_practices.xml delete mode 100644 .roo/rules-merge-resolver/3_tool_usage.xml delete mode 100644 .roo/rules-merge-resolver/4_complete_example.xml delete mode 100644 .roo/rules-merge-resolver/5_communication.xml delete mode 100644 .roo/rules-pr-fixer/1_workflow.xml delete mode 100644 .roo/rules-pr-fixer/2_best_practices.xml delete mode 100644 .roo/rules-pr-fixer/3_common_patterns.xml delete mode 100644 .roo/rules-pr-fixer/4_tool_usage.xml delete mode 100644 .roo/rules-pr-fixer/5_examples.xml delete mode 100644 .roo/rules-translate/001-general-rules.md delete mode 100644 .roo/rules-translate/instructions-de.md delete mode 100644 .roo/rules-translate/instructions-zh-cn.md delete mode 100644 .roo/rules-translate/instructions-zh-tw.md delete mode 100644 .roo/rules/rules.md delete mode 100644 .roo/skills/evals-context/SKILL.md delete mode 100644 .roo/skills/roo-conflict-resolution/SKILL.md delete mode 100644 .roo/skills/roo-translation/SKILL.md diff --git a/.roo/commands/cli-release.md b/.roo/commands/cli-release.md deleted file mode 100644 index 5e68e4df2d..0000000000 --- a/.roo/commands/cli-release.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -description: "Prepare a new release of the Roo Code CLI" -argument-hint: "[version-description]" -mode: code ---- - -1. Identify changes since the last CLI release: - - - Get the last CLI release tag: `gh release list --limit 10 | grep "cli-v"` - - View changes since last release: `git log cli-v..HEAD -- apps/cli --oneline` - - Or for uncommitted changes: `git diff --stat -- apps/cli` - -2. Review and summarize the changes to determine an appropriate changelog entry. Group changes by type: - - - **Added**: New features - - **Changed**: Changes to existing functionality - - **Fixed**: Bug fixes - - **Removed**: Removed features - - **Tests**: New or updated tests - -3. Bump the version in `apps/cli/package.json`: - - - Increment the patch version (e.g., 0.0.43 → 0.0.44) for bug fixes and minor changes - - Increment the minor version (e.g., 0.0.43 → 0.1.0) for new features - - Increment the major version (e.g., 0.0.43 → 1.0.0) for breaking changes - -4. Update `apps/cli/CHANGELOG.md` with a new entry: - - - Add a new section at the top (below the header) following this format: - - ```markdown - ## [X.Y.Z] - YYYY-MM-DD - - ### Added - - - Description of new features - - ### Changed - - - Description of changes - - ### Fixed - - - Description of bug fixes - ``` - - - Use the current date in YYYY-MM-DD format - - Include links to relevant source files where helpful - - Describe changes from the user's perspective - -5. Create a release branch and commit the changes: - - ```bash - # Ensure you're on main and up to date - git checkout main - git pull origin main - - # Create a new branch for the release - git checkout -b cli-release-v - - # Commit the version bump and changelog update - git add apps/cli/package.json apps/cli/CHANGELOG.md - git commit -m "chore(cli): prepare release v" - - # Push the branch to origin - git push -u origin cli-release-v - ``` - -6. Create a pull request for the release: - - ```bash - gh pr create --title "chore(cli): prepare release v" \ - --body "## CLI Release v - - This PR prepares the CLI release v. - - ### Changes - - Version bump in package.json - - Changelog update - - ### Checklist - - [ ] Version number is correct - - [ ] Changelog entry is complete and accurate - - [ ] All CI checks pass" \ - --base main - ``` diff --git a/.roo/commands/commit.md b/.roo/commands/commit.md deleted file mode 100644 index 7796c49fa9..0000000000 --- a/.roo/commands/commit.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -description: "Commit and push changes with a descriptive message" -argument-hint: "[optional-context]" -mode: code ---- - -1. Analyze the current changes to understand what needs to be committed: - - ```bash - # Check for staged and unstaged changes - git status --short - - # View the diff of all changes (staged and unstaged) - git diff HEAD - ``` - -2. Based on the diff output, formulate a commit message following conventional commit format: - - - **feat**: New feature or functionality - - **fix**: Bug fix - - **refactor**: Code restructuring without behavior change - - **docs**: Documentation changes - - **test**: Adding or updating tests - - **chore**: Maintenance tasks, dependencies, configs - - **style**: Formatting, whitespace, no logic changes - - Format: `type(scope): brief description` - - Examples: - - - `feat(api): add user authentication endpoint` - - `fix(ui): resolve button alignment on mobile` - - `refactor(core): simplify error handling logic` - - `docs(readme): update installation instructions` - -3. Stage all unstaged changes: - - ```bash - git add -A - ``` - -4. Commit with the generated message: - - ```bash - git commit -m "type(scope): brief description" - ``` - - **If pre-commit hooks fail:** - - - Review the error output (linter errors, type checking errors, etc.) - - Fix the identified issues in the affected files - - Re-stage the fixes: `git add -A` - - Retry the commit: `git commit -m "type(scope): brief description"` - -5. Push to the remote repository: - - ```bash - git push - ``` - - **If pre-push hooks fail:** - - - Review the error output (test failures, linter errors, etc.) - - Fix the identified issues in the affected files - - Stage and commit the fixes using steps 3-4 - - Retry the push: `git push` - -**Tips for good commit messages:** - -- Keep the first line under 72 characters -- Use imperative mood ("add", "fix", "update", not "added", "fixes", "updated") -- Be specific but concise -- If multiple unrelated changes exist, consider splitting into separate commits - -**Common hook failures and fixes:** - -- **Linter errors**: Run the project's linter (e.g., `npm run lint` or `pnpm lint`) to see all issues, then fix them -- **Type checking errors**: Run type checker (e.g., `npx tsc --noEmit`) to identify type issues -- **Test failures**: Run tests (e.g., `npm test` or `pnpm test`) to identify failing tests and fix them -- **Format issues**: Run formatter (e.g., `npm run format` or `pnpm format`) to auto-fix formatting diff --git a/.roo/commands/release.md b/.roo/commands/release.md deleted file mode 100644 index 2e09783a58..0000000000 --- a/.roo/commands/release.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -description: "Create a new release of the Roo Code extension" -argument-hint: patch | minor | major -mode: code ---- - -1. Identify the SHA corresponding to the most recent release using GitHub CLI: `gh release view --json tagName,targetCommitish,publishedAt` -2. Analyze changes since the last release using: `gh pr list --state merged --base main --json number,title,author,url,mergedAt,closingIssuesReferences --limit 1000 -q '[.[] | select(.mergedAt > "TIMESTAMP") | {number, title, author: .author.login, url, mergedAt, issues: .closingIssuesReferences}] | sort_by(.number)'` -3. For each PR with linked issues, fetch the issue details to get the issue reporter: `gh issue view ISSUE_NUMBER --json number,author -q '{number, reporter: .author.login}'` -4. Summarize the changes. If the user did not specify, ask them whether this should be a major, minor, or patch release. -5. Create a changeset in .changeset/v[version].md instead of directly modifying package.json. The format is: - -``` ---- -"roo-cline": patch|minor|major ---- -[list of changes] -``` - -- Always include contributor attribution and the PR number: use "(PR # by @username)". -- For PRs that close issues, include both the issue number and the PR number and authors: "- Fix: Description (#123 by @reporter, PR #456 by @contributor)" -- For PRs without linked issues, include the PR number and author: "- Add support for feature (PR #456 by @contributor)" -- Provide brief descriptions of each item to explain the change -- Order the list from most important to least important -- Example formats: - - With issue: "- Fix: Resolve memory leak in extension (#456 by @issueReporter, PR #789 by @prAuthor)" - - Without issue: "- Add support for Gemini 2.5 Pro caching (PR #789 by @contributor)" -- CRITICAL: Include EVERY SINGLE PR in the changeset - don't assume you know which ones are important. Count the total PRs to verify completeness and cross-reference the list to ensure nothing is missed. - -6. If the generate_image tool is available, create a release image at `releases/[version]-release.png` - - The image should feature a realistic-looking kangaroo doing something human-like that relates to the main highlight of the release - - Pass `releases/template.png` as the reference image for aspect ratio and kangaroo style - - Add the generated image to .changeset/v[version].md before the list of changes with format: `![X.Y.Z Release - Description](/releases/X.Y.Z-release.png)` -7. If a major or minor release: - - Ask the user what the three most important areas to highlight are in the release - - Update the English version relevant announcement files and documentation (webview-ui/src/components/chat/Announcement.tsx, README.md, and the `latestAnnouncementId` in src/core/webview/ClineProvider.ts) - - Ask the user to confirm that the English version looks good to them before proceeding - - Use the new_task tool to create a subtask in `translate` mode with detailed instructions of which content needs to be translated into all supported languages (The READMEs as well as the translation strings) -8. Create a new branch for the release preparation: `git checkout -b release/v[version]` -9. Commit and push the changeset file and any documentation updates to the repository: `git add . && git commit -m "chore: add changeset for v[version]" && git push origin release/v[version]` -10. Create a pull request for the release: `gh pr create --title "Release v[version]" --body "Release preparation for v[version]. This PR includes the changeset and any necessary documentation updates." --base main --head release/v[version]` -11. The GitHub Actions workflow will automatically: - - Create a version bump PR when changesets are merged to main - - Update the CHANGELOG.md with proper formatting - - Publish the release when the version bump PR is merged diff --git a/.roo/commands/roo-resolve-conflicts.md b/.roo/commands/roo-resolve-conflicts.md deleted file mode 100644 index 4a3a80bdd3..0000000000 --- a/.roo/commands/roo-resolve-conflicts.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -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 deleted file mode 100644 index 3f97494894..0000000000 --- a/.roo/commands/roo-translate.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -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 deleted file mode 100644 index 2539778f27..0000000000 --- a/.roo/guidance/roo-translator.md +++ /dev/null @@ -1,15 +0,0 @@ -# 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/roomotes.yml b/.roo/roomotes.yml deleted file mode 100644 index 0ea30b93af..0000000000 --- a/.roo/roomotes.yml +++ /dev/null @@ -1,6 +0,0 @@ -version: "1.0" - -commands: - - name: Install dependencies - run: pnpm install - timeout: 60 diff --git a/.roo/rules-code/use-safeWriteJson.md b/.roo/rules-code/use-safeWriteJson.md deleted file mode 100644 index 21e42553da..0000000000 --- a/.roo/rules-code/use-safeWriteJson.md +++ /dev/null @@ -1,6 +0,0 @@ -# JSON File Writing Must Be Atomic - -- You MUST use `safeWriteJson(filePath: string, data: any): Promise` from `src/utils/safeWriteJson.ts` instead of `JSON.stringify` with file-write operations -- `safeWriteJson` will create parent directories if necessary, so do not call `mkdir` prior to `safeWriteJson` -- `safeWriteJson` prevents data corruption via atomic writes with locking and streams the write to minimize memory footprint -- Test files are exempt from this rule diff --git a/.roo/rules-debug/cli.md b/.roo/rules-debug/cli.md deleted file mode 100644 index 7992718ffa..0000000000 --- a/.roo/rules-debug/cli.md +++ /dev/null @@ -1,67 +0,0 @@ -# CLI Debugging with File-Based Logging - -When debugging the CLI, `console.log` will break the TUI (Terminal User Interface). Use file-based logging to capture debug output without interfering with the application's display. - -## File-Based Logging Strategy - -1. **Write logs to a temporary file instead of console**: - - - Create a log file at a known location, e.g., `/tmp/roo-cli-debug.log` - - Use `fs.appendFileSync()` to write timestamped log entries - - Example logging utility: - - ```typescript - import fs from "fs" - const DEBUG_LOG = "/tmp/roo-cli-debug.log" - - function debugLog(message: string, data?: unknown) { - const timestamp = new Date().toISOString() - const entry = data - ? `[${timestamp}] ${message}: ${JSON.stringify(data, null, 2)}\n` - : `[${timestamp}] ${message}\n` - fs.appendFileSync(DEBUG_LOG, entry) - } - ``` - -2. **Clear the log file before each debugging session**: - - Run `echo "" > /tmp/roo-cli-debug.log` or use `fs.writeFileSync(DEBUG_LOG, "")` at app startup during debugging - -## Iterative Debugging Workflow - -Follow this feedback loop to systematically narrow down issues: - -1. **Add targeted logging** at suspected problem areas based on your hypotheses -2. **Instruct the user** to reproduce the issue using the CLI normally -3. **Read the log file** after the user completes testing: - - Run `cat /tmp/roo-cli-debug.log` to retrieve the captured output -4. **Analyze the log output** to gather clues about: - - Execution flow and timing - - Variable values at key points - - Which code paths were taken - - Error conditions or unexpected states -5. **Refine your logging** based on findings—add more detail where needed, remove noise -6. **Ask the user to test again** with updated logging -7. **Repeat** until the root cause is identified - -## Best Practices - -- Log entry/exit points of functions under investigation -- Include relevant variable values and state information -- Use descriptive prefixes to categorize logs: `[STATE]`, `[EVENT]`, `[ERROR]`, `[FLOW]` -- Log both the "happy path" and error handling branches -- When dealing with async operations, log before and after `await` statements -- For user interactions, log the received input and the resulting action - -## Example Debug Session - -```typescript -// Add logging to investigate a picker selection issue -debugLog("[FLOW] PickerSelect onSelect called", { selectedIndex, item }) -debugLog("[STATE] Current selection state", { currentValue, isOpen }) - -// After async operation -const result = await fetchOptions() -debugLog("[FLOW] fetchOptions completed", { resultCount: result.length }) -``` - -Then ask: "Please reproduce the issue by [specific steps]. When you're done, let me know and I'll analyze the debug logs." diff --git a/.roo/rules-docs-extractor/1_extraction_workflow.xml b/.roo/rules-docs-extractor/1_extraction_workflow.xml deleted file mode 100644 index 200e48da0c..0000000000 --- a/.roo/rules-docs-extractor/1_extraction_workflow.xml +++ /dev/null @@ -1,113 +0,0 @@ - - - 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. - - - - - Identify Target - - Parse the user's request to identify the feature/aspect - Clarify scope if ambiguous (ask one question max) - - - - - 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 - - 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 - - - - - - Error conditions in code - Error messages (exact text) - Recovery paths in code - - - - - - UI components involved - User-visible labels and text - Interaction patterns - - - - - - Other features this interacts with - External APIs or services called - Events emitted or consumed - - - - - - 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_verification_workflow.xml b/.roo/rules-docs-extractor/2_verification_workflow.xml deleted file mode 100644 index 4635d8eb45..0000000000 --- a/.roo/rules-docs-extractor/2_verification_workflow.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - 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_output_format.xml b/.roo/rules-docs-extractor/3_output_format.xml deleted file mode 100644 index 185f7b23b8..0000000000 --- a/.roo/rules-docs-extractor/3_output_format.xml +++ /dev/null @@ -1,133 +0,0 @@ - - - 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-issue-fixer/1_Workflow.xml b/.roo/rules-issue-fixer/1_Workflow.xml deleted file mode 100644 index c6f2b570a0..0000000000 --- a/.roo/rules-issue-fixer/1_Workflow.xml +++ /dev/null @@ -1,566 +0,0 @@ - - - Retrieve Issue Context - - The user should provide a full GitHub issue URL (e.g., "https://github.com/owner/repo/issues/123") for implementation. - - Parse the URL to extract: - - Owner (organization or username) - - Repository name - - Issue number - - For example, from https://github.com/RooCodeInc/Roo-Code/issues/123: - - Owner: RooCodeInc - - Repo: Roo-Code - - Issue: 123 - - Then retrieve the issue: - - - gh api repos/[owner]/[repo]/issues/[issue-number] --jq '{number,title,body,state,labels,assignees,milestone,createdAt:.created_at,updatedAt:.updated_at,closedAt:.closed_at,author:.user.login}' - - - If the command fails with an authentication error (e.g., "gh: Not authenticated" or "HTTP 401"), ask the user to authenticate: - - GitHub CLI is not authenticated. Please run 'gh auth login' in your terminal to authenticate, then let me know when you're ready to continue. - - I've authenticated, please continue - I need help with authentication - Let's use a different approach - - - - Analyze the issue to determine: - 1. All requirements and acceptance criteria - 2. Technical details mentioned - 3. Any linked issues or discussions - - Note: For PR review feedback, users should use the dedicated pr-fixer mode instead. - - - - - Review Issue Comments and Related Context - - Get all comments on the issue to understand: - - Additional context or clarifications - - Maintainer feedback - - Community suggestions - - Any decisions or changes to requirements - - - gh api repos/[owner]/[repo]/issues/[issue-number]/comments --paginate --jq '.[].body' - - - Also check for: - 1. Related issues mentioned in the body or comments - 2. Linked pull requests - 3. Referenced discussions - - If related PRs are mentioned, view them: - - gh pr view [pr-number] --repo [owner]/[repo] - - - Document all requirements and constraints found. - - - - - Explore Codebase and Related Files - - Use codebase_search FIRST to understand the codebase structure and find ALL related files: - - For Bug Fixes: - - Search for the broken functionality - - Find error handling and logging - - Locate related test files - - Identify dependencies and imports - - Find similar patterns in the codebase - - For Features: - - Search for similar existing features - - Find integration points - - Locate configuration files - - Identify patterns to follow - - Find related components and utilities - - Example searches based on issue type: - - Bug: Search for error messages, function names, component names - - Feature: Search for similar functionality, API endpoints, UI components - - CRITICAL: Always read multiple related files together to understand: - - Current code patterns and conventions - - How similar functionality is implemented - - Testing patterns used in the project - - Import/export patterns - - Error handling approaches - - Configuration and setup patterns - - Then use other tools: - - list_code_definition_names to understand file structure - - read_file to examine specific implementations (read multiple files at once) - - search_files for specific patterns or error messages - - Also use GitHub CLI to check recent changes: - - gh api repos/[owner]/[repo]/commits?path=[file-path]&per_page=10 --jq '.[].sha + " " + .[].commit.message' - - - Search for related PRs: - - gh pr list --repo [owner]/[repo] --search "[relevant search terms]" --limit 10 - - - Document: - - All files that need modification - - Current implementation details and patterns - - Code conventions to follow (naming, structure, etc.) - - Test file locations and patterns - - Related files that might be affected - - - - - Create Implementation Plan - - Based on the issue analysis, create a detailed implementation plan: - - For Bug Fixes: - 1. Reproduce the bug locally (if possible) - 2. Identify root cause - 3. Plan the fix approach. The plan should be focused on resolving the issue with a high-quality, targeted fix, while avoiding unrelated changes. - 4. Identify files to modify. - 5. Plan test cases to prevent regression. - - For Feature Implementation: - 1. Break down the feature into components - 2. Identify all files that need changes - 3. Plan the implementation approach - 4. Consider edge cases and error handling - 5. Plan test coverage - - Present the plan to the user: - - - I've analyzed issue #[number]: "[title]" - - Here's my implementation plan to resolve the issue: - - [Detailed plan with steps and affected files] - - This plan focuses on providing a quality fix for the reported problem without introducing unrelated changes. - - Would you like me to proceed with this implementation? - - Yes, proceed with the implementation - Let me review the issue first - Modify the approach for: [specific aspect] - Focus only on: [specific part] - - - - - - - Implement the Solution - - Implement the fix or feature following the plan: - - General Guidelines: - 1. Follow existing code patterns and style - 2. Add appropriate error handling - 3. Include necessary comments - 4. Update related documentation - 5. Ensure backward compatibility (if applicable) - - For Bug Fixes: - 1. Implement the planned fix, focusing on quality and precision. - 2. The scope of the fix should be as narrow as possible to address the issue. Avoid making changes to code that is not directly related to the fix. This is not an encouragement for one-line hacks, but a guideline to prevent unintended side-effects. - 3. Add regression tests. - 4. Verify the fix resolves the issue. - 5. Check for side effects. - - For Features: - 1. Implement incrementally - 2. Test each component as you build - 3. Follow the acceptance criteria exactly - 4. Add comprehensive tests - 5. Update documentation - - Use appropriate tools: - - apply_diff for targeted changes - - write_to_file for new files - - After each significant change, run relevant tests: - - execute_command to run test suites - - Check for linting errors - - Verify functionality works as expected - - - - - Verify Acceptance Criteria - - Systematically verify all acceptance criteria from the issue: - - For Bug Fixes: - 1. Confirm the bug no longer reproduces - 2. Follow the exact reproduction steps - 3. Verify expected behavior now occurs - 4. Check no new bugs introduced - 5. Run all related tests - - For Features: - 1. Test each acceptance criterion - 2. Verify all Given/When/Then scenarios - 3. Test edge cases - 4. Verify UI changes (if applicable) - 5. Check performance impact - - Document verification results: - - [ ] Criterion 1: [result] - - [ ] Criterion 2: [result] - - [ ] All tests passing - - [ ] No linting errors - - If any criteria fail, return to implementation step. - - - - - Check for Translation Requirements - - After implementing changes, analyze if any translations are required: - - Translation is needed if the implementation includes: - 1. New user-facing text strings in UI components - 2. New error messages or user notifications - 3. Updated documentation files that need localization - 4. New command descriptions or tooltips - 5. Changes to announcement files or release notes - 6. New configuration options with user-visible descriptions - - Check for these patterns: - - Hard-coded strings in React components (.tsx/.jsx files) - - New entries needed in i18n JSON files - - Updated markdown documentation files - - New VSCode command contributions - - Changes to user-facing configuration schemas - - If translations are required: - - - translate - Translation needed for issue #[issue-number] implementation. - - The following changes require translation into all supported languages: - - **Files with new/updated user-facing content:** - - [List specific files and what content needs translation] - - [Include context about where the strings appear] - - [Note any special formatting or constraints] - - **Translation scope:** - - [Specify if it's new strings, updated strings, or both] - - [List specific JSON keys that need attention] - - [Note any markdown files that need localization] - - **Context for translators:** - - [Explain the feature/fix being implemented] - - [Provide context about how the text is used] - - [Note any technical terms or constraints] - - Please ensure all translations maintain consistency with existing terminology and follow the project's localization guidelines. - -[ ] Identify all user-facing strings that need translation -[ ] Update i18n JSON files for all supported languages -[ ] Translate any markdown documentation files -[ ] Verify translations maintain consistency with existing terminology -[ ] Test translations in the application context - - - - Wait for the translation task to complete before proceeding to testing. - - If no translations are required, continue to the next step. - - - - - Run Tests and Checks - - Run comprehensive tests to ensure quality: - - 1. Run unit tests for modified files: - ``` - npm test [test file paths] - ``` - - 2. Run integration tests if applicable: - ``` - npm run test:integration - ``` - - 3. Check for linting errors: - ``` - npm run lint - ``` - - 4. Run type checking: - ``` - npm run type-check - ``` - - 5. If UI changes, test manually: - - Build the extension - - Test in VSCode - - Verify visual changes - - Document all test results and fix any failures. - - - - - Prepare Summary - - Create a comprehensive summary of the implementation: - - ## Summary of Changes - - **Issue:** #[number] - [title] - **Type:** [Bug Fix/Feature Implementation] - - ### What was done: - - [List key changes] - - [Files modified] - - [Tests added] - - ### How it addresses the issue: - [Explain how each requirement is met] - - ### Testing performed: - - [List all tests run] - - [Manual testing done] - - [Verification of acceptance criteria] - - ### Files changed: - - `path/to/file1.ts` - [brief description] - - `path/to/file2.ts` - [brief description] - - ### Potential impacts: - - [Any breaking changes] - - [Performance considerations] - - [Compatibility notes] - - Present to user for review: - - - I've completed the implementation for issue #[number]. Here's what was done: - - [Insert summary] - - All acceptance criteria have been met and tests are passing. - - Would you like me to prepare a pull request, or would you like to review the changes first? - - Create a pull request with these changes - Show me the key changes in detail - Run additional tests for: [specific area] - Make additional changes to: [specific file] - - - - - - - Prepare for Pull Request - - If user wants to create a pull request, prepare everything needed: - - 1. Create appropriate branch name: - - Bug fix: `fix/issue-[number]-[brief-description]` - - Feature: `feat/issue-[number]-[brief-description]` - - 2. Ensure all changes are committed: - ```bash - git status - git add [modified files] - git commit -m "fix: [description] (#[issue-number])" - ``` - - 3. Push to a fork or branch (depending on user's access): - ```bash - git push origin [branch-name] - ``` - - 4. Prepare comprehensive PR description: - ```markdown - ## Description - - Fixes #[issue number] - - [Detailed description of what was changed and why] - - ## Changes Made - - - [Specific change 1 with file references] - - [Specific change 2 with technical details] - - [Any refactoring or cleanup done] - - ## Testing - - - [x] All existing tests pass - - [x] Added tests for [specific functionality] - - [x] Manual testing completed: - - [Specific manual test 1] - - [Specific manual test 2] - - ## Verification of Acceptance Criteria - - [For each criterion from the issue, show it's met] - - [x] Criterion 1: [How it's verified] - - [x] Criterion 2: [How it's verified] - - ## Checklist - - - [x] Code follows project style guidelines - - [x] Self-review completed - - [x] Comments added for complex logic - - [x] Documentation updated (if needed) - - [x] No breaking changes (or documented if any) - - [x] Accessibility checked (for UI changes) - - ## Screenshots/Demo (if applicable) - - [Add before/after screenshots for UI changes] - [Add terminal output for CLI changes] - ``` - - 5. Ask user for final approval: - - - I've prepared everything for the pull request: - - **Branch:** [branch-name] - **Title:** [PR title] - **Target:** [owner]/[repo] (main branch) - - Here's the PR description: - - [Show prepared PR description] - - Would you like me to create this pull request to [owner]/[repo]? - - Yes, create the pull request - Let me review the PR description first - Change the PR title to: [let me specify] - Add more details about: [specific aspect] - - - - - - - Create Pull Request - - Once user approves, create the pull request using GitHub CLI: - - If the user doesn't have push access to [owner]/[repo], fork the repository: - - gh repo fork [owner]/[repo] --clone - - - Create the pull request: - - gh pr create --repo [owner]/[repo] --base main --title "[Type]: [Brief description] (#[issue-number])" --body "[Complete PR description from step 10]" --maintainer-can-modify - - - The gh CLI will automatically handle the fork workflow if needed. - - After PR creation: - 1. Capture the PR number and URL from the command output - 2. Link the PR to the issue by commenting on the issue - 3. Inform the user of the successful creation - - - gh issue comment [original issue number] --repo [owner]/[repo] --body "PR #[new PR number] has been created to address this issue" - - - Final message to user: - ``` - ✅ Pull Request Created Successfully! - - PR #[number]: [title] - URL: [PR URL] - - The PR has been created and linked to issue #[issue number]. - - Next steps: - 1. The PR will be reviewed by maintainers - 2. Address any feedback in the PR comments - 3. Once approved, it will be merged - - You can track the PR status at: [PR URL] - ``` - - - - - Monitor PR Checks - - After the PR is created, monitor the CI/CD checks to ensure they pass: - - - gh pr checks [PR number] --repo [owner]/[repo] --watch - - - This command will: - 1. Display all CI/CD checks configured for the repository - 2. Show the status of each check in real-time - 3. Update automatically as checks complete - 4. Exit when all checks have finished running - - Monitor the output and note: - - Which checks are running (e.g., tests, linting, build) - - Any checks that fail and their error messages - - The overall status of the PR checks - - If any checks fail: - 1. Analyze the failure logs - 2. Identify what needs to be fixed - 3. Ask the user if they want you to address the failures - - - The PR checks have completed. Here's the status: - - [Show check results - passing/failing] - - [If all pass]: All checks have passed successfully! The PR is ready for review. - - [If any fail]: Some checks have failed: - - [Failed check 1]: [Brief error description] - - [Failed check 2]: [Brief error description] - - Would you like me to fix these issues? - - Yes, please fix the failing checks - Show me the detailed error logs - I'll handle the failures manually - The PR is fine as-is, these failures are expected - - - - If user wants fixes: - 1. Create a plan to address each failure - 2. Make necessary code changes - 3. Commit and push the fixes - 4. Monitor checks again to ensure they pass - - Important notes: - - The --watch flag will keep the command running until all checks complete - - This step helps ensure the PR meets all quality standards before review - - Early detection of CI/CD failures saves reviewer time - - - \ No newline at end of file diff --git a/.roo/rules-issue-fixer/2_best_practices.xml b/.roo/rules-issue-fixer/2_best_practices.xml deleted file mode 100644 index 81a06fe94a..0000000000 --- a/.roo/rules-issue-fixer/2_best_practices.xml +++ /dev/null @@ -1,19 +0,0 @@ - - - Always read the entire issue and all comments before starting - - Follow the project's coding standards and patterns - - Focus exclusively on addressing the issue's requirements. - - Make minimal, high-quality changes for bug fixes. The goal is a narrow, targeted fix, not a one-line hack. - - Test thoroughly - both automated and manual testing - - Document complex logic with comments - - Keep commits focused and well-described - - Reference the issue number in commits - - Verify all acceptance criteria are met - - Consider performance and security implications - - Update documentation when needed - - Add tests for any new functionality - - Check for accessibility issues (for UI changes) - - Delegate translation tasks to translate mode when implementing user-facing changes - - Always check for hard-coded strings and internationalization needs - - When using new_task to delegate work, always include a comprehensive todos list - - Wait for translation completion before proceeding to final testing - \ No newline at end of file diff --git a/.roo/rules-issue-fixer/3_common_patterns.xml b/.roo/rules-issue-fixer/3_common_patterns.xml deleted file mode 100644 index 0fdffa8b69..0000000000 --- a/.roo/rules-issue-fixer/3_common_patterns.xml +++ /dev/null @@ -1,21 +0,0 @@ - - - 1. Reproduce the issue - 2. Identify root cause - 3. Implement minimal fix - 4. Add regression test - 5. Verify fix works - 6. Check for side effects - - - - 1. Understand all requirements - 2. Design the solution - 3. Implement incrementally - 4. Test each component - 5. Integrate components - 6. Verify acceptance criteria - 7. Add comprehensive tests - 8. Update documentation - - \ No newline at end of file diff --git a/.roo/rules-issue-fixer/4_github_cli_usage.xml b/.roo/rules-issue-fixer/4_github_cli_usage.xml deleted file mode 100644 index b4fa19b3cc..0000000000 --- a/.roo/rules-issue-fixer/4_github_cli_usage.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - This mode uses the GitHub CLI (gh) for all GitHub operations. - The mode assumes the user has gh installed and authenticated. If authentication errors occur, - the mode will prompt the user to authenticate. - - Users must provide full GitHub issue URLs (e.g., https://github.com/owner/repo/issues/123) - so the mode can extract the repository information dynamically. - - - - https://github.com/[owner]/[repo]/issues/[number] - - - Owner: The organization or username - - Repo: The repository name - - Number: The issue number - - - - - Assume authenticated, handle errors gracefully - Only check authentication if a gh command fails with auth error - - - "gh: Not authenticated" - - "HTTP 401" - - "HTTP 403: Resource not accessible" - - - - - - Retrieve the issue details at the start using the REST Issues API. - Always use first to get the full issue content - gh api repos/[owner]/[repo]/issues/[issue-number] --jq '{number,title,body,state,labels,assignees,milestone,createdAt:.created_at,updatedAt:.updated_at,closedAt:.closed_at,author:.user.login}' - - - gh api repos/octocat/hello-world/issues/123 --jq '{number,title,body,state,labels,assignees,milestone,createdAt:.created_at,updatedAt:.updated_at,closedAt:.closed_at,author:.user.login}' - - - - - - Get additional context and requirements from issue comments. - Always use after viewing issue to see full discussion - gh api repos/[owner]/[repo]/issues/[issue-number]/comments --paginate --jq '.[].body' - - - gh api repos/octocat/hello-world/issues/123/comments --paginate --jq '.[].body' - - - - - - - Find recent changes to affected files - Use during codebase exploration - gh api repos/[owner]/[repo]/commits?path=[file-path]&per_page=10 - - - gh api repos/octocat/hello-world/commits?path=src/api/index.ts&per_page=10 --jq '.[].sha + " " + .[].commit.message' - - - - - - Search for code patterns on GitHub - Use to supplement local codebase_search - gh search code "[search-query]" --repo [owner]/[repo] - - - gh search code "function handleError" --repo octocat/hello-world --limit 10 - - - - - - - - Add progress updates or ask questions on issues - Use if clarification needed or to show progress - gh issue comment [issue-number] --repo [owner]/[repo] --body "[comment]" - - - gh issue comment 123 --repo octocat/hello-world --body "Working on this issue. Found the root cause in the theme detection logic." - - - - - - Find related or similar PRs - Use to understand similar changes - gh pr list --repo [owner]/[repo] --search "[search-terms]" - - - gh pr list --repo octocat/hello-world --search "dark theme" --limit 10 - - - - - - View the diff of a pull request - Use to understand changes in a PR - gh pr diff [pr-number] --repo [owner]/[repo] - - - gh pr diff 456 --repo octocat/hello-world - - - - - - - - Inspect associations with GitHub Projects (new Projects experience) for a given issue - Use when project context is relevant to understanding priority, ownership, or workflow - gh api graphql -f query=' -query($owner:String!, $repo:String!, $number:Int!) { - repository(owner:$owner, name:$repo) { - issue(number:$number) { - projectsV2(first:20) { - nodes { - title - url - } - } - } - } -} -' -F owner=[owner] -F repo=[repo] -F number=[issue-number] - - This uses the projectsV2 field from the new GitHub Projects experience for issue-level project context. - - - - - - - Create a pull request - Use in step 11 after user approval - - - Target the repository from the provided URL - - Use "main" as the base branch unless specified otherwise - - Include issue number in PR title - - Use --maintainer-can-modify flag - - gh pr create --repo [owner]/[repo] --base main --title "[title]" --body "[body]" --maintainer-can-modify - - - gh pr create --repo octocat/hello-world --base main --title "fix: Resolve dark theme button visibility (#123)" --body "## Description - -Fixes #123 - -[Full PR description]" --maintainer-can-modify - - - - If working from a fork, ensure the fork is set as the remote and push the branch there first. - The gh CLI will automatically handle the fork workflow. - - - - - Fork the repository if user doesn't have push access - Use if user needs to work from a fork - gh repo fork [owner]/[repo] --clone - - - gh repo fork octocat/hello-world --clone - - - - - - Monitor CI/CD checks on a pull request - Use after creating PR to ensure checks pass - gh pr checks [pr-number] --repo [owner]/[repo] --watch - - - gh pr checks 789 --repo octocat/hello-world --watch - - - - - - - - Access GitHub API directly for advanced operations - Use when specific gh commands don't provide needed functionality - - - - gh api repos/[owner]/[repo] --jq '.default_branch' - - - - - gh api repos/[owner]/[repo]/contents/README.md --jq '.content' | base64 -d - - - - - gh api repos/[owner]/[repo]/actions/runs --jq '.workflow_runs[0:5] | .[] | .id, .status, .conclusion' - - - - - - Check GitHub Actions workflow status - Use to monitor CI/CD pipeline - gh run list --repo [owner]/[repo] --limit 5 - - - gh run list --repo octocat/hello-world --limit 5 - - - - - - - - gh: Not authenticated. Run 'gh auth login' to authenticate. - - Ask user to authenticate: - - GitHub CLI is not authenticated. Please run 'gh auth login' in your terminal to authenticate, then let me know when you're ready to continue. - - I've authenticated, please continue - I need help with authentication - Let's use a different approach - - - - - - - HTTP 403: Resource not accessible by integration - - Check if working from a fork is needed: - - gh repo fork [owner]/[repo] --clone - - - - - \ No newline at end of file diff --git a/.roo/rules-issue-fixer/5_pull_request_workflow.xml b/.roo/rules-issue-fixer/5_pull_request_workflow.xml deleted file mode 100644 index aaba5dea4b..0000000000 --- a/.roo/rules-issue-fixer/5_pull_request_workflow.xml +++ /dev/null @@ -1,52 +0,0 @@ - - - 1. Ensure all changes are committed with proper message format - 2. Push to appropriate branch (fork or direct) - 3. Prepare comprehensive PR description - 4. Get user approval before creating PR - 5. Extract owner and repo from the provided GitHub URL - - - - - Bug fixes: "fix: [description] (#[issue-number])" - - Features: "feat: [description] (#[issue-number])" - - Follow conventional commit format - - - - Must include: - - Link to issue (Fixes #[number]) - - Detailed description of changes - - Testing performed - - Verification of acceptance criteria - - Checklist items - - Screenshots/demos if applicable - - - - Use GitHub CLI to create the pull request: - - gh pr create --repo [owner]/[repo] --base main --title "[title]" --body "[description]" --maintainer-can-modify - - - If working from a fork, ensure you've forked first: - - gh repo fork [owner]/[repo] --clone - - - The gh CLI automatically handles fork workflows. - - - - 1. Comment on original issue with PR link: - - gh issue comment [issue-number] --repo [owner]/[repo] --body "PR #[pr-number] has been created to address this issue" - - 2. Inform user of successful creation - 3. Provide next steps and tracking info - 4. Monitor PR checks: - - gh pr checks [pr-number] --repo [owner]/[repo] --watch - - - \ No newline at end of file diff --git a/.roo/rules-issue-fixer/6_testing_guidelines.xml b/.roo/rules-issue-fixer/6_testing_guidelines.xml deleted file mode 100644 index 721a89f2b9..0000000000 --- a/.roo/rules-issue-fixer/6_testing_guidelines.xml +++ /dev/null @@ -1,10 +0,0 @@ - - - Always run existing tests before making changes (baseline) - - Add tests for any new functionality - - Add regression tests for bug fixes - - Test edge cases and error conditions - - Run the full test suite before completing - - For UI changes, test in multiple themes - - Verify accessibility (keyboard navigation, screen readers) - - Test performance impact for large operations - \ No newline at end of file diff --git a/.roo/rules-issue-fixer/7_communication_style.xml b/.roo/rules-issue-fixer/7_communication_style.xml deleted file mode 100644 index a2a2ada082..0000000000 --- a/.roo/rules-issue-fixer/7_communication_style.xml +++ /dev/null @@ -1,8 +0,0 @@ - - - Be clear about what you're doing at each step - - Explain technical decisions and trade-offs - - Ask for clarification if requirements are ambiguous - - Provide regular progress updates for complex issues - - Summarize changes clearly for non-technical stakeholders - - Use issue numbers and links for reference - \ No newline at end of file diff --git a/.roo/rules-issue-fixer/8_github_communication_guidelines.xml b/.roo/rules-issue-fixer/8_github_communication_guidelines.xml deleted file mode 100644 index 627908f1f7..0000000000 --- a/.roo/rules-issue-fixer/8_github_communication_guidelines.xml +++ /dev/null @@ -1,16 +0,0 @@ - - - - Provide brief status updates when working on complex issues - - Ask specific questions if requirements are unclear - - Share findings when investigation reveals important context - - Keep progress updates factual and concise - - Example: "Found the root cause in the theme detection logic. Working on a fix that preserves backward compatibility." - - - - - Follow conventional commit format: "type: description (#issue-number)" - - Keep first line under 72 characters - - Be specific about what changed - - Example: "fix: resolve button visibility in dark theme (#123)" - - \ No newline at end of file diff --git a/.roo/rules-issue-fixer/9_pr_template.xml b/.roo/rules-issue-fixer/9_pr_template.xml deleted file mode 100644 index 4c35819b1f..0000000000 --- a/.roo/rules-issue-fixer/9_pr_template.xml +++ /dev/null @@ -1,205 +0,0 @@ - - - This file contains the official Roo Code PR template that must be used when creating pull requests. - All PRs must follow this exact format to ensure consistency and proper documentation. - - - - - The PR body must follow this exact Roo Code PR template with all required sections. - Replace placeholder content in square brackets with actual information. - - - - - - - Valid GitHub CLI commands for creating PRs with the proper template - - - - Create a PR using the filled template - - The PR body should be saved to a temporary file first, then referenced with --body-file - - - - Alternative: Create PR with inline body (for shorter content) - - Use this only if the body content doesn't contain special characters that need escaping - - - - Fork repository if user doesn't have push access - - The --clone=false flag prevents cloning since we're already in the repo - - - - - PR titles should follow conventional commit format - - fix: [brief description] (#[issue-number]) - feat: [brief description] (#[issue-number]) - docs: [brief description] (#[issue-number]) - refactor: [brief description] (#[issue-number]) - test: [brief description] (#[issue-number]) - chore: [brief description] (#[issue-number]) - - - - - How to fill in the template placeholders - - - The GitHub issue number being addressed - 123 - - - Optional Roo Code task links if used during development - https://app.roocode.com/share/task-abc123 - _No Roo Code task context for this PR_ - - - Detailed explanation of implementation approach - - - Focus on HOW you solved the problem - - Mention key design decisions - - Highlight any trade-offs made - - Point out areas needing special review attention - - - - Steps to verify the changes work correctly - - - List specific test commands run - - Describe manual testing performed - - Include steps for reviewers to reproduce tests - - Mention test environment details if relevant - - - - Visual evidence of changes for UI modifications - _No UI changes in this PR_ - - - Documentation impact assessment - - [x] No documentation updates are required. - - - Any extra context for reviewers - _No additional notes_ - - - Discord username for communication - @username - - - - \ No newline at end of file diff --git a/.roo/rules-issue-investigator/1_workflow.xml b/.roo/rules-issue-investigator/1_workflow.xml deleted file mode 100644 index 4d2528e775..0000000000 --- a/.roo/rules-issue-investigator/1_workflow.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - This mode investigates GitHub issues to find the probable root cause and suggest a theoretical solution. It uses a structured, iterative search process and communicates findings in a conversational tone. - - - - - Understand the user's request -
- The user will provide a GitHub issue URL or number. Your first step is to fetch the issue details using the `gh` CLI. -
- - gh issue view ISSUE_URL --json title,body,labels,comments - - - - Create an investigation plan -
- Based on the issue details, create a todo list to track the investigation. -
- - -[ ] Extract keywords from the issue title and body. -[ ] Perform initial codebase search with keywords. -[ ] Analyze search results and form a hypothesis. -[ ] Attempt to disprove the hypothesis. -[ ] Formulate a theoretical solution. -[ ] Draft a comment for the user. - - - ]]> - - - - - - - Systematically search the codebase to identify the root cause. This is an iterative process. - - - - Extract Keywords - Identify key terms, function names, error messages, and concepts from the issue title, body, and comments. - - - Iterative Codebase Search - Use `codebase_search` with the extracted keywords. Start broad and then narrow down your search based on the results. Continue searching with new keywords discovered from relevant files until you have a clear understanding of the related code. - - codebase_search - - - - Form a Hypothesis - Based on the search results, form a hypothesis about the probable cause of the issue. Document this hypothesis. - - - Attempt to Disprove Hypothesis - Actively try to find evidence that contradicts your hypothesis. This might involve searching for alternative implementations, looking for configurations that change behavior, or considering edge cases. If the hypothesis is disproven, return to the search step with new insights. - - - - - - Formulate a solution and prepare to communicate it. - - - Formulate Theoretical Solution - Once the hypothesis is stable, describe a potential solution. Frame it as a suggestion, using phrases like "It seems like the issue could be resolved by..." or "A possible fix would be to...". - - - Draft Comment - 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,". - - - - - - Ask the user for confirmation before posting any comments. - -I've investigated the issue and drafted a comment with my findings and a suggested solution. Would you like me to post it to the GitHub issue? - -Yes, please post the comment to the issue. -Show me the draft comment first. -No, do not post the comment. - - - ]]> - - - - - A probable cause has been identified and validated. - A theoretical solution has been proposed. - The user has decided whether to post a comment on the issue. - - \ No newline at end of file diff --git a/.roo/rules-issue-investigator/2_best_practices.xml b/.roo/rules-issue-investigator/2_best_practices.xml deleted file mode 100644 index 1445822ccd..0000000000 --- a/.roo/rules-issue-investigator/2_best_practices.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - Be Methodical - Follow the workflow steps precisely. Do not skip the hypothesis validation step. A rigorous process leads to more accurate conclusions. - Skipping steps can lead to incorrect assumptions and wasted effort. The goal is to be confident in the proposed solution. - - - Embrace Iteration - The investigation is not linear. Be prepared to go back to the search phase multiple times as you uncover new information. Each search should build on the last. - Complex issues rarely have a single, obvious cause. Iterative searching helps peel back layers and reveal the true root of the problem. - - - Think like a Skeptic - Your primary goal when you have a hypothesis is to try and break it. Actively look for evidence that you are wrong. This makes your final conclusion much stronger. - Confirmation bias is a common pitfall. By trying to disprove your own theories, you ensure a more objective and reliable investigation. - - - - - - Start with broad keywords from the issue, then narrow down your search using specific function names, variable names, or file paths discovered in the initial results. - - Initial search: "user authentication fails". Follow-up search: "getUserById invalid token". - Searching for a generic term like "error" without context. - - - - - - - Jumping to conclusions after the first search. - The first set of results might be misleading or only part of the story. - Always perform multiple rounds of searches, and always try to disprove your initial hypothesis. - - - Forgetting to use the todo list. - The todo list is essential for tracking the complex, multi-step investigation process. Without it, you can lose track of your progress and findings. - Update the todo list after each major step in the workflow. - - - - - - Have I extracted all relevant keywords from the issue? - Have I performed at least two rounds of codebase searches? - Have I genuinely tried to disprove my hypothesis? - - - Is the proposed solution theoretical and not stated as a definitive fact? - Is the explanation clear and easy to understand? - - - 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? - - - \ No newline at end of file diff --git a/.roo/rules-issue-investigator/3_common_patterns.xml b/.roo/rules-issue-investigator/3_common_patterns.xml deleted file mode 100644 index 2a17e7be72..0000000000 --- a/.roo/rules-issue-investigator/3_common_patterns.xml +++ /dev/null @@ -1,45 +0,0 @@ - - - For investigating bug reports where something is broken. - - - - - For investigating issues where the system works but not as expected. - - - - - For investigating issues related to slowness or high resource usage. - - - \ No newline at end of file diff --git a/.roo/rules-issue-investigator/4_tool_usage.xml b/.roo/rules-issue-investigator/4_tool_usage.xml deleted file mode 100644 index f34f57f5ff..0000000000 --- a/.roo/rules-issue-investigator/4_tool_usage.xml +++ /dev/null @@ -1,84 +0,0 @@ - - - - gh issue view - Always use first to get the issue context. - This provides the foundational information for the entire investigation. - - - codebase_search - For all investigation steps to find relevant code. - Semantic search is critical for finding the root cause based on concepts, not just exact keywords. - - - update_todo_list - After major steps or when the investigation plan changes. - Maintains a clear record of the investigation's state and next steps. - - - - - - - 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." - - ]]> - - - - - Extract multiple keywords from the issue. Combine them in your search query. - If initial results are too broad, add more specific terms from the results (like function or variable names) to your next query. - Use this tool iteratively. Don't rely on a single search. - - -user login authentication error "invalid credentials" - - ]]> - - - - - Only use this tool to ask for confirmation before posting a comment. - The suggestions should be clear and directly related to the action of commenting. - - -I have analyzed the issue and drafted a comment. Would you like me to post it? - -Yes, go ahead and post the comment. -Let me see the comment first before you post it. -No, do not post anything. I will handle it. - - - ]]> - - - - - - - execute_command (gh issue view) - Get issue details. - update_todo_list - Create an investigation plan. - codebase_search - Perform initial search. - read_file - Analyze relevant file contents. - codebase_search - Perform follow-up search to confirm/deny hypothesis. - ask_followup_question - Ask user to confirm before commenting. - execute_command (gh issue comment) - Post the comment if approved. - - - - \ No newline at end of file diff --git a/.roo/rules-issue-investigator/5_examples.xml b/.roo/rules-issue-investigator/5_examples.xml deleted file mode 100644 index af417e3e69..0000000000 --- a/.roo/rules-issue-investigator/5_examples.xml +++ /dev/null @@ -1,99 +0,0 @@ - - - - A user has reported a bug where they are unable to log in with valid credentials, but no error message is shown. - - - - "Please investigate issue #456. Users are reporting that they can't log in." - - - - - Fetch issue details from GitHub. - -gh issue view 456 --json title,body,comments - - ]]> - Get the title "Login fails silently" and body "Users with valid credentials are not able to log in. The page just refreshes without any error message." - - - - Create the initial investigation plan. - - -[x] Extract keywords from the issue title and body. -[-] Perform initial codebase search with keywords. -[ ] Analyze search results and form a hypothesis. -[ ] Attempt to disprove the hypothesis. -[ ] Formulate a theoretical solution. -[ ] Draft a comment for the user. - - - ]]> - - - - Perform initial codebase search using keywords "login", "authentication", "silent fail". - -user login authentication silent fail - - ]]> - The search results point to `src/auth/login.ts` as a highly relevant file. - - - - Read the contents of the relevant file. - -src/auth/login.ts - - ]]> - - The file contains a `try...catch` block in the `handleLogin` function. The `catch` block is empty, which explains the silent failure. This is the likely cause. Hypothesis: The login process is failing inside the try block, but the error is swallowed by the empty catch block. - - - - - Attempt to disprove the hypothesis by looking for other error handling mechanisms. - -global error handling middleware Express - - ]]> - No global error handling middleware seems to be in use that would override this local empty catch block. The hypothesis stands. - - - - Formulate a solution and draft a comment. - -"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." - - - - - Ask the user for confirmation before posting the comment. - -I've investigated the issue and drafted a comment with my findings and a suggested solution. Would you like me to post it to the GitHub issue? - -Yes, please post the comment to the issue. -Show me the draft comment first. -No, do not post the comment. - - - ]]> - - - - - Empty catch blocks are a strong indicator of silent failures. - Always try to disprove a hypothesis by looking for conflicting code patterns. - - - \ No newline at end of file diff --git a/.roo/rules-issue-investigator/6_communication.xml b/.roo/rules-issue-investigator/6_communication.xml deleted file mode 100644 index 6ed68c0043..0000000000 --- a/.roo/rules-issue-investigator/6_communication.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - 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 @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 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. - Keep it concise and easy to read. Avoid large blocks of text. - Use markdown for code snippets or file paths only when necessary for clarity. - - - - - What was accomplished (e.g., "Investigation complete."). - A summary of the findings and the proposed solution. - A final statement indicating that the user has been prompted on how to proceed with the comment. - - - Ending with a question. - Offers for further assistance. - - - \ No newline at end of file diff --git a/.roo/rules-issue-writer/1_workflow.xml b/.roo/rules-issue-writer/1_workflow.xml deleted file mode 100644 index 0dc2e279d2..0000000000 --- a/.roo/rules-issue-writer/1_workflow.xml +++ /dev/null @@ -1,391 +0,0 @@ - - - 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) - - - - - - - Kickoff - - 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 - - Verify we're in a Git repository and capture the GitHub remote for safe submission. - - 1) Check if inside a git repository: - - git rev-parse --is-inside-work-tree 2>/dev/null || echo "not-git-repo" - - - 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. - - - - 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$//' - - - 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) - - - - - - - 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. - - Identify whether this is a monorepo and record the search root(s). - - 1) List top-level entries: - - . - false - - - 2) Monorepo indicators: - - package.json with "workspaces" - - lerna.json, pnpm-workspace.yaml, rush.json - - Top-level directories like apps/, packages/, services/, libs/ - - 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 - - If standard repository: - - Use repository root for searches - - - - [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) - - - - - - - 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, ...). - - - - [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) - - - - - - - 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. - - - - [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) - - - - - - - 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. - - - - [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) - - - - - - - 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. - - - - [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) - - - - - - - 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. - - - - [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/3_best_practices.xml b/.roo/rules-issue-writer/3_best_practices.xml deleted file mode 100644 index b6f90c8014..0000000000 --- a/.roo/rules-issue-writer/3_best_practices.xml +++ /dev/null @@ -1,147 +0,0 @@ - - - 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. - - - - - 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 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 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. - - \ 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 deleted file mode 100644 index 4077edfb4d..0000000000 --- a/.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - 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" 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 - - - - - 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 - - - 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 - - - - - Accepting user claims that contradict the codebase without verification - Produces misleading or incorrect issue framing - - - 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 - - - - - - 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 deleted file mode 100644 index 6c19018e6c..0000000000 --- a/.roo/rules-issue-writer/5_examples.xml +++ /dev/null @@ -1,134 +0,0 @@ - - - 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-merge-resolver/1_workflow.xml b/.roo/rules-merge-resolver/1_workflow.xml deleted file mode 100644 index 2f0d1162f6..0000000000 --- a/.roo/rules-merge-resolver/1_workflow.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - This mode resolves merge conflicts for a specific pull request by analyzing git history, - commit messages, and code changes to make intelligent resolution decisions. It receives - a PR number (e.g., "#123") and handles the entire conflict resolution process. - - - - - Parse PR number from user input -
- Extract the PR number from input like "#123" or "PR #123" - Validate that a PR number was provided -
- - - - Fetch PR information - - gh pr view [PR_NUMBER] --json title,body,headRefName,baseRefName - -
- Get PR title and description to understand the intent - Identify the source and target branches -
- - - - Checkout PR branch and prepare for rebase - - 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 -
- - - - Check for merge conflicts - - git status --porcelain - git diff --name-only --diff-filter=U - -
- Identify files with merge conflicts (marked with 'UU') - Create a list of files that need resolution -
- - - - - - Analyze each conflicted file to understand the changes - - Read the conflicted file to identify conflict markers - Extract the conflicting sections between <<<<<<< and >>>>>>> - Run git blame on both sides of the conflict - Fetch commit messages and diffs for relevant commits - Analyze the intent behind each change - - - - - Determine the best resolution strategy for each conflict - - Categorize changes by intent (bugfix, feature, refactor, etc.) - Evaluate recency and relevance of changes - Check for structural overlap vs formatting differences - Identify if changes can be combined or if one should override - Consider test updates and related changes - - - - - Apply the resolution strategy to resolve conflicts - - For each conflict, apply the chosen resolution - Ensure proper escaping of conflict markers in diffs - Validate that resolved code is syntactically correct - Stage resolved files with git add - - - - - Verify the resolution and prepare for commit - - Run git status to confirm all conflicts are resolved - Check for any compilation or syntax errors - Review the final diff to ensure sensible resolutions - Prepare a summary of resolution decisions - - - - - - - gh pr checkout [PR_NUMBER] --force - Force checkout the PR branch to ensure clean state - - - - git fetch origin main - Get the latest main branch from origin - - - - GIT_EDITOR=true git rebase origin/main - Rebase current branch onto main to reveal conflicts (non-interactive) - - - - git blame -L [start_line],[end_line] [commit_sha] -- [file_path] - Get commit information for specific lines - - - - git show --format="%H%n%an%n%ae%n%ad%n%s%n%b" --no-patch [commit_sha] - Get commit metadata including message - - - - git show [commit_sha] -- [file_path] - 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 (non-interactive) - - - - - - true - Set to 'true' (a no-op command) to prevent interactive prompts during rebase operations - Prefix git rebase commands with GIT_EDITOR=true to ensure non-interactive execution - - - - - All merge conflicts have been resolved - Resolved files have been staged - No syntax errors in resolved code - Resolution decisions are documented - - \ No newline at end of file diff --git a/.roo/rules-merge-resolver/2_best_practices.xml b/.roo/rules-merge-resolver/2_best_practices.xml deleted file mode 100644 index ea6c7cc6a5..0000000000 --- a/.roo/rules-merge-resolver/2_best_practices.xml +++ /dev/null @@ -1,165 +0,0 @@ - - - - Intent-Based Resolution - - 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. - - - Code changes have purpose - bugfixes should be preserved, features - should be integrated properly, and refactors should maintain consistency. - - - Conflict between a bugfix and a refactor - Apply the bugfix logic within the refactored structure - Simply choose one side without considering both intents - - - - - Preserve All Valuable Changes - - 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 - - When using apply_diff, always escape merge - conflict markers with backslashes to prevent parsing errors. - - - - - - Consider Related Changes - - 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 that spans multiple files. - - - - - - - Bugfixes generally take precedence over features - - Bugfixes address existing problems and should be preserved, - while features can be reintegrated around the fix. - - - - - More recent changes are often more relevant - - Recent changes likely reflect the current understanding of - requirements and may supersede older implementations. - - - When older changes are bugfixes or security patches that - haven't been addressed in newer code. - - - - - Changes that include test updates are likely more complete - - Developers who update tests alongside code changes demonstrate - thoroughness and understanding of the impact. - - - - - Logic changes take precedence over formatting changes - - Formatting can be reapplied, but logic changes represent - functional improvements or fixes. - - - - - - - Blindly choosing one side without analysis - - You might lose important changes or introduce regressions - - - Always analyze both sides using git blame and commit history - - - - - Ignoring the PR description and context - - The PR description often explains the why behind changes, - which is crucial for proper resolution - - - Always fetch and read the PR information before resolving - - - - - Not validating the resolved code - - Merged code might be syntactically incorrect or introduce - logical errors - - - Always check for syntax errors and review the final diff - - - - - Not escaping conflict markers in diffs - - Unescaped conflict markers (<<<<<<, =======, >>>>>>) in SEARCH - or REPLACE sections will be interpreted as actual diff syntax, - causing the apply_diff tool to fail or produce incorrect results - - - Always escape conflict markers with a backslash (\) when they - appear in the content you're searching for or replacing. - Example: \<<<<<<< HEAD instead of <<<<<<< HEAD - - - - - - - Fetch PR title and description for context - Identify all files with conflicts - Understand the overall change being merged - - - - Run git blame on conflicting sections - Read commit messages for intent - Consider if changes can be combined - Escape conflict markers in diffs - - - - Verify no conflict markers remain - Check for syntax/compilation errors - Review the complete diff - Document resolution decisions - - - \ No newline at end of file diff --git a/.roo/rules-merge-resolver/3_tool_usage.xml b/.roo/rules-merge-resolver/3_tool_usage.xml deleted file mode 100644 index a54367f75f..0000000000 --- a/.roo/rules-merge-resolver/3_tool_usage.xml +++ /dev/null @@ -1,258 +0,0 @@ - - - - execute_command - For all git and gh CLI operations - Git commands provide the historical context needed for intelligent resolution - - - - read_file - To examine conflicted files and understand the conflict structure - Need to see the actual conflict markers and code - - - - apply_diff - To resolve conflicts by replacing conflicted sections - Precise editing of specific conflict blocks - - - - - - - Always use gh CLI for GitHub operations instead of MCP tools - Chain git commands with && for efficiency - Use --format options for structured output - Capture command output for parsing - Use GIT_EDITOR=true for non-interactive git rebase operations - Set environment variables inline to avoid prompts during automation - - - - - Get PR information - gh pr view [PR_NUMBER] --json title,body,headRefName,baseRefName - - - - Checkout PR branch - gh pr checkout [PR_NUMBER] --force - - - - Fetch latest main branch - git fetch origin main - - - - Rebase onto main to reveal conflicts - GIT_EDITOR=true git rebase origin/main - - - - Check conflict status - git status --porcelain | grep "^UU" - - - - Get blame for specific lines - git blame -L [start],[end] HEAD -- [file] | cut -d' ' -f1 - - - - Get commit message - git log -1 --format="%s%n%n%b" [commit_sha] - - - - Stage resolved file - git add [file_path] - - - - Continue rebase after resolution - GIT_EDITOR=true git rebase --continue - - - - - - - Read the entire conflicted file first to understand structure - Note line numbers of conflict markers for precise editing - Identify the pattern of conflicts (multiple vs single) - - - - <<<<<<< HEAD - Start of current branch changes - ======= - Separator between versions - >>>>>>> [branch] - End of incoming changes - - - - - - Always escape conflict markers with backslash - Include enough context to ensure unique matches - Use :start_line: for precision - Combine multiple resolutions in one diff when possible - - - -src/feature.ts - -<<<<<<< SEARCH -:start_line:45 -------- -\<<<<<<< HEAD -function oldImplementation() { - return "old"; -} -\======= -function newImplementation() { - return "new"; -} -\>>>>>>> feature-branch -======= -function mergedImplementation() { - // Combining both approaches - return "merged"; -} ->>>>>>> REPLACE - - - ]]> - - - - - - - - execute_command - Get PR info with gh CLI - execute_command - Checkout PR with gh pr checkout --force - execute_command - Fetch origin main - execute_command - Rebase onto origin/main with GIT_EDITOR=true - execute_command - Check for conflicts with git status - - - - - - execute_command - List conflicted files - read_file - Examine conflict structure - execute_command - Git blame on conflict regions - execute_command - Fetch commit messages - - - - - - read_file - Get exact conflict content - apply_diff - Replace conflict with resolution - execute_command - Stage resolved file - execute_command - Verify resolution status - - - - - - execute_command - Check all conflicts resolved - execute_command - Continue rebase with GIT_EDITOR=true git rebase --continue - execute_command - Verify clean status - - - - - - - Git commands waiting for interactive input - - Use GIT_EDITOR=true to bypass editor prompts - Set GIT_SEQUENCE_EDITOR=true for sequence editing - Consider --no-edit flag for commit operations - - - - - Rebase completes without conflicts - - Inform user that PR can be merged without conflicts - No resolution needed - - - - - A rebase is already in progress - - Check status with git status - Either continue existing rebase or abort with git rebase --abort - - - - - Conflict markers are incomplete or nested - - Use apply_diff with precise search blocks; split into multiple targeted edits if needed - Manual inspection may be required - - - - - Binary files cannot be merged automatically - - Identify which version to keep based on PR intent - Use git checkout --theirs or --ours - - - - - Code contains literal conflict marker strings - - Extra careful escaping in diffs - Prefer apply_diff with precise search blocks - - - - - - - Ensuring git operations run without requiring user interaction is critical - for automated conflict resolution. The mode uses environment variables to - bypass interactive prompts. - - - - - Set to 'true' (a no-op command) to skip editor prompts - GIT_EDITOR=true git rebase --continue - During rebase operations that would normally open an editor - - - - Skip interactive rebase todo editing - GIT_SEQUENCE_EDITOR=true git rebase -i HEAD~3 - When interactive rebase is triggered but no editing needed - - - - Use flags to avoid interactive prompts - - git commit --no-edit (use existing message) - git merge --no-edit (skip merge message editing) - git cherry-pick --no-edit (keep original message) - - - - - - Always test commands locally first to identify potential prompts - Combine environment variables when multiple editors might be invoked - Document why non-interactive mode is used in comments - Have fallback strategies if automation fails - - - \ No newline at end of file diff --git a/.roo/rules-merge-resolver/4_complete_example.xml b/.roo/rules-merge-resolver/4_complete_example.xml deleted file mode 100644 index 32b2bf344b..0000000000 --- a/.roo/rules-merge-resolver/4_complete_example.xml +++ /dev/null @@ -1,316 +0,0 @@ - - - User provides PR #123 which has merge conflicts between a bugfix branch - and a feature branch that refactored the same code. - - - - #123 - - - - - Parse PR number and fetch PR information - -gh pr view 123 --json title,body,headRefName,baseRefName - - ]]> - - - The PR is a bugfix for a memory leak issue. This context will help - prioritize preserving the fix during conflict resolution. - - - - - Checkout PR branch and prepare for rebase - -gh pr checkout 123 --force - - ]]> - - - -git fetch origin main - - ]]> - FETCH_HEAD - ]]> - - -GIT_EDITOR=true git rebase origin/main - - ]]> - ", then run "git rebase --continue". - ]]> - - - - Check for merge conflicts - -git status --porcelain | grep "^UU" - - ]]> - - - Two files have conflicts: the main processor file and its test file. - Both need to be resolved before continuing the rebase. - - - - - Examine the conflicted processor file - -src/data/processor.ts - - ]]> - = new Map(); -47 | -48 | <<<<<<< HEAD -49 | async processData(data: DataInput): Promise { -50 | // Refactored to use async/await -51 | const result = await this.transform(data); -52 | return result; -53 | } -54 | ======= -55 | processData(data: any[]): ProcessedData { -56 | const listener = this.createListener(); -57 | this.listeners.set(data.id, listener); -58 | -59 | return this.transform(data); -60 | } -61 | >>>>>>> abc123 (Fix memory leak in data processor) -62 | -63 | cleanup() { -64 | <<<<<<< HEAD -65 | // TODO: Implement cleanup -66 | ======= -67 | // Fix: Clear all listeners to prevent memory leak -68 | this.listeners.forEach(listener => { -69 | listener.removeAllListeners(); -70 | }); -71 | this.listeners.clear(); -72 | >>>>>>> abc123 (Fix memory leak in data processor) -73 | } -74 | } - ]]> - - - - Analyze the conflicts using git blame - -git blame -L 49,53 HEAD -- src/data/processor.ts | cut -d' ' -f1 | sort -u | xargs -I {} git log -1 --format="%h %s" {} - - ]]> - - - -git log -1 --format="%h %s" abc123 - - ]]> - - - - HEAD (main after rebase): Has async/await refactor but missing listener logic - Incoming (bugfix branch): Adds listener tracking and cleanup for memory leak fix - - Resolution strategy: Combine both changes - keep async/await refactor - but include the listener tracking and cleanup logic. - - - - - Resolve the conflicts - -src/data/processor.ts - -<<<<<<< SEARCH -:start_line:48 -------- -\<<<<<<< HEAD - async processData(data: DataInput): Promise { - // Refactored to use async/await - const result = await this.transform(data); - return result; - } -\======= - processData(data: any[]): ProcessedData { - const listener = this.createListener(); - this.listeners.set(data.id, listener); - - return this.transform(data); - } -\>>>>>>> abc123 (Fix memory leak in data processor) -======= - async processData(data: DataInput): Promise { - // Create and track listener for cleanup (memory leak fix) - const listener = this.createListener(); - this.listeners.set(data.id, listener); - - // Refactored to use async/await - const result = await this.transform(data); - return result; - } ->>>>>>> REPLACE - -<<<<<<< SEARCH -:start_line:63 -------- - cleanup() { -\<<<<<<< HEAD - // TODO: Implement cleanup -\======= - // Fix: Clear all listeners to prevent memory leak - this.listeners.forEach(listener => { - listener.removeAllListeners(); - }); - this.listeners.clear(); -\>>>>>>> abc123 (Fix memory leak in data processor) - } -======= - cleanup() { - // Fix: Clear all listeners to prevent memory leak - this.listeners.forEach(listener => { - listener.removeAllListeners(); - }); - this.listeners.clear(); - } ->>>>>>> REPLACE - - - ]]> - - Combined both changes: kept the async/await refactor from main - while preserving the memory leak fix (listener tracking and cleanup) - from the bugfix branch. - - - - - Resolve test file conflicts - -src/data/processor.test.ts - - ]]> - - -src/data/processor.test.ts - - - - - ]]> - - - - Stage resolved files and continue rebase - -git add src/data/processor.ts src/data/processor.test.ts - - ]]> - - -GIT_EDITOR=true git rebase --continue - - ]]> - - - - - Final validation - -git status - - ]]> - - - -git diff origin/main --stat - - ]]> - - - - - - -Successfully resolved merge conflicts for PR #123 "Fix memory leak in data processor". - -Resolution Summary: -- src/data/processor.ts: Combined the async/await refactor with the memory leak fix by preserving listener tracking and cleanup logic within the refactored async method -- src/data/processor.test.ts: Updated tests to work with the async implementation while maintaining memory leak test coverage - -Both the feature refactor and the critical bugfix have been preserved in the resolution. The rebase has been completed successfully and the branch is ready to be pushed. - - - ]]> - - - Always checkout PR with --force and rebase to reveal conflicts - Fetch PR context to understand the intent of changes - Use git blame and commit messages to understand the history - Combine non-conflicting improvements when possible - Prioritize bugfixes while accommodating refactors - Use GIT_EDITOR=true to ensure non-interactive rebase operations - Complete the rebase process with GIT_EDITOR=true git rebase --continue - Validate that both sets of changes work together - - \ No newline at end of file diff --git a/.roo/rules-merge-resolver/5_communication.xml b/.roo/rules-merge-resolver/5_communication.xml deleted file mode 100644 index 18594d5269..0000000000 --- a/.roo/rules-merge-resolver/5_communication.xml +++ /dev/null @@ -1,153 +0,0 @@ - - - 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 - - - I'll help you resolve these conflicts... - Let me handle this for you... - Don't worry about the conflicts... - - - - Analyzing PR #123 for merge conflicts... - Resolving conflicts based on commit history analysis... - Applied resolution strategy: [specific strategy] - - - - - - Acknowledge the PR number - State that you're fetching PR information - Indicate the analysis will begin - - - - Fetching information for PR #123 to understand the context and identify merge conflicts... - - - - - During each major phase of resolution - - Analyzing [X] conflicted files... - Running git blame on [file] to understand change history... - Resolving conflicts in [file] by [strategy]... - Validating resolved changes... - - - - Number of conflicts found - Files being processed - Resolution strategy being applied - - - - - Explain each significant resolution decision - Reference specific commits when relevant - Justify why certain changes were kept or merged - - - - Conflict in [file]: - - HEAD: [brief description of changes] - - Incoming: [brief description of changes] - - Resolution: [what was decided and why] - - - - - - - - Expected a PR number (e.g., "#123" or "123"). Please provide the PR number to resolve conflicts for. - - - - - - PR #[number] does not have any merge conflicts. The branch can be merged without conflict resolution. - - - - - - Could not find PR #[number]. Please verify the PR number and ensure you have access to the repository. - - - - - - Found complex conflicts in [file] that require careful analysis. Examining commit history to determine the best resolution strategy... - - - - - - - State that conflicts are resolved - Provide resolution summary - List files that were resolved - Mention key decisions made - - - - - - Questions about next steps - Offers to do additional work - Uncertain language about the resolution - - - - - Document why specific resolutions were chosen - Reference commit SHAs when they influenced decisions - Explain trade-offs when both sides had valid changes - - - - Preserved bugfix from commit abc123 while adapting it to the refactored structure from def456 - - - Combined both implementations as they addressed different aspects of the same feature - - - Chose the more recent implementation as it included additional error handling - - - - - - - - Binary file conflict in [file]. Based on PR intent "[title]", choosing [which version] version. - - - - - - Conflict: [file] was deleted in one branch but modified in another. Based on the changes, [keeping/removing] the file because [reason]. - - - - - - Conflict in [file] involves only whitespace/formatting. Applying consistent formatting from [which] branch. - - - - \ No newline at end of file diff --git a/.roo/rules-pr-fixer/1_workflow.xml b/.roo/rules-pr-fixer/1_workflow.xml deleted file mode 100644 index fb487e5fdd..0000000000 --- a/.roo/rules-pr-fixer/1_workflow.xml +++ /dev/null @@ -1,75 +0,0 @@ - - - This mode is designed to help resolve issues in existing pull requests. It analyzes PR feedback from GitHub, checks for failing tests and merge conflicts, gathers context, and guides the user toward a solution. All GitHub operations are performed using the GitHub CLI. - - - - - Understand the user's request -
- Parse the user's input to identify the pull request URL or number. Extract the repository owner and name. -
- - - Gather PR context - - gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles,comments,reviews - gh pr checks [PR_NUMBER] --repo [owner]/[repo] - Check workflow status for failing tests - gh pr view [PR_NUMBER] --repo [owner]/[repo] --json mergeable,mergeStateStatus - Check for merge conflicts - - - - - - - Analyze the gathered information to identify the core problems. - - Summarize review comments and requested changes from gh pr view output. - Identify the root cause of failing tests by analyzing workflow logs with 'gh run view'. - Determine if merge conflicts exist from mergeable status. - - - - - Synthesize the findings and present them to the user. - - Present a summary of the issues found (reviews, failing tests, conflicts). - Use ask_followup_question to ask the user how they want to proceed with fixing the issues. - - - - - Execute the user's chosen course of action. - - Check out the PR branch locally using 'gh pr checkout [PR_NUMBER] --repo [owner]/[repo] --force'. - Determine if the PR is from a fork by checking 'gh pr view [PR_NUMBER] --repo [owner]/[repo] --json isCrossRepository'. - Apply code changes based on review feedback using file editing tools. - Fix failing tests by modifying test files or source code as needed. - For conflict resolution: Delegate to merge-resolver mode using new_task with the PR number. - If changes affect user-facing content (i18n files, UI components, announcements), delegate translation updates using the new_task tool with translate mode. - Review modified files with 'git status --porcelain' to ensure no temporary files are included. - Stage files selectively using 'git add -u' (for modified tracked files) or 'git add ' (for new files). - Verify staged files with 'git diff --cached --name-only' before committing. - Commit changes using git commands with descriptive messages. - Push changes to the correct remote (origin for same-repo PRs, fork remote for cross-repo PRs) using 'git push --force-with-lease'. - - - - - Verify that the pushed changes resolve the issues. - - Use 'gh pr checks [PR_NUMBER] --repo [owner]/[repo] --watch' to monitor check status in real-time until all checks complete. - If needed, check specific workflow runs with 'gh run list --pr [PR_NUMBER] --repo [owner]/[repo]' for detailed CI/CD pipeline status. - Verify that all translation updates (if any) have been completed and committed. - Confirm PR is ready for review by checking mergeable state with 'gh pr view [PR_NUMBER] --repo [owner]/[repo] --json mergeable,mergeStateStatus'. - - - - - - All actionable review comments have been addressed. - All tests are passing. - The PR is free of merge conflicts. - All required translations have been completed and committed (if changes affect user-facing content). - - \ No newline at end of file diff --git a/.roo/rules-pr-fixer/2_best_practices.xml b/.roo/rules-pr-fixer/2_best_practices.xml deleted file mode 100644 index 2dc5775ced..0000000000 --- a/.roo/rules-pr-fixer/2_best_practices.xml +++ /dev/null @@ -1,75 +0,0 @@ - - - - Context is Key - Always gather full context before attempting a fix. This includes reading all relevant PR comments, checking CI/CD logs, and understanding the surrounding code. - Without full context, fixes may be incomplete or introduce new issues. - - - Incremental Fixes - Address issues one at a time (e.g., fix tests first, then address comments). This makes the process more manageable and easier to validate. - Tackling all issues at once can be complex and error-prone. - - - Handle Fork Remotes Correctly - Always check if a PR comes from a fork (cross-repository) before pushing changes. Use 'gh pr view --json isCrossRepository' to determine the correct remote. - Pushing to the wrong remote (e.g., origin instead of fork) will fail for cross-repository PRs. - - PR from a fork - Check isCrossRepository, add fork remote if needed, push to fork - Always push to origin without checking PR source - - - - Safe File Staging - Always review files before staging to avoid committing temporary files, build artifacts, or system files. Use selective git commands that respect .gitignore. - Committing unwanted files can expose sensitive data, clutter the repository, and cause CI/CD failures. - - Staging files for commit - Use 'git add -u' to stage only modified tracked files, or explicitly list files to add - Use 'git add .' which stages everything including temp files - - - Review git status before staging - Check for temporary files (.swp, .DS_Store, *.tmp) - Exclude build artifacts (dist/, build/, *.pyc) - Avoid IDE-specific files (.idea/, .vscode/) - Verify .gitignore is properly configured - - - - - - - Delegate merge conflict resolution to the merge-resolver mode. - - - - - - - Have all review comments been addressed? - Are all CI/CD checks passing? - Is the PR free of merge conflicts? - Have the changes been tested locally? - - - \ No newline at end of file diff --git a/.roo/rules-pr-fixer/3_common_patterns.xml b/.roo/rules-pr-fixer/3_common_patterns.xml deleted file mode 100644 index 4ef2a34b9e..0000000000 --- a/.roo/rules-pr-fixer/3_common_patterns.xml +++ /dev/null @@ -1,136 +0,0 @@ - - - A set of commands to quickly assess the state of a Pull Request. - - - - Commands to investigate why a specific test is failing. - - - - Commands to detect merge conflicts. - - - - - Delegate merge conflict resolution to the merge-resolver mode. - - - - - Check out a pull request branch locally. - - - - - Determine the correct remote to push to (handles forks). - - - - - Monitor PR checks in real-time as they run. - - - - - Push operations that handle both origin and fork remotes correctly. - - - - - Commit operations that work in automated environments while respecting .gitignore. - - - - Safely stage files for commit while avoiding temporary files and respecting .gitignore. - - - diff --git a/.roo/rules-pr-fixer/4_tool_usage.xml b/.roo/rules-pr-fixer/4_tool_usage.xml deleted file mode 100644 index d8ce7e8859..0000000000 --- a/.roo/rules-pr-fixer/4_tool_usage.xml +++ /dev/null @@ -1,156 +0,0 @@ - - - - gh pr view - Use at the start to get all review comments and PR metadata. - Provides the core context of what needs to be fixed from a human perspective. - - - gh pr checks - After getting comments, to check the technical status. - Quickly identifies if there are failing automated checks that need investigation. - - - new_task (mode: translate) - When changes affect user-facing content, i18n files, or UI components that require translation. - Ensures translation consistency across all supported languages when PR fixes involve user-facing changes. - - - gh pr checks --watch - After pushing a fix, to confirm that the changes have resolved the CI/CD failures. - Provides real-time feedback on whether the fix was successful. - - - - - - - Always fetch details with --json to get structured data: gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles,comments,reviews,mergeable,mergeStateStatus,isCrossRepository - Parse the JSON output to extract branch name, owner, repo slug, and mergeable state. - - - - - - Use gh pr view --json comments to get all comments in structured format. - Parse all comments to create a checklist of required changes. - Ignore comments that are not actionable or have been resolved. - - - - - - Use this command to get the exact error messages from failing tests. - Search the log for keywords like 'error', 'failed', or 'exception' to quickly find the root cause. - Always specify run ID explicitly to avoid interactive selection prompts: gh run view [RUN_ID] --log-failed - Get run IDs with: gh run list --pr [PR_NUMBER] --repo [owner]/[repo] - - - - - - Use --force flag: 'gh pr checkout [PR_NUMBER] --repo [owner]/[repo] --force' - If gh checkout fails, use: git fetch origin pull/[PR_NUMBER]/head:[branch_name] - - - - - - Use --force-with-lease for safer force pushing. - Use GIT_EDITOR=true to prevent interactive prompts during rebases. - Always determine the correct remote before pushing (origin vs fork). - - - Check if PR is from a fork: 'gh pr view [PR_NUMBER] --repo [owner]/[repo] --json isCrossRepository' - If isCrossRepository is true, add fork remote if needed - Push to appropriate remote: 'git push --force-with-lease [remote] [branch]' - - - Delegate to merge-resolver mode using new_task - Provide the PR number (e.g., "#123") as the message - The merge-resolver mode will handle all conflict resolution automatically - - - - - - Use --watch flag to monitor checks in real-time: 'gh pr checks [PR_NUMBER] --repo [owner]/[repo] --watch' - For one-time status checks, use --json flag: 'gh pr checks [PR_NUMBER] --repo [owner]/[repo] --json state,conclusion,name' - The --watch flag automatically updates the display as check statuses change. - Use 'gh run list --pr [PR_NUMBER] --repo [owner]/[repo]' to get detailed workflow status if needed. - - - - - - After analyzing all the problems (reviews, tests, conflicts), present a summary to the user. - Provide clear, actionable next steps as suggestions. - Example suggestions: "Address review comments first.", "Tackle the failing tests.", "Resolve merge conflicts." - - - - - - Use when PR fixes involve changes to user-facing strings, i18n files, or UI components. - Provide specific details about what content needs translation in the message. - Include file paths and descriptions of the changes made. - List all affected languages that need updates. - Wait for translation completion before proceeding to validation phase. - - - Changes to webview-ui/src/i18n/locales/en/*.json files - Changes to src/i18n/locales/en/*.json files - Modifications to UI components with user-facing text - Updates to announcement files or documentation requiring localization - Addition of new error messages or user notifications - - -translate -Translation updates needed for PR #1234 fixes. Please translate the following changes: - -Files modified: -- webview-ui/src/i18n/locales/en/common.json: Added new error message "connection_failed" -- webview-ui/src/components/settings/ApiSettings.tsx: Updated button text from "Save" to "Save Configuration" - -Please ensure all supported languages (ca, de, es, fr, hi, id, it, ja, ko, nl, pl, pt-BR, ru, tr, vi, zh-CN, zh-TW) are updated with appropriate translations for these changes. - - ]]> - - - - - Use when PR has merge conflicts that need to be resolved. - Simply provide the PR number (e.g., "#123") as the message. - The merge-resolver mode will handle checkout, rebase, conflict resolution, and pushing. - Wait for merge-resolver to complete before continuing with other PR fixes. - - - When gh pr view shows mergeable: false or mergeStateStatus: CONFLICTING - When git rebase fails with conflicts - When git status shows unmerged paths - - -merge-resolver -#1234 - - ]]> - - - - - - gh pr view [PR_NUMBER] --repo [owner]/[repo] --json [fields] - gh pr checkout [PR_NUMBER] --repo [owner]/[repo] --force - gh pr checks [PR_NUMBER] --repo [owner]/[repo] [--watch|--json] - gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body "[text]" - - - - gh run list --pr [PR_NUMBER] --repo [owner]/[repo] - gh run view [RUN_ID] --repo [owner]/[repo] --log-failed - gh workflow view [WORKFLOW_NAME] --repo [owner]/[repo] - - - \ No newline at end of file diff --git a/.roo/rules-pr-fixer/5_examples.xml b/.roo/rules-pr-fixer/5_examples.xml deleted file mode 100644 index 640e6398ad..0000000000 --- a/.roo/rules-pr-fixer/5_examples.xml +++ /dev/null @@ -1,304 +0,0 @@ - - - - A pull request has a failing CI check and a review comment asking for a change. - - - - Fix PR #4365 in RooCodeInc/Roo-Code. - - - - - Get PR details and review comments. - - -gh pr view 4365 --repo RooCodeInc/Roo-Code --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles,comments,reviews,mergeable,mergeStateStatus - - - Get the branch name, list of review comments, and check for mergeability. - - - - Check CI status. - - -gh pr checks 4365 --repo RooCodeInc/Roo-Code - - - Identify which check is failing. - - - - Get logs for the failing check. - - -gh run list --pr 4365 --repo RooCodeInc/Roo-Code - - - Get the run ID of the failing workflow. - - - - View the failed logs. - - -gh run view [run_id] --repo RooCodeInc/Roo-Code --log-failed - - - Find the specific error message causing the test to fail. - - - - Check out the pull request branch. - - - gh pr checkout 4365 --repo RooCodeInc/Roo-Code --force - - - The PR branch is now ready for local edits. - - - - Summarize findings and ask the user for the next action. - - -I've checked out the branch. I've found a failing test related to 'XYZ' and a review comment asking to rename a variable. How should we proceed? - -First, apply the change requested in the review comment. -Let's start by fixing the failing test. -Show me the code for the failing test and the file with the requested change. - - - - - - After pushing the changes, monitor PR checks in real-time. - - - gh pr checks 4365 --repo RooCodeInc/Roo-Code --watch - - - Monitor checks continuously until all complete. The --watch flag provides real-time updates as check statuses change. - - - - - Always gather all information before proposing a solution. - Use the GitHub CLI to get a complete picture of the PR's status. - The --watch flag on gh pr checks provides real-time monitoring of CI status. - - - - - - A pull request has review comments requesting UI text changes that require translation updates across all supported languages. - - - - Fix PR #1234 in RooCodeInc/Roo-Code - the reviewer asked to change button text and there are some failing tests. - - - - - Get PR details and analyze changes. - - -gh pr view 1234 --repo RooCodeInc/Roo-Code --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles,comments,reviews - - - Identify the files changed and review feedback requiring UI text modifications. - - - - Check out PR and apply the requested changes. - - -gh pr checkout 1234 --repo RooCodeInc/Roo-Code --force - - - Make the requested button text changes in the UI components. - - - - Identify translation requirements and delegate to translate mode. - - -translate -Translation updates needed for PR #1234 fixes. The following changes were made based on review feedback: - -Files modified: -- webview-ui/src/components/settings/ApiSettings.tsx: Changed button text from "Save" to "Save Configuration" -- webview-ui/src/i18n/locales/en/common.json: Updated key "save_button" to "save_config_button" - -Please update all supported languages (ca, de, es, fr, hi, id, it, ja, ko, nl, pl, pt-BR, ru, tr, vi, zh-CN, zh-TW) with appropriate translations for: -- New key "save_config_button" with translation equivalent to "Save Configuration" -- Any other text changes that affect user-facing content - -Ensure consistency across all language files and maintain the same context and tone as existing translations. - - - Translation subtask created and all language files updated. - - - - Review and commit changes including translations. - - -git status --porcelain - - - Review the list of modified files to ensure only intended changes are present. - - - - Stage only the intended files for commit. - - -git add -u && git commit -m "fix: update button text and translations as requested in review" - - - Using 'git add -u' stages only modified tracked files, avoiding any temporary files. - - - - Check if PR is from a fork and push to correct remote. - - -gh pr view 1234 --repo RooCodeInc/Roo-Code --json isCrossRepository,headRepositoryOwner,headRefName - - - Determine if this is a cross-repository PR to know which remote to push to. - - - - Push changes to the appropriate remote. - - -git push --force-with-lease origin [branch_name] - - - Push changes safely to update the pull request. Use 'fork' remote instead if PR is from a fork. - - - - Monitor CI status in real-time. - - -gh pr checks 1234 --repo RooCodeInc/Roo-Code --watch - - - Watch CI checks continuously until all tests pass. The --watch flag provides automatic updates as check statuses change. - - - - - Always check if PR fixes involve user-facing content that requires translation. - Use new_task with translate mode to ensure consistent translation updates. - Include detailed context about what changed and why in translation requests. - Verify translation completeness before considering the PR fix complete. - Use gh pr view --json to get structured data about PR properties. - - - - - - A pull request has merge conflicts that need to be resolved before other fixes can be applied. - - - - Fix PR #5678 in RooCodeInc/Roo-Code - it has merge conflicts and failing tests. - - - - - Get PR details and check merge status. - - -gh pr view 5678 --repo RooCodeInc/Roo-Code --json number,title,author,state,body,url,headRefName,baseRefName,mergeable,mergeStateStatus - - - Identify that mergeable is false and mergeStateStatus is CONFLICTING. - - - - Delegate merge conflict resolution to merge-resolver mode. - - -merge-resolver -#5678 - - - The merge-resolver mode will handle checkout, rebase, conflict resolution, and pushing the resolved changes. - - - - After merge-resolver completes, check PR status again. - - -gh pr view 5678 --repo RooCodeInc/Roo-Code --json mergeable,mergeStateStatus - - - Verify that the PR is now mergeable after conflict resolution. - - - - Check CI status for any remaining failures. - - -gh pr checks 5678 --repo RooCodeInc/Roo-Code - - - Identify any tests that are still failing after the merge conflict resolution. - - - - If tests are still failing, proceed with fixing them. - - -gh pr checkout 5678 --repo RooCodeInc/Roo-Code --force - - - Now that conflicts are resolved, we can focus on fixing the failing tests. - - - - Apply test fixes and push changes. - - -git add -u && git commit -m "fix: resolve failing tests after merge conflict resolution" - - - Commit the test fixes separately from the merge conflict resolution. - - - - Push changes and monitor CI status. - - -git push --force-with-lease origin [branch_name] - - - Push the test fixes to update the PR. - - - - Monitor CI checks in real-time. - - -gh pr checks 5678 --repo RooCodeInc/Roo-Code --watch - - - Watch CI checks continuously until all tests pass. - - - - - Always check for merge conflicts before attempting other fixes. - Delegate merge conflict resolution to the specialized merge-resolver mode. - The merge-resolver mode handles the entire conflict resolution workflow including pushing. - After conflict resolution, continue with other PR fixes like failing tests. - Keep conflict resolution commits separate from other fix commits for clarity. - - - diff --git a/.roo/rules-translate/001-general-rules.md b/.roo/rules-translate/001-general-rules.md deleted file mode 100644 index e27b9793e2..0000000000 --- a/.roo/rules-translate/001-general-rules.md +++ /dev/null @@ -1,106 +0,0 @@ -# 1. SUPPORTED LANGUAGES AND LOCATION - -- Localize all strings into the following locale files: ca, de, en, es, fr, hi, id, it, ja, ko, nl, pl, pt-BR, ru, tr, vi, zh-CN, zh-TW -- The VSCode extension has two main areas that require localization: - - Core Extension: src/i18n/locales/ (extension backend) - - WebView UI: webview-ui/src/i18n/locales/ (user interface) - -# 2. VOICE, STYLE AND TONE - -- Always use informal speech (e.g., "du" instead of "Sie" in German) for all translations -- Maintain a direct and concise style that mirrors the tone of the original text -- Carefully account for colloquialisms and idiomatic expressions in both source and target languages -- Aim for culturally relevant and meaningful translations rather than literal translations -- Preserve the personality and voice of the original content -- Use natural-sounding language that feels native to speakers of the target language -- Don't translate the word "token" as it means something specific in English that all languages will understand -- Don't translate domain-specific words (especially technical terms like "Prompt") that are commonly used in English in the target language - -# 3. CORE EXTENSION LOCALIZATION (src/) - -- Located in src/i18n/locales/ -- NOT ALL strings in core source need internationalization - only user-facing messages -- Internal error messages, debugging logs, and developer-facing messages should remain in English -- The t() function is used with namespaces like 'core:errors.missingToolParameter' -- Be careful when modifying interpolation variables; they must remain consistent across all translations -- Some strings in formatResponse.ts are intentionally not internationalized since they're internal -- When updating strings in core.json, maintain all existing interpolation variables -- Check string usages in the codebase before making changes to ensure you're not breaking functionality - -# 4. WEBVIEW UI LOCALIZATION (webview-ui/src/) - -- Located in webview-ui/src/i18n/locales/ -- Uses standard React i18next patterns with the useTranslation hook -- All user interface strings should be internationalized -- Always use the Trans component with named components for text with embedded components - - example: - -`"changeSettings": "You can always change this at the bottom of the settings",` - -``` - - }} - /> -``` - -# 5. TECHNICAL IMPLEMENTATION - -- Use namespaces to organize translations logically -- Handle pluralization using i18next's built-in capabilities -- Implement proper interpolation for variables using {{variable}} syntax -- Don't include defaultValue. The `en` translations are the fallback -- Always use apply_diff instead of write_to_file when editing existing translation files (much faster and more reliable) -- When using apply_diff, carefully identify the exact JSON structure to edit to avoid syntax errors -- Placeholders (like {{variable}}) must remain exactly identical to the English source to maintain code integration and prevent syntax errors - -# 6. WORKFLOW AND APPROACH - -- First add or modify English strings, then ask for confirmation before translating to all other languages -- Use this process for each localization task: - 1. Identify where the string appears in the UI/codebase - 2. Understand the context and purpose of the string - 3. Update English translation first - 4. Use the `` tool to find JSON keys that are near new keys in English translations but do not yet exist in the other language files for `` SEARCH context - 5. Create appropriate translations for all other supported languages utilizing the `search_files` result using `` without reading every file. - 6. Do not output the translated text into the chat, just modify the files. - 7. Validate your changes with the missing translations script -- Flag or comment if an English source string is incomplete ("please see this...") to avoid truncated or unclear translations -- For UI elements, distinguish between: - - Button labels: Use short imperative commands ("Save", "Cancel") - - Tooltip text: Can be slightly more descriptive -- Preserve the original perspective: If text is a user command directed at the software, ensure the translation maintains this direction, avoiding language that makes it sound like an instruction from the system to the user - -# 7. COMMON PITFALLS TO AVOID - -- Switching between formal and informal addressing styles - always stay informal ("du" not "Sie") -- Translating or altering technical terms and brand names that should remain in English -- Modifying or removing placeholders like {{variable}} - these must remain identical -- Translating domain-specific terms that are commonly used in English in the target language -- Changing the meaning or nuance of instructions or error messages -- Forgetting to maintain consistent terminology throughout the translation - -# 8. QUALITY ASSURANCE - -- Maintain consistent terminology across all translations -- Respect the JSON structure of translation files -- Watch for placeholders and preserve them in translations -- Be mindful of text length in UI elements when translating to languages that might require more characters -- Use context-aware translations when the same string has different meanings -- Always validate your translation work by running the missing translations script: - ``` - node scripts/find-missing-translations.js - ``` -- Address any missing translations identified by the script to ensure complete coverage across all locales - -# 9. TRANSLATOR'S CHECKLIST - -- ✓ Used informal tone consistently ("du" not "Sie") -- ✓ Preserved all placeholders exactly as in the English source -- ✓ Maintained consistent terminology with existing translations -- ✓ Kept technical terms and brand names unchanged where appropriate -- ✓ Preserved the original perspective (user→system vs system→user) -- ✓ Adapted the text appropriately for UI context (buttons vs tooltips) diff --git a/.roo/rules-translate/instructions-de.md b/.roo/rules-translate/instructions-de.md deleted file mode 100644 index 1268424832..0000000000 --- a/.roo/rules-translate/instructions-de.md +++ /dev/null @@ -1,14 +0,0 @@ -# German (de) Translation Guidelines - -**Key Rule:** Always use informal speech ("du" form) in all German translations without exception. - -## Quick Reference - -| Category | Formal (Avoid) | Informal (Use) | Example | -| ----------- | ------------------------- | ------------------- | ----------------- | -| Pronouns | Sie | du | you | -| Possessives | Ihr/Ihre/Ihrem | dein/deine/deinem | your | -| Verbs | können Sie, müssen Sie | kannst du, musst du | you can, you must | -| Imperatives | Geben Sie ein, Wählen Sie | Gib ein, Wähle | Enter, Choose | - -**Technical terms** like "API", "token", "prompt" should not be translated. diff --git a/.roo/rules-translate/instructions-zh-cn.md b/.roo/rules-translate/instructions-zh-cn.md deleted file mode 100644 index b166a1e6a8..0000000000 --- a/.roo/rules-translate/instructions-zh-cn.md +++ /dev/null @@ -1,277 +0,0 @@ -# Simplified Chinese (zh-CN) Translation Guidelines - -## Key Terminology - -| English Term | Preferred (zh-CN) | Avoid | Context/Notes | -| --------------------- | ----------------- | ------------ | ------------- | -| API Cost | API 费用 | API 成本 | 财务相关术语 | -| Tokens | Token | Tokens/令牌 | 保留抽象术语 | -| Token Usage | Token 使用量 | Token 用量 | 技术计量单位 | -| Cache | 缓存 | 高速缓存 | 简洁优先 | -| Context | 上下文 | | 保留抽象术语 | -| Context Menu | 右键菜单 | 上下文菜单 | 技术术语准确 | -| Context Window | 上下文窗口 | | 技术术语准确 | -| Proceed While Running | 强制继续 | 运行时继续 | 操作命令 | -| Enhance Prompt | 增强提示词 | 优化提示 | AI相关功能 | -| Auto-approve | 自动批准 | 始终批准 | 权限相关术语 | -| Checkpoint | 存档点 | 检查点/快照 | 技术概念统一 | -| MCP Server | MCP 服务 | MCP 服务器 | 技术组件 | -| Network Timeout | 请求超时 | 网络超时 | 更准确描述 | -| Terminal | 终端 | 命令行 | 技术术语统一 | -| diff | 差异更新 | 差分/补丁 | 代码变更 | -| prompt caching | 提示词缓存 | 提示缓存 | AI功能 | -| computer use | 计算机交互 | 计算机使用 | 技术能力 | -| rate limit | API 请求频率限制 | 速率限制 | API控制 | -| Browser Session | 浏览器会话 | 浏览器进程 | 技术概念 | -| Run Command | 运行命令 | 执行命令 | 操作动词 | -| power steering mode | 增强导向模式 | 动力转向模式 | 避免直译 | -| Boomerang Tasks | 任务拆分 | 回旋镖任务 | 避免直译 | - -## Formatting Rules - -1. **中英文混排** - - - 添加空格：在中文和英文/数字之间添加空格，如"API 费用"（不是"API费用"） - - 单位格式：时间单位统一为"15秒"、"1分钟"（不是"15 seconds"、"1 minute"） - - 数字范围："已使用: {{used}} / {{total}}" - - 技术符号保留原样："{{amount}} tokens"→"{{amount}}" - -2. **标点符号** - - - 使用中文全角标点 - - 列表项使用中文顿号："创建、编辑文件" - -3. **UI文本优化** - - - 按钮文本：使用简洁动词，如"展开"优于"查看更多" - - 操作说明：使用步骤式说明（1. 2. 3.）替代长段落 - - 错误提示：使用"确认删除？此操作不可逆"替代"Are you sure...?" - - 操作说明要简洁："Shift+拖拽文件"优于长描述 - - 按钮文本控制在2-4个汉字："展开"优于"查看更多" - -4. **技术描述** - - - 保留英文缩写：如"MCP"不翻译 - - 统一术语：整个系统中相同概念使用相同译法 - - 长句拆分为短句 - - 被动语态转为主动语态 - - 功能名称统一："计算机交互"优于"计算机使用" - - 参数说明："差异更新"优于"差分/补丁" - -5. **变量占位符** - - 保持原格式：`{{variable}}` - - 中文说明放在变量外："Token 使用量: {{used}}" - -## UI Element Translation Standards - -1. **按钮(Buttons)** - - - 确认类：确定/取消/应用/保存 - - 操作类：添加/删除/编辑/导出 - - 状态类：启用/禁用/展开/收起 - - 长度限制：2-4个汉字 - -2. **菜单(Menus)** - - - 主菜单：文件/编辑/视图/帮助 - - 子菜单：使用">"连接，如"文件>打开" - - 快捷键：保留英文，如"Ctrl+S" - -3. **标签(Labels)** - - - 设置项：描述功能，如"自动保存间隔" - - 状态提示：简洁明确，如"正在处理..." - - 单位说明：放在括号内，如"超时时间(秒)" - -4. **工具提示(Tooltips)** - - - 功能说明：简洁描述，如"复制选中内容" - - 操作指引：步骤明确，如"双击编辑单元格" - - 长度限制：不超过50个汉字 - -5. **对话框(Dialogs)** - - 标题：说明对话框用途 - - 正文：分段落说明 - - 按钮：使用动词，如"确认删除" - -## Contextual Translation Principles - -1. **根据UI位置调整** - - - 按钮文本：简洁动词 (如"展开", "收起") - - 设置项：描述性 (如"自动批准写入操作") - - 帮助文本：完整说明 (如"开启后自动创建任务存档点，方便回溯修改") - -2. **技术文档风格** - - - 使用主动语态：如"自动创建和编辑文件" - - 避免口语化表达 - - 复杂功能使用分点说明 - - 说明操作结果：如"无需二次确认" - - 参数说明清晰：如"延迟一段时间再自动批准写入" - -3. **品牌/产品名称** - - - 保留英文品牌名 - - 技术术语保持一致性 - - 保留英文专有名词：如"Amazon Bedrock ARN" - -4. **用户操作** - - 操作动词统一： - - "Click"→"点击" - - "Type"→"输入" - - "Scroll"→"滚动" - - 按钮状态： - - "Enabled"→"已启用" - - "Disabled"→"已禁用" - -## Technical Documentation Guidelines - -1. **技术术语** - - - 统一使用"Token"而非"令牌" - - 保留英文专有名词：如"Model Context Protocol" - - 功能名称统一：如"计算机功能调用"优于"计算机使用" - -2. **API文档** - - - 端点(Endpoint)：保留原始路径 - - 参数说明：表格形式展示 - - 示例：保留代码格式 - - 参数标签： - - 单位明确：如"最大输出 Token 数" - - 范围说明完整：如"模型可以处理的总 Token 数" - -3. **代码相关翻译** - - - 代码注释： - - 保留技术术语：如"// Initialize MCP client" - - 简短说明：如"检查文件是否存在" - - 错误信息： - - 包含错误代码：如"Error 404: 文件未找到" - - 提供解决方案：如"请检查文件权限" - - 命令行： - - 保留原生命令：如"git commit -m 'message'" - - 参数说明：如"-v: 显示详细输出" - -4. **配置指南** - - 设置项命名：如"Enable prompt caching"→"启用提示词缓存" - - 价格描述： - - 单位统一：如"每百万 Token 的成本" - - 说明影响：如"这会影响生成内容和补全的成本" - - 操作说明： - - 使用编号步骤：如"1. 注册Google Cloud账号" - - 步骤动词一致：如"安装配置Google Cloud CLI工具" - -## Common Patterns - -```markdown -<<<<<<< BEFORE -"dragFiles": "按住shift拖动文件" -======= -"dragFiles": "Shift+拖拽文件" - -> > > > > > > AFTER - -<<<<<<< BEFORE -"description": "启用后，Roo 将能够与 MCP 服务器交互以获取高级功能。" -======= -"description": "启用后 Roo 可与 MCP 服务交互获取高级功能。" - -> > > > > > > AFTER - -<<<<<<< BEFORE -"cannotUndo": "此操作无法撤消。" -======= -"cannotUndo": "此操作不可逆。" - -> > > > > > > AFTER - -<<<<<<< BEFORE -"hold shift to drag in files" → "按住shift拖动文件" -======= -"hold shift to drag in files" → "Shift+拖拽文件" - -> > > > > > > AFTER - -<<<<<<< BEFORE -"Double click to edit" → "双击进行编辑" -======= -"Double click to edit" → "双击编辑" - -> > > > > > > AFTER -``` - -## Common Pitfalls - -1. 避免过度直译导致生硬 - - - ✗ "Do more with Boomerang Tasks" → "使用回旋镖任务完成更多工作" - - ✓ "Do more with Boomerang Tasks" → "允许任务拆分" - -2. 保持功能描述准确 - - - ✗ "Enhance prompt with additional context" → "使用附加上下文增强提示" - - ✓ "Enhance prompt with additional context" → "增强提示词" - -3. 操作指引清晰 - - - ✗ "hold shift to drag in files" → "按住shift拖动文件" - - ✓ "hold shift to drag in files" → "Shift+拖拽文件" - -4. 确保术语一致性 - - - ✗ 同一文档中混用"Token"/"令牌"/"代币" - - ✓ 统一使用"Token"作为技术术语 - -5. 注意文化适应性 - - - ✗ "Kill the process" → "杀死进程"(过于暴力) - - ✓ "Kill the process" → "终止进程" - -6. 技术文档特殊处理 - - 代码示例中的注释： - ✗ 翻译后破坏代码结构 - ✓ 保持代码注释原样或仅翻译说明部分 - - 命令行参数： - ✗ 翻译参数名称导致无法使用 - ✓ 保持参数名称英文，仅翻译说明 - -## Best Practices - -1. **翻译工作流程** - - - 通读全文理解上下文 - - 标记并统一技术术语 - - 分段翻译并检查一致性 - - 最终整体审校 - -2. **质量检查要点** - - - 术语一致性 - - 功能描述准确性 - - UI元素长度适配性 - - 文化适应性 - -3. **工具使用建议** - - - 建立项目术语库 - - 使用翻译记忆工具 - - 维护风格指南 - - 定期更新翻译资源 - -4. **审校流程** - - 初翻 → 技术审校 → 语言润色 → 最终确认 - - 重点关注技术准确性、语言流畅度和UI显示效果 - -## Quality Checklist - -1. 术语是否全文一致？ -2. 是否符合中文技术文档习惯？ -3. UI控件文本是否简洁明确？ -4. 长句是否已合理拆分？ -5. 变量占位符是否保留原格式？ -6. 技术描述是否准确无误？ -7. 文化表达是否恰当？ -8. 是否保持了原文的精确含义？ -9. 特殊格式(如变量、代码)是否正确保留？ diff --git a/.roo/rules-translate/instructions-zh-tw.md b/.roo/rules-translate/instructions-zh-tw.md deleted file mode 100644 index ee4d07a07a..0000000000 --- a/.roo/rules-translate/instructions-zh-tw.md +++ /dev/null @@ -1,18 +0,0 @@ -# Traditional Chinese (zh-TW) Translation Guidelines - -## Key Terminology - -| English Term | Use (zh-TW) | Avoid (Mainland) | -| ------------- | ----------- | ---------------- | -| file | 檔案 | 文件 | -| task | 工作 | 任務 | -| project | 專案 | 項目 | -| configuration | 設定 | 配置 | -| server | 伺服器 | 服務器 | -| import/export | 匯入/匯出 | 導入/導出 | - -## Formatting Rules - -- Add spaces between Chinese and English/numbers: "AI 驅動" (not "AI驅動") -- Use Traditional Chinese quotation marks: 「範例文字」(not "範例文字") -- Use Taiwanese computing conventions rather than mainland terminology diff --git a/.roo/rules/rules.md b/.roo/rules/rules.md deleted file mode 100644 index 5726770a28..0000000000 --- a/.roo/rules/rules.md +++ /dev/null @@ -1,24 +0,0 @@ -# Code Quality Rules - -1. Test Coverage: - - - Before attempting completion, always make sure that any code changes have test coverage - - Ensure all tests pass before submitting changes - - The vitest framework is used for testing; the `vi`, `describe`, `test`, `it`, etc functions are defined by default in `tsconfig.json` and therefore don't need to be imported from `vitest` - - Tests must be run from the same directory as the `package.json` file that specifies `vitest` in `devDependencies` - - Run tests with: `npx vitest run ` - - Do NOT run tests from project root - this causes "vitest: command not found" error - - Tests must be run from inside the correct workspace: - - Backend tests: `cd src && npx vitest run path/to/test-file` (don't include `src/` in path) - - UI tests: `cd webview-ui && npx vitest run src/path/to/test-file` - - Example: For `src/tests/user.test.ts`, run `cd src && npx vitest run tests/user.test.ts` NOT `npx vitest run src/tests/user.test.ts` - -2. Lint Rules: - - - Never disable any lint rules without explicit user approval - -3. Styling Guidelines: - - - Use Tailwind CSS classes instead of inline style objects for new markup - - VSCode CSS variables must be added to webview-ui/src/index.css before using them in Tailwind classes - - Example: `
` instead of style objects diff --git a/.roo/skills/evals-context/SKILL.md b/.roo/skills/evals-context/SKILL.md deleted file mode 100644 index 985b788b94..0000000000 --- a/.roo/skills/evals-context/SKILL.md +++ /dev/null @@ -1,188 +0,0 @@ ---- -name: evals-context -description: Provides context about the Roo Code evals system structure in this monorepo. Use when tasks mention "evals", "evaluation", "eval runs", "eval exercises", or working with the evals infrastructure. Helps distinguish between the evals execution system (packages/evals, apps/web-evals) and the public website evals display page (apps/web-roo-code/src/app/evals). ---- - -# Evals Codebase Context - -## When to Use This Skill - -Use this skill when the task involves: - -- Modifying or debugging the evals execution infrastructure -- Adding new eval exercises or languages -- Working with the evals web interface (apps/web-evals) -- Modifying the public evals display page on roocode.com -- Understanding where evals code lives in this monorepo - -## When NOT to Use This Skill - -Do NOT use this skill when: - -- Working on unrelated parts of the codebase (extension, webview-ui, etc.) -- The task is purely about the VS Code extension's core functionality -- Working on the main website pages that don't involve evals - -## Key Disambiguation: Two "Evals" Locations - -This monorepo has **two distinct evals-related locations** that can cause confusion: - -| Component | Path | Purpose | -| --------------------------- | -------------------------------------------------------------- | -------------------------------------------------------------- | -| **Evals Execution System** | `packages/evals/` | Core eval infrastructure: CLI, DB schema, Docker configs | -| **Evals Management UI** | `apps/web-evals/` | Next.js app for creating/monitoring eval runs (localhost:3446) | -| **Website Evals Page** | `apps/web-roo-code/src/app/evals/` | Public roocode.com page displaying eval results | -| **External Exercises Repo** | [Roo-Code-Evals](https://github.com/RooCodeInc/Roo-Code-Evals) | Actual coding exercises (NOT in this monorepo) | - -## Directory Structure Reference - -### `packages/evals/` - Core Evals Package - -``` -packages/evals/ -├── ARCHITECTURE.md # Detailed architecture documentation -├── ADDING-EVALS.md # Guide for adding new exercises/languages -├── README.md # Setup and running instructions -├── docker-compose.yml # Container orchestration -├── Dockerfile.runner # Runner container definition -├── Dockerfile.web # Web app container -├── drizzle.config.ts # Database ORM config -├── src/ -│ ├── index.ts # Package exports -│ ├── cli/ # CLI commands for running evals -│ │ ├── runEvals.ts # Orchestrates complete eval runs -│ │ ├── runTask.ts # Executes individual tasks in containers -│ │ ├── runUnitTest.ts # Validates task completion via tests -│ │ └── redis.ts # Redis pub/sub integration -│ ├── db/ -│ │ ├── schema.ts # Database schema (runs, tasks) -│ │ ├── queries/ # Database query functions -│ │ └── migrations/ # SQL migrations -│ └── exercises/ -│ └── index.ts # Exercise loading utilities -└── scripts/ - └── setup.sh # Local macOS setup script -``` - -### `apps/web-evals/` - Evals Management Web App - -``` -apps/web-evals/ -├── src/ -│ ├── app/ -│ │ ├── page.tsx # Home page (runs list) -│ │ ├── runs/ -│ │ │ ├── new/ # Create new eval run -│ │ │ └── [id]/ # View specific run status -│ │ └── api/runs/ # SSE streaming endpoint -│ ├── actions/ # Server actions -│ │ ├── runs.ts # Run CRUD operations -│ │ ├── tasks.ts # Task queries -│ │ ├── exercises.ts # Exercise listing -│ │ └── heartbeat.ts # Controller health checks -│ ├── hooks/ # React hooks (SSE, models, etc.) -│ └── lib/ # Utilities and schemas -``` - -### `apps/web-roo-code/src/app/evals/` - Public Website Evals Page - -``` -apps/web-roo-code/src/app/evals/ -├── page.tsx # Fetches and displays public eval results -├── evals.tsx # Main evals display component -├── plot.tsx # Visualization component -└── types.ts # EvalRun type (extends packages/evals types) -``` - -This page **displays** eval results on the public roocode.com website. It imports types from `@roo-code/evals` but does NOT run evals. - -## Architecture Overview - -The evals system is a distributed evaluation platform that runs AI coding tasks in isolated VS Code environments: - -``` -┌─────────────────────────────────────────────────────────────┐ -│ Web App (apps/web-evals) ──────────────────────────────── │ -│ │ │ -│ ▼ │ -│ PostgreSQL ◄────► Controller Container │ -│ │ │ │ -│ ▼ ▼ │ -│ Redis ◄───► Runner Containers (1-25 parallel) │ -└─────────────────────────────────────────────────────────────┘ -``` - -**Key components:** - -- **Controller**: Orchestrates eval runs, spawns runners, manages task queue (p-queue) -- **Runner**: Isolated Docker container with VS Code + Roo Code extension + language runtimes -- **Redis**: Pub/sub for real-time events (NOT task queuing) -- **PostgreSQL**: Stores runs, tasks, metrics - -## Common Tasks Quick Reference - -### Adding a New Eval Exercise - -1. Add exercise to [Roo-Code-Evals](https://github.com/RooCodeInc/Roo-Code-Evals) repo (external) -2. See [`packages/evals/ADDING-EVALS.md`](packages/evals/ADDING-EVALS.md) for structure - -### Modifying Eval CLI Behavior - -Edit files in [`packages/evals/src/cli/`](packages/evals/src/cli/): - -- [`runEvals.ts`](packages/evals/src/cli/runEvals.ts) - Run orchestration -- [`runTask.ts`](packages/evals/src/cli/runTask.ts) - Task execution -- [`runUnitTest.ts`](packages/evals/src/cli/runUnitTest.ts) - Test validation - -### Modifying the Evals Web Interface - -Edit files in [`apps/web-evals/src/`](apps/web-evals/src/): - -- [`app/runs/new/new-run.tsx`](apps/web-evals/src/app/runs/new/new-run.tsx) - New run form -- [`actions/runs.ts`](apps/web-evals/src/actions/runs.ts) - Run server actions - -### Modifying the Public Evals Display Page - -Edit files in [`apps/web-roo-code/src/app/evals/`](apps/web-roo-code/src/app/evals/): - -- [`evals.tsx`](apps/web-roo-code/src/app/evals/evals.tsx) - Display component -- [`plot.tsx`](apps/web-roo-code/src/app/evals/plot.tsx) - Charts - -### Database Schema Changes - -1. Edit [`packages/evals/src/db/schema.ts`](packages/evals/src/db/schema.ts) -2. Generate migration: `cd packages/evals && pnpm drizzle-kit generate` -3. Apply migration: `pnpm drizzle-kit migrate` - -## Running Evals Locally - -```bash -# From repo root -pnpm evals - -# Opens web UI at http://localhost:3446 -``` - -**Ports (defaults):** - -- PostgreSQL: 5433 -- Redis: 6380 -- Web: 3446 - -## Testing - -```bash -# packages/evals tests -cd packages/evals && npx vitest run - -# apps/web-evals tests -cd apps/web-evals && npx vitest run -``` - -## Key Types/Exports from `@roo-code/evals` - -The package exports are defined in [`packages/evals/src/index.ts`](packages/evals/src/index.ts): - -- Database queries: `getRuns`, `getTasks`, `getTaskMetrics`, etc. -- Schema types: `Run`, `Task`, `TaskMetrics` -- Used by both `apps/web-evals` and `apps/web-roo-code` diff --git a/.roo/skills/roo-conflict-resolution/SKILL.md b/.roo/skills/roo-conflict-resolution/SKILL.md deleted file mode 100644 index 7b123a8107..0000000000 --- a/.roo/skills/roo-conflict-resolution/SKILL.md +++ /dev/null @@ -1,256 +0,0 @@ ---- -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 deleted file mode 100644 index 2660e39ba9..0000000000 --- a/.roo/skills/roo-translation/SKILL.md +++ /dev/null @@ -1,151 +0,0 @@ ---- -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