scriptoriumadmin/Roo-Code
1
0
Fork 0
mirror of https://github.com/RooVetGit/Roo-Code.git synced 2026-09-06 08:18:39 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge branch 'RooCodeInc:main' into main

Browse source
This commit is contained in:
Murilo Pires 2025-07-04 22:19:37 -03:00 • committed by GitHub
commit bcbf329af5
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
56 changed files with 3876 additions and 539 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

213
.roo/rules-issue-fixer-orchestrator/10_pr_template_format.xml Normal file
View file

@ -0,0 +1,213 @@
<pr_template_format>
<overview>
This document defines the format for PR messages that are saved to the temp folder
before creating a pull request. The PR message is saved in two formats:
1. JSON format in pr_summary.json (for programmatic use)
2. Markdown format in pr_message.md (for manual PR creation)
The PR message must follow the exact Roo Code contribution template.
</overview>
<json_format>
<description>
The pr_summary.json file contains the PR title and body in a structured format
that can be easily parsed by scripts and the GitHub CLI.
</description>
<structure>
{
"title": "fix: [description] (#[issue-number])",
"body": "[Full markdown body as described below]",
"issue_number": 123,
"repo_owner": "owner",
"repo_name": "repo",
"base_branch": "main",
"head_branch": "fix/issue-123-description"
}
</structure>
</json_format>
<markdown_format>
<description>
The pr_message.md file contains the complete PR message in a format that can be
directly copied and pasted when creating a PR manually.
</description>
<structure>
PR Title: [title from JSON]
---
[Full PR body from JSON]
</structure>
</markdown_format>
<pr_body_template>
<description>
The PR body must follow this exact Roo Code PR template with all required sections.
</description>
<template><![CDATA[
<!--
Thank you for contributing to Roo Code!
Before submitting your PR, please ensure:
- It's linked to an approved GitHub Issue.
- You've reviewed our [Contributing Guidelines](../CONTRIBUTING.md).
-->
### Related GitHub Issue
<!-- Every PR MUST be linked to an approved issue. -->
Closes: #[ISSUE_NUMBER] <!-- Replace with the issue number, e.g., Closes: #123 -->
### Roo Code Task Context (Optional)
<!--
If you used Roo Code to help create this PR, you can share public task links here.
This helps reviewers understand your development process and provides additional context.
Example: https://app.roocode.com/share/task-id
-->
[TASK_CONTEXT]
### Description
<!--
Briefly summarize the changes in this PR and how they address the linked issue.
The issue should cover the "what" and "why"; this section should focus on:
- The "how": key implementation details, design choices, or trade-offs made.
- Anything specific reviewers should pay attention to in this PR.
-->
[DESCRIPTION_CONTENT]
### Test Procedure
<!--
Detail the steps to test your changes. This helps reviewers verify your work.
- How did you test this specific implementation? (e.g., unit tests, manual testing steps)
- How can reviewers reproduce your tests or verify the fix/feature?
- Include relevant testing environment details if applicable.
-->
[TEST_PROCEDURE_CONTENT]
### Pre-Submission Checklist
<!-- Go through this checklist before marking your PR as ready for review. -->
- [x] **Issue Linked**: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
- [x] **Scope**: My changes are focused on the linked issue (one major feature/fix per PR).
- [x] **Self-Review**: I have performed a thorough self-review of my code.
- [x] **Testing**: New and/or updated tests have been added to cover my changes (if applicable).
- [x] **Documentation Impact**: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
- [x] **Contribution Guidelines**: I have read and agree to the [Contributor Guidelines](/CONTRIBUTING.md).
### Screenshots / Videos
<!--
For UI changes, please provide before-and-after screenshots or a short video of the *actual results*.
This greatly helps in understanding the visual impact of your changes.
-->
[SCREENSHOTS_CONTENT]
### Documentation Updates
<!--
Does this PR necessitate updates to user-facing documentation?
- [ ] No documentation updates are required.
- [ ] Yes, documentation updates are required. (Please describe what needs to be updated or link to a PR in the docs repository).
-->
[DOCUMENTATION_UPDATES_CONTENT]
### Additional Notes
<!-- Add any other context, questions, or information for reviewers here. -->
[ADDITIONAL_NOTES_CONTENT]
### Get in Touch
<!--
Please provide your Discord username for reviewers or maintainers to reach you if they have questions about your PR
-->
[DISCORD_USERNAME]
]]></template>
</pr_body_template>
<template_placeholders>
<placeholder name="[ISSUE_NUMBER]">The GitHub issue number being fixed</placeholder>
<placeholder name="[TASK_CONTEXT]">Optional Roo Code task links (remove section if not applicable)</placeholder>
<placeholder name="[DESCRIPTION_CONTENT]">
Summary of changes and implementation details. Should include:
- Key implementation details
- Design choices or trade-offs made
- Specific areas reviewers should focus on
</placeholder>
<placeholder name="[TEST_PROCEDURE_CONTENT]">
Detailed testing steps including:
- Unit tests added/modified
- Manual testing steps performed
- How reviewers can reproduce tests
- Testing environment details
</placeholder>
<placeholder name="[SCREENSHOTS_CONTENT]">
For UI changes: before/after screenshots or video
For non-UI changes: "N/A - No UI changes"
</placeholder>
<placeholder name="[DOCUMENTATION_UPDATES_CONTENT]">
Check appropriate box:
- "- [x] No documentation updates are required." OR
- "- [x] Yes, documentation updates are required. [describe updates]"
</placeholder>
<placeholder name="[ADDITIONAL_NOTES_CONTENT]">
Any additional context, or remove entire section if not needed
</placeholder>
<placeholder name="[DISCORD_USERNAME]">User's Discord username for contact</placeholder>
</template_placeholders>
<file_locations>
<file>
<name>pr_summary.json</name>
<path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json</path>
<purpose>Structured data for programmatic PR creation</purpose>
</file>
<file>
<name>pr_message.md</name>
<path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md</path>
<purpose>Human-readable format for manual PR creation</purpose>
</file>
</file_locations>
<usage_guidelines>
<guideline>
Always save both formats when preparing a PR to give users flexibility
in how they create the pull request.
</guideline>
<guideline>
The pr_message.md file should be self-contained and ready to copy/paste
without any additional formatting needed.
</guideline>
<guideline>
Include all sections in the template, maintaining the exact format
and HTML comments as shown.
</guideline>
<guideline>
Pre-check all checklist items that can be verified programmatically.
Leave documentation checkbox unchecked for user to decide.
</guideline>
<guideline>
For sections that don't apply, use appropriate placeholder text
rather than removing the section entirely.
</guideline>
</usage_guidelines>
<translation_handling>
<note>
If translations were added during the issue fix, include details in the
Description section about which languages were updated.
</note>
</translation_handling>
</pr_template_format>

351
.roo/rules-issue-fixer-orchestrator/1_Workflow.xml
View file

@ -347,32 +347,59 @@
<message>
**Task: Prepare Pull Request Title and Body**
You are an expert at writing clear and concise pull request summaries.
You are an expert at writing clear and concise pull request summaries following the Roo Code contribution guidelines.
**Context Files:**
- **Issue**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json`
- **Plan**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md`
- **Verification**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/verification_results.md`
- **Translation Summary** (if exists): `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/translation_summary.md`
- **Modified Files**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json`
**Your Task:**
1. **Read all context files.** Check if translation_summary.md exists to know if translations were done.
2. **Generate a PR Title**: Create a conventional commit style title (e.g., "fix: ...", "feat: ...") that references the issue number.
3. **Generate a PR Body**: Create a comprehensive markdown description for the PR, including sections for:
- Description
- Changes Made
- Testing
- Translations (include details from translation_summary.md if it exists)
- Verification of Acceptance Criteria
- Checklist
4. **Save as JSON**: Save the title and body to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json` in the format: `{"title": "...", "body": "..."}`.
Format: `fix: Brief description (#issue-number)`
3. **Generate a PR Body**: You MUST use the exact PR template from `.roo/rules-issue-fixer-orchestrator/10_pr_template_format.xml`.
Read this file to get the template and fill it in with appropriate content from the context files.
4. **Fill in the template** with information from the context files:
- Replace [ISSUE_NUMBER] with the actual issue number
- Fill in Description with implementation details from the plan and verification
- Fill in Test Procedure with testing details from verification_results.md
- If translations were done, mention them in the Description section
- For UI changes, note that screenshots should be added manually
- Pre-check all applicable checklist items
- Leave Documentation Updates unchecked for user to decide
- For Discord username, use a placeholder like "[Your Discord username]"
**Important**: If translations were done (translation_summary.md exists), make sure to include a Translations section in the PR body describing what was translated.
5. **Save as JSON**: Save the title and body to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json` in the format:
```json
{
"title": "fix: Brief description (#123)",
"body": "[The complete filled PR body template]",
"issue_number": 123,
"repo_owner": "owner",
"repo_name": "repo",
"base_branch": "main",
"head_branch": "fix/issue-123-description"
}
```
6. **Also save as Markdown**: Save just the PR body to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md` for easy copying.
**Important Notes:**
- Use the EXACT template format from 10_pr_template_format.xml
- Keep all HTML comments in the template
- Pre-check items that can be verified programmatically
- Fill in all sections appropriately based on the context files
**Completion Protocol:**
- This is your only task. Do not deviate.
- Upon successfully saving `pr_summary.json`, you MUST use the `attempt_completion` tool.
- The `result` MUST be a concise confirmation, e.g., "PR summary created and saved to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json."
- Upon successfully saving both `pr_summary.json` and `pr_message.md`, you MUST use the `attempt_completion` tool.
- The `result` MUST be a concise confirmation, e.g., "PR summary and message created and saved to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/"
- These instructions override any conflicting mode-specific guidelines.
</message>
</new_task>
@ -560,53 +587,287 @@
</step>
<step number="10">
<name>Prepare Branch and Present PR Template</name>
<name>Prepare Branch and Review Changes</name>
<instructions>
This step prepares the branch and commits, then presents the PR template to the user for confirmation before creating the actual pull request.
This step prepares the branch, reviews the changes, and gets user confirmation before committing.
1. Read Issue Context for Issue Number:
Use read_file to get the issue context from .roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json
1. Read Issue Context and PR Summary:
- Read issue context from .roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json
- Read PR summary from .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json
2. Git Operations - Create branch and commit changes:
- Create a new branch: feat/issue-[number] or fix/issue-[number]
- Selectively add only the applicable files to the git stage
- Commit the staged changes
- Push the new branch to the remote repository
Use execute_command with:
BRANCH_NAME="fix/issue-[issue_number]-solution"
2. Create Branch:
Extract issue number from context and create appropriate branch:
<execute_command>
<command>
# Extract issue number from context
ISSUE_NUM=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json | jq -r '.number')
# Determine branch type based on labels or title
BRANCH_NAME="fix/issue-${ISSUE_NUM}-solution"
git checkout -b $BRANCH_NAME
cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json | jq -r '.[]' | xargs git add
git commit -m "[PR Title]"
git push -u origin $BRANCH_NAME
</command>
</execute_command>
3. Present PR Template - Instead of creating the PR automatically, present the standardized PR template to the user:
Use ask_followup_question to ask: "The branch has been created and changes have been committed. I have prepared a standardized PR template for this issue. Would you like me to create the pull request using the standard Roo Code PR template, or would you prefer to make changes first?"
3. Review Files to be Committed:
a. Read the modified files list:
<read_file>
<path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json</path>
</read_file>
Provide these options:
- Yes, create the pull request with the standard template
- No, I want to make changes to the implementation first
- No, I want to customize the PR template before creating it
- Cancel the task
b. Check git status to ensure only intended files are staged:
<execute_command>
<command>git status --porcelain</command>
</execute_command>
c. Stage only the files from modified_files.json:
<execute_command>
<command>
# Stage only the files we actually modified
cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json | jq -r '.[]' | while read file; do
if [ -f "$file" ]; then
git add "$file"
fi
done
# Show what will be committed
git status --short
</command>
</execute_command>
4. Handle User Decision:
If user chooses to create the PR: Use gh CLI to create the pull request with the standard template
If user chooses to make changes: Launch a rework subtask using new_task with code mode
If user wants to customize the template: Ask for their preferred PR title and body
4. Generate and Save Merge Diff:
<execute_command>
<command>
# Generate diff of staged changes
git diff --cached > .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes.diff
# Count lines in diff
LINE_COUNT=$(wc -l < .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes.diff)
echo "Diff contains $LINE_COUNT lines"
# If diff is too large, create a summary instead
if [ $LINE_COUNT -gt 2000 ]; then
echo "Creating summary due to large diff size..."
git diff --cached --stat > .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes_summary.txt
git diff --cached --name-status >> .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes_summary.txt
echo -e "\n\nNote: Full diff exceeds 2000 lines. Showing summary only." >> .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes_summary.txt
fi
</command>
</execute_command>
5. Link to Issue - After PR creation, comment on the original issue with the PR link using gh issue comment
5. Save PR Message to File:
Read the PR summary and save the formatted PR message:
<execute_command>
<command>
# Extract title and body from pr_summary.json
PR_TITLE=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json | jq -r '.title')
PR_BODY=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json | jq -r '.body')
# Save PR message to file
echo "PR Title: $PR_TITLE" > .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md
echo -e "\n---\n" >> .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md
echo "$PR_BODY" >> .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md
echo "PR message saved to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md"
</command>
</execute_command>
6. Present Changes for User Confirmation:
Read the diff (or summary) and PR message, then ask for confirmation:
a. Read the appropriate diff file:
<read_file>
<path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes.diff</path>
</read_file>
OR (if summary exists):
<read_file>
<path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes_summary.txt</path>
</read_file>
b. Read the PR message:
<read_file>
<path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md</path>
</read_file>
c. Ask for user confirmation:
<ask_followup_question>
<question>
I've prepared the changes for commit. Here's what will be included:
**Files to be committed:**
[List files from modified_files.json]
**Changes summary:**
[Include diff or summary content]
**Proposed PR message:**
[Include PR message content]
How would you like to proceed?
</question>
<follow_up>
<suggest>Looks good, go ahead and commit the changes</suggest>
<suggest>I tested the changes, and something is wrong - let me explain...</suggest>
<suggest>I still need to test the changes manually before committing</suggest>
<suggest>I want to modify the PR message before proceeding</suggest>
<suggest>Cancel this task</suggest>
</follow_up>
</ask_followup_question>
7. Handle User Decision:
Based on user response:
**If "Looks good, go ahead and commit":**
- Proceed to commit and push:
<execute_command>
<command>
# Get PR title for commit message
PR_TITLE=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json | jq -r '.title')
git commit -m "$PR_TITLE"
git push -u origin $(git branch --show-current)
</command>
</execute_command>
- Continue to next step
**If "something is wrong":**
- Ask for details about the issue
- Launch a fix subtask in code mode to address the problems
- Return to Step 5 (Verify and Test) after fixes
**If "need to test manually":**
- Inform user that changes are staged but not committed
- Provide instructions for testing
- Wait for user to confirm testing is complete
**If "modify PR message":**
- Ask for the new PR title and body
- Update pr_summary.json with new content
- Return to step 5 of this workflow
**If "cancel":**
- Clean up staged changes and branch
- End workflow
</instructions>
</step>
<step number="11">
<name>Monitor PR Checks and Cleanup</name>
<name>Finalize and Create PR</name>
<instructions>
After creating the PR (if created), monitor the CI checks and then clean up the temporary files.
After user confirmation and successful commit, finalize the process.
1. Verify Push Success:
<execute_command>
<command>
# Verify the branch was pushed
git branch -r | grep $(git branch --show-current)
# Get the remote URL for PR creation
git remote get-url origin
</command>
</execute_command>
2. Present Final PR Creation Options:
<ask_followup_question>
<question>
The changes have been committed and pushed to the branch. The PR message has been saved to:
`.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md`
You can now:
1. Create the PR manually using the saved message
2. Let me create the PR automatically
3. Make additional changes before creating the PR
What would you like to do?
</question>
<follow_up>
<suggest>Create the PR automatically using the saved message</suggest>
<suggest>I'll create the PR manually - just show me the branch name</suggest>
<suggest>I want to make more changes first</suggest>
</follow_up>
</ask_followup_question>
3. Handle Final Decision:
**If "Create PR automatically":**
- Read PR details and create:
<execute_command>
<command>
# Extract PR details
PR_TITLE=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json | jq -r '.title')
PR_BODY=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json | jq -r '.body')
ISSUE_NUM=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json | jq -r '.number')
# Create PR
gh pr create --title "$PR_TITLE" --body "$PR_BODY" --base main
# Get PR number and link to issue
PR_NUM=$(gh pr list --head $(git branch --show-current) --json number -q '.[0].number')
gh issue comment $ISSUE_NUM --body "PR #$PR_NUM has been created to address this issue."
</command>
</execute_command>
**If "Create manually":**
- Show branch name and location of PR message:
<execute_command>
<command>
echo "Branch name: $(git branch --show-current)"
echo "PR message saved at: .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md"
echo "You can copy the PR message from the file above when creating the PR."
</command>
</execute_command>
**If "Make more changes":**
- Inform user they can continue working on the branch
- Provide the task directory location for reference
4. Cleanup:
Ask if user wants to clean up the temporary files:
<ask_followup_question>
<question>
Would you like me to clean up the temporary task files now, or keep them for reference?
</question>
<follow_up>
<suggest>Yes, clean up the temporary files</suggest>
<suggest>No, keep the files for now</suggest>
</follow_up>
</ask_followup_question>
If yes, clean up:
<execute_command>
<command>rm -rf .roo/temp/issue-fixer-orchestrator/[TASK_ID]</command>
</execute_command>
</instructions>
</step>
<step number="12">
<name>Monitor PR (Optional)</name>
<instructions>
If a PR was created automatically, offer to monitor its status.
1. Check if PR exists:
<execute_command>
<command>
# Check if there's a PR for the current branch
BRANCH=$(git branch --show-current)
gh pr list --head $BRANCH --json number,state,checks
</command>
</execute_command>
2. If PR exists, offer monitoring:
<ask_followup_question>
<question>
Would you like me to monitor the PR checks and CI status?
</question>
<follow_up>
<suggest>Yes, monitor the PR checks</suggest>
<suggest>No, I'll check it myself</suggest>
</follow_up>
</ask_followup_question>
3. If user wants monitoring:
<execute_command>
<command>
PR_NUM=$(gh pr list --head $(git branch --show-current) --json number -q '.[0].number')
echo "Monitoring PR #$PR_NUM checks..."
gh pr checks $PR_NUM --watch
</command>
</execute_command>
1. Monitor Checks - Use gh pr checks with --watch to monitor CI status in real-time
2. Report Status - Inform the user of the final status of the checks
3. Cleanup - Remove the temporary task directory using rm -rf .roo/temp/issue-fixer-orchestrator/[TASK_ID]
This concludes the orchestration workflow.
</instructions>
</step>

40
.roo/rules-issue-fixer-orchestrator/2_best_practices.xml
View file

@ -24,6 +24,46 @@
- Adding translations to all supported language files
- Ensuring consistency with existing terminology
- Maintaining sync across all language resources
<commit_and_pr_best_practices>
<principle>Always verify files before committing</principle>
<guidelines>
- Review git status to ensure only intended files are staged
- Stage only files listed in modified_files.json
- Never commit unrelated changes or temporary files
- Always get user confirmation before committing
</guidelines>
<diff_management>
- Save full diff to staged_changes.diff for review
- If diff exceeds 2000 lines, create a summary instead
- Summary should include file stats and change types
- Always inform user when showing summary vs full diff
</diff_management>
<pr_message_handling>
- Save PR message in both JSON and Markdown formats
- pr_summary.json for programmatic use
- pr_message.md for manual PR creation
- Include all standard template sections
- Make PR message self-contained and ready to use
</pr_message_handling>
<user_confirmation_flow>
- Always ask for confirmation with clear options
- First option should be "Looks good, go ahead"
- Provide options for testing and issue reporting
- Allow PR message modification before proceeding
- Handle each user response appropriately
</user_confirmation_flow>
<temp_file_management>
- All delegated tasks must save outputs to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/
- Keep all context files until user confirms cleanup
- Offer cleanup option after PR creation
- Never delete files without user permission
</temp_file_management>
</commit_and_pr_best_practices>
<codebase_exploration_guidelines>
<principle>Always use `codebase_search` FIRST to understand the codebase structure and find all related files before using other tools like `read_file`.</principle>

17
.roo/rules-issue-fixer-orchestrator/3_common_patterns.xml
View file

@ -18,4 +18,21 @@
7. Add comprehensive tests
8. Update documentation
</feature_implementation_pattern>
<commit_and_pr_pattern>
1. Review git status to identify all changes
2. Stage only files from modified_files.json
3. Generate diff for review (full or summary based on size)
4. Create PR message and save to temp directory
5. Present changes to user for confirmation
6. Handle user response:
- If approved: commit and proceed to PR options
- If issues found: return to implementation
- If manual testing needed: wait for user
7. After commit, offer PR creation options:
- Create PR automatically
- Save PR message for manual creation
- Skip PR creation
8. Optionally monitor PR and offer cleanup
</commit_and_pr_pattern>
</common_patterns>

16
.roo/rules-issue-fixer-orchestrator/7_communication_style.xml
View file

@ -8,4 +8,20 @@
- Inform the user when delegating to translate mode
- Include translation status in progress updates
- Mention in PR description if translations were added
<pre_commit_communication>
- Clearly list all files that will be committed
- Explain when showing a summary vs full diff (>2000 lines)
- Provide file statistics for large diffs
- Mention that PR message has been saved to temp directory
- Offer clear options for user to proceed or report issues
</pre_commit_communication>
<post_commit_communication>
- Confirm successful commit with commit hash
- Explain PR creation options clearly
- Mention that PR message is saved and ready to use
- Provide path to PR message file for manual creation
- Offer cleanup option after PR is created
</post_commit_communication>
</communication_style>

771
.roo/rules-pr-fixer-orchestrator/1_Workflow.xml Normal file
View file

@ -0,0 +1,771 @@
<workflow>
<step number="1">
<name>Initialize PR Context</name>
<instructions>
The user will provide a GitHub PR URL or number.
1. **Parse Input**: Extract the `owner`, `repo`, and `pr_number` from the URL or use provided number.
2. **Create Task Directory**: Create a dedicated directory to store all context for this PR fix task.
<execute_command>
<command>mkdir -p .roo/temp/pr-fixer-orchestrator/[TASK_ID]</command>
</execute_command>
3. **Retrieve PR Details**: Fetch the PR details, comments, and check status as a comprehensive JSON object.
<execute_command>
<command>gh pr view [pr_number] --repo [owner]/[repo] --json number,title,body,state,labels,author,headRefName,baseRefName,mergeable,mergeStateStatus,isDraft,isCrossRepository,headRepositoryOwner,reviews,statusCheckRollup,comments > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_context.json</command>
</execute_command>
4. **Get Review Comments**: Fetch detailed review comments separately for better analysis.
<execute_command>
<command>gh pr view [pr_number] --repo [owner]/[repo] --comments > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_comments.txt</command>
</execute_command>
5. **Check CI Status**: Get current check status and any failing workflows.
<execute_command>
<command>gh pr checks [pr_number] --repo [owner]/[repo] --json name,state,conclusion,detailsUrl > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_checks.json</command>
</execute_command>
6. **Get Associated Issue**: Check if PR is linked to an issue and fetch issue details if available.
<execute_command>
<command>gh pr view [pr_number] --repo [owner]/[repo] --json closingIssuesReferences > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/linked_issues.json</command>
</execute_command>
If linked issues exist, fetch the first issue's details:
<execute_command>
<command>gh issue view [issue_number] --repo [owner]/[repo] --json number,title,body,state,labels,assignees,milestone,createdAt,updatedAt,closedAt,author,comments > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/issue_context.json</command>
</execute_command>
7. **Handle Auth Errors**: If any `gh` command fails with authentication error, prompt the user to log in.
8. **Confirm Context**: Inform the user that the PR context has been gathered.
</instructions>
</step>
<step number="2">
<name>Checkout PR Branch and Initial Analysis</name>
<instructions>
Before delegating analysis, ensure the PR branch is checked out locally.
1. **Checkout PR Branch**: Use gh to checkout the PR branch locally.
<execute_command>
<command>gh pr checkout [pr_number] --repo [owner]/[repo] --force</command>
</execute_command>
2. **Determine Remote Type**: Check if this is a cross-repository PR (from a fork).
<execute_command>
<command>gh pr view [pr_number] --repo [owner]/[repo] --json isCrossRepository,headRepositoryOwner,headRefName > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_remote_info.json</command>
</execute_command>
3. **Setup Fork Remote if Needed**: If it's a cross-repository PR, ensure fork remote is configured.
Read the pr_remote_info.json file. If isCrossRepository is true:
<execute_command>
<command>git remote add fork https://github.com/[headRepositoryOwner]/[repo].git || git remote set-url fork https://github.com/[headRepositoryOwner]/[repo].git</command>
</execute_command>
4. **Fetch Latest Main**: Ensure we have the latest main branch for comparison.
<execute_command>
<command>git fetch origin main</command>
</execute_command>
5. **Check for Conflicts**: Determine if there are merge conflicts with main.
<execute_command>
<command>git merge-tree $(git merge-base HEAD origin/main) HEAD origin/main > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/merge_conflicts.txt</command>
</execute_command>
6. **Get PR Diff**: Fetch the files changed in this PR for context.
<execute_command>
<command>gh pr diff [pr_number] --repo [owner]/[repo] --name-only > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_changed_files.txt</command>
</execute_command>
7. **Check Merge Diff Size**: Get the full diff and check line count.
<execute_command>
<command>git diff origin/main...HEAD > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/full_merge_diff.txt</command>
</execute_command>
<execute_command>
<command>wc -l .roo/temp/pr-fixer-orchestrator/[TASK_ID]/full_merge_diff.txt</command>
</execute_command>
If the diff has over 2000 lines, create a summary instead:
<execute_command>
<command>git diff origin/main...HEAD --stat > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/merge_diff_summary.txt</command>
</execute_command>
<execute_command>
<command>rm .roo/temp/pr-fixer-orchestrator/[TASK_ID]/full_merge_diff.txt</command>
</execute_command>
</instructions>
</step>
<step number="3">
<name>Delegate: Comprehensive Requirements and PR Analysis</name>
<instructions>
Launch a subtask in `architect` mode to perform a detailed analysis of the PR, its underlying requirements, and all issues that need to be addressed.
The context files in `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/` will be the input for this subtask.
The subtask should write its findings to: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_analysis_report.md`.
<new_task>
<mode>architect</mode>
<message>
**Task: Analyze Pull Request Requirements and Create Comprehensive Fix Plan**
You are an expert software architect. Your task is to analyze a pull request, understand its underlying requirements, and create a comprehensive plan to address all issues.
1. **Read PR Context**: The PR details are in:
- `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_context.json` - Full PR metadata
- `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_comments.txt` - Review comments
- `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_checks.json` - CI/CD check status
- `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/merge_conflicts.txt` - Conflict analysis
- `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_changed_files.txt` - Files changed in PR
- `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/linked_issues.json` - Associated issues (if any)
- `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/issue_context.json` - Issue details (if linked)
- `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/full_merge_diff.txt` OR `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/merge_diff_summary.txt` - Diff information
2. **Understand the PR's Purpose**:
- Extract the feature or bug being addressed from PR title, body, and linked issues
- Identify the acceptance criteria (from PR description or linked issue)
- Understand the intended functionality and expected behavior
- Note any design decisions or architectural choices made
3. **Perform Architectural Analysis**:
- **Map Component Interactions**: Trace the complete data flow for the PR's changes
- **Identify Paired Operations**: For any operation (e.g., export), find its counterpart (e.g., import)
- **Find Similar Patterns**: Search for existing implementations of similar features
- **Analyze Dependencies**: Identify all consumers of the functionality being modified
- **Assess Impact**: Determine how changes affect other parts of the system
4. **Explore Codebase Systematically**:
- Use `codebase_search` FIRST to understand the feature area
- Search for related functionality that might be affected
- Find all files that consume or depend on the changed functionality
- Identify configuration files, tests, and documentation that need updates
- Study similar features to understand established patterns
5. **Analyze Review Feedback**:
- Categorize review comments by type (bug, enhancement, style, etc.)
- Identify which comments are actionable vs informational
- Prioritize changes based on reviewer authority and importance
- Note any conflicting feedback that needs clarification
6. **Investigate Failing Tests**:
- For each failing check, determine the root cause
- Use `gh run view --log-failed` to get detailed error logs
- Identify if failures are due to code issues, flaky tests, or environment problems
- Determine which files need modification to fix test failures
7. **Assess Merge Conflicts**:
- Analyze the merge_conflicts.txt file
- Identify which files have conflicts
- Determine the complexity of conflict resolution
- Plan the rebase/merge strategy
8. **Create Comprehensive Fix Plan**: The plan must include:
- **PR Purpose Summary**: Clear description of what the PR is trying to achieve
- **Requirements Analysis**:
- Original requirements from issue or PR description
- Acceptance criteria that must be met
- Any missing functionality that needs to be added
- **Architectural Context**:
- Data flow diagram showing component interactions
- List of paired operations that must be updated together
- Dependencies and consumers of the affected functionality
- **Issue Summary**: Clear categorization of all issues found
- **Priority Order**: Which issues to tackle first and why
- **Review Feedback Analysis**:
- List of all actionable review comments
- Specific code changes required for each
- Any clarifications needed from reviewers
- **Test Failure Resolution**:
- Root cause of each failing test
- Files and changes needed to fix
- Any test updates required
- **Conflict Resolution Strategy**:
- Whether to rebase or merge
- Order of operations for conflict resolution
- Risk assessment of conflicts
- **Implementation Steps**:
- Detailed, ordered steps for fixing all issues
- Specific commands and file modifications
- Validation steps after each change
- **Risk Assessment**:
- Potential side effects of changes
- Areas requiring extra testing
- Backward compatibility concerns
9. **Save the Analysis**: Write the complete analysis to `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_analysis_report.md`.
**Critical Requirements:**
- Always understand the PR's underlying purpose before analyzing issues
- Be thorough in analyzing all aspects of the PR
- Consider the interaction between different fixes
- Provide specific, actionable steps
- Include exact commands where applicable
- **IMPORTANT**: Save your analysis to the specified file in .roo/temp/pr-fixer-orchestrator/[TASK_ID]/
**Completion Protocol:**
- This is your only task. Do not deviate from these instructions.
- Once you have successfully written the analysis report, you MUST signal completion by using the `attempt_completion` tool.
- The `result` parameter MUST be: "PR analysis complete and saved to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_analysis_report.md"
</message>
</new_task>
After launching the subtask, wait for it to complete. The orchestrator will then read the analysis report to proceed.
</instructions>
</step>
<step number="4">
<name>Review Analysis and Get User Approval</name>
<instructions>
After the analysis subtask completes, present the findings to the user for approval.
1. **Read the Analysis Report**:
<read_file>
<args>
<file>
<path>.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_analysis_report.md</path>
</file>
</args>
</read_file>
2. **Present for Approval**: Show the analysis to the user and ask how to proceed.
<ask_followup_question>
<question>
I've completed the analysis of PR #[pr_number]. Here's what I found:
---
[Insert content of pr_analysis_report.md here]
---
How would you like to proceed with fixing these issues?
</question>
<follow_up>
<suggest>Fix all issues in the recommended priority order</suggest>
<suggest>Only fix the review comments, skip failing tests for now</suggest>
<suggest>Only fix failing tests and conflicts, skip review comments</suggest>
<suggest>Let me choose specific issues to fix</suggest>
</follow_up>
</ask_followup_question>
3. **Handle User Choice**: Based on the user's selection, prepare the implementation scope.
Save the user's choice to `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/implementation_scope.txt`
</instructions>
</step>
<step number="5">
<name>Fetch Latest from Main and Check Differences</name>
<instructions>
Before implementing fixes, ensure we're working with the latest code and understand what has changed.
1. **Fetch Latest Changes**:
<execute_command>
<command>git fetch origin main</command>
</execute_command>
2. **Analyze Differences**: Create a detailed diff report.
<execute_command>
<command>git diff origin/main...HEAD --name-status > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_file_changes.txt</command>
</execute_command>
3. **Check Commit History**: Understand what commits are in this PR.
<execute_command>
<command>git log origin/main..HEAD --oneline > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_commits.txt</command>
</execute_command>
4. **Identify New Commits on Main**: See what has been merged to main since the PR was created.
<execute_command>
<command>git log HEAD..origin/main --oneline > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/new_main_commits.txt</command>
</execute_command>
5. **Save Merge Strategy**: Based on the analysis, determine if we should rebase or merge.
Create `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/merge_strategy.txt` with either "rebase" or "merge"
</instructions>
</step>
<step number="6">
<name>Delegate: Implement Fixes</name>
<instructions>
Launch a subtask in `code` mode to implement all the fixes based on the analysis and user's choices.
<new_task>
<mode>code</mode>
<message>
**Task: Implement PR Fixes Based on Analysis**
You are an expert software developer. Your task is to implement fixes for a pull request based on the analysis and plan.
1. **Read Context Files**:
- Analysis Report: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_analysis_report.md`
- Implementation Scope: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/implementation_scope.txt`
- File Changes: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_file_changes.txt`
- Merge Strategy: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/merge_strategy.txt`
2. **Handle Merge/Rebase First** (if conflicts exist):
- If merge_strategy.txt says "rebase":
<execute_command>
<command>GIT_EDITOR=true git rebase origin/main</command>
</execute_command>
- If conflicts occur, resolve them by editing the conflicted files
- Remember to escape conflict markers when using apply_diff
- After resolving each file: `git add [file]`
- Continue rebase: `git rebase --continue`
3. **Implement Missing Functionality** (if identified in analysis):
- Add any missing features or functionality noted in the requirements analysis
- Follow the architectural patterns identified in the analysis
- Ensure all acceptance criteria are met
- Update related operations to maintain consistency
4. **Implement Review Feedback**:
- Address each actionable review comment from the analysis
- Make code changes using appropriate file editing tools
- Ensure changes follow project coding standards
- Add comments where complex logic is introduced
5. **Fix Failing Tests**:
- Based on the root cause analysis, fix test failures
- This may involve fixing source code or updating tests
- Run tests locally if possible to verify fixes
- Document any test changes made
6. **Track All Changes**: As you make changes, maintain a list of:
- Files modified with brief description of changes
- Review comments addressed
- Tests fixed
- Missing functionality added
- Any additional improvements made
7. **Create Change Summary**: Write a comprehensive summary to:
`.roo/temp/pr-fixer-orchestrator/[TASK_ID]/changes_implemented.md`
Include:
- List of all files modified
- Review comments addressed (with file:line references)
- Test fixes applied
- Conflict resolutions performed
- Missing functionality implemented
- Any additional improvements
**Important Reminders:**
- Follow the implementation plan from the analysis
- Respect the user's chosen scope
- Make minimal, targeted changes
- Preserve existing functionality
- When resolving conflicts, understand both sides before choosing
- Ensure all original PR requirements are met
- **IMPORTANT**: Save all output files to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/
**Completion Protocol:**
- Once all fixes are implemented and the summary is saved, use `attempt_completion`.
- Result: "PR fixes implemented and summary saved to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/changes_implemented.md"
</message>
</new_task>
Wait for the implementation subtask to complete before proceeding.
</instructions>
</step>
<step number="7">
<name>Delegate: Test and Validate Changes</name>
<instructions>
After implementation, delegate testing and validation to ensure all fixes work correctly.
<new_task>
<mode>test</mode>
<message>
**Task: Validate PR Fixes and Run Tests**
You are a meticulous QA engineer. Your task is to validate that all PR fixes have been properly implemented.
**Context Files:**
- Original Analysis: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_analysis_report.md`
- Changes Made: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/changes_implemented.md`
- Original PR Checks: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_checks.json`
**Your Steps:**
1. **Verify Requirements**: Check that all original PR requirements and acceptance criteria are met.
2. **Verify Review Comments**: Check that each review comment marked as addressed in changes_implemented.md has been properly fixed.
3. **Run Local Tests**: Execute relevant test suites.
- Identify test files related to changed code
- Run unit tests for modified components
- Run integration tests if applicable
- Document all test results
4. **Validate Code Quality**:
- Run linters on changed files
- Check for type errors (if TypeScript)
- Verify no console.logs or debug code remains
- Ensure proper error handling
5. **Check for Regressions**:
- Verify existing functionality still works
- Look for potential side effects of changes
- Test edge cases around modified code
6. **Create Validation Report**: Write findings to `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/validation_report.md`
Include:
- Test results summary (pass/fail counts)
- Requirements verification checklist
- Review comment verification checklist
- Any issues or concerns found
- Recommendations for additional testing
- Overall assessment: READY or NEEDS_WORK
**Critical Focus Areas:**
- Ensure all originally failing tests now pass
- Verify no new test failures introduced
- Confirm review feedback properly addressed
- Check that all PR requirements are fulfilled
- Check for unintended consequences
- **IMPORTANT**: Save your report to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/
**Completion Protocol:**
- Save validation report and use `attempt_completion`
- Result: "Validation complete. Report saved to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/validation_report.md"
</message>
</new_task>
Wait for validation to complete before proceeding.
</instructions>
</step>
<step number="8">
<name>Handle Validation Results and Translation Needs</name>
<instructions>
Review validation results and check if translation updates are needed.
1. **Read Validation Report**:
<read_file>
<args>
<file>
<path>.roo/temp/pr-fixer-orchestrator/[TASK_ID]/validation_report.md</path>
</file>
</args>
</read_file>
2. **If Validation Failed**: Present issues to user and ask how to proceed.
If the report indicates NEEDS_WORK, use ask_followup_question to get direction.
3. **Check for Translation Requirements**:
Read the changes_implemented.md file and check for:
- Changes to i18n JSON files
- Modifications to UI components with user-facing text
- Updates to announcement files or documentation
- New error messages or notifications
4. **Delegate Translation if Needed**:
If translation is required:
<new_task>
<mode>translate</mode>
<message>
**Task: Update Translations for PR Fixes**
PR #[pr_number] fixes have been implemented. Please handle translation updates for the following changes:
**Changed Files:**
[List specific files from changes_implemented.md that need translation]
**Specific Changes:**
[Detail what text was added/modified]
Please ensure all supported languages are updated with appropriate translations.
Save a summary of translation changes to `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/translation_summary.md`
**IMPORTANT**: Save your summary to the specified file in .roo/temp/pr-fixer-orchestrator/[TASK_ID]/
</message>
</new_task>
5. **Proceed When Ready**: Only continue after validation passes and translations complete (if needed).
</instructions>
</step>
<step number="9">
<name>Prepare PR Message and Get User Approval</name>
<instructions>
Before committing changes, prepare the PR update message and get user approval.
1. **Check Files to be Committed**: List all modified files.
<execute_command>
<command>git status --porcelain > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/files_to_commit.txt</command>
</execute_command>
2. **Read Implementation Summary**:
<read_file>
<args>
<file>
<path>.roo/temp/pr-fixer-orchestrator/[TASK_ID]/changes_implemented.md</path>
</file>
</args>
</read_file>
3. **Create PR Update Message**: Based on the changes, create a comprehensive PR update message following the template.
Save to `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_update_message.md`:
```markdown
## PR Update Summary
This update addresses the review feedback and fixes identified issues.
## Changes Made
[List from changes_implemented.md]
- Fixed [specific issue] in [file]
- Addressed review comment about [topic]
- Updated tests for [functionality]
- Resolved merge conflicts in [files]
## Review Comments Addressed
[For each review comment addressed]
- ✅ Comment: "[reviewer comment]"
- Fix: [what was done]
- Files: [files modified]
## Test Fixes
[If tests were fixed]
- Fixed failing test: [test name]
- Issue: [root cause]
- Solution: [fix applied]
## Translations Updated
[If translations were updated]
- Updated [X] language files for [changes]
- All user-facing strings properly translated
## Verification
- [x] All review comments addressed
- [x] All tests passing locally
- [x] No regressions introduced
- [x] Code follows project standards
- [x] Translations updated (if applicable)
## Files Modified
[List all files that will be committed]
```
4. **Get User Approval**: Present the changes and ask for confirmation.
<ask_followup_question>
<question>
I've completed all the fixes for PR #[pr_number]. Here's a summary of what will be committed:
**Files to be committed:**
[Content of files_to_commit.txt]
**PR Update Message:**
[Content of pr_update_message.md]
Would you like me to proceed with committing these changes?
</question>
<follow_up>
<suggest>Looks good, go ahead and commit the changes</suggest>
<suggest>I tested the changes and something is wrong - let me describe the issue</suggest>
<suggest>I still need to test the changes manually before committing</suggest>
<suggest>Let me review specific files before committing</suggest>
</follow_up>
</ask_followup_question>
5. **Handle User Response**:
- If approved: Continue to commit
- If issues found: Document the issue and determine next steps
- If manual testing needed: Wait for user to complete testing
- If review requested: Show requested files and wait for approval
</instructions>
</step>
<step number="10">
<name>Commit Changes and Prepare for Push</name>
<instructions>
Once user approves, commit the changes with appropriate message.
1. **Stage Only Necessary Files**: Review files and stage appropriately.
Read files_to_commit.txt and ensure only relevant files are staged.
<execute_command>
<command>git add [specific files from the implementation]</command>
</execute_command>
Note: Do NOT use `git add -A` to avoid adding unintended files.
2. **Create Commit Message**: Based on the changes made, create an appropriate commit message.
<execute_command>
<command>git commit -m "fix: address PR feedback and fix failing tests
- addressed review comments
- fixed failing tests
- resolved conflicts (if applicable)
- updated translations (if needed)
See PR for detailed changes"</command>
</execute_command>
3. **Verify Remote Configuration**: Check which remote to push to.
<read_file>
<args>
<file>
<path>.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_remote_info.json</path>
</file>
</args>
</read_file>
4. **Determine Push Target**:
- If isCrossRepository is false: push to origin
- If isCrossRepository is true: push to fork
</instructions>
</step>
<step number="11">
<name>Delegate: Final PR Review</name>
<instructions>
Before pushing changes, have the PR reviewer mode review all changes to ensure quality.
<new_task>
<mode>pr-reviewer</mode>
<message>
**Task: Review PR Fix Implementation**
You are reviewing the fixes applied to PR #[pr_number]. Your task is to ensure all changes are high quality and properly address the original feedback.
**Context Files:**
- Original PR Analysis: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_analysis_report.md`
- Changes Implemented: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/changes_implemented.md`
- Validation Report: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/validation_report.md`
- Translation Summary (if exists): `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/translation_summary.md`
- PR Update Message: `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_update_message.md`
**Review Focus:**
1. **Completeness**: Verify all identified issues have been addressed
2. **Requirements**: Confirm all original PR requirements are met
3. **Code Quality**: Check that fixes follow best practices
4. **No Regressions**: Ensure no new issues introduced
5. **Review Feedback**: Confirm all reviewer comments properly addressed
6. **Test Coverage**: Verify tests cover the changes
7. **Documentation**: Check if docs/comments are adequate
**Your Task:**
1. Review the actual code changes using git diff
2. Cross-reference with the original review feedback
3. Verify all PR requirements are fulfilled
4. Assess the quality of the implementation
5. Check for any missed requirements
6. Create a final review report
Save your review to `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/final_review.md` with:
- Overall Assessment: APPROVED or NEEDS_REVISION
- Quality Score: 1-10
- Detailed feedback on the implementation
- Any remaining concerns
- Recommendations for improvement
**IMPORTANT**: Save your review to the specified file in .roo/temp/pr-fixer-orchestrator/[TASK_ID]/
**Completion Protocol:**
- Save review and use `attempt_completion`
- Result: "Final review complete and saved to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/final_review.md"
</message>
</new_task>
Wait for the review to complete.
</instructions>
</step>
<step number="12">
<name>Process Final Review and Push Changes</name>
<instructions>
Based on the final review, either push changes or address remaining issues.
1. **Read Final Review**:
<read_file>
<args>
<file>
<path>.roo/temp/pr-fixer-orchestrator/[TASK_ID]/final_review.md</path>
</file>
</args>
</read_file>
2. **If Review Requests Revisions**:
Present the feedback to the user and ask if they want to address the issues now or push as-is.
3. **Push Changes**: If approved or user chooses to push:
Based on pr_remote_info.json, push to the correct remote:
For same-repository PRs:
<execute_command>
<command>git push --force-with-lease origin [branch_name]</command>
</execute_command>
For cross-repository PRs:
<execute_command>
<command>git push --force-with-lease fork [branch_name]</command>
</execute_command>
4. **Monitor Push Result**: Ensure the push succeeds.
If --force-with-lease fails, fetch and retry with --force.
</instructions>
</step>
<step number="13">
<name>Verify PR Status and Monitor Checks</name>
<instructions>
After pushing, verify the PR is in good state and monitor CI/CD checks.
1. **Verify PR is Up to Date**:
<execute_command>
<command>gh pr view [pr_number] --repo [owner]/[repo] --json mergeable,mergeStateStatus</command>
</execute_command>
2. **Monitor CI/CD Checks in Real-Time**:
<execute_command>
<command>gh pr checks [pr_number] --repo [owner]/[repo] --watch</command>
</execute_command>
This will continuously monitor until all checks complete.
3. **Get Final Status**: Once monitoring completes, get the final state.
<execute_command>
<command>gh pr checks [pr_number] --repo [owner]/[repo] --json name,state,conclusion > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/final_checks.json</command>
</execute_command>
4. **Comment on PR**: Add a summary comment about the fixes applied.
Read the PR update message we prepared:
<read_file>
<args>
<file>
<path>.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_update_message.md</path>
</file>
</args>
</read_file>
Then post it as a comment:
<execute_command>
<command>gh pr comment [pr_number] --repo [owner]/[repo] --body-file .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_update_message.md</command>
</execute_command>
5. **Save PR Message**: Keep the PR message for reference.
The PR update message has already been saved to `.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_update_message.md`
6. **Final Summary**: Present the final status to the user, confirming:
- All requested changes have been implemented
- The branch is synced with main
- CI/CD checks status
- The PR is ready for maintainer review and merge
- PR update message has been posted and saved
7. **Optional Cleanup**: Ask user if they want to clean up temporary files.
<ask_followup_question>
<question>
PR #[pr_number] has been successfully updated!
- All changes committed and pushed
- CI/CD checks are [status]
- PR comment posted with update summary
- PR message saved to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_update_message.md
Would you like me to clean up the temporary files?
</question>
<follow_up>
<suggest>Yes, clean up temporary files</suggest>
<suggest>No, keep the files for reference</suggest>
</follow_up>
</ask_followup_question>
If user chooses cleanup:
<execute_command>
<command>rm -rf .roo/temp/pr-fixer-orchestrator/[TASK_ID]</command>
</execute_command>
</instructions>
</step>
</workflow>

186
.roo/rules-pr-fixer-orchestrator/2_best_practices.xml Normal file
View file

@ -0,0 +1,186 @@
<best_practices>
<orchestration_principles>
<principle priority="critical">
<name>Always Delegate Specialized Work</name>
<description>The orchestrator coordinates but doesn't implement. Use specialized modes for analysis, coding, testing, and review.</description>
<rationale>Each mode has specific expertise and permissions optimized for their tasks.</rationale>
</principle>
<principle priority="critical">
<name>Maintain Context Between Steps</name>
<description>Use temporary files in .roo/temp/pr-fixer-orchestrator/[TASK_ID]/ to pass context between subtasks. ALL delegated tasks must save outputs to this directory.</description>
<rationale>Subtasks run in isolation and need explicit context sharing. Files saved elsewhere will be inaccessible to subsequent steps.</rationale>
</principle>
<principle priority="critical">
<name>Get User Approval Before Committing</name>
<description>ALWAYS present changes and get explicit user approval before committing. Show modified files, summarize changes, and ask for confirmation.</description>
<rationale>Users must maintain control over what gets committed to their PR. Unexpected changes can break functionality or introduce unwanted modifications.</rationale>
</principle>
<principle priority="critical">
<name>Understand Requirements First</name>
<description>Always analyze the PR's underlying purpose and requirements before fixing issues.</description>
<rationale>Fixing review comments without understanding the feature can lead to incomplete or incorrect solutions.</rationale>
</principle>
<principle priority="high">
<name>Handle Large Diffs Gracefully</name>
<description>Check diff size before processing. If over 2000 lines, create a summary instead of including the full diff.</description>
<rationale>Large diffs can overwhelm context windows and make analysis difficult. Summaries maintain clarity.</rationale>
</principle>
</orchestration_principles>
<pr_fixing_guidelines>
- Always understand the PR's purpose and requirements first
- Analyze before implementing - understand all issues comprehensively
- Address review feedback with the same priority as the reviewer's authority
- Fix root causes of test failures, not just symptoms
- Ensure all original PR requirements are met, not just review comments
- Resolve conflicts carefully, understanding both sides of changes
- Validate all changes before committing to avoid breaking the PR further
- NEVER use `git add -A` - always stage specific files intentionally
- Get user approval before committing any changes
- Keep commits focused and well-described
- Always check if PR is from a fork to push to correct remote
- Monitor CI/CD checks in real-time after pushing
- Consider translation needs for any user-facing changes
- Document what was changed and why in the PR update message
- Use the EXACT PR template format specified in 6_pr_template_format.xml
</pr_fixing_guidelines>
<git_operation_best_practices>
<practice category="conflict_resolution">
<name>Non-Interactive Rebasing</name>
<description>Always use GIT_EDITOR=true for automated rebase operations</description>
<example>GIT_EDITOR=true git rebase origin/main</example>
</practice>
<practice category="remote_handling">
<name>Fork-Aware Pushing</name>
<description>Always check isCrossRepository before pushing</description>
<steps>
- Check if PR is from fork using gh pr view --json isCrossRepository
- Add fork remote if needed
- Push to correct remote (origin vs fork)
</steps>
</practice>
<practice category="safe_pushing">
<name>Force with Lease</name>
<description>Use --force-with-lease for safer force pushing</description>
<fallback>If it fails, fetch and use --force</fallback>
</practice>
<practice category="staging_files">
<name>Selective File Staging</name>
<description>Always stage files individually, never use git add -A</description>
<steps>
- Review all modified files with git status
- Stage only files that were intentionally modified
- Use git add [specific-file] for each file
- Double-check staged files with git diff --cached
</steps>
<rationale>Prevents accidentally committing temporary files, debug logs, or unintended changes</rationale>
</practice>
<practice category="diff_management">
<name>Large Diff Handling</name>
<description>Check diff size before including in context files</description>
<steps>
- Save diff to file and check line count with wc -l
- If over 2000 lines, create a summary instead
- Include file counts, insertion/deletion stats
- List most significantly changed files
</steps>
</practice>
</git_operation_best_practices>
<subtask_delegation_patterns>
<pattern name="analysis_delegation">
<to_mode>architect</to_mode>
<purpose>Comprehensive analysis and planning</purpose>
<provides>Detailed reports and implementation plans</provides>
<output_requirement>MUST save all outputs to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/</output_requirement>
</pattern>
<pattern name="implementation_delegation">
<to_mode>code</to_mode>
<purpose>Executing code changes and fixes</purpose>
<provides>Implemented solutions and change summaries</provides>
<output_requirement>MUST save changes_implemented.md to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/</output_requirement>
</pattern>
<pattern name="validation_delegation">
<to_mode>test</to_mode>
<purpose>Testing and validating changes</purpose>
<provides>Test results and validation reports</provides>
<output_requirement>MUST save validation_report.md to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/</output_requirement>
</pattern>
<pattern name="review_delegation">
<to_mode>pr-reviewer</to_mode>
<purpose>Final quality review before submission</purpose>
<provides>Quality assessment and recommendations</provides>
<output_requirement>MUST save final_review.md to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/</output_requirement>
</pattern>
<pattern name="translation_delegation">
<to_mode>translate</to_mode>
<purpose>Updating translations for UI changes</purpose>
<provides>Synchronized translations across languages</provides>
<output_requirement>MUST save translation_summary.md to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/</output_requirement>
</pattern>
</subtask_delegation_patterns>
<error_handling>
<scenario name="auth_failure">
<error>GitHub CLI authentication error</error>
<action>Prompt user to run 'gh auth login'</action>
</scenario>
<scenario name="no_linked_issue">
<error>No linked issue found</error>
<action>Extract requirements from PR description and comments</action>
</scenario>
<scenario name="push_failure">
<error>Force-with-lease push fails</error>
<action>Fetch latest and retry with --force</action>
</scenario>
<scenario name="large_diff">
<error>Diff exceeds 2000 lines</error>
<action>Create summary with stats instead of full diff</action>
</scenario>
<scenario name="missing_context_files">
<error>Expected context files not found in temp directory</error>
<action>Check if delegated task saved to correct location, re-run if needed</action>
</scenario>
</error_handling>
<user_interaction_guidelines>
<guideline priority="critical">
<name>Pre-Commit Approval</name>
<description>Always get explicit user approval before committing changes</description>
<implementation>
- Show list of modified files
- Summarize key changes made
- Present clear approval options
- Wait for user confirmation
</implementation>
</guideline>
<guideline priority="high">
<name>Clear Communication</name>
<description>Present information clearly and concisely</description>
<implementation>
- Use bullet points for lists
- Highlight important warnings
- Provide actionable suggestions
- Avoid technical jargon when possible
</implementation>
</guideline>
</user_interaction_guidelines>
</best_practices>

68
.roo/rules-pr-fixer-orchestrator/3_github_cli_usage.xml Normal file
View file

@ -0,0 +1,68 @@
<github_cli_usage>
<overview>
This mode uses the GitHub CLI (gh) for all GitHub operations.
The mode assumes the user has gh installed and authenticated.
It can work with PRs from both the main repository and forks.
</overview>
<pr_specific_commands>
<command name="gh_pr_view">
<purpose>Get comprehensive PR details</purpose>
<syntax>gh pr view [pr-number] --repo [owner]/[repo] --json [fields]</syntax>
<fields>number,title,body,state,labels,author,headRefName,baseRefName,mergeable,mergeStateStatus,isDraft,isCrossRepository,headRepositoryOwner,reviews,statusCheckRollup,comments</fields>
</command>
<command name="gh_pr_checkout">
<purpose>Checkout PR branch locally</purpose>
<syntax>gh pr checkout [pr-number] --repo [owner]/[repo] --force</syntax>
<note>Automatically handles fork setup</note>
</command>
<command name="gh_pr_checks">
<purpose>Monitor CI/CD status</purpose>
<syntax>gh pr checks [pr-number] --repo [owner]/[repo] --watch</syntax>
<note>Use --json for programmatic access</note>
</command>
<command name="gh_pr_diff">
<purpose>Get PR changes</purpose>
<syntax>gh pr diff [pr-number] --repo [owner]/[repo] --name-only</syntax>
<note>Use without --name-only for full diff</note>
</command>
<command name="gh_pr_comment">
<purpose>Add comment to PR</purpose>
<syntax>gh pr comment [pr-number] --repo [owner]/[repo] --body "[message]"</syntax>
</command>
</pr_specific_commands>
<issue_integration>
<command name="gh_pr_linked_issues">
<purpose>Get issues linked to PR</purpose>
<syntax>gh pr view [pr-number] --repo [owner]/[repo] --json closingIssuesReferences</syntax>
<note>Returns array of linked issues</note>
</command>
<command name="gh_issue_view">
<purpose>Get issue details if linked</purpose>
<syntax>gh issue view [issue-number] --repo [owner]/[repo] --json [fields]</syntax>
<fields>number,title,body,state,labels,assignees,milestone,createdAt,updatedAt,closedAt,author,comments</fields>
</command>
</issue_integration>
<workflow_commands>
<command name="gh_run_view">
<purpose>Get detailed CI logs</purpose>
<syntax>gh run view [run-id] --repo [owner]/[repo] --log-failed</syntax>
<note>Use to debug failing tests</note>
</command>
<command name="gh_api">
<purpose>Direct API access for advanced operations</purpose>
<examples>
- Get PR reviews: gh api repos/[owner]/[repo]/pulls/[pr-number]/reviews
- Get review comments: gh api repos/[owner]/[repo]/pulls/[pr-number]/comments
</examples>
</command>
</workflow_commands>
</github_cli_usage>

120
.roo/rules-pr-fixer-orchestrator/4_requirements_analysis.xml Normal file
View file

@ -0,0 +1,120 @@
<requirements_analysis_guidelines>
<overview>
The PR Fixer Orchestrator must understand the underlying requirements
of a PR before fixing issues. This ensures fixes align with the
original intent and all acceptance criteria are met.
</overview>
<sources_of_requirements>
<source priority="1">
<name>Linked GitHub Issues</name>
<description>Primary source of requirements and acceptance criteria</description>
<extraction>
- Issue title and body
- Acceptance criteria sections
- Technical specifications
- User stories or use cases
</extraction>
</source>
<source priority="2">
<name>PR Description</name>
<description>Often contains implementation notes and context</description>
<extraction>
- Feature description
- Implementation approach
- Testing notes
- Breaking changes
</extraction>
</source>
<source priority="3">
<name>PR Comments</name>
<description>May contain clarifications and additional requirements</description>
<extraction>
- Author clarifications
- Reviewer questions and answers
- Scope changes or additions
</extraction>
</source>
<source priority="4">
<name>Code Analysis</name>
<description>Infer requirements from the implementation</description>
<extraction>
- API contracts
- Data flow patterns
- Test cases (reveal expected behavior)
- Documentation comments
</extraction>
</source>
</sources_of_requirements>
<analysis_approach>
<step number="1">
<name>Extract Explicit Requirements</name>
<actions>
- Parse linked issues for acceptance criteria
- Extract requirements from PR description
- Identify success metrics
</actions>
</step>
<step number="2">
<name>Understand Implementation Intent</name>
<actions>
- Analyze the code changes to understand approach
- Identify design decisions made
- Note any architectural patterns used
</actions>
</step>
<step number="3">
<name>Map Requirements to Implementation</name>
<actions>
- Verify each requirement has corresponding code
- Identify any missing functionality
- Note any extra functionality added
</actions>
</step>
<step number="4">
<name>Identify Gaps</name>
<actions>
- List unimplemented requirements
- Note incomplete features
- Identify missing tests
</actions>
</step>
</analysis_approach>
<common_requirement_patterns>
<pattern name="bug_fix">
<requirements>
- Clear description of the bug
- Steps to reproduce
- Expected vs actual behavior
- Affected versions/environments
</requirements>
</pattern>
<pattern name="new_feature">
<requirements>
- Feature description
- User stories or use cases
- API design (if applicable)
- UI/UX specifications
- Performance requirements
</requirements>
</pattern>
<pattern name="refactoring">
<requirements>
- Motivation for refactoring
- Backward compatibility needs
- Performance improvements expected
- Migration path (if breaking)
</requirements>
</pattern>
</common_requirement_patterns>
</requirements_analysis_guidelines>

99
.roo/rules-pr-fixer-orchestrator/5_self_contained_workflow.xml Normal file
View file

@ -0,0 +1,99 @@
<self_contained_workflow>
<overview>
The PR Fixer Orchestrator must be completely self-contained and able
to work on any PR without requiring pre-existing context files from
other workflows like the Issue Fixer.
</overview>
<independence_principles>
<principle>
<name>No External Dependencies</name>
<description>Never assume files from other workflows exist</description>
<implementation>
- Create own temp directory structure
- Gather all needed context independently
- Generate own analysis and plans
</implementation>
</principle>
<principle>
<name>Complete Context Gathering</name>
<description>Collect all information needed for the task</description>
<implementation>
- Fetch PR details and metadata
- Get linked issues if they exist
- Analyze codebase independently
- Understand requirements from available sources
</implementation>
</principle>
<principle>
<name>Flexible Requirements Analysis</name>
<description>Work with whatever information is available</description>
<implementation>
- Use linked issues when available
- Fall back to PR description
- Infer from code changes if needed
- Ask user for clarification when necessary
</implementation>
</principle>
</independence_principles>
<context_initialization>
<step>Create dedicated task directory</step>
<step>Fetch all PR-related information</step>
<step>Check for linked issues and fetch if present</step>
<step>Analyze PR changes to understand scope</step>
<step>Build complete context from available sources</step>
</context_initialization>
<handling_different_pr_types>
<type name="pr_with_linked_issue">
<description>PR that references a GitHub issue</description>
<approach>
- Fetch issue details for requirements
- Use issue acceptance criteria
- Cross-reference PR implementation with issue requirements
</approach>
</type>
<type name="standalone_pr">
<description>PR without linked issue</description>
<approach>
- Extract requirements from PR description
- Analyze code to understand intent
- Use PR comments for additional context
- Infer acceptance criteria from tests
</approach>
</type>
<type name="fork_pr">
<description>PR from a forked repository</description>
<approach>
- Handle remote configuration properly
- Ensure push targets correct repository
- Manage permissions appropriately
</approach>
</type>
</handling_different_pr_types>
<fallback_strategies>
<strategy name="missing_requirements">
<when>No clear requirements found</when>
<action>
- Analyze code changes to infer purpose
- Look at test changes for expected behavior
- Ask user for clarification if needed
</action>
</strategy>
<strategy name="unclear_scope">
<when>PR scope is ambiguous</when>
<action>
- Present findings to user
- Ask for specific guidance on what to fix
- Proceed with user-defined scope
</action>
</strategy>
</fallback_strategies>
</self_contained_workflow>

361
.roo/rules-pr-fixer-orchestrator/6_pr_template_format.xml Normal file
View file

@ -0,0 +1,361 @@
<pr_template_format>
<overview>
This file defines the EXACT PR message template that must be used when updating
pull requests. The format is specific to the Roo Code project and must be followed
precisely.
</overview>
<template>
<![CDATA[
<!--
Thank you for contributing to Roo Code!
Before submitting your PR, please ensure:
- It's linked to an approved GitHub Issue.
- You've reviewed our [Contributing Guidelines](../CONTRIBUTING.md).
-->
### Related GitHub Issue
<!-- Every PR MUST be linked to an approved issue. -->
Closes: #[ISSUE_NUMBER] <!-- Replace with the issue number, e.g., Closes: #123 -->
### Roo Code Task Context (Optional)
<!--
If you used Roo Code to help create this PR, you can share public task links here.
This helps reviewers understand your development process and provides additional context.
Example: https://app.roocode.com/share/task-id
-->
[TASK_CONTEXT_IF_APPLICABLE]
### Description
<!--
Briefly summarize the changes in this PR and how they address the linked issue.
The issue should cover the "what" and "why"; this section should focus on:
- The "how": key implementation details, design choices, or trade-offs made.
- Anything specific reviewers should pay attention to in this PR.
-->
[DESCRIPTION_OF_CHANGES]
### Test Procedure
<!--
Detail the steps to test your changes. This helps reviewers verify your work.
- How did you test this specific implementation? (e.g., unit tests, manual testing steps)
- How can reviewers reproduce your tests or verify the fix/feature?
- Include relevant testing environment details if applicable.
-->
[TEST_PROCEDURE_DETAILS]
### Pre-Submission Checklist
<!-- Go through this checklist before marking your PR as ready for review. -->
- [x] **Issue Linked**: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
- [x] **Scope**: My changes are focused on the linked issue (one major feature/fix per PR).
- [x] **Self-Review**: I have performed a thorough self-review of my code.
- [x] **Testing**: New and/or updated tests have been added to cover my changes (if applicable).
- [x] **Documentation Impact**: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
- [x] **Contribution Guidelines**: I have read and agree to the [Contributor Guidelines](/CONTRIBUTING.md).
### Screenshots / Videos
<!--
For UI changes, please provide before-and-after screenshots or a short video of the *actual results*.
This greatly helps in understanding the visual impact of your changes.
-->
[SCREENSHOTS_OR_VIDEOS_IF_UI_CHANGES]
### Documentation Updates
<!--
Does this PR necessitate updates to user-facing documentation?
- [ ] No documentation updates are required.
- [ ] Yes, documentation updates are required. (Please describe what needs to be updated or link to a PR in the docs repository).
-->
[DOCUMENTATION_UPDATE_STATUS]
### Additional Notes
<!-- Add any other context, questions, or information for reviewers here. -->
[ADDITIONAL_NOTES]
### Get in Touch
<!--
Please provide your Discord username for reviewers or maintainers to reach you if they have questions about your PR
-->
[DISCORD_USERNAME]
]]>
</template>
<placeholders>
<placeholder name="[ISSUE_NUMBER]">
<description>The GitHub issue number this PR closes</description>
<source>From linked_issues.json or pr_context.json</source>
</placeholder>
<placeholder name="[TASK_CONTEXT_IF_APPLICABLE]">
<description>Optional Roo Code task links if used</description>
<default>_No Roo Code task context for this PR._</default>
</placeholder>
<placeholder name="[DESCRIPTION_OF_CHANGES]">
<description>Summary of changes and implementation details</description>
<content>
This PR addresses the review feedback and fixes identified issues for #[PR_NUMBER].
**Key Changes:**
- [List major changes from changes_implemented.md]
- [Implementation details and design choices]
- [Trade-offs or decisions made]
**Review Comments Addressed:**
[Summary of addressed review comments]
**Test Failures Fixed:**
[Summary of test fixes if applicable]
**Conflicts Resolved:**
[Summary of conflict resolutions if applicable]
</content>
</placeholder>
<placeholder name="[TEST_PROCEDURE_DETAILS]">
<description>How the changes were tested</description>
<content>
**Testing performed:**
1. Ran all unit tests locally: `[test command used]`
2. Ran integration tests: `[test command used]`
3. Manual testing steps:
- [Step 1]
- [Step 2]
- [Step 3]
**To verify these changes:**
1. Check out this branch
2. Run `[specific test commands]`
3. [Additional verification steps]
**Test Environment:**
- Node.js version: [version]
- OS: [operating system]
- [Other relevant environment details]
</content>
</placeholder>
<placeholder name="[SCREENSHOTS_OR_VIDEOS_IF_UI_CHANGES]">
<description>Visual evidence of UI changes</description>
<default>_No UI changes in this PR._</default>
</placeholder>
<placeholder name="[DOCUMENTATION_UPDATE_STATUS]">
<description>Documentation impact assessment</description>
<options>
<option condition="no_docs_needed">- [x] No documentation updates are required.</option>
<option condition="docs_needed">- [x] Yes, documentation updates are required. [Describe what needs updating]</option>
</options>
</placeholder>
<placeholder name="[ADDITIONAL_NOTES]">
<description>Any additional context for reviewers</description>
<content>
[Any special considerations, known issues, or questions for reviewers]
**Files Modified:**
```
[List of modified files from changes_implemented.md]
```
</content>
</placeholder>
<placeholder name="[DISCORD_USERNAME]">
<description>Contact information</description>
<default>Discord: @[username]</default>
</placeholder>
</placeholders>
<generation_instructions>
<instruction priority="1">
The template MUST be followed exactly - do not modify the structure or remove any sections
</instruction>
<instruction priority="2">
All placeholders must be replaced with actual content - no brackets should remain
</instruction>
<instruction priority="3">
The Pre-Submission Checklist items should all be marked as checked [x] since we're fixing an existing PR
</instruction>
<instruction priority="4">
Pull information from:
- changes_implemented.md for the description and file list
- validation_report.md for test results
- pr_context.json for issue numbers and PR details
- translation_summary.md for any translation updates
</instruction>
<instruction priority="5">
Keep the HTML comments intact - they provide guidance for reviewers
</instruction>
</generation_instructions>
<file_handling>
<location>.roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_update_message.md</location>
<purpose>
- Used as the PR comment body when updating the PR
- Saved for reference and audit trail
- Can be edited by user before posting
- Should NOT be deleted even if temp files are cleaned
</purpose>
<usage>
Post to PR using: gh pr comment [pr_number] --repo [owner]/[repo] --body-file [path_to_file]
</usage>
</file_handling>
<example_filled_template>
<![CDATA[
<!--
Thank you for contributing to Roo Code!
Before submitting your PR, please ensure:
- It's linked to an approved GitHub Issue.
- You've reviewed our [Contributing Guidelines](../CONTRIBUTING.md).
-->
### Related GitHub Issue
<!-- Every PR MUST be linked to an approved issue. -->
Closes: #456
### Roo Code Task Context (Optional)
<!--
If you used Roo Code to help create this PR, you can share public task links here.
This helps reviewers understand your development process and provides additional context.
Example: https://app.roocode.com/share/task-id
-->
_No Roo Code task context for this PR._
### Description
<!--
Briefly summarize the changes in this PR and how they address the linked issue.
The issue should cover the "what" and "why"; this section should focus on:
- The "how": key implementation details, design choices, or trade-offs made.
- Anything specific reviewers should pay attention to in this PR.
-->
This PR addresses the review feedback and fixes identified issues for #789.
**Key Changes:**
- Fixed TypeScript type errors in the API handler by adding proper type annotations
- Improved error handling in the authentication flow to handle edge cases
- Refactored complex functions for better testability and maintainability
- Added missing user role management functionality
- Resolved merge conflicts with the latest main branch
**Review Comments Addressed:**
- Added timeout handling with exponential backoff for network requests
- Refactored large functions into smaller, testable units
- Added comprehensive TypeScript interfaces for API responses
- Improved error messages for better debugging
**Test Failures Fixed:**
- Updated email validation tests to match new validation rules
- Fixed mock server responses in integration tests
- Added missing test coverage for new functionality
### Test Procedure
<!--
Detail the steps to test your changes. This helps reviewers verify your work.
- How did you test this specific implementation? (e.g., unit tests, manual testing steps)
- How can reviewers reproduce your tests or verify the fix/feature?
- Include relevant testing environment details if applicable.
-->
**Testing performed:**
1. Ran all unit tests locally: `npm test`
2. Ran integration tests: `npm run test:integration`
3. Manual testing steps:
- Created new user with various role types
- Tested authentication flow with invalid credentials
- Verified timeout handling with slow network simulation
**To verify these changes:**
1. Check out this branch
2. Run `npm install && npm test`
3. Start the dev server with `npm run dev`
4. Test the authentication flow at http://localhost:3000/login
**Test Environment:**
- Node.js version: 18.17.0
- OS: Windows 11
- Browser: Chrome 120
### Pre-Submission Checklist
<!-- Go through this checklist before marking your PR as ready for review. -->
- [x] **Issue Linked**: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
- [x] **Scope**: My changes are focused on the linked issue (one major feature/fix per PR).
- [x] **Self-Review**: I have performed a thorough self-review of my code.
- [x] **Testing**: New and/or updated tests have been added to cover my changes (if applicable).
- [x] **Documentation Impact**: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
- [x] **Contribution Guidelines**: I have read and agree to the [Contributor Guidelines](/CONTRIBUTING.md).
### Screenshots / Videos
<!--
For UI changes, please provide before-and-after screenshots or a short video of the *actual results*.
This greatly helps in understanding the visual impact of your changes.
-->
_No UI changes in this PR._
### Documentation Updates
<!--
Does this PR necessitate updates to user-facing documentation?
- [ ] No documentation updates are required.
- [ ] Yes, documentation updates are required. (Please describe what needs to be updated or link to a PR in the docs repository).
-->
- [x] No documentation updates are required.
### Additional Notes
<!-- Add any other context, questions, or information for reviewers here. -->
All review feedback has been addressed. The main architectural change was refactoring the authentication service to use dependency injection, which improves testability.
**Files Modified:**
```
src/api/handler.ts - Added type annotations, improved error handling
src/services/auth.service.ts - Refactored for dependency injection
src/services/user.service.ts - Added role management functionality
src/types/api.types.ts - New TypeScript interfaces
src/__tests__/services/auth.service.test.ts - Updated tests
src/__tests__/integration/api.test.ts - Fixed mock responses
```
### Get in Touch
<!--
Please provide your Discord username for reviewers or maintainers to reach you if they have questions about your PR
-->
Discord: @contributor123
]]>
</example_filled_template>
</pr_template_format>

203
.roo/rules-pr-reviewer/1_orchestrator_workflow.xml Normal file
View file

@ -0,0 +1,203 @@
<orchestrator_workflow>
<overview>
This workflow orchestrates a comprehensive pull request review process by delegating
specialized analysis tasks to appropriate modes while maintaining context through
structured report files. The orchestrator ensures critical review coverage while
avoiding redundant feedback.
</overview>
<initialization>
<step number="1">
<name>Parse PR Information and Initialize Context</name>
<description>
Extract PR information from user input (URL or PR number).
Create context directory and tracking files.
If called by another mode (Issue Fixer, PR Fixer), set calledByMode field.
</description>
<actions>
- Parse PR URL or number from user input
- Create directory: .roo/temp/pr-[PR_NUMBER]/
- Initialize review-context.json with PR metadata
- Check if called by another mode and record it
</actions>
</step>
</initialization>
<github_operations>
<step number="2">
<name>Fetch PR Details and Context</name>
<description>
Try using GitHub MCP tools first. If unavailable or failing, fall back to GitHub CLI.
</description>
<mcp_approach>
Use get_pull_request tool to fetch PR details
</mcp_approach>
<cli_fallback>
gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles
</cli_fallback>
</step>
<step number="3">
<name>Fetch Linked Issue</name>
<description>
If PR references an issue, fetch its details for context.
</description>
<mcp_approach>
Use get_issue tool if issue is referenced
</mcp_approach>
<cli_fallback>
gh issue view [issue_number] --repo [owner]/[repo] --json number,title,body,author,state
</cli_fallback>
</step>
<step number="4">
<name>Fetch Existing Comments and Reviews</name>
<description>
CRITICAL: Get all existing feedback to avoid redundancy.
</description>
<mcp_approach>
Use get_pull_request_comments and get_pull_request_reviews
</mcp_approach>
<cli_fallback>
gh pr review [PR_NUMBER] --repo [owner]/[repo] --json comments,reviews
</cli_fallback>
<save_to>.roo/temp/pr-[PR_NUMBER]/existing-feedback.json</save_to>
</step>
<step number="5">
<name>Check Out PR Locally</name>
<command>gh pr checkout [PR_NUMBER] --repo [owner]/[repo]</command>
<purpose>Enable local code analysis and pattern comparison</purpose>
</step>
</github_operations>
<delegated_analysis>
<step number="6">
<name>Delegate Pattern Analysis</name>
<description>
Create a subtask to analyze code patterns and organization.
</description>
<delegation>
<mode>code</mode>
<focus_areas>
- Identifying similar existing features/components
- Checking if implementations follow established patterns
- Finding potential code redundancy
- Verifying test organization
- Checking file/directory structure consistency
</focus_areas>
<output>.roo/temp/pr-[PR_NUMBER]/pattern-analysis.md</output>
</delegation>
</step>
<step number="7">
<name>Delegate Architecture Review</name>
<description>
Create a subtask for architectural analysis.
</description>
<delegation>
<mode>architect</mode>
<focus_areas>
- Module boundary violations
- Dependency management issues
- Separation of concerns
- Potential circular dependencies
- Overall architectural consistency
</focus_areas>
<output>.roo/temp/pr-[PR_NUMBER]/architecture-review.md</output>
</delegation>
</step>
<step number="8">
<name>Delegate Test Coverage Analysis</name>
<description>
If test files are modified or added, delegate test analysis.
</description>
<delegation>
<mode>test</mode>
<focus_areas>
- Test organization and location
- Test coverage adequacy
- Test naming conventions
- Mock usage patterns
- Edge case coverage
</focus_areas>
<output>.roo/temp/pr-[PR_NUMBER]/test-analysis.md</output>
</delegation>
</step>
</delegated_analysis>
<synthesis>
<step number="9">
<name>Synthesize Findings</name>
<description>
Collect all delegated analysis results and create comprehensive review.
</description>
<actions>
- Read all analysis files from .roo/temp/pr-[PR_NUMBER]/
- Identify critical issues vs suggestions
- Check against existing comments to avoid redundancy
- Prioritize findings by impact
</actions>
</step>
<step number="10">
<name>Create Final Review Report</name>
<description>
Generate comprehensive review report with all findings.
</description>
<output>.roo/temp/pr-[PR_NUMBER]/final-review.md</output>
<sections>
- Executive Summary
- Critical Issues (must fix)
- Pattern Inconsistencies
- Redundancy Findings
- Architecture Concerns
- Test Coverage Issues
- Minor Suggestions
</sections>
</step>
</synthesis>
<completion>
<step number="11">
<name>Present Review to User</name>
<description>
Show the review findings and ask for action.
</description>
<decision_points>
<if_called_by_mode>
Only present the analysis report, do not comment on PR
</if_called_by_mode>
<if_direct_review>
Ask user if they want to post the review as a comment
</if_direct_review>
</decision_points>
</step>
<step number="12">
<name>Post Review Comment (if approved)</name>
<description>
If user approves and not called by another mode, post review.
</description>
<mcp_approach>
Use add_issue_comment or create PR review
</mcp_approach>
<cli_fallback>
gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body-file .roo/temp/pr-[PR_NUMBER]/final-review.md
</cli_fallback>
</step>
</completion>
<error_handling>
<github_api_failures>
Always fall back to GitHub CLI commands
</github_api_failures>
<delegation_failures>
Continue with available analysis and note limitations
</delegation_failures>
<context_preservation>
Always save intermediate results to temp files
</context_preservation>
</error_handling>
</orchestrator_workflow>

281
.roo/rules-pr-reviewer/1_workflow.xml
View file

@ -1,281 +0,0 @@
<workflow>
<step number="1">
<name>Fetch Pull Request Information</name>
<instructions>
By default, use the GitHub MCP server to fetch and review pull requests from the
https://github.com/RooCodeInc/Roo-Code repository.
If the user provides a PR number or URL, extract the necessary information:
- Repository owner and name
- Pull request number
Use the GitHub MCP tool to fetch the PR details:
<use_mcp_tool>
<server_name>github</server_name>
<tool_name>get_pull_request</tool_name>
<arguments>
{
"owner": "[owner]",
"repo": "[repo]",
"pullNumber": [number]
}
</arguments>
</use_mcp_tool>
</instructions>
</step>
<step number="2">
<name>Fetch Associated Issue (If Any)</name>
<instructions>
Check the pull request body for a reference to a GitHub issue (e.g., "Fixes #123", "Closes #456").
If an issue is referenced, use the GitHub MCP tool to fetch its details:
<use_mcp_tool>
<server_name>github</server_name>
<tool_name>get_issue</tool_name>
<arguments>
{
"owner": "[owner]",
"repo": "[repo]",
"issue_number": [issue_number]
}
</arguments>
</use_mcp_tool>
The issue description and comments can provide valuable context for the review.
</instructions>
</step>
<step number="3">
<name>Fetch Pull Request Diff</name>
<instructions>
Get the pull request diff to understand the changes:
<use_mcp_tool>
<server_name>github</server_name>
<tool_name>get_pull_request_diff</tool_name>
<arguments>
{
"owner": "[owner]",
"repo": "[repo]",
"pullNumber": [number]
}
</arguments>
</use_mcp_tool>
</instructions>
</step>
<step number="4">
<name>Fetch Existing PR Comments and Reviews</name>
<instructions>
IMPORTANT: Before reviewing any code, first get all existing comments and reviews to understand what feedback has already been provided:
<use_mcp_tool>
<server_name>github</server_name>
<tool_name>get_pull_request_comments</tool_name>
<arguments>
{
"owner": "[owner]",
"repo": "[repo]",
"pullNumber": [number]
}
</arguments>
</use_mcp_tool>
Also fetch existing reviews:
<use_mcp_tool>
<server_name>github</server_name>
<tool_name>get_pull_request_reviews</tool_name>
<arguments>
{
"owner": "[owner]",
"repo": "[repo]",
"pullNumber": [number]
}
</arguments>
</use_mcp_tool>
Create a mental or written list of:
- All issues/suggestions that have been raised
- The specific files and line numbers mentioned
- Whether comments appear to be resolved or still pending
This information will guide your review to avoid duplicate feedback.
</instructions>
</step>
<step number="5">
<name>Check Out Pull Request Locally</name>
<instructions>
Use the GitHub CLI to check out the pull request locally:
<execute_command>
<command>gh pr checkout [PR_NUMBER]</command>
</execute_command>
This allows you to:
- Navigate the actual code structure
- Understand how changes interact with existing code
- Get better context for your review
</instructions>
</step>
<step number="6">
<name>Verify Existing Comments Against Current Code</name>
<instructions>
Now that you have the code checked out locally and know what comments exist:
1. For each existing comment/review point:
- Navigate to the specific file and line mentioned
- Check if the issue has been addressed in the current code
- Mark it as "resolved" or "still pending" in your notes
2. Use read_file or codebase_search to examine the specific areas mentioned in comments:
- If a comment says "missing error handling on line 45", check if error handling now exists
- If a review mentioned "this function needs tests", check if tests have been added
- If feedback was about code structure, verify if refactoring has occurred
3. Keep track of:
- Comments that have been addressed (DO NOT repeat these)
- Comments that are still valid (you may reinforce these if critical)
- New issues not previously mentioned (these are your main focus)
This verification step is CRITICAL to avoid redundant feedback and ensures your review adds value.
</instructions>
</step>
<step number="7">
<name>Perform Comprehensive Review</name>
<instructions>
Review the pull request thoroughly:
- Verify that the changes are directly related to the linked issue and do not include unrelated modifications.
- Focus primarily on the changes made in the PR.
- Prioritize code quality, code smell, structural consistency, and for UI-related changes, ensure proper internationalization (i18n) is applied.
- Watch for signs of technical debt (e.g., overly complex logic, lack of abstraction, tight coupling, missing tests, TODOs).
- For large PRs, alert the user and recommend breaking it up if appropriate.
- NEVER run tests or execute code in PR Reviewer mode. The repository likely has automated testing. Your role is limited to:
- Code review and analysis
- Leaving review comments
- Checking code quality and structure
- Reviewing test coverage and quality (without execution)
Document your findings:
- Code quality issues
- Structural improvements
- Missing tests or documentation
- Potential bugs or edge cases
- Performance concerns
- Security considerations
</instructions>
</step>
<step number="8">
<name>Prepare Review Comments</name>
<instructions>
Format your review comments following these guidelines:
CRITICAL: Before adding any comment, verify it's not already addressed:
- Cross-reference with your notes from Step 6
- Only comment on NEW issues or UNRESOLVED existing issues
- Never repeat feedback that has been addressed in the current code
Your suggestions should:
- Use a **friendly, curious tone** — prefer asking: "Is this intentional?" or "Could we approach this differently to improve X?"
- Avoid assumptions or judgments; ask questions instead of declaring problems.
- Skip ALL praise and positive comments. Focus exclusively on issues that need attention.
- Use Markdown sparingly — only for code blocks or when absolutely necessary for clarity. Avoid markdown headings (###, ##, etc.) entirely.
- Avoid including internal evaluation terminology (e.g., scores or internal tags) in public comments.
When linking to specific lines or files, use full GitHub URLs relative to the repository, e.g.
`https://github.com/RooCodeInc/Roo-Code/blob/main/src/api/providers/human-relay.ts#L50`.
Group your comments by:
- Critical issues (must fix)
- Important suggestions (should consider)
- Minor improvements (nice to have)
Include a note about which existing comments you verified as resolved (for user awareness).
</instructions>
</step>
<step number="9">
<name>Preview Review with User</name>
<instructions>
Always show the user a preview of your review suggestions and comments before taking any action.
Summarize your findings clearly for the user before submitting comments.
<ask_followup_question>
<question>I've completed my review of PR #[number]. Here's what I found:
[If applicable: Existing comments that have been resolved:
- Comment about X on file Y - now addressed
- Suggestion about Z - implemented]
[Summary of NEW findings organized by priority]
Would you like me to:
1. Create a comprehensive review with all comments
2. Modify any of the suggestions
3. Skip the review submission</question>
<follow_up>
<suggest>Create a comprehensive review</suggest>
<suggest>Let me modify the suggestions first</suggest>
<suggest>Skip submission - just wanted the analysis</suggest>
</follow_up>
</ask_followup_question>
</instructions>
</step>
<step number="10">
<name>Submit Review</name>
<instructions>
Based on user preference, submit the review as a comprehensive review:
1. First create a pending review:
<use_mcp_tool>
<server_name>github</server_name>
<tool_name>create_pending_pull_request_review</tool_name>
<arguments>
{
"owner": "[owner]",
"repo": "[repo]",
"pullNumber": [number]
}
</arguments>
</use_mcp_tool>
2. Add comments to the pending review using:
<use_mcp_tool>
<server_name>github</server_name>
<tool_name>add_pull_request_review_comment_to_pending_review</tool_name>
<arguments>
{
"owner": "[owner]",
"repo": "[repo]",
"pullNumber": [number],
"path": "[file path]",
"line": [line number],
"body": "[comment text]",
"subjectType": "LINE"
}
</arguments>
</use_mcp_tool>
3. Submit the review:
<use_mcp_tool>
<server_name>github</server_name>
<tool_name>submit_pending_pull_request_review</tool_name>
<arguments>
{
"owner": "[owner]",
"repo": "[repo]",
"pullNumber": [number],
"event": "COMMENT",
"body": "[overall review summary]"
}
</arguments>
</use_mcp_tool>
</instructions>
</step>
</workflow>

27
.roo/rules-pr-reviewer/2_best_practices.xml
View file

@ -1,27 +0,0 @@
<best_practices>
- ALWAYS fetch existing comments and reviews BEFORE reviewing any code (Step 4)
- Create a list of all existing feedback before starting your review
- Check out the PR locally for better context understanding
- Systematically verify each existing comment against the current code (Step 6)
- Track which comments are resolved vs still pending
- Only provide feedback on NEW issues or UNRESOLVED existing issues
- Never duplicate feedback that has already been addressed
- Always fetch and review the entire PR diff before commenting
- Check for and review any associated issue for context
- Focus on the changes made, not unrelated code
- Ensure all changes are directly related to the linked issue
- Use a friendly, curious tone in all comments
- Ask questions rather than making assumptions - there may be intentions behind the code choices
- Provide actionable feedback with specific suggestions
- Focus exclusively on issues and improvements - skip all praise or positive comments
- Use minimal markdown - avoid headings (###, ##) and excessive formatting
- Only use markdown for code blocks or when absolutely necessary for clarity
- Consider the PR's scope - suggest breaking up large PRs
- Verify proper i18n implementation for UI changes
- Check for test coverage without executing tests
- Look for signs of technical debt and code smells
- Ensure consistency with existing code patterns
- Link to specific lines using full GitHub URLs
- Group feedback by priority (critical, important, minor)
- Always preview comments with the user before submitting
</best_practices>

208
.roo/rules-pr-reviewer/2_critical_review_guidelines.xml Normal file
View file

@ -0,0 +1,208 @@
<critical_review_guidelines>
<overview>
These guidelines ensure PR reviews are appropriately critical while remaining
constructive. The goal is to maintain high code quality and consistency
across the codebase by identifying issues that might be overlooked in a
less thorough review.
</overview>
<being_appropriately_critical>
<principle name="evidence_based_criticism">
<description>Always support criticism with evidence from the codebase</description>
<example>
Instead of: "This doesn't follow our patterns"
Say: "This implementation differs from the pattern used in src/api/handlers/*.ts
where we consistently use the factory pattern for endpoint creation"
</example>
</principle>
<principle name="compare_with_existing_code">
<description>Reference similar existing implementations</description>
<approach>
1. Find 2-3 examples of similar features
2. Identify the common patterns they follow
3. Explain how the PR deviates from these patterns
4. Suggest alignment with existing approaches
</approach>
</principle>
<principle name="question_design_decisions">
<description>Challenge architectural choices when appropriate</description>
<examples>
- "Why was this implemented as a separate module instead of extending the existing X module?"
- "This introduces a new pattern for Y. Have we considered using the established pattern from Z?"
- "This creates a circular dependency with module A. Could we restructure to maintain cleaner boundaries?"
</examples>
</principle>
</being_appropriately_critical>
<pattern_analysis_checklist>
<category name="api_endpoints">
<check>Do new endpoints follow the same structure as existing ones?</check>
<check>Are error responses consistent with other endpoints?</check>
<check>Is authentication/authorization handled the same way?</check>
<check>Are request validations following established patterns?</check>
</category>
<category name="react_components">
<check>Do components follow the same file structure (types, helpers, component)?</check>
<check>Are props interfaces defined consistently?</check>
<check>Is state management approach consistent with similar components?</check>
<check>Are hooks used in the same patterns as elsewhere?</check>
</category>
<category name="test_files">
<check>Are test files in the correct directory structure?</check>
<check>Do test descriptions follow the same format?</check>
<check>Are mocking strategies consistent with other tests?</check>
<check>Is test data generation following established patterns?</check>
</category>
<category name="utility_functions">
<check>Could this utility already exist elsewhere?</check>
<check>Should this be added to an existing utility module?</check>
<check>Does the naming convention match other utilities?</check>
<check>Are similar transformations already implemented?</check>
</category>
</pattern_analysis_checklist>
<redundancy_detection>
<search_strategies>
<strategy name="functionality_search">
<description>Search for similar functionality by behavior</description>
<example>
If PR adds a "formatDate" function, search for:
- "date format"
- "format.*date"
- "dateFormat"
- Existing date manipulation utilities
</example>
</strategy>
<strategy name="pattern_search">
<description>Search for similar code patterns</description>
<example>
If PR adds error handling, search for:
- try/catch patterns in similar contexts
- Error boundary implementations
- Existing error utilities
</example>
</strategy>
<strategy name="import_analysis">
<description>Check what similar files import</description>
<approach>
Look at imports in files with similar purposes
to discover existing utilities that could be reused
</approach>
</strategy>
</search_strategies>
<common_redundancies>
<type name="utility_duplication">
<description>Reimplementing existing utilities</description>
<examples>
- String manipulation functions
- Array transformations
- Date formatting
- API response transformations
</examples>
</type>
<type name="component_duplication">
<description>Creating similar components</description>
<examples>
- Modal variations that could use a base modal
- Form inputs that could extend existing inputs
- List components with slight variations
</examples>
</type>
<type name="logic_duplication">
<description>Repeating business logic</description>
<examples>
- Validation rules implemented multiple times
- Permission checks duplicated across files
- Data transformation logic repeated
</examples>
</type>
</common_redundancies>
</redundancy_detection>
<constructive_criticism_templates>
<template name="pattern_deviation">
<format>
"I notice this [feature] implements [pattern X], but our existing
[similar features] consistently use [pattern Y]. For example:
- [Link to example 1]
- [Link to example 2]
Consider aligning with the established pattern to maintain consistency.
If there's a specific reason for the deviation, it would be helpful
to document it."
</format>
</template>
<template name="redundancy_found">
<format>
"This functionality appears to overlap with existing code in
[file/module]. Specifically, [existing function/component] already
handles [similar use case].
Could we either:
1. Reuse the existing implementation
2. Extend it to cover this use case
3. Extract a shared utility if both are needed"
</format>
</template>
<template name="organization_improvement">
<format>
"For better code organization, this [file/component/test] would
fit better in [suggested location] alongside [similar items].
This follows our pattern where [explanation of pattern]."
</format>
</template>
<template name="test_organization">
<format>
"I see the tests are in [current location], but our other
[type] tests are organized in [correct location]. Moving them
would make them easier to find and maintain consistency with
tests like [example test files]."
</format>
</template>
</constructive_criticism_templates>
<severity_guidelines>
<level name="must_fix">
<description>Issues that should block PR approval</description>
<examples>
- Security vulnerabilities
- Breaking changes without migration path
- Significant pattern violations that would confuse future developers
- Major redundancy that adds maintenance burden
</examples>
</level>
<level name="should_fix">
<description>Important issues that need addressing</description>
<examples>
- Test files in wrong location
- Inconsistent error handling
- Missing critical test cases
- Code organization that violates module boundaries
</examples>
</level>
<level name="consider_fixing">
<description>Improvements that would benefit the codebase</description>
<examples>
- Minor pattern inconsistencies
- Opportunities for code reuse
- Additional test coverage
- Documentation improvements
</examples>
</level>
</severity_guidelines>
</critical_review_guidelines>

24
.roo/rules-pr-reviewer/3_common_mistakes_to_avoid.xml
View file

@ -1,24 +0,0 @@
<common_mistakes_to_avoid>
- Starting to review code WITHOUT first fetching existing comments and reviews
- Failing to create a list of existing feedback before reviewing
- Not systematically checking each existing comment against the current code
- Repeating feedback that has already been addressed in the current code
- Ignoring existing PR comments or failing to verify if they have already been resolved
- Running tests or executing code during review
- Making judgmental or harsh comments
- Providing feedback on code outside the PR's scope
- Overlooking unrelated changes not tied to the main issue
- Including ANY praise or positive comments - focus only on issues
- Using markdown headings (###, ##, #) in review comments
- Using excessive markdown formatting when plain text would suffice
- Submitting comments without user preview/approval
- Forgetting to check for an associated issue for additional context
- Missing critical security or performance issues
- Not checking for proper i18n in UI changes
- Failing to suggest breaking up large PRs
- Using internal evaluation terminology in public comments
- Not providing actionable suggestions for improvements
- Reviewing only the diff without local context
- Making assumptions instead of asking clarifying questions about potential intentions
- Forgetting to link to specific lines with full GitHub URLs
</common_mistakes_to_avoid>

238
.roo/rules-pr-reviewer/3_delegation_patterns.xml Normal file
View file

@ -0,0 +1,238 @@
<delegation_patterns>
<overview>
Patterns for effectively delegating analysis tasks to specialized modes
while maintaining context and ensuring comprehensive review coverage.
</overview>
<delegation_strategies>
<strategy name="pattern_analysis_delegation">
<when_to_delegate>
When PR contains new features or significant code changes
</when_to_delegate>
<delegate_to>code</delegate_to>
<task_template>
Analyze the following changed files for pattern consistency:
[List of changed files]
Please focus on:
1. Finding similar existing implementations in the codebase
2. Identifying established patterns for this type of feature
3. Checking if the new code follows these patterns
4. Looking for potential code redundancy
5. Verifying proper file organization
Use codebase_search and search_files to find similar code.
Document all findings with specific examples and file references.
Save your analysis to: .roo/temp/pr-[PR_NUMBER]/pattern-analysis.md
Format the output as:
## Pattern Analysis for PR #[PR_NUMBER]
### Similar Existing Implementations
### Established Patterns
### Pattern Deviations
### Redundancy Findings
### Organization Issues
</task_template>
</strategy>
<strategy name="architecture_review_delegation">
<when_to_delegate>
When PR modifies core modules, adds new modules, or changes dependencies
</when_to_delegate>
<delegate_to>architect</delegate_to>
<task_template>
Review the architectural implications of PR #[PR_NUMBER]:
Changed files:
[List of changed files]
PR Description:
[PR description]
Please analyze:
1. Module boundary adherence
2. Dependency management (new dependencies, circular dependencies)
3. Separation of concerns
4. Impact on system architecture
5. Consistency with architectural patterns
Save your findings to: .roo/temp/pr-[PR_NUMBER]/architecture-review.md
Format as:
## Architecture Review for PR #[PR_NUMBER]
### Module Boundaries
### Dependency Analysis
### Architectural Concerns
### Recommendations
</task_template>
</strategy>
<strategy name="test_analysis_delegation">
<when_to_delegate>
When PR adds or modifies test files
</when_to_delegate>
<delegate_to>test</delegate_to>
<task_template>
Analyze test changes in PR #[PR_NUMBER]:
Test files changed:
[List of test files]
Please review:
1. Test file organization and location
2. Test naming conventions
3. Coverage of edge cases
4. Mock usage patterns
5. Consistency with existing test patterns
Compare with similar existing tests in the codebase.
Save analysis to: .roo/temp/pr-[PR_NUMBER]/test-analysis.md
Format as:
## Test Analysis for PR #[PR_NUMBER]
### Test Organization
### Coverage Assessment
### Pattern Consistency
### Recommendations
</task_template>
</strategy>
<strategy name="ui_review_delegation">
<when_to_delegate>
When PR modifies UI components or adds new ones
</when_to_delegate>
<delegate_to>design-engineer</delegate_to>
<task_template>
Review UI changes in PR #[PR_NUMBER]:
UI files changed:
[List of UI files]
Please analyze:
1. Component structure consistency
2. Styling approach (Tailwind usage)
3. Accessibility considerations
4. i18n implementation
5. Component reusability
Save findings to: .roo/temp/pr-[PR_NUMBER]/ui-review.md
</task_template>
</strategy>
</delegation_strategies>
<context_preservation>
<principle name="use_temp_files">
<description>Always save delegation results to temp files</description>
<pattern>.roo/temp/pr-[PR_NUMBER]/[analysis-type].md</pattern>
</principle>
<principle name="structured_output">
<description>Request structured markdown output from delegates</description>
<benefits>
- Easy to parse and combine
- Consistent formatting
- Clear section headers
</benefits>
</principle>
<principle name="pass_context_forward">
<description>Include relevant context in delegation requests</description>
<include>
- PR number and description
- List of changed files
- Specific areas of concern
- Output file location
</include>
</principle>
</context_preservation>
<coordination_patterns>
<pattern name="sequential_delegation">
<description>Delegate tasks one at a time, using results to inform next delegation</description>
<example>
1. Pattern analysis first
2. If patterns violated, delegate architecture review
3. If tests affected, delegate test analysis
</example>
</pattern>
<pattern name="parallel_delegation">
<description>Delegate multiple independent analyses simultaneously</description>
<example>
- Pattern analysis (code mode)
- Test analysis (test mode)
- UI review (design-engineer mode)
</example>
</pattern>
<pattern name="conditional_delegation">
<description>Only delegate based on file types changed</description>
<conditions>
- If *.test.ts changed -> delegate to test mode
- If src/components/* changed -> delegate to design-engineer
- If package.json changed -> delegate to architect
</conditions>
</pattern>
</coordination_patterns>
<result_synthesis>
<step name="collect_results">
<action>Read all analysis files from temp directory</action>
<files>
- pattern-analysis.md
- architecture-review.md
- test-analysis.md
- ui-review.md
</files>
</step>
<step name="identify_themes">
<action>Find common issues across analyses</action>
<themes>
- Pattern violations mentioned multiple times
- Redundancy identified by different modes
- Organizational issues
</themes>
</step>
<step name="prioritize_findings">
<action>Categorize by severity</action>
<categories>
- Critical (blocks PR)
- Important (should fix)
- Suggestions (nice to have)
</categories>
</step>
<step name="create_unified_report">
<action>Combine all findings into final review</action>
<format>
## PR Review Summary
### Critical Issues
### Pattern Inconsistencies
### Architecture Concerns
### Test Coverage
### Suggestions
</format>
</step>
</result_synthesis>
<fallback_strategies>
<scenario name="delegation_fails">
<action>Continue with available analyses</action>
<note>Document which analyses couldn't be completed</note>
</scenario>
<scenario name="mode_unavailable">
<action>Perform basic analysis in orchestrator mode</action>
<limitations>Note limitations in final report</limitations>
</scenario>
<scenario name="timeout">
<action>Use completed analyses</action>
<timeout>Set reasonable time limits for delegations</timeout>
</scenario>
</fallback_strategies>
</delegation_patterns>

226
.roo/rules-pr-reviewer/4_github_operations.xml Normal file
View file

@ -0,0 +1,226 @@
<github_operations>
<overview>
Guidelines for handling GitHub operations with fallback strategies
when MCP tools are unavailable or failing.
</overview>
<mcp_vs_cli>
<principle>
Always try MCP tools first, fall back to GitHub CLI if they fail
</principle>
<benefits_of_mcp>
- Structured data responses
- Better error handling
- Integrated with the system
</benefits_of_mcp>
<benefits_of_cli>
- More reliable when MCP is down
- Direct GitHub API access
- Can handle complex queries
</benefits_of_cli>
</mcp_vs_cli>
<operation_patterns>
<operation name="fetch_pr_details">
<mcp_approach>
<tool>get_pull_request</tool>
<example><![CDATA[
<use_mcp_tool>
<server_name>github</server_name>
<tool_name>get_pull_request</tool_name>
<arguments>
{
"owner": "RooCodeInc",
"repo": "Roo-Code",
"pullNumber": 123
}
</arguments>
</use_mcp_tool>
]]></example>
</mcp_approach>
<cli_fallback>
<command>gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles</command>
<parse_json>true</parse_json>
</cli_fallback>
</operation>
<operation name="fetch_pr_diff">
<mcp_approach>
<tool>get_pull_request_diff</tool>
<example><![CDATA[
<use_mcp_tool>
<server_name>github</server_name>
<tool_name>get_pull_request_diff</tool_name>
<arguments>
{
"owner": "RooCodeInc",
"repo": "Roo-Code",
"pullNumber": 123
}
</arguments>
</use_mcp_tool>
]]></example>
</mcp_approach>
<cli_fallback>
<command>gh pr diff [PR_NUMBER] --repo [owner]/[repo]</command>
<save_to>.roo/temp/pr-[PR_NUMBER]/pr.diff</save_to>
</cli_fallback>
</operation>
<operation name="fetch_pr_files">
<mcp_approach>
<tool>get_pull_request_files</tool>
</mcp_approach>
<cli_fallback>
<command>gh pr view [PR_NUMBER] --repo [owner]/[repo] --json files --jq '.files[].path'</command>
<description>Lists all files changed in the PR</description>
</cli_fallback>
</operation>
<operation name="fetch_comments">
<mcp_approach>
<tool>get_pull_request_comments</tool>
</mcp_approach>
<cli_fallback>
<command>gh pr view [PR_NUMBER] --repo [owner]/[repo] --json comments --jq '.comments'</command>
</cli_fallback>
</operation>
<operation name="fetch_reviews">
<mcp_approach>
<tool>get_pull_request_reviews</tool>
</mcp_approach>
<cli_fallback>
<command>gh pr view [PR_NUMBER] --repo [owner]/[repo] --json reviews --jq '.reviews'</command>
</cli_fallback>
</operation>
<operation name="checkout_pr">
<cli_only>
<command>gh pr checkout [PR_NUMBER] --repo [owner]/[repo]</command>
<note>No MCP equivalent - always use CLI</note>
</cli_only>
</operation>
<operation name="post_comment">
<mcp_approach>
<tool>add_issue_comment</tool>
<note>PRs use same comment system as issues</note>
</mcp_approach>
<cli_fallback>
<command>gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body-file [file_path]</command>
<alternative>gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body "[comment_text]"</alternative>
</cli_fallback>
</operation>
<operation name="create_review">
<mcp_approach>
<sequence>
1. create_pending_pull_request_review
2. add_pull_request_review_comment_to_pending_review (multiple times)
3. submit_pending_pull_request_review
</sequence>
</mcp_approach>
<cli_fallback>
<command>gh pr review [PR_NUMBER] --repo [owner]/[repo] --comment --body-file [review_file]</command>
</cli_fallback>
</operation>
</operation_patterns>
<error_handling>
<scenario name="mcp_server_unavailable">
<detection>
Error message contains "MCP server" or "github server not found"
</detection>
<action>
Immediately switch to CLI commands for all operations
</action>
</scenario>
<scenario name="api_rate_limit">
<detection>
Error contains "rate limit" or status code 403
</detection>
<action>
1. Wait briefly (30 seconds)
2. Retry with CLI using --limit flag
3. Reduce number of API calls
</action>
</scenario>
<scenario name="authentication_failure">
<detection>
Error contains "authentication" or status code 401
</detection>
<action>
1. Inform user about auth issue
2. Suggest checking gh auth status
3. Continue with available data
</action>
</scenario>
<scenario name="pr_not_found">
<detection>
Error contains "not found" or status code 404
</detection>
<action>
1. Verify PR number and repository
2. Ask user to confirm details
3. Check if PR is from a fork
</action>
</scenario>
</error_handling>
<data_handling>
<principle name="save_everything">
<description>Always save API responses to temp files</description>
<reason>Preserve data in case of failures</reason>
</principle>
<principle name="parse_json_safely">
<description>Use jq or built-in JSON parsing</description>
<example>
gh pr view --json files --jq '.files[].path'
</example>
</principle>
<principle name="handle_large_prs">
<description>For PRs with many files, process in batches</description>
<threshold>More than 50 files</threshold>
</principle>
</data_handling>
<cli_command_reference>
<command_group name="pr_info">
<command>gh pr view [number] --json [fields]</command>
<fields>
number, title, author, state, body, url,
headRefName, baseRefName, files, additions,
deletions, changedFiles, comments, reviews
</fields>
</command_group>
<command_group name="pr_interaction">
<command>gh pr checkout [number]</command>
<command>gh pr diff [number]</command>
<command>gh pr comment [number] --body "[text]"</command>
<command>gh pr review [number] --comment --body "[text]"</command>
</command_group>
<command_group name="issue_info">
<command>gh issue view [number] --json [fields]</command>
<fields>
number, title, body, author, state,
labels, assignees, milestone
</fields>
</command_group>
</cli_command_reference>
<best_practices>
<practice>Always specify --repo to avoid ambiguity</practice>
<practice>Use --json for structured data</practice>
<practice>Save command outputs to temp files</practice>
<practice>Check gh auth status before operations</practice>
<practice>Handle both personal repos and org repos</practice>
</best_practices>
</github_operations>

356
.roo/rules-pr-reviewer/5_context_management.xml Normal file
View file

@ -0,0 +1,356 @@
<context_management>
<overview>
Strategies for maintaining review context across delegated tasks and
ensuring no information is lost during the orchestration process.
</overview>
<context_files>
<file name="review-context.json">
<purpose>Central tracking file for the entire review process</purpose>
<location>.roo/temp/pr-[PR_NUMBER]/review-context.json</location>
<structure>
{
"prNumber": "string",
"repository": "string",
"reviewStartTime": "ISO timestamp",
"calledByMode": "string or null",
"prMetadata": {
"title": "string",
"author": "string",
"state": "string",
"baseRefName": "string",
"headRefName": "string",
"additions": "number",
"deletions": "number",
"changedFiles": "number"
},
"linkedIssue": {
"number": "number",
"title": "string",
"body": "string"
},
"existingComments": [],
"existingReviews": [],
"filesChanged": [],
"delegatedTasks": [
{
"mode": "string",
"status": "pending|completed|failed",
"outputFile": "string",
"startTime": "ISO timestamp",
"endTime": "ISO timestamp"
}
],
"findings": {
"critical": [],
"patterns": [],
"redundancy": [],
"architecture": [],
"tests": []
},
"reviewStatus": "initialized|analyzing|synthesizing|completed"
}
</structure>
</file>
<file name="pr-metadata.json">
<purpose>Raw PR data from GitHub</purpose>
<location>.roo/temp/pr-[PR_NUMBER]/pr-metadata.json</location>
</file>
<file name="existing-feedback.json">
<purpose>All existing comments and reviews</purpose>
<location>.roo/temp/pr-[PR_NUMBER]/existing-feedback.json</location>
</file>
<file name="pattern-analysis.md">
<purpose>Output from code mode delegation</purpose>
<location>.roo/temp/pr-[PR_NUMBER]/pattern-analysis.md</location>
</file>
<file name="architecture-review.md">
<purpose>Output from architect mode delegation</purpose>
<location>.roo/temp/pr-[PR_NUMBER]/architecture-review.md</location>
</file>
<file name="test-analysis.md">
<purpose>Output from test mode delegation</purpose>
<location>.roo/temp/pr-[PR_NUMBER]/test-analysis.md</location>
</file>
<file name="final-review.md">
<purpose>Synthesized review ready for posting</purpose>
<location>.roo/temp/pr-[PR_NUMBER]/final-review.md</location>
</file>
</context_files>
<update_patterns>
<pattern name="after_github_fetch">
<action>Update review-context.json with PR metadata</action>
<example><![CDATA[
<read_file>
<path>.roo/temp/pr-123/review-context.json</path>
</read_file>
<!-- Parse and update the JSON -->
<write_to_file>
<path>.roo/temp/pr-123/review-context.json</path>
<content>
{
...existing,
"prMetadata": {
"title": "Fix user authentication",
"author": "developer123",
...
},
"filesChanged": ["src/auth.ts", "tests/auth.test.ts"],
"reviewStatus": "analyzing"
}
</content>
</write_to_file>
]]></example>
</pattern>
<pattern name="after_delegation">
<action>Update delegatedTasks array with task status</action>
<fields>
- mode: Which mode was delegated to
- status: pending -> completed/failed
- outputFile: Where results were saved
- timestamps: Start and end times
</fields>
</pattern>
<pattern name="after_synthesis">
<action>Update findings object with categorized issues</action>
<categories>
- critical: Must-fix issues
- patterns: Pattern inconsistencies
- redundancy: Duplicate code findings
- architecture: Architectural concerns
- tests: Test-related issues
</categories>
</pattern>
</update_patterns>
<context_preservation_strategies>
<strategy name="atomic_updates">
<description>Always read-modify-write for JSON updates</description>
<steps>
1. Read current context file
2. Parse JSON
3. Update specific fields
4. Write entire updated JSON
</steps>
</strategy>
<strategy name="backup_critical_data">
<description>Save copies of important data</description>
<files>
- PR diff before analysis
- Existing comments before review
- Each delegation output
</files>
</strategy>
<strategy name="status_tracking">
<description>Track review progress through status field</description>
<states>
- initialized: Just started
- analyzing: Delegating tasks
- synthesizing: Combining results
- completed: Ready for user
</states>
</strategy>
</context_preservation_strategies>
<recovery_procedures>
<scenario name="partial_failure">
<description>Some delegations failed</description>
<action>
1. Mark failed tasks in context
2. Continue with available data
3. Note limitations in final review
</action>
</scenario>
<scenario name="context_corruption">
<description>JSON file becomes invalid</description>
<action>
1. Try to recover from backups
2. Reconstruct from individual files
3. Start fresh if necessary
</action>
</scenario>
<scenario name="interrupted_review">
<description>Review process interrupted</description>
<action>
1. Check reviewStatus field
2. Resume from last completed step
3. Re-run failed delegations
</action>
</scenario>
</recovery_procedures>
<best_practices>
<practice name="always_update_status">
Keep reviewStatus current to enable recovery
</practice>
<practice name="timestamp_everything">
Add timestamps to all operations for debugging
</practice>
<practice name="validate_json">
Ensure JSON is valid before writing
</practice>
<practice name="use_descriptive_filenames">
Make it clear what each file contains
</practice>
<practice name="clean_up_old_reviews">
Suggest cleaning .roo/temp/ periodically
</practice>
</best_practices>
<example_workflow>
<step number="1">
<action>Initialize context</action>
<code><![CDATA[
<execute_command>
<command>New-Item -ItemType Directory -Force -Path ".roo/temp/pr-123"</command>
</execute_command>
<write_to_file>
<path>.roo/temp/pr-123/review-context.json</path>
<content>
{
"prNumber": "123",
"repository": "RooCodeInc/Roo-Code",
"reviewStartTime": "2025-01-04T18:00:00Z",
"calledByMode": null,
"prMetadata": {},
"linkedIssue": {},
"existingComments": [],
"existingReviews": [],
"filesChanged": [],
"delegatedTasks": [],
"findings": {
"critical": [],
"patterns": [],
"redundancy": [],
"architecture": [],
"tests": []
},
"reviewStatus": "initialized"
}
</content>
</write_to_file>
]]></code>
</step>
<step number="2">
<action>Update after GitHub fetch</action>
<code><![CDATA[
<read_file>
<path>.roo/temp/pr-123/review-context.json</path>
</read_file>
<!-- Update with PR data -->
<write_to_file>
<path>.roo/temp/pr-123/review-context.json</path>
<content>
{
...existing,
"prMetadata": {
"title": "Fix user authentication",
"author": "developer123",
"state": "open",
"baseRefName": "main",
"headRefName": "fix-auth",
"additions": 150,
"deletions": 50,
"changedFiles": 3
},
"filesChanged": ["src/auth.ts", "tests/auth.test.ts", "docs/auth.md"],
"reviewStatus": "analyzing"
}
</content>
</write_to_file>
]]></code>
</step>
<step number="3">
<action>Track delegation</action>
<code><![CDATA[
<!-- Before delegation -->
<read_file>
<path>.roo/temp/pr-123/review-context.json</path>
</read_file>
<!-- Update to add pending task -->
<write_to_file>
<path>.roo/temp/pr-123/review-context.json</path>
<content>
{
...existing,
"delegatedTasks": [
...existing,
{
"mode": "code",
"status": "pending",
"outputFile": "pattern-analysis.md",
"startTime": "2025-01-04T18:05:00Z",
"endTime": null
}
]
}
</content>
</write_to_file>
<!-- After delegation completes -->
<!-- Update task status to completed -->
]]></code>
</step>
<step number="4">
<action>Synthesize results</action>
<code><![CDATA[
<!-- Read all analysis files -->
<read_file>
<path>.roo/temp/pr-123/pattern-analysis.md</path>
</read_file>
<read_file>
<path>.roo/temp/pr-123/architecture-review.md</path>
</read_file>
<read_file>
<path>.roo/temp/pr-123/test-analysis.md</path>
</read_file>
<!-- Update findings and status -->
<write_to_file>
<path>.roo/temp/pr-123/review-context.json</path>
<content>
{
...existing,
"findings": {
"critical": ["Missing error handling in auth.ts"],
"patterns": ["Inconsistent naming convention"],
"redundancy": ["Duplicate validation logic"],
"architecture": [],
"tests": ["Missing test for edge case"]
},
"reviewStatus": "completed"
}
</content>
</write_to_file>
]]></code>
</step>
</example_workflow>
</context_management>

36
.roomodes
View file

@ -139,14 +139,28 @@ customModes:
- slug: pr-reviewer
name: 🔍 PR Reviewer
roleDefinition: |-
You are Roo, a pull request reviewer specializing in code quality, structure, and translation consistency. Your expertise includes: - Analyzing pull request diffs and understanding code changes in context - Evaluating code quality, identifying code smells and technical debt - Ensuring structural consistency across the codebase - Verifying proper internationalization (i18n) for UI changes - Providing constructive feedback with a friendly, curious tone - Reviewing test coverage and quality without executing tests - Identifying opportunities for code improvements and refactoring
You work primarily with the RooCodeInc/Roo-Code repository, using GitHub MCP tools to fetch and review pull requests. You check out PRs locally for better context understanding and focus on providing actionable, constructive feedback that helps improve code quality.
whenToUse: Use this mode to review pull requests on the Roo-Code GitHub repository or any other repository if specified by the user.
You are Roo, a critical pull request review orchestrator specializing in code quality, architectural consistency, and codebase organization. Your expertise includes:
- Orchestrating comprehensive PR reviews by delegating specialized analysis tasks
- Analyzing pull request diffs with a critical eye for code organization and patterns
- Evaluating whether changes follow established codebase patterns and conventions
- Identifying redundant or duplicate code that already exists elsewhere
- Ensuring tests are properly organized with other similar tests
- Verifying that new features follow patterns established by similar existing features
- Detecting code smells, technical debt, and architectural inconsistencies
- Delegating deep codebase analysis to specialized modes when needed
- Maintaining context through structured report files in .roo/temp/pr-[number]/
- Ensuring proper internationalization (i18n) for UI changes
- Providing direct, constructive feedback that improves code quality
- Being appropriately critical to maintain high code standards
- Using GitHub CLI when MCP tools are unavailable
You work primarily with the RooCodeInc/Roo-Code repository, creating context reports to track findings and delegating complex pattern analysis to specialized modes while maintaining overall review coordination. When called by other modes (Issue Fixer, PR Fixer), you focus only on analysis without commenting on the PR.
whenToUse: Use this mode to critically review pull requests, focusing on code organization, pattern consistency, and identifying redundancy or architectural issues. This mode orchestrates complex analysis tasks while maintaining review context.
groups:
- read
- - edit
- fileRegex: \.md$
description: Markdown files only
- fileRegex: (\.md$|\.roo/temp/pr-.*\.(json|md|txt)$)
description: Markdown files and PR review context files
- mcp
- command
source: project
@ -182,3 +196,15 @@ customModes:
- edit
- command
source: project
- slug: pr-fixer-orchestrator
name: 🛠️ PR Fixer Orchestrator
roleDefinition: |-
You are an orchestrator for fixing pull requests. Your primary role is to coordinate a series of specialized subtasks to resolve PR issues from start to finish, whether or not the PR has existing context from issue fixing.
**Your Orchestration Responsibilities:** - Delegate analysis, implementation, testing, and review to specialized subtasks using the `new_task` tool. - Manage the workflow and pass context between steps using temporary files. - Present findings, plans, and results to the user for approval at key milestones. - Ensure the PR branch is properly synced with main and ready for merge.
**Your Core Expertise Includes:** - Analyzing PR feedback, failing tests, and merge conflicts. - Understanding the underlying issue or feature being implemented. - Exploring codebases to identify all affected files and dependencies. - Understanding CI/CD pipeline failures and test results. - Coordinating code fixes based on review comments. - Managing git operations including rebases and conflict resolution. - Ensuring proper testing and validation of changes. - Overseeing PR review before final submission. - Using GitHub CLI (gh) for all GitHub operations.
whenToUse: Use this mode to orchestrate the process of fixing a pull request. Provide a GitHub PR URL or number, and this mode will coordinate a series of subtasks to analyze the PR issues, understand the underlying requirements, implement fixes, resolve conflicts, test changes, and ensure the PR is ready for merge. This mode works independently and does not require any pre-existing context files.
groups:
- read
- edit
- command
source: project

16
packages/types/src/codebase-index.ts
View file

@ -1,5 +1,16 @@
import { z } from "zod"
/**
* Codebase Index Constants
*/
export const CODEBASE_INDEX_DEFAULTS = {
MIN_SEARCH_RESULTS: 10,
MAX_SEARCH_RESULTS: 200,
DEFAULT_SEARCH_RESULTS: 50,
SEARCH_RESULTS_STEP: 10,
DEFAULT_SEARCH_MIN_SCORE: 0.4,
} as const
/**
* CodebaseIndexConfig
*/
@ -11,6 +22,11 @@ export const codebaseIndexConfigSchema = z.object({
codebaseIndexEmbedderBaseUrl: z.string().optional(),
codebaseIndexEmbedderModelId: z.string().optional(),
codebaseIndexSearchMinScore: z.number().min(0).max(1).optional(),
codebaseIndexSearchMaxResults: z
.number()
.min(CODEBASE_INDEX_DEFAULTS.MIN_SEARCH_RESULTS)
.max(CODEBASE_INDEX_DEFAULTS.MAX_SEARCH_RESULTS)
.optional(),
})
export type CodebaseIndexConfig = z.infer<typeof codebaseIndexConfigSchema>

1
src/core/webview/webviewMessageHandler.ts
View file

@ -1840,6 +1840,7 @@ export const webviewMessageHandler = async (
codebaseIndexEmbedderModelId: settings.codebaseIndexEmbedderModelId,
codebaseIndexOpenAiCompatibleBaseUrl: settings.codebaseIndexOpenAiCompatibleBaseUrl,
codebaseIndexOpenAiCompatibleModelDimension: settings.codebaseIndexOpenAiCompatibleModelDimension,
codebaseIndexSearchMaxResults: settings.codebaseIndexSearchMaxResults,
}
// Save global state first

62
src/services/code-index/__tests__/config-manager.spec.ts
View file

@ -767,7 +767,7 @@ describe("CodeIndexConfigManager", () => {
expect(configManager.currentSearchMinScore).toBe(0.15)
})
it("should fall back to default SEARCH_MIN_SCORE when neither user setting nor model threshold exists", async () => {
it("should fall back to default DEFAULT_SEARCH_MIN_SCORE when neither user setting nor model threshold exists", async () => {
mockContextProxy.getGlobalState.mockReturnValue({
codebaseIndexEnabled: true,
codebaseIndexQdrantUrl: "http://qdrant.local",
@ -781,7 +781,7 @@ describe("CodeIndexConfigManager", () => {
})
await configManager.loadConfiguration()
// Should fall back to default SEARCH_MIN_SCORE (0.4)
// Should fall back to default DEFAULT_SEARCH_MIN_SCORE (0.4)
expect(configManager.currentSearchMinScore).toBe(0.4)
})
@ -881,6 +881,61 @@ describe("CodeIndexConfigManager", () => {
expect(anotherManager.currentSearchMinScore).toBe(0.4) // Default
})
})
describe("currentSearchMaxResults", () => {
it("should return user setting when provided, otherwise default", async () => {
// Test 1: User setting takes precedence
mockContextProxy.getGlobalState.mockReturnValue({
codebaseIndexEnabled: true,
codebaseIndexQdrantUrl: "http://qdrant.local",
codebaseIndexEmbedderProvider: "openai",
codebaseIndexEmbedderModelId: "text-embedding-3-small",
codebaseIndexSearchMaxResults: 150, // User setting
})
await configManager.loadConfiguration()
expect(configManager.currentSearchMaxResults).toBe(150) // User setting
// Test 2: Default when no user setting
mockContextProxy.getGlobalState.mockReturnValue({
codebaseIndexEnabled: true,
codebaseIndexQdrantUrl: "http://qdrant.local",
codebaseIndexEmbedderProvider: "openai",
codebaseIndexEmbedderModelId: "text-embedding-3-small",
// No user setting
})
const newManager = new CodeIndexConfigManager(mockContextProxy)
await newManager.loadConfiguration()
expect(newManager.currentSearchMaxResults).toBe(50) // Default (DEFAULT_MAX_SEARCH_RESULTS)
// Test 3: Boundary values
mockContextProxy.getGlobalState.mockReturnValue({
codebaseIndexEnabled: true,
codebaseIndexQdrantUrl: "http://qdrant.local",
codebaseIndexEmbedderProvider: "openai",
codebaseIndexEmbedderModelId: "text-embedding-3-small",
codebaseIndexSearchMaxResults: 10, // Minimum allowed
})
const minManager = new CodeIndexConfigManager(mockContextProxy)
await minManager.loadConfiguration()
expect(minManager.currentSearchMaxResults).toBe(10)
// Test 4: Maximum value
mockContextProxy.getGlobalState.mockReturnValue({
codebaseIndexEnabled: true,
codebaseIndexQdrantUrl: "http://qdrant.local",
codebaseIndexEmbedderProvider: "openai",
codebaseIndexEmbedderModelId: "text-embedding-3-small",
codebaseIndexSearchMaxResults: 200, // Maximum allowed
})
const maxManager = new CodeIndexConfigManager(mockContextProxy)
await maxManager.loadConfiguration()
expect(maxManager.currentSearchMaxResults).toBe(200)
})
})
})
describe("empty/missing API key handling", () => {
@ -1157,9 +1212,12 @@ describe("CodeIndexConfigManager", () => {
modelId: "text-embedding-3-large",
openAiOptions: { openAiNativeApiKey: "test-openai-key" },
ollamaOptions: { ollamaBaseUrl: undefined },
geminiOptions: undefined,
openAiCompatibleOptions: undefined,
qdrantUrl: "http://qdrant.local",
qdrantApiKey: "test-qdrant-key",
searchMinScore: 0.4,
searchMaxResults: 50,
})
})

19
src/services/code-index/config-manager.ts
View file

@ -2,7 +2,7 @@ import { ApiHandlerOptions } from "../../shared/api"
import { ContextProxy } from "../../core/config/ContextProxy"
import { EmbedderProvider } from "./interfaces/manager"
import { CodeIndexConfig, PreviousConfigSnapshot } from "./interfaces/config"
import { SEARCH_MIN_SCORE } from "./constants"
import { DEFAULT_SEARCH_MIN_SCORE, DEFAULT_MAX_SEARCH_RESULTS } from "./constants"
import { getDefaultModelId, getModelDimension, getModelScoreThreshold } from "../../shared/embeddingModels"
/**
@ -20,6 +20,7 @@ export class CodeIndexConfigManager {
private qdrantUrl?: string = "http://localhost:6333"
private qdrantApiKey?: string
private searchMinScore?: number
private searchMaxResults?: number
constructor(private readonly contextProxy: ContextProxy) {
// Initialize with current configuration to avoid false restart triggers
@ -46,6 +47,7 @@ export class CodeIndexConfigManager {
codebaseIndexEmbedderBaseUrl: "",
codebaseIndexEmbedderModelId: "",
codebaseIndexSearchMinScore: undefined,
codebaseIndexSearchMaxResults: undefined,
}
const {
@ -55,6 +57,7 @@ export class CodeIndexConfigManager {
codebaseIndexEmbedderBaseUrl,
codebaseIndexEmbedderModelId,
codebaseIndexSearchMinScore,
codebaseIndexSearchMaxResults,
} = codebaseIndexConfig
const openAiKey = this.contextProxy?.getSecret("codeIndexOpenAiKey") ?? ""
@ -71,6 +74,7 @@ export class CodeIndexConfigManager {
this.qdrantUrl = codebaseIndexQdrantUrl
this.qdrantApiKey = qdrantApiKey ?? ""
this.searchMinScore = codebaseIndexSearchMinScore
this.searchMaxResults = codebaseIndexSearchMaxResults
this.openAiOptions = { openAiNativeApiKey: openAiKey }
// Set embedder provider with support for openai-compatible
@ -334,6 +338,7 @@ export class CodeIndexConfigManager {
qdrantUrl: this.qdrantUrl,
qdrantApiKey: this.qdrantApiKey,
searchMinScore: this.currentSearchMinScore,
searchMaxResults: this.currentSearchMaxResults,
}
}
@ -377,7 +382,7 @@ export class CodeIndexConfigManager {
/**
* Gets the configured minimum search score based on user setting, model-specific threshold, or fallback.
* Priority: 1) User setting, 2) Model-specific threshold, 3) Default SEARCH_MIN_SCORE constant.
* Priority: 1) User setting, 2) Model-specific threshold, 3) Default DEFAULT_SEARCH_MIN_SCORE constant.
*/
public get currentSearchMinScore(): number {
// First check if user has configured a custom score threshold
@ -388,6 +393,14 @@ export class CodeIndexConfigManager {
// Fall back to model-specific threshold
const currentModelId = this.modelId ?? getDefaultModelId(this.embedderProvider)
const modelSpecificThreshold = getModelScoreThreshold(this.embedderProvider, currentModelId)
return modelSpecificThreshold ?? SEARCH_MIN_SCORE
return modelSpecificThreshold ?? DEFAULT_SEARCH_MIN_SCORE
}
/**
* Gets the configured maximum search results.
* Returns user setting if configured, otherwise returns default.
*/
public get currentSearchMaxResults(): number {
return this.searchMaxResults ?? DEFAULT_MAX_SEARCH_RESULTS
}
}

8
src/services/code-index/constants/index.ts
View file

@ -1,12 +1,14 @@
import { CODEBASE_INDEX_DEFAULTS } from "@roo-code/types"
/**Parser */
export const MAX_BLOCK_CHARS = 1000
export const MIN_BLOCK_CHARS = 100
export const MIN_BLOCK_CHARS = 50
export const MIN_CHUNK_REMAINDER_CHARS = 200 // Minimum characters for the *next* chunk after a split
export const MAX_CHARS_TOLERANCE_FACTOR = 1.15 // 15% tolerance for max chars
/**Search */
export const SEARCH_MIN_SCORE = 0.4
export const MAX_SEARCH_RESULTS = 50 // Maximum number of search results to return
export const DEFAULT_SEARCH_MIN_SCORE = CODEBASE_INDEX_DEFAULTS.DEFAULT_SEARCH_MIN_SCORE
export const DEFAULT_MAX_SEARCH_RESULTS = CODEBASE_INDEX_DEFAULTS.DEFAULT_SEARCH_RESULTS
/**File Watcher */
export const QDRANT_CODE_BLOCK_NAMESPACE = "f47ac10b-58cc-4372-a567-0e02b2c3d479"

1
src/services/code-index/interfaces/config.ts
View file

@ -16,6 +16,7 @@ export interface CodeIndexConfig {
qdrantUrl?: string
qdrantApiKey?: string
searchMinScore?: number
searchMaxResults?: number
}
/**

11
src/services/code-index/interfaces/vector-store.ts
View file

@ -23,10 +23,17 @@ export interface IVectorStore {
/**
* Searches for similar vectors
* @param queryVector Vector to search for
* @param limit Maximum number of results to return
* @param directoryPrefix Optional directory prefix to filter results
* @param minScore Optional minimum score threshold
* @param maxResults Optional maximum number of results to return
* @returns Promise resolving to search results
*/
search(queryVector: number[], directoryPrefix?: string, minScore?: number): Promise<VectorStoreSearchResult[]>
search(
queryVector: number[],
directoryPrefix?: string,
minScore?: number,
maxResults?: number,
): Promise<VectorStoreSearchResult[]>
/**
* Deletes points by file path

63
src/services/code-index/processors/__tests__/parser.spec.ts
View file

@ -188,6 +188,50 @@ describe("CodeParser", () => {
const result = await parser["_performFallbackChunking"]("test.js", shortContent, "hash", new Set())
expect(result).toEqual([])
})
it("should respect 50-character minimum threshold for all languages", async () => {
// Test content that is exactly 49 characters (should be filtered)
const shortContent = "function f() { return 1; } // Exactly 49 chars!!!"
expect(shortContent.length).toBe(49)
// Test content that is exactly 50 characters (should be included)
const minContent = "function g() { return 42; } // Exactly 50 chars!!!"
expect(minContent.length).toBe(50)
// Test content that is longer than 50 characters (should be included)
const longContent = "function calculate() { return 1 + 2 + 3; } // This is longer than 50 characters"
expect(longContent.length).toBeGreaterThan(50)
// Mock the language parser to return captures for our test content
const mockCapture = (content: string, startLine: number = 0) => ({
node: {
text: content,
startPosition: { row: startLine },
endPosition: { row: startLine },
type: "function_declaration",
childForFieldName: vi.fn().mockReturnValue(null),
children: [],
},
name: "definition.function",
})
// Test short content (49 chars) - should be filtered out
mockLanguageParser.js.query.captures.mockReturnValue([mockCapture(shortContent)])
const shortResult = await parser["parseContent"]("test.js", shortContent, "hash1")
expect(shortResult).toEqual([])
// Test minimum content (50 chars) - should be included
mockLanguageParser.js.query.captures.mockReturnValue([mockCapture(minContent)])
const minResult = await parser["parseContent"]("test.js", minContent, "hash2")
expect(minResult.length).toBe(1)
expect(minResult[0].content).toBe(minContent)
// Test longer content - should be included
mockLanguageParser.js.query.captures.mockReturnValue([mockCapture(longContent)])
const longResult = await parser["parseContent"]("test.js", longContent, "hash3")
expect(longResult.length).toBe(1)
expect(longResult[0].content).toBe(longContent)
})
})
describe("_chunkLeafNodeByLines", () => {
@ -217,7 +261,7 @@ describe("CodeParser", () => {
it("should handle oversized lines by splitting them", async () => {
const longLine = "a".repeat(2000)
const lines = ["normal", longLine, "normal"]
const result = await parser["_chunkTextByLines"](lines, "test.js", "hash", "test_type", new Set())
const result = await parser["_chunkTextByLines"](lines, "test.js", "hash", "test_type", new Set(), 100)
const segments = result.filter((r) => r.type === "test_type_segment")
expect(segments.length).toBeGreaterThan(1)
@ -227,7 +271,7 @@ describe("CodeParser", () => {
const lines = Array(100)
.fill("line with 10 chars")
.map((_, i) => `${i}: line`)
const result = await parser["_chunkTextByLines"](lines, "test.js", "hash", "test_type", new Set())
const result = await parser["_chunkTextByLines"](lines, "test.js", "hash", "test_type", new Set(), 100)
result.forEach((chunk) => {
expect(chunk.content.length).toBeGreaterThanOrEqual(100)
@ -544,7 +588,7 @@ ${largeContent}`
// Each chunk should be within 30% of average size (re-balanced)
expect(Math.abs(size - avgSize) / avgSize).toBeLessThan(0.3)
// Each chunk should respect MIN_BLOCK_CHARS
expect(size).toBeGreaterThanOrEqual(100)
expect(size).toBeGreaterThanOrEqual(50)
})
// Verify each chunk has unique segment hash
@ -563,7 +607,7 @@ This paragraph continues with more details to ensure we exceed the minimum block
Content under the first header with enough text to be indexed properly.
This section contains multiple lines to ensure it meets the minimum character requirements.
We need at least 100 characters for a section to be included in the index.
We need at least 50 characters for a section to be included in the index.
This additional content ensures the header section will be processed correctly.`
const markdownContent = `${preHeaderContent}
@ -595,8 +639,8 @@ ${headerContent}`
const result = await parser.parseFile("test.md", { content: markdownContent })
// Should have exactly 2 blocks: pre-header content and header section
expect(result.length).toBe(2)
// With MIN_BLOCK_CHARS=50, content may be split into more blocks
expect(result.length).toBeGreaterThanOrEqual(2)
// First block should be the content before the header
expect(result[0]).toMatchObject({
@ -943,16 +987,17 @@ This content verifies that processing continues after multiple oversized lines.`
it("should return empty array for markdown content below MIN_BLOCK_CHARS threshold", async () => {
const parser = new CodeParser()
const smallContent = "This is a small markdown file.\nWith just a few lines.\nNothing special."
// Create content that is below the new MIN_BLOCK_CHARS threshold of 50
const smallContent = "Small markdown.\nJust a bit.\nTiny."
// Mock parseMarkdown to return empty array (no headers)
vi.mocked(parseMarkdown).mockReturnValue([])
const results = await parser["parseContent"]("test.md", smallContent, "test-hash")
// Should return empty array since content (71 chars) is below MIN_BLOCK_CHARS (100)
// Should return empty array since content is below MIN_BLOCK_CHARS (50)
expect(results.length).toBe(0)
expect(smallContent.length).toBeLessThan(100) // Verify our test assumption
expect(smallContent.length).toBeLessThan(50) // Verify our test assumption
})
})
})

6
src/services/code-index/processors/parser.ts
View file

@ -161,8 +161,7 @@ export class CodeParser implements ICodeParser {
// If it has children, process them instead
queue.push(...currentNode.children.filter((child) => child !== null))
} else {
// If it's a leaf node, chunk it (passing MIN_BLOCK_CHARS as per Task 1 Step 5)
// Note: _chunkLeafNodeByLines logic might need further adjustment later
// If it's a leaf node, chunk it
const chunkedBlocks = this._chunkLeafNodeByLines(
currentNode,
filePath,
@ -201,7 +200,7 @@ export class CodeParser implements ICodeParser {
}
}
}
// Nodes smaller than MIN_BLOCK_CHARS are ignored
// Nodes smaller than minBlockChars are ignored
}
return results
@ -214,7 +213,6 @@ export class CodeParser implements ICodeParser {
lines: string[],
filePath: string,
fileHash: string,
chunkType: string,
seenSegmentHashes: Set<string>,
baseStartLine: number = 1, // 1-based start line of the *first* line in the `lines` array

3
src/services/code-index/search-service.ts
View file

@ -30,6 +30,7 @@ export class CodeIndexSearchService {
}
const minScore = this.configManager.currentSearchMinScore
const maxResults = this.configManager.currentSearchMaxResults
const currentState = this.stateManager.getCurrentStatus().systemStatus
if (currentState !== "Indexed" && currentState !== "Indexing") {
@ -52,7 +53,7 @@ export class CodeIndexSearchService {
}
// Perform search
const results = await this.vectorStore.search(vector, normalizedPrefix, minScore)
const results = await this.vectorStore.search(vector, normalizedPrefix, minScore, maxResults)
return results
} catch (error) {
console.error("[CodeIndexSearchService] Error during search:", error)

46
src/services/code-index/vector-store/__tests__/qdrant-client.spec.ts
View file

@ -3,7 +3,7 @@ import { createHash } from "crypto"
import { QdrantVectorStore } from "../qdrant-client"
import { getWorkspacePath } from "../../../../utils/path"
import { MAX_SEARCH_RESULTS, SEARCH_MIN_SCORE } from "../../constants"
import { DEFAULT_MAX_SEARCH_RESULTS, DEFAULT_SEARCH_MIN_SCORE } from "../../constants"
// Mocks
vitest.mock("@qdrant/js-client-rest")
@ -1005,8 +1005,8 @@ describe("QdrantVectorStore", () => {
expect(mockQdrantClientInstance.query).toHaveBeenCalledWith(expectedCollectionName, {
query: queryVector,
filter: undefined,
score_threshold: SEARCH_MIN_SCORE,
limit: MAX_SEARCH_RESULTS,
score_threshold: DEFAULT_SEARCH_MIN_SCORE,
limit: DEFAULT_MAX_SEARCH_RESULTS,
params: {
hnsw_ef: 128,
exact: false,
@ -1056,8 +1056,8 @@ describe("QdrantVectorStore", () => {
},
],
},
score_threshold: SEARCH_MIN_SCORE,
limit: MAX_SEARCH_RESULTS,
score_threshold: DEFAULT_SEARCH_MIN_SCORE,
limit: DEFAULT_MAX_SEARCH_RESULTS,
params: {
hnsw_ef: 128,
exact: false,
@ -1083,7 +1083,31 @@ describe("QdrantVectorStore", () => {
query: queryVector,
filter: undefined,
score_threshold: customMinScore,
limit: MAX_SEARCH_RESULTS,
limit: DEFAULT_MAX_SEARCH_RESULTS,
params: {
hnsw_ef: 128,
exact: false,
},
with_payload: {
include: ["filePath", "codeChunk", "startLine", "endLine", "pathSegments"],
},
})
})
it("should use custom maxResults when provided", async () => {
const queryVector = [0.1, 0.2, 0.3]
const customMaxResults = 100
const mockQdrantResults = { points: [] }
mockQdrantClientInstance.query.mockResolvedValue(mockQdrantResults)
await vectorStore.search(queryVector, undefined, undefined, customMaxResults)
expect(mockQdrantClientInstance.query).toHaveBeenCalledWith(expectedCollectionName, {
query: queryVector,
filter: undefined,
score_threshold: DEFAULT_SEARCH_MIN_SCORE,
limit: customMaxResults,
params: {
hnsw_ef: 128,
exact: false,
@ -1229,8 +1253,8 @@ describe("QdrantVectorStore", () => {
},
],
},
score_threshold: SEARCH_MIN_SCORE,
limit: MAX_SEARCH_RESULTS,
score_threshold: DEFAULT_SEARCH_MIN_SCORE,
limit: DEFAULT_MAX_SEARCH_RESULTS,
params: {
hnsw_ef: 128,
exact: false,
@ -1254,7 +1278,7 @@ describe("QdrantVectorStore", () => {
;(console.error as any).mockRestore()
})
it("should use constants MAX_SEARCH_RESULTS and SEARCH_MIN_SCORE correctly", async () => {
it("should use constants DEFAULT_MAX_SEARCH_RESULTS and DEFAULT_SEARCH_MIN_SCORE correctly", async () => {
const queryVector = [0.1, 0.2, 0.3]
const mockQdrantResults = { points: [] }
@ -1263,8 +1287,8 @@ describe("QdrantVectorStore", () => {
await vectorStore.search(queryVector)
const callArgs = mockQdrantClientInstance.query.mock.calls[0][1]
expect(callArgs.limit).toBe(MAX_SEARCH_RESULTS)
expect(callArgs.score_threshold).toBe(SEARCH_MIN_SCORE)
expect(callArgs.limit).toBe(DEFAULT_MAX_SEARCH_RESULTS)
expect(callArgs.score_threshold).toBe(DEFAULT_SEARCH_MIN_SCORE)
})
})
})

15
src/services/code-index/vector-store/qdrant-client.ts
View file

@ -4,7 +4,7 @@ import * as path from "path"
import { getWorkspacePath } from "../../../utils/path"
import { IVectorStore } from "../interfaces/vector-store"
import { Payload, VectorStoreSearchResult } from "../interfaces"
import { MAX_SEARCH_RESULTS, SEARCH_MIN_SCORE } from "../constants"
import { DEFAULT_MAX_SEARCH_RESULTS, DEFAULT_SEARCH_MIN_SCORE } from "../constants"
import { t } from "../../../i18n"
/**
@ -271,13 +271,16 @@ export class QdrantVectorStore implements IVectorStore {
/**
* Searches for similar vectors
* @param queryVector Vector to search for
* @param limit Maximum number of results to return
* @param directoryPrefix Optional directory prefix to filter results
* @param minScore Optional minimum score threshold
* @param maxResults Optional maximum number of results to return
* @returns Promise resolving to search results
*/
async search(
queryVector: number[],
directoryPrefix?: string,
minScore?: number,
maxResults?: number,
): Promise<VectorStoreSearchResult[]> {
try {
let filter = undefined
@ -296,8 +299,8 @@ export class QdrantVectorStore implements IVectorStore {
const searchRequest = {
query: queryVector,
filter,
score_threshold: SEARCH_MIN_SCORE,
limit: MAX_SEARCH_RESULTS,
score_threshold: minScore ?? DEFAULT_SEARCH_MIN_SCORE,
limit: maxResults ?? DEFAULT_MAX_SEARCH_RESULTS,
params: {
hnsw_ef: 128,
exact: false,
@ -307,10 +310,6 @@ export class QdrantVectorStore implements IVectorStore {
},
}
if (minScore !== undefined) {
searchRequest.score_threshold = minScore
}
const operationResult = await this.client.query(this.collectionName, searchRequest)
const filteredPoints = operationResult.points.filter((p) => this.isPayloadValid(p.payload))

42
src/services/tree-sitter/__tests__/inspectGo.spec.ts
View file

@ -20,4 +20,46 @@ describe("Go Tree-sitter Parser", () => {
const result = await testParseSourceCodeDefinitions("file.go", sampleGoContent, testOptions)
expect(result).toBeDefined()
})
// Test 3: Verify no duplicate captures for Go constructs
it("should not create duplicate captures for Go constructs", async () => {
const testOptions = {
language: "go",
wasmFile: "tree-sitter-go.wasm",
queryString: goQuery,
extKey: "go",
}
const result = await testParseSourceCodeDefinitions("file.go", sampleGoContent, testOptions)
// Check that we have results
expect(result).toBeDefined()
expect(typeof result).toBe("string")
expect(result!.length).toBeGreaterThan(0)
// Parse the result to extract line ranges
const lines = result!.split("\n").filter((line) => line.trim() && !line.startsWith("#"))
// Extract line ranges from the format "startLine--endLine | content"
const lineRanges = lines
.map((line) => {
const match = line.match(/^(\d+)--(\d+)/)
return match ? `${match[1]}-${match[2]}` : null
})
.filter(Boolean)
// Check for duplicate line ranges (which was the original problem)
const uniqueLineRanges = [...new Set(lineRanges)]
expect(lineRanges.length).toBe(uniqueLineRanges.length)
// With the new query that captures full declarations, we expect the entire file
// to be captured as a single block containing all the declarations
expect(lines.length).toBeGreaterThan(0)
// The line range should cover the entire sample file content
expect(lineRanges[0]).toBe("2-126")
// The captured content should start with the package declaration
expect(result).toContain("// Package declaration test")
})
})

62
src/services/tree-sitter/__tests__/parseSourceCodeDefinitions.go.spec.ts
View file

@ -37,59 +37,21 @@ describe("Go Source Code Definition Tests", () => {
parseResult = result as string
})
it("should parse package declarations", () => {
expect(parseResult).toMatch(/\d+--\d+ \|\s*package main/)
it("should capture the entire Go file as a single block", () => {
// With the universal 50-character threshold, the entire file is captured as one block
expect(parseResult).toMatch(/2--126 \| \/\/ Package declaration test/)
})
it("should parse import declarations", () => {
expect(parseResult).toMatch(/\d+--\d+ \|\s*"fmt"/)
expect(parseResult).toMatch(/\d+--\d+ \|\s*"sync"/)
expect(parseResult).toMatch(/\d+--\d+ \|\s*"time"/)
it("should contain package declaration in the captured content", () => {
// The captured block should contain the package declaration
expect(parseResult).toContain("# file.go")
expect(parseResult).toContain("2--126")
})
it("should parse const declarations", () => {
expect(parseResult).toMatch(/\d+--\d+ \|\s*TestConstDefinition1 = "test1"/)
expect(parseResult).toMatch(/\d+--\d+ \|\s*TestConstDefinition2 = "test2"/)
})
it("should parse var declarations", () => {
expect(parseResult).toMatch(/\d+--\d+ \|\s*TestVarDefinition1 string = "var1"/)
expect(parseResult).toMatch(/\d+--\d+ \|\s*TestVarDefinition2 int\s*= 42/)
})
it("should parse interface declarations", () => {
expect(parseResult).toMatch(/\d+--\d+ \|\s*type TestInterfaceDefinition interface/)
})
it("should parse struct declarations", () => {
expect(parseResult).toMatch(/\d+--\d+ \|\s*type TestStructDefinition struct/)
})
it("should parse type declarations", () => {
expect(parseResult).toMatch(/\d+--\d+ \|\s*type TestTypeDefinition struct/)
})
it("should parse function declarations", () => {
expect(parseResult).toMatch(/\d+--\d+ \|\s*func TestFunctionDefinition\(/)
})
it("should parse method declarations", () => {
expect(parseResult).toMatch(/\d+--\d+ \|\s*func \(t \*TestStructDefinition\) TestMethodDefinition\(/)
})
it("should parse channel function declarations", () => {
expect(parseResult).toMatch(/\d+--\d+ \|\s*func TestChannelDefinition\(/)
})
it("should parse goroutine function declarations", () => {
expect(parseResult).toMatch(/\d+--\d+ \|\s*func TestGoroutineDefinition\(\)/)
})
it("should parse defer function declarations", () => {
expect(parseResult).toMatch(/\d+--\d+ \|\s*func TestDeferDefinition\(\)/)
})
it("should parse select function declarations", () => {
expect(parseResult).toMatch(/\d+--\d+ \|\s*func TestSelectDefinition\(/)
it("should not have duplicate captures", () => {
// Should only have one capture for the entire file
const lineRanges = parseResult.match(/\d+--\d+ \|/g)
expect(lineRanges).toBeDefined()
expect(lineRanges!.length).toBe(1)
})
})

62
src/services/tree-sitter/queries/go.ts
View file

@ -1,58 +1,26 @@
/*
Go Tree-Sitter Query Patterns
Updated to capture full declarations instead of just identifiers
*/
export default `
; Package declarations
(package_clause
(package_identifier) @name.definition.package)
; Function declarations - capture the entire declaration
(function_declaration) @name.definition.function
; Import declarations
(import_declaration
(import_spec_list
(import_spec path: (_) @name.definition.import)))
; Method declarations - capture the entire declaration
(method_declaration) @name.definition.method
; Const declarations
(const_declaration
(const_spec name: (identifier) @name.definition.const))
; Type declarations (interfaces, structs, type aliases) - capture the entire declaration
(type_declaration) @name.definition.type
; Var declarations
(var_declaration
(var_spec name: (identifier) @name.definition.var))
; Variable declarations - capture the entire declaration
(var_declaration) @name.definition.var
; Interface declarations
(type_declaration
(type_spec
name: (type_identifier) @name.definition.interface
type: (interface_type)))
; Constant declarations - capture the entire declaration
(const_declaration) @name.definition.const
; Struct declarations
(type_declaration
(type_spec
name: (type_identifier) @name.definition.struct
type: (struct_type)))
; Package clause
(package_clause) @name.definition.package
; Type declarations
(type_declaration
(type_spec
name: (type_identifier) @name.definition.type))
; Function declarations
(function_declaration
name: (identifier) @name.definition.function)
; Method declarations
(method_declaration
name: (field_identifier) @name.definition.method)
; Channel operations
(channel_type) @name.definition.channel
; Goroutine declarations
(go_statement) @name.definition.goroutine
; Defer statements
(defer_statement) @name.definition.defer
; Select statements
(select_statement) @name.definition.select
; Import declarations - capture the entire import block
(import_declaration) @name.definition.import
`

1
src/shared/WebviewMessage.ts
View file

@ -234,6 +234,7 @@ export interface WebviewMessage {
codebaseIndexEmbedderModelId: string
codebaseIndexOpenAiCompatibleBaseUrl?: string
codebaseIndexOpenAiCompatibleModelDimension?: number
codebaseIndexSearchMaxResults?: number
// Secret settings
codeIndexOpenAiKey?: string

67
webview-ui/src/components/chat/CodeIndexPopover.tsx
View file

@ -31,10 +31,13 @@ import {
Popover,
PopoverContent,
PopoverTrigger,
Slider,
StandardTooltip,
} from "@src/components/ui"
import { useRooPortal } from "@src/components/ui/hooks/useRooPortal"
import type { EmbedderProvider } from "@roo/embeddingModels"
import type { IndexingStatus } from "@roo/ExtensionMessage"
import { CODEBASE_INDEX_DEFAULTS } from "@roo-code/types"
interface CodeIndexPopoverProps {
children: React.ReactNode
@ -48,6 +51,7 @@ interface LocalCodeIndexSettings {
codebaseIndexEmbedderProvider: EmbedderProvider
codebaseIndexEmbedderBaseUrl?: string
codebaseIndexEmbedderModelId: string
codebaseIndexSearchMaxResults?: number
// Secret settings (start empty, will be loaded separately)
codeIndexOpenAiKey?: string
@ -66,6 +70,7 @@ export const CodeIndexPopover: React.FC<CodeIndexPopoverProps> = ({
const { t } = useAppTranslation()
const { codebaseIndexConfig, codebaseIndexModels } = useExtensionState()
const [open, setOpen] = useState(false)
const [isAdvancedSettingsOpen, setIsAdvancedSettingsOpen] = useState(false)
const [indexingStatus, setIndexingStatus] = useState<IndexingStatus>(externalIndexingStatus)
@ -79,6 +84,7 @@ export const CodeIndexPopover: React.FC<CodeIndexPopoverProps> = ({
codebaseIndexEmbedderProvider: "openai",
codebaseIndexEmbedderBaseUrl: "",
codebaseIndexEmbedderModelId: "",
codebaseIndexSearchMaxResults: CODEBASE_INDEX_DEFAULTS.DEFAULT_SEARCH_RESULTS,
codeIndexOpenAiKey: "",
codeIndexQdrantApiKey: "",
codebaseIndexOpenAiCompatibleBaseUrl: "",
@ -107,6 +113,8 @@ export const CodeIndexPopover: React.FC<CodeIndexPopoverProps> = ({
codebaseIndexEmbedderProvider: codebaseIndexConfig.codebaseIndexEmbedderProvider || "openai",
codebaseIndexEmbedderBaseUrl: codebaseIndexConfig.codebaseIndexEmbedderBaseUrl || "",
codebaseIndexEmbedderModelId: codebaseIndexConfig.codebaseIndexEmbedderModelId || "",
codebaseIndexSearchMaxResults:
codebaseIndexConfig.codebaseIndexSearchMaxResults || CODEBASE_INDEX_DEFAULTS.DEFAULT_SEARCH_RESULTS,
codeIndexOpenAiKey: "",
codeIndexQdrantApiKey: "",
codebaseIndexOpenAiCompatibleBaseUrl: "",
@ -575,6 +583,65 @@ export const CodeIndexPopover: React.FC<CodeIndexPopoverProps> = ({
/>
</div>
{/* Advanced Settings Disclosure */}
<div className="mt-4">
<button
onClick={() => setIsAdvancedSettingsOpen(!isAdvancedSettingsOpen)}
className="flex items-center text-xs text-vscode-foreground hover:text-vscode-textLink-foreground focus:outline-none"
aria-expanded={isAdvancedSettingsOpen}>
<span
className={`codicon codicon-${isAdvancedSettingsOpen ? "chevron-down" : "chevron-right"} mr-1`}></span>
<span>{t("settings:codeIndex.advancedConfigLabel")}</span>
</button>
{isAdvancedSettingsOpen && (
<div className="mt-4 space-y-4 pl-4">
{/* Maximum Search Results Slider */}
<div className="space-y-2">
<div className="flex items-center gap-2">
<label className="text-sm font-medium">
{t("settings:codeIndex.searchMaxResultsLabel")}
</label>
<StandardTooltip content={t("settings:codeIndex.searchMaxResultsDescription")}>
<span className="codicon codicon-info text-xs text-vscode-descriptionForeground cursor-help" />
</StandardTooltip>
</div>
<div className="flex items-center gap-2">
<Slider
min={CODEBASE_INDEX_DEFAULTS.MIN_SEARCH_RESULTS}
max={CODEBASE_INDEX_DEFAULTS.MAX_SEARCH_RESULTS}
step={CODEBASE_INDEX_DEFAULTS.SEARCH_RESULTS_STEP}
value={[
currentSettings.codebaseIndexSearchMaxResults ||
CODEBASE_INDEX_DEFAULTS.DEFAULT_SEARCH_RESULTS,
]}
onValueChange={(values) =>
updateSetting("codebaseIndexSearchMaxResults", values[0])
}
className="flex-1"
data-testid="search-max-results-slider"
/>
<span className="w-12 text-center">
{currentSettings.codebaseIndexSearchMaxResults ||
CODEBASE_INDEX_DEFAULTS.DEFAULT_SEARCH_RESULTS}
</span>
<VSCodeButton
appearance="icon"
title={t("settings:codeIndex.resetToDefault")}
onClick={() =>
updateSetting(
"codebaseIndexSearchMaxResults",
CODEBASE_INDEX_DEFAULTS.DEFAULT_SEARCH_RESULTS,
)
}>
<span className="codicon codicon-discard" />
</VSCodeButton>
</div>
</div>
</div>
)}
</div>
{/* Action Buttons */}
<div className="flex items-center justify-between gap-2 pt-2">
<div className="flex gap-2">

1
webview-ui/src/context/ExtensionStateContext.tsx
View file

@ -217,6 +217,7 @@ export const ExtensionStateContextProvider: React.FC<{ children: React.ReactNode
codebaseIndexEmbedderProvider: "openai",
codebaseIndexEmbedderBaseUrl: "",
codebaseIndexEmbedderModelId: "",
codebaseIndexSearchMaxResults: undefined,
},
codebaseIndexModels: { ollama: {}, openai: {} },
})

5
webview-ui/src/i18n/locales/ca/settings.json
View file

@ -100,7 +100,10 @@
"advancedConfigLabel": "Configuració avançada",
"searchMinScoreLabel": "Llindar de puntuació de cerca",
"searchMinScoreDescription": "Puntuació mínima de similitud (0.0-1.0) requerida per als resultats de la cerca. Valors més baixos retornen més resultats però poden ser menys rellevants. Valors més alts retornen menys resultats però més rellevants.",
"searchMinScoreResetTooltip": "Restablir al valor per defecte (0.4)"
"searchMinScoreResetTooltip": "Restablir al valor per defecte (0.4)",
"searchMaxResultsLabel": "Màxim de resultats de cerca",
"searchMaxResultsDescription": "Nombre màxim de resultats de cerca a retornar quan es consulta l'índex de la base de codi. Els valors més alts proporcionen més context però poden incloure resultats menys rellevants.",
"resetToDefault": "Restablir al valor per defecte"
},
"autoApprove": {
"description": "Permet que Roo realitzi operacions automàticament sense requerir aprovació. Activeu aquesta configuració només si confieu plenament en la IA i enteneu els riscos de seguretat associats.",

5
webview-ui/src/i18n/locales/de/settings.json
View file

@ -100,7 +100,10 @@
"advancedConfigLabel": "Erweiterte Konfiguration",
"searchMinScoreLabel": "Suchergebnis-Schwellenwert",
"searchMinScoreDescription": "Mindestähnlichkeitswert (0.0-1.0), der für Suchergebnisse erforderlich ist. Niedrigere Werte liefern mehr Ergebnisse, die jedoch möglicherweise weniger relevant sind. Höhere Werte liefern weniger, aber relevantere Ergebnisse.",
"searchMinScoreResetTooltip": "Auf Standardwert zurücksetzen (0.4)"
"searchMinScoreResetTooltip": "Auf Standardwert zurücksetzen (0.4)",
"searchMaxResultsLabel": "Maximale Suchergebnisse",
"searchMaxResultsDescription": "Maximale Anzahl von Suchergebnissen, die bei der Abfrage des Codebase-Index zurückgegeben werden. Höhere Werte bieten mehr Kontext, können aber weniger relevante Ergebnisse enthalten.",
"resetToDefault": "Auf Standard zurücksetzen"
},
"autoApprove": {
"description": "Erlaubt Roo, Operationen automatisch ohne Genehmigung durchzuführen. Aktiviere diese Einstellungen nur, wenn du der KI vollständig vertraust und die damit verbundenen Sicherheitsrisiken verstehst.",

3
webview-ui/src/i18n/locales/en/settings.json
View file

@ -76,6 +76,9 @@
"searchMinScoreLabel": "Search Score Threshold",
"searchMinScoreDescription": "Minimum similarity score (0.0-1.0) required for search results. Lower values return more results but may be less relevant. Higher values return fewer but more relevant results.",
"searchMinScoreResetTooltip": "Reset to default value (0.4)",
"searchMaxResultsLabel": "Maximum Search Results",
"searchMaxResultsDescription": "Maximum number of search results to return when querying the codebase index. Higher values provide more context but may include less relevant results.",
"resetToDefault": "Reset to default",
"startIndexingButton": "Start Indexing",
"clearIndexDataButton": "Clear Index Data",
"unsavedSettingsMessage": "Please save your settings before starting the indexing process.",

5
webview-ui/src/i18n/locales/es/settings.json
View file

@ -100,7 +100,10 @@
"advancedConfigLabel": "Configuración avanzada",
"searchMinScoreLabel": "Umbral de puntuación de búsqueda",
"searchMinScoreDescription": "Puntuación mínima de similitud (0.0-1.0) requerida para los resultados de búsqueda. Valores más bajos devuelven más resultados pero pueden ser menos relevantes. Valores más altos devuelven menos resultados pero más relevantes.",
"searchMinScoreResetTooltip": "Restablecer al valor predeterminado (0.4)"
"searchMinScoreResetTooltip": "Restablecer al valor predeterminado (0.4)",
"searchMaxResultsLabel": "Resultados máximos de búsqueda",
"searchMaxResultsDescription": "Número máximo de resultados de búsqueda a devolver al consultar el índice de código. Valores más altos proporcionan más contexto pero pueden incluir resultados menos relevantes.",
"resetToDefault": "Restablecer al valor predeterminado"
},
"autoApprove": {
"description": "Permitir que Roo realice operaciones automáticamente sin requerir aprobación. Habilite esta configuración solo si confía plenamente en la IA y comprende los riesgos de seguridad asociados.",

5
webview-ui/src/i18n/locales/fr/settings.json
View file

@ -100,7 +100,10 @@
"advancedConfigLabel": "Configuration avancée",
"searchMinScoreLabel": "Seuil de score de recherche",
"searchMinScoreDescription": "Score de similarité minimum (0.0-1.0) requis pour les résultats de recherche. Des valeurs plus faibles renvoient plus de résultats mais peuvent être moins pertinents. Des valeurs plus élevées renvoient moins de résultats mais plus pertinents.",
"searchMinScoreResetTooltip": "Réinitialiser à la valeur par défaut (0.4)"
"searchMinScoreResetTooltip": "Réinitialiser à la valeur par défaut (0.4)",
"searchMaxResultsLabel": "Résultats de recherche maximum",
"searchMaxResultsDescription": "Nombre maximum de résultats de recherche à retourner lors de l'interrogation de l'index de code. Des valeurs plus élevées fournissent plus de contexte mais peuvent inclure des résultats moins pertinents.",
"resetToDefault": "Réinitialiser par défaut"
},
"autoApprove": {
"description": "Permettre à Roo d'effectuer automatiquement des opérations sans requérir d'approbation. Activez ces paramètres uniquement si vous faites entièrement confiance à l'IA et que vous comprenez les risques de sécurité associés.",

5
webview-ui/src/i18n/locales/hi/settings.json
View file

@ -100,7 +100,10 @@
"advancedConfigLabel": "उन्नत कॉन्फ़िगरेशन",
"searchMinScoreLabel": "खोज स्कोर थ्रेसहोल्ड",
"searchMinScoreDescription": "खोज परिणामों के लिए आवश्यक न्यूनतम समानता स्कोर (0.0-1.0)। कम मान अधिक परिणाम लौटाते हैं लेकिन कम प्रासंगिक हो सकते हैं। उच्च मान कम लेकिन अधिक प्रासंगिक परिणाम लौटाते हैं।",
"searchMinScoreResetTooltip": "डिफ़ॉल्ट मान पर रीसेट करें (0.4)"
"searchMinScoreResetTooltip": "डिफ़ॉल्ट मान पर रीसेट करें (0.4)",
"searchMaxResultsLabel": "अधिकतम खोज परिणाम",
"searchMaxResultsDescription": "कोडबेस इंडेक्स को क्वेरी करते समय वापस करने के लिए खोज परिणामों की अधिकतम संख्या। उच्च मान अधिक संदर्भ प्रदान करते हैं लेकिन कम प्रासंगिक परिणाम शामिल कर सकते हैं।",
"resetToDefault": "डिफ़ॉल्ट पर रीसेट करें"
},
"autoApprove": {
"description": "Roo को अनुमोदन की आवश्यकता के बिना स्वचालित रूप से ऑपरेशन करने की अनुमति दें। इन सेटिंग्स को केवल तभी सक्षम करें जब आप AI पर पूरी तरह से भरोसा करते हों और संबंधित सुरक्षा जोखिमों को समझते हों।",

5
webview-ui/src/i18n/locales/id/settings.json
View file

@ -100,7 +100,10 @@
"advancedConfigLabel": "Konfigurasi Lanjutan",
"searchMinScoreLabel": "Ambang Batas Skor Pencarian",
"searchMinScoreDescription": "Skor kesamaan minimum (0.0-1.0) yang diperlukan untuk hasil pencarian. Nilai yang lebih rendah mengembalikan lebih banyak hasil tetapi mungkin kurang relevan. Nilai yang lebih tinggi mengembalikan lebih sedikit hasil tetapi lebih relevan.",
"searchMinScoreResetTooltip": "Reset ke nilai default (0.4)"
"searchMinScoreResetTooltip": "Reset ke nilai default (0.4)",
"searchMaxResultsLabel": "Hasil Pencarian Maksimum",
"searchMaxResultsDescription": "Jumlah maksimum hasil pencarian yang dikembalikan saat melakukan query indeks basis kode. Nilai yang lebih tinggi memberikan lebih banyak konteks tetapi mungkin menyertakan hasil yang kurang relevan.",
"resetToDefault": "Reset ke default"
},
"autoApprove": {
"description": "Izinkan Roo untuk secara otomatis melakukan operasi tanpa memerlukan persetujuan. Aktifkan pengaturan ini hanya jika kamu sepenuhnya mempercayai AI dan memahami risiko keamanan yang terkait.",

5
webview-ui/src/i18n/locales/it/settings.json
View file

@ -100,7 +100,10 @@
"advancedConfigLabel": "Configurazione avanzata",
"searchMinScoreLabel": "Soglia punteggio di ricerca",
"searchMinScoreDescription": "Punteggio minimo di somiglianza (0.0-1.0) richiesto per i risultati della ricerca. Valori più bassi restituiscono più risultati ma potrebbero essere meno pertinenti. Valori più alti restituiscono meno risultati ma più pertinenti.",
"searchMinScoreResetTooltip": "Ripristina al valore predefinito (0.4)"
"searchMinScoreResetTooltip": "Ripristina al valore predefinito (0.4)",
"searchMaxResultsLabel": "Risultati di ricerca massimi",
"searchMaxResultsDescription": "Numero massimo di risultati di ricerca da restituire quando si interroga l'indice del codice. Valori più alti forniscono più contesto ma possono includere risultati meno pertinenti.",
"resetToDefault": "Ripristina al valore predefinito"
},
"autoApprove": {
"description": "Permetti a Roo di eseguire automaticamente operazioni senza richiedere approvazione. Abilita queste impostazioni solo se ti fidi completamente dell'IA e comprendi i rischi di sicurezza associati.",

5
webview-ui/src/i18n/locales/ja/settings.json
View file

@ -100,7 +100,10 @@
"advancedConfigLabel": "詳細設定",
"searchMinScoreLabel": "検索スコアのしきい値",
"searchMinScoreDescription": "検索結果に必要な最小類似度スコア（0.0-1.0）。値を低くするとより多くの結果が返されますが、関連性が低くなる可能性があります。値を高くすると返される結果は少なくなりますが、より関連性が高くなります。",
"searchMinScoreResetTooltip": "デフォルト値（0.4）にリセット"
"searchMinScoreResetTooltip": "デフォルト値（0.4）にリセット",
"searchMaxResultsLabel": "最大検索結果数",
"searchMaxResultsDescription": "コードベースインデックスをクエリする際に返される検索結果の最大数。値を高くするとより多くのコンテキストが提供されますが、関連性の低い結果が含まれる可能性があります。",
"resetToDefault": "デフォルトにリセット"
},
"autoApprove": {
"description": "Rooが承認なしで自動的に操作を実行できるようにします。AIを完全に信頼し、関連するセキュリティリスクを理解している場合にのみ、これらの設定を有効にしてください。",

5
webview-ui/src/i18n/locales/ko/settings.json
View file

@ -100,7 +100,10 @@
"advancedConfigLabel": "고급 구성",
"searchMinScoreLabel": "검색 점수 임계값",
"searchMinScoreDescription": "검색 결과에 필요한 최소 유사도 점수(0.0-1.0). 값이 낮을수록 더 많은 결과가 반환되지만 관련성이 떨어질 수 있습니다. 값이 높을수록 결과는 적지만 관련성이 높은 결과가 반환됩니다.",
"searchMinScoreResetTooltip": "기본값(0.4)으로 재설정"
"searchMinScoreResetTooltip": "기본값(0.4)으로 재설정",
"searchMaxResultsLabel": "최대 검색 결과",
"searchMaxResultsDescription": "코드베이스 인덱스를 쿼리할 때 반환할 최대 검색 결과 수입니다. 값이 높을수록 더 많은 컨텍스트를 제공하지만 관련성이 낮은 결과가 포함될 수 있습니다.",
"resetToDefault": "기본값으로 재설정"
},
"autoApprove": {
"description": "Roo가 승인 없이 자동으로 작업을 수행할 수 있도록 허용합니다. AI를 완전히 신뢰하고 관련 보안 위험을 이해하는 경우에만 이러한 설정을 활성화하세요.",

5
webview-ui/src/i18n/locales/nl/settings.json
View file

@ -100,7 +100,10 @@
"advancedConfigLabel": "Geavanceerde configuratie",
"searchMinScoreLabel": "Zoekscore drempel",
"searchMinScoreDescription": "Minimale overeenkomstscore (0.0-1.0) vereist voor zoekresultaten. Lagere waarden leveren meer resultaten op, maar zijn mogelijk minder relevant. Hogere waarden leveren minder, maar relevantere resultaten op.",
"searchMinScoreResetTooltip": "Reset naar standaardwaarde (0.4)"
"searchMinScoreResetTooltip": "Reset naar standaardwaarde (0.4)",
"searchMaxResultsLabel": "Maximum Zoekresultaten",
"searchMaxResultsDescription": "Maximum aantal zoekresultaten dat wordt geretourneerd bij het doorzoeken van de codebase-index. Hogere waarden bieden meer context maar kunnen minder relevante resultaten bevatten.",
"resetToDefault": "Reset naar standaard"
},
"autoApprove": {
"description": "Sta Roo toe om automatisch handelingen uit te voeren zonder goedkeuring. Schakel deze instellingen alleen in als je de AI volledig vertrouwt en de bijbehorende beveiligingsrisico's begrijpt.",

5
webview-ui/src/i18n/locales/pl/settings.json
View file

@ -100,7 +100,10 @@
"advancedConfigLabel": "Konfiguracja zaawansowana",
"searchMinScoreLabel": "Próg wyniku wyszukiwania",
"searchMinScoreDescription": "Minimalny wynik podobieństwa (0.0-1.0) wymagany dla wyników wyszukiwania. Niższe wartości zwracają więcej wyników, ale mogą być mniej trafne. Wyższe wartości zwracają mniej wyników, ale bardziej trafnych.",
"searchMinScoreResetTooltip": "Zresetuj do wartości domyślnej (0.4)"
"searchMinScoreResetTooltip": "Zresetuj do wartości domyślnej (0.4)",
"searchMaxResultsLabel": "Maksymalna liczba wyników wyszukiwania",
"searchMaxResultsDescription": "Maksymalna liczba wyników wyszukiwania zwracanych podczas zapytania do indeksu bazy kodu. Wyższe wartości zapewniają więcej kontekstu, ale mogą zawierać mniej istotne wyniki.",
"resetToDefault": "Przywróć domyślne"
},
"autoApprove": {
"description": "Pozwól Roo na automatyczne wykonywanie operacji bez wymagania zatwierdzenia. Włącz te ustawienia tylko jeśli w pełni ufasz AI i rozumiesz związane z tym zagrożenia bezpieczeństwa.",

5
webview-ui/src/i18n/locales/pt-BR/settings.json
View file

@ -100,7 +100,10 @@
"advancedConfigLabel": "Configuração Avançada",
"searchMinScoreLabel": "Limite de pontuação de busca",
"searchMinScoreDescription": "Pontuação mínima de similaridade (0.0-1.0) necessária para os resultados da busca. Valores mais baixos retornam mais resultados, mas podem ser menos relevantes. Valores mais altos retornam menos resultados, mas mais relevantes.",
"searchMinScoreResetTooltip": "Redefinir para o valor padrão (0.4)"
"searchMinScoreResetTooltip": "Redefinir para o valor padrão (0.4)",
"searchMaxResultsLabel": "Resultados máximos de busca",
"searchMaxResultsDescription": "Número máximo de resultados de busca a retornar ao consultar o índice de código. Valores mais altos fornecem mais contexto, mas podem incluir resultados menos relevantes.",
"resetToDefault": "Redefinir para o padrão"
},
"autoApprove": {
"description": "Permitir que o Roo realize operações automaticamente sem exigir aprovação. Ative essas configurações apenas se confiar totalmente na IA e compreender os riscos de segurança associados.",

5
webview-ui/src/i18n/locales/ru/settings.json
View file

@ -100,7 +100,10 @@
"advancedConfigLabel": "Расширенная конфигурация",
"searchMinScoreLabel": "Порог оценки поиска",
"searchMinScoreDescription": "Минимальный балл сходства (0.0-1.0), необходимый для результатов поиска. Более низкие значения возвращают больше результатов, но они могут быть менее релевантными. Более высокие значения возвращают меньше результатов, но более релевантных.",
"searchMinScoreResetTooltip": "Сбросить к значению по умолчанию (0.4)"
"searchMinScoreResetTooltip": "Сбросить к значению по умолчанию (0.4)",
"searchMaxResultsLabel": "Максимальное количество результатов поиска",
"searchMaxResultsDescription": "Максимальное количество результатов поиска, возвращаемых при запросе индекса кодовой базы. Более высокие значения предоставляют больше контекста, но могут включать менее релевантные результаты.",
"resetToDefault": "Сбросить к значению по умолчанию"
},
"autoApprove": {
"description": "Разрешить Roo автоматически выполнять операции без необходимости одобрения. Включайте эти параметры только если полностью доверяете ИИ и понимаете связанные с этим риски безопасности.",

5
webview-ui/src/i18n/locales/tr/settings.json
View file

@ -100,7 +100,10 @@
"advancedConfigLabel": "Gelişmiş Yapılandırma",
"searchMinScoreLabel": "Arama Skoru Eşiği",
"searchMinScoreDescription": "Arama sonuçları için gereken minimum benzerlik puanı (0.0-1.0). Düşük değerler daha fazla sonuç döndürür ancak daha az alakalı olabilir. Yüksek değerler daha az ancak daha alakalı sonuçlar döndürür.",
"searchMinScoreResetTooltip": "Varsayılan değere sıfırla (0.4)"
"searchMinScoreResetTooltip": "Varsayılan değere sıfırla (0.4)",
"searchMaxResultsLabel": "Maksimum Arama Sonuçları",
"searchMaxResultsDescription": "Kod tabanı dizinini sorgularken döndürülecek maksimum arama sonucu sayısı. Daha yüksek değerler daha fazla bağlam sağlar ancak daha az alakalı sonuçlar içerebilir.",
"resetToDefault": "Varsayılana sıfırla"
},
"autoApprove": {
"description": "Roo'nun onay gerektirmeden otomatik olarak işlemler gerçekleştirmesine izin verin. Bu ayarları yalnızca yapay zekaya tamamen güveniyorsanız ve ilgili güvenlik risklerini anlıyorsanız etkinleştirin.",

5
webview-ui/src/i18n/locales/vi/settings.json
View file

@ -100,7 +100,10 @@
"advancedConfigLabel": "Cấu hình nâng cao",
"searchMinScoreLabel": "Ngưỡng điểm tìm kiếm",
"searchMinScoreDescription": "Điểm tương đồng tối thiểu (0.0-1.0) cần thiết cho kết quả tìm kiếm. Giá trị thấp hơn trả về nhiều kết quả hơn nhưng có thể kém liên quan hơn. Giá trị cao hơn trả về ít kết quả hơn nhưng có liên quan hơn.",
"searchMinScoreResetTooltip": "Đặt lại về giá trị mặc định (0.4)"
"searchMinScoreResetTooltip": "Đặt lại về giá trị mặc định (0.4)",
"searchMaxResultsLabel": "Số Kết Quả Tìm Kiếm Tối Đa",
"searchMaxResultsDescription": "Số lượng kết quả tìm kiếm tối đa được trả về khi truy vấn chỉ mục cơ sở mã. Giá trị cao hơn cung cấp nhiều ngữ cảnh hơn nhưng có thể bao gồm các kết quả ít liên quan hơn.",
"resetToDefault": "Đặt lại về mặc định"
},
"autoApprove": {
"description": "Cho phép Roo tự động thực hiện các hoạt động mà không cần phê duyệt. Chỉ bật những cài đặt này nếu bạn hoàn toàn tin tưởng AI và hiểu rõ các rủi ro bảo mật liên quan.",

5
webview-ui/src/i18n/locales/zh-CN/settings.json
View file

@ -100,7 +100,10 @@
"advancedConfigLabel": "高级配置",
"searchMinScoreLabel": "搜索分数阈值",
"searchMinScoreDescription": "搜索结果所需的最低相似度分数（0.0-1.0）。较低的值返回更多结果，但可能不太相关。较高的值返回较少但更相关的结果。",
"searchMinScoreResetTooltip": "恢复默认值 (0.4)"
"searchMinScoreResetTooltip": "恢复默认值 (0.4)",
"searchMaxResultsLabel": "最大搜索结果数",
"searchMaxResultsDescription": "查询代码库索引时返回的最大搜索结果数。较高的值提供更多上下文，但可能包含相关性较低的结果。",
"resetToDefault": "恢复默认值"
},
"autoApprove": {
"description": "允许 Roo 自动执行操作而无需批准。只有在您完全信任 AI 并了解相关安全风险的情况下才启用这些设置。",

5
webview-ui/src/i18n/locales/zh-TW/settings.json
View file

@ -100,7 +100,10 @@
"advancedConfigLabel": "進階設定",
"searchMinScoreLabel": "搜尋分數閾值",
"searchMinScoreDescription": "搜尋結果所需的最低相似度分數（0.0-1.0）。較低的值會傳回更多結果，但可能較不相關。較高的值會傳回較少但更相關的結果。",
"searchMinScoreResetTooltip": "重設為預設值 (0.4)"
"searchMinScoreResetTooltip": "重設為預設值 (0.4)",
"searchMaxResultsLabel": "最大搜尋結果數",
"searchMaxResultsDescription": "查詢程式碼庫索引時傳回的最大搜尋結果數。較高的值提供更多上下文，但可能包含相關性較低的結果。",
"resetToDefault": "重設為預設值"
},
"autoApprove": {
"description": "允許 Roo 無需核准即執行操作。僅在您完全信任 AI 並了解相關安全風險時啟用這些設定。",