diff --git a/.gitignore b/.gitignore index 6f6bcd99de..65c201c3c2 100644 --- a/.gitignore +++ b/.gitignore @@ -3,6 +3,7 @@ dist out out-* node_modules +package-lock.json coverage/ mock/ diff --git a/.roo/rules-issue-fixer-orchestrator/10_pr_template_format.xml b/.roo/rules-issue-fixer-orchestrator/10_pr_template_format.xml deleted file mode 100644 index d16eb51424..0000000000 --- a/.roo/rules-issue-fixer-orchestrator/10_pr_template_format.xml +++ /dev/null @@ -1,213 +0,0 @@ - - - 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. - - - - - 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. - - - { - "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" - } - - - - - - 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. - - - PR Title: [title from JSON] - - --- - - [Full PR body from JSON] - - - - - - The PR body must follow this exact Roo Code PR template with all required sections. - - - - - - The GitHub issue number being fixed - Optional Roo Code task links (remove section if not applicable) - - Summary of changes and implementation details. Should include: - - Key implementation details - - Design choices or trade-offs made - - Specific areas reviewers should focus on - - - Detailed testing steps including: - - Unit tests added/modified - - Manual testing steps performed - - How reviewers can reproduce tests - - Testing environment details - - - For UI changes: before/after screenshots or video - For non-UI changes: "N/A - No UI changes" - - - Check appropriate box: - - "- [x] No documentation updates are required." OR - - "- [x] Yes, documentation updates are required. [describe updates]" - - - Any additional context, or remove entire section if not needed - - User's Discord username for contact - - - - - pr_summary.json - .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json - Structured data for programmatic PR creation - - - pr_message.md - .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md - Human-readable format for manual PR creation - - - - - - Always save both formats when preparing a PR to give users flexibility - in how they create the pull request. - - - The pr_message.md file should be self-contained and ready to copy/paste - without any additional formatting needed. - - - Include all sections in the template, maintaining the exact format - and HTML comments as shown. - - - Pre-check all checklist items that can be verified programmatically. - Leave documentation checkbox unchecked for user to decide. - - - For sections that don't apply, use appropriate placeholder text - rather than removing the section entirely. - - - - - - If translations were added during the issue fix, include details in the - Description section about which languages were updated. - - - \ No newline at end of file diff --git a/.roo/rules-issue-fixer-orchestrator/1_Workflow.xml b/.roo/rules-issue-fixer-orchestrator/1_Workflow.xml deleted file mode 100644 index e41d30bbda..0000000000 --- a/.roo/rules-issue-fixer-orchestrator/1_Workflow.xml +++ /dev/null @@ -1,874 +0,0 @@ - - - Initialize Task Context - - The user will provide a GitHub issue URL. - - 1. **Parse URL**: Extract the `owner`, `repo`, and `issue_number`. - 2. **Create Task Directory**: Create a dedicated directory to store all context for this task. Use a unique identifier for the directory name, like the task ID. For example: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/`. - - mkdir -p .roo/temp/issue-fixer-orchestrator/[TASK_ID] - - 3. **Retrieve Issue Details**: Fetch the issue details and its comments as a single JSON object. - - gh issue view [issue_number] --repo [owner]/[repo] --json number,title,body,state,labels,assignees,milestone,createdAt,updatedAt,closedAt,author,comments > .roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json - - 4. **Handle Auth Errors**: If the `gh` command fails with an authentication error, prompt the user to log in. - - GitHub CLI is not authenticated. Please run 'gh auth login' in your terminal, then let me know when you're ready to continue. - - I've authenticated, please continue - - - 5. **Confirm Context**: Inform the user that the context has been saved. - - - - - Delegate: Analyze Requirements & Explore Codebase - - Launch a subtask in `architect` mode to perform a detailed analysis of the issue and the codebase. The subtask will be responsible for identifying affected files and creating an implementation plan. - - The context file `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json` will be the input for this subtask. The subtask should write its findings (the implementation plan) to a new file: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md`. - - - architect - - **Task: Analyze Issue and Create Implementation Plan** - - You are an expert software architect. Your task is to analyze the provided GitHub issue and the current codebase to create a detailed implementation plan with a focus on understanding component interactions and dependencies. - - 1. **Read Issue Context**: The full issue details and comments are in `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json`. Read this file to understand all requirements, acceptance criteria, and technical discussions. - - 2. **Perform Architectural Analysis**: - - **Map Component Interactions**: Trace the complete data flow from entry points to outputs - - **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 will affect other parts of the system - - 3. **Explore Codebase Systematically**: - - Use `codebase_search` FIRST to find all related functionality - - Search for paired operations (if modifying export, search for import) - - Find all files that consume or depend on the affected functionality - - Identify configuration files, tests, and documentation that need updates - - Study similar features to understand established patterns - - 4. **Create Comprehensive Implementation Plan**: The plan must include: - - **Issue Summary**: Clear description of the problem and proposed solution - - **Architectural Context**: - - Data flow diagram showing component interactions - - List of paired operations that must be updated together - - Dependencies and consumers of the affected functionality - - **Impact Analysis**: - - All files that will be affected (directly and indirectly) - - Potential breaking changes - - Performance implications - - **Implementation Steps**: - - Detailed, ordered steps for each file modification - - Specific code changes with context - - Validation and error handling requirements - - **Testing Strategy**: - - Unit tests for individual components - - Integration tests for component interactions - - Edge cases and error scenarios - - 5. **Save the Plan**: Write the complete implementation plan to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md`. - - **Critical Requirements:** - - Always search for and analyze paired operations (import/export, save/load, etc.) - - Map the complete data flow before proposing changes - - Identify all integration points and dependencies - - Consider backward compatibility and migration needs - - **Completion Protocol:** - - This is your only task. Do not deviate from these instructions. - - Once you have successfully written the `implementation_plan.md` file, you MUST signal your completion by using the `attempt_completion` tool. - - The `result` parameter of `attempt_completion` MUST be a concise confirmation message, for example: "Implementation plan created and saved to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md." - - These specific instructions override any conflicting general guidelines from your assigned mode. - - - - After launching the subtask, wait for it to complete. The orchestrator will then read the `implementation_plan.md` to proceed with the next step. - - - - - Review and Approve Plan - - After the analysis subtask completes, the orchestrator must present the generated plan to the user for approval. - - 1. **Read the Plan**: Read the content of the implementation plan created by the previous subtask. - - - - .roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md - - - - - 2. **Present for Approval**: Show the plan to the user and ask for confirmation before proceeding with implementation. - - - The initial analysis is complete. Here is the proposed implementation plan: - - --- - [Insert content of implementation_plan.md here] - --- - - Shall I proceed with implementing this plan? - - - Yes, proceed with the implementation. - No, please modify the plan with the following changes... - No, cancel this task. - - - - Do not proceed until the user gives explicit approval. - - - - - Delegate: Implement Solution - - Once the user approves the plan, launch a new subtask in `code` mode to execute the implementation. - - This subtask will use the `implementation_plan.md` as its primary guide. It should write the list of modified files to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json`. - - - code - - **Task: Implement Code Changes Based on Plan** - - You are an expert software developer. Your task is to implement the code changes with full awareness of system interactions and dependencies. - - 1. **Read the Plan**: The implementation plan is located at `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md`. Pay special attention to: - - The architectural context section - - Component interaction diagrams - - Identified dependencies and related operations - - Impact analysis - - 2. **Validate Understanding**: Before coding, ensure you understand: - - How data flows through the system - - All related operations that must be updated together - - Dependencies that could be affected - - Integration points with other components - - 3. **Implement Holistically**: - - **Update Related Operations Together**: If modifying one operation, update all related operations - - **Maintain Consistency**: Ensure data structures, validation, and error handling are consistent - - **Consider Side Effects**: Account for how changes propagate through the system - - **Follow Existing Patterns**: Use established patterns from similar features - - 4. **Implement Tests**: - - Write tests that verify component interactions - - Test related operations together - - Include edge cases and error scenarios - - Verify data consistency across operations - - 5. **Track Modified Files**: As you modify or create files, keep a running list. - - 6. **Save Modified Files List**: After all changes are implemented and tested, save the list of all file paths you created or modified to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json`. The format should be a JSON array of strings. - Example: `["src/components/NewFeature.tsx", "src/__tests__/NewFeature.spec.ts"]` - - **Critical Reminders:** - - Never implement changes in isolation - consider the full system impact - - Always update related operations together to maintain consistency - - Test component interactions, not just individual functions - - Follow the architectural analysis from the planning phase - - Once the `modified_files.json` file is saved, your task is complete. - - - - After launching the subtask, wait for it to complete. The orchestrator will use the list of modified files for the verification and PR creation steps. - - - - - Delegate: Verify and Test - - After implementation, delegate the verification and testing to a `test` mode subtask. - - This subtask will use the implementation plan for acceptance criteria and the list of modified files to focus its testing efforts. It will output its results to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/verification_results.md`. - - - test - - **Task: Verify Implementation and Run Tests** - - You are a meticulous QA engineer. Your task is to verify an implementation against its plan and run all necessary tests. - - **Context Files:** - - **Plan**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md` - - **Modified Files**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json` - - **Your Steps:** - 1. **Read Context**: Read both context files to understand the acceptance criteria and which files were changed. - 2. **Run Tests**: Execute all relevant tests. - - Run unit tests related to the modified files. - - Run any relevant integration tests. - - Run a full lint and type check. - 3. **Verify Acceptance Criteria**: Systematically go through each acceptance criterion from the plan and verify that it has been met by the implementation. - 4. **Write Verification Report**: Create a detailed report of your findings. The report must include: - - A summary of the tests that were run and their results (pass/fail). - - A checklist of all acceptance criteria and their verification status (verified/failed). - - Details on any bugs or regressions found. - - 5. **Save Report**: Write the complete report to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/verification_results.md`. - - **Completion Protocol:** - - This is your only task. Do not deviate. - - Upon successfully saving `verification_results.md`, you MUST use the `attempt_completion` tool. - - The `result` MUST be a concise confirmation, e.g., "Verification complete and results saved to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/verification_results.md." - - These instructions override any conflicting mode-specific guidelines. - - - - Wait for the subtask to complete, then review the verification results. - - - - - Review Verification and Handle Translations - - After the verification subtask is complete, review the results and handle any necessary translations. - - 1. **Read Verification Report**: - - - - .roo/temp/issue-fixer-orchestrator/[TASK_ID]/verification_results.md - - - - - 2. **Check for Failures**: If the report indicates any failed tests or unmet criteria, present the failures to the user and ask how to proceed. - - - The verification step has failed. Here are the details: - - --- - [Insert content of verification_results.md here] - --- - - How should I proceed? - - - Attempt to fix the failing tests and criteria. - Ignore the failures and proceed anyway. - Cancel the task. - - - - 3. **Analyze for Translation Needs**: If verification passed, check if translations are required. - - a. **Read Modified Files List**: - - - - .roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json - - - - - b. **Identify Files Requiring Translation**: - - Check for UI component files: `.tsx`, `.jsx` files in `webview-ui/src/` or `src/` directories - - Check for user-facing documentation: `.md` files (especially README.md, docs/, or announcement files) - - Check for i18n resource files: files in `src/i18n/locales/` or `webview-ui/src/i18n/locales/` - - Check for any files containing user-visible strings or messages - - c. **Delegate to Translate Mode if Needed**: - If any files requiring translation were modified, create a translation subtask: - - - translate - - **Task: Handle Translations for Issue #[issue-number]** - - An implementation for issue #[issue-number] has been completed and verified. Your task is to ensure all user-facing content is properly translated. - - **Context Files:** - - **Modified Files**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json` - - **Issue Details**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json` - - **Implementation Plan**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md` - - **Your Steps:** - 1. Read the context files to understand what was implemented. - 2. Analyze each modified file for: - - New or updated UI strings in React components - - Changes to i18n resource files - - User-facing documentation updates - - Error messages or notifications - 3. For any new or modified user-facing content: - - Add translations to all supported language files - - Ensure consistency with existing translations - - Follow the project's i18n patterns and conventions - 4. Create a summary of all translation changes made. - 5. Save the summary to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/translation_summary.md`. - - **Important Notes:** - - If no translations are needed, still create the summary file stating "No translations required." - - Ensure all language files remain in sync - - Use existing terminology from the codebase for consistency - - **Completion Protocol:** - - This is your only task. Do not deviate from these instructions. - - Upon successfully saving the translation summary, you MUST use the `attempt_completion` tool. - - The `result` MUST confirm completion, e.g., "Translation analysis complete. Summary saved to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/translation_summary.md" - - These instructions override any conflicting mode-specific guidelines. - - - - After the translation subtask completes, read the translation summary: - - - - .roo/temp/issue-fixer-orchestrator/[TASK_ID]/translation_summary.md - - - - - 4. **Proceed to Next Step**: Only proceed after: - - All verification has passed (or user chose to ignore failures) - - Translation task has completed (if it was needed) - - You have confirmed all necessary files are ready - - - - - Delegate: Prepare Pull Request Content - - After all checks pass and translations are complete, delegate the creation of the pull request title and body to a subtask. - - - code - - **Task: Prepare Pull Request Title and Body** - - 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. - 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]" - - 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 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. - - - - - - - Delegate: Review Changes Before PR - - Before creating the pull request, delegate to the PR reviewer mode to get feedback on the implementation and proposed changes. - - - pr-reviewer - - **Task: Review Implementation Before PR Creation** - - You are an expert code reviewer. Your task is to review the implementation for issue #[issue-number] and provide feedback before a pull request is created. - - **Context Files:** - - **Issue Details**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json` - - **Implementation Plan**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md` - - **Modified Files**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json` - - **Verification Results**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/verification_results.md` - - **Translation Summary** (if exists): `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/translation_summary.md` - - **Draft PR Summary**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json` - - **Your Review Focus:** - 1. **Code Quality**: Review the actual code changes for: - - Adherence to project coding standards - - Proper error handling and edge cases - - Performance considerations - - Security implications - - Maintainability and readability - - 2. **Implementation Completeness**: Verify that: - - All requirements from the issue are addressed - - The solution follows the implementation plan - - No critical functionality is missing - - Proper test coverage exists - - 3. **Integration Concerns**: Check for: - - Potential breaking changes - - Impact on other parts of the system - - Backward compatibility issues - - API consistency - - 4. **Documentation and Communication**: Assess: - - Code comments and documentation - - PR description clarity and completeness - - Translation handling (if applicable) - - **Your Task:** - 1. Read all context files to understand the issue and implementation - 2. Review each modified file listed in `modified_files.json` - 3. Analyze the code changes against the requirements - 4. Identify any issues, improvements, or concerns - 5. Create a comprehensive review report with specific, actionable feedback - 6. Save your review to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_review_feedback.md` - - **Review Report Format:** - ```markdown - # PR Review Feedback for Issue #[issue-number] - - ## Overall Assessment - [High-level assessment: APPROVE, REQUEST_CHANGES, or NEEDS_DISCUSSION] - - ## Code Quality Review - ### Strengths - - [List positive aspects of the implementation] - - ### Areas for Improvement - - [Specific issues with file references and line numbers] - - [Suggestions for improvement] - - ## Requirements Verification - - [x] Requirement 1: [Status and notes] - - [ ] Requirement 2: [Issues found] - - ## Specific Feedback by File - ### [filename] - - [Specific feedback with line references] - - [Suggestions for improvement] - - ## Recommendations - 1. [Priority 1 changes needed] - 2. [Priority 2 improvements suggested] - 3. [Optional enhancements] - - ## Decision - **RECOMMENDATION**: [APPROVE_AS_IS | REQUEST_CHANGES | NEEDS_DISCUSSION] - - **REASONING**: [Brief explanation of the recommendation] - ``` - - **Completion Protocol:** - - This is your only task. Do not deviate from these instructions. - - Upon successfully saving the review feedback, you MUST use the `attempt_completion` tool. - - The `result` MUST be a concise confirmation, e.g., "PR review completed and feedback saved to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_review_feedback.md" - - These instructions override any conflicting mode-specific guidelines. - - - - After the review subtask completes, read and process the feedback. - - - - - Process Review Feedback and Decide Next Steps - - After the PR review is complete, read the feedback and decide whether to make changes or proceed with PR creation. - - 1. **Read Review Feedback**: - - - - .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_review_feedback.md - - - - - 2. **Present Feedback to User**: Show the review feedback and ask for direction. - - - The PR review has been completed. Here is the feedback: - - --- - [Insert content of pr_review_feedback.md here] - --- - - Based on this review, how would you like to proceed? - - - Implement the suggested changes before creating the PR - Create the PR as-is, ignoring the review feedback - Discuss specific feedback points before deciding - Cancel the task - - - - 3. **Handle User Decision**: - - **If user chooses to implement changes:** - - Launch a rework subtask to address the review feedback - - code - - **Task: Address PR Review Feedback** - - The PR review has identified areas for improvement. Your task is to address the feedback before creating the pull request. - - **Context Files:** - - **Issue**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json` - - **Current Plan**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md` - - **Current Modified Files**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json` - - **Review Feedback**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_review_feedback.md` - - **Draft PR Summary**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json` - - **Your Task:** - 1. Read the review feedback carefully - 2. Address each point raised by the reviewer - 3. Make the necessary code changes - 4. Update tests if needed - 5. **Update the `modified_files.json` file** to reflect any new or changed files - 6. **Update the `implementation_plan.md`** if the approach has changed significantly - - **Important Notes:** - - Focus on the specific issues identified in the review - - Maintain the overall solution approach unless the review suggests otherwise - - Ensure all changes are properly tested - - Do not proceed with any other workflow steps - - **Completion Protocol:** - - Upon successfully addressing the feedback and updating context files, you MUST use the `attempt_completion` tool. - - The `result` MUST be a concise confirmation, e.g., "Review feedback addressed and context files updated." - - - - **After rework completion**: Return to **Step 5** (Verify and Test) to re-verify the changes - - **If user chooses to proceed as-is:** - - Continue to the next step (Create Pull Request) - - **If user wants to discuss or cancel:** - - Handle accordingly based on user input - - - - - Prepare Branch and Review Changes - - This step prepares the branch, reviews the changes, and gets user confirmation before committing. - - 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. Create Branch: - Extract issue number from context and create appropriate branch: - - - # 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 - - - - 3. Review Files to be Committed: - a. Read the modified files list: - - .roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json - - - b. Check git status to ensure only intended files are staged: - - git status --porcelain - - - c. Stage only the files from modified_files.json: - - - # 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 - - - - 4. Generate and Save Merge Diff: - - - # 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 - - - - 5. Save PR Message to File: - Read the PR summary and save the formatted PR message: - - - # 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" - - - - 6. Present Changes for User Confirmation: - Read the diff (or summary) and PR message, then ask for confirmation: - - a. Read the appropriate diff file: - - .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes.diff - - OR (if summary exists): - - .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes_summary.txt - - - b. Read the PR message: - - .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md - - - c. Ask for user confirmation: - - - 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? - - - Looks good, go ahead and commit the changes - I tested the changes, and something is wrong - let me explain... - I still need to test the changes manually before committing - I want to modify the PR message before proceeding - Cancel this task - - - - 7. Handle User Decision: - Based on user response: - - **If "Looks good, go ahead and commit":** - - Proceed to commit and push: - - - # 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) - - - - 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 - - - - - Finalize and Create PR - - After user confirmation and successful commit, finalize the process. - - 1. Verify Push Success: - - - # 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 - - - - 2. Present Final PR Creation Options: - - - 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? - - - Create the PR automatically using the saved message - I'll create the PR manually - just show me the branch name - I want to make more changes first - - - - 3. Handle Final Decision: - - **If "Create PR automatically":** - - Read PR details and create: - - - # 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." - - - - **If "Create manually":** - - Show branch name and location of PR message: - - - 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." - - - - **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: - - - Would you like me to clean up the temporary task files now, or keep them for reference? - - - Yes, clean up the temporary files - No, keep the files for now - - - - If yes, clean up: - - rm -rf .roo/temp/issue-fixer-orchestrator/[TASK_ID] - - - - - - Monitor PR (Optional) - - If a PR was created automatically, offer to monitor its status. - - 1. Check if PR exists: - - - # Check if there's a PR for the current branch - BRANCH=$(git branch --show-current) - gh pr list --head $BRANCH --json number,state,checks - - - - 2. If PR exists, offer monitoring: - - - Would you like me to monitor the PR checks and CI status? - - - Yes, monitor the PR checks - No, I'll check it myself - - - - 3. If user wants monitoring: - - - 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 - - - - This concludes the orchestration workflow. - - - \ No newline at end of file diff --git a/.roo/rules-issue-fixer-orchestrator/2_best_practices.xml b/.roo/rules-issue-fixer-orchestrator/2_best_practices.xml deleted file mode 100644 index 839d862fb8..0000000000 --- a/.roo/rules-issue-fixer-orchestrator/2_best_practices.xml +++ /dev/null @@ -1,120 +0,0 @@ - - - Always read the entire issue and all comments before starting - - Follow the project's coding standards and patterns - - Focus exclusively on addressing the issue's requirements. - - Make minimal, high-quality changes for bug fixes. The goal is a narrow, targeted fix, not a one-line hack. - - Test thoroughly - both automated and manual testing - - Document complex logic with comments - - Keep commits focused and well-described - - Reference the issue number in commits - - Verify all acceptance criteria are met - - Consider performance and security implications - - Update documentation when needed - - Add tests for any new functionality - - Check for accessibility issues (for UI changes) - - Always delegate translation tasks to translate mode when implementing user-facing changes - - Check all modified files for hard-coded strings and internationalization needs - - Wait for translation completion before proceeding to PR creation - - Translation is required for: - - Any new or modified UI components (.tsx, .jsx files) - - User-facing documentation changes (.md files) - - Error messages and notifications - - Any strings visible to end users - - The translate mode will handle: - - Adding translations to all supported language files - - Ensuring consistency with existing terminology - - Maintaining sync across all language resources - - - Always verify files before committing - - - 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 - - - - - 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 - - - - - 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 - - - - - 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 - - - - - 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 - - - - Always use `codebase_search` FIRST to understand the codebase structure and find all related files before using other tools like `read_file`. - - - Critical: Understand Component Interactions - - Map the complete data flow from input to output - Identify ALL paired operations (import/export, save/load, encode/decode) - Find all consumers and dependencies of the affected code - Trace how data transformations occur throughout the system - Understand error propagation and handling patterns - - - - - Investigation Checklist for Bug Fixes - Search for the specific error message or broken functionality. - Find all relevant error handling and logging statements. - Locate related test files to understand expected behavior. - Identify all dependencies and import/export patterns for the affected code. - Find similar, working patterns in the codebase to use as a reference. - **CRITICAL**: For any operation being fixed, find and analyze its paired operations - Trace the complete data flow to understand all affected components - - - - Investigation Checklist for New Features - Search for any similar existing features to use as a blueprint. - Find potential integration points (e.g., API routes, UI component registries). - Locate relevant configuration files that may need to be updated. - Identify common patterns, components, and utilities that should be reused. - **CRITICAL**: Design paired operations together (e.g., both import AND export) - Map all data transformations and state changes - Identify all downstream consumers of the new functionality - - - - Always Implement Paired Operations Together - - When fixing export, ALWAYS check and update import - When modifying save, ALWAYS verify load handles the changes - When changing serialization, ALWAYS update deserialization - When updating create, consider read/update/delete operations - - - Paired operations must maintain consistency. Changes to one without the other leads to data corruption, import failures, or broken functionality. - - - - - Always read multiple related files together to understand the full context. Never assume a change is isolated - trace its impact through the entire system. - - - \ No newline at end of file diff --git a/.roo/rules-issue-fixer-orchestrator/3_common_patterns.xml b/.roo/rules-issue-fixer-orchestrator/3_common_patterns.xml deleted file mode 100644 index 97bba7a9e4..0000000000 --- a/.roo/rules-issue-fixer-orchestrator/3_common_patterns.xml +++ /dev/null @@ -1,38 +0,0 @@ - - - 1. Reproduce the issue - 2. Identify root cause - 3. Implement minimal fix - 4. Add regression test - 5. Verify fix works - 6. Check for side effects - - - - 1. Understand all requirements - 2. Design the solution - 3. Implement incrementally - 4. Test each component - 5. Integrate components - 6. Verify acceptance criteria - 7. Add comprehensive tests - 8. Update documentation - - - - 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 - - \ No newline at end of file diff --git a/.roo/rules-issue-fixer-orchestrator/4_github_cli_usage.xml b/.roo/rules-issue-fixer-orchestrator/4_github_cli_usage.xml deleted file mode 100644 index e12fb06a5b..0000000000 --- a/.roo/rules-issue-fixer-orchestrator/4_github_cli_usage.xml +++ /dev/null @@ -1,221 +0,0 @@ - - - This mode uses the GitHub CLI (gh) for all GitHub operations. - The mode assumes the user has gh installed and authenticated. If authentication errors occur, - the mode will prompt the user to authenticate. - - Users must provide full GitHub issue URLs (e.g., https://github.com/owner/repo/issues/123) - so the mode can extract the repository information dynamically. - - - - https://github.com/[owner]/[repo]/issues/[number] - - - Owner: The organization or username - - Repo: The repository name - - Number: The issue number - - - - - Assume authenticated, handle errors gracefully - Only check authentication if a gh command fails with auth error - - - "gh: Not authenticated" - - "HTTP 401" - - "HTTP 403: Resource not accessible" - - - - - - Retrieve the issue details at the start - Always use first to get the full issue content - gh issue view [issue-number] --repo [owner]/[repo] --json number,title,body,state,labels,assignees,milestone,createdAt,updatedAt,closedAt,author - - - gh issue view 123 --repo octocat/hello-world --json number,title,body,state,labels,assignees,milestone,createdAt,updatedAt,closedAt,author - - - - - - Get additional context and requirements from issue comments - Always use after viewing issue to see full discussion - gh issue view [issue-number] --repo [owner]/[repo] --comments - - - gh issue view 123 --repo octocat/hello-world --comments - - - - - - - Find recent changes to affected files - Use during codebase exploration - gh api repos/[owner]/[repo]/commits?path=[file-path]&per_page=10 - - - gh api repos/octocat/hello-world/commits?path=src/api/index.ts&per_page=10 --jq '.[].sha + " " + .[].commit.message' - - - - - - Search for code patterns on GitHub - Use to supplement local codebase_search - gh search code "[search-query]" --repo [owner]/[repo] - - - gh search code "function handleError" --repo octocat/hello-world --limit 10 - - - - - - - - Add progress updates or ask questions on issues - Use if clarification needed or to show progress - gh issue comment [issue-number] --repo [owner]/[repo] --body "[comment]" - - - gh issue comment 123 --repo octocat/hello-world --body "Working on this issue. Found the root cause in the theme detection logic." - - - - - - Find related or similar PRs - Use to understand similar changes - gh pr list --repo [owner]/[repo] --search "[search-terms]" - - - gh pr list --repo octocat/hello-world --search "dark theme" --limit 10 - - - - - - View the diff of a pull request - Use to understand changes in a PR - gh pr diff [pr-number] --repo [owner]/[repo] - - - gh pr diff 456 --repo octocat/hello-world - - - - - - - - Create a pull request - Use in step 11 after user approval - - - Target the repository from the provided URL - - Use "main" as the base branch unless specified otherwise - - Include issue number in PR title - - Use --maintainer-can-modify flag - - gh pr create --repo [owner]/[repo] --base main --title "[title]" --body "[body]" --maintainer-can-modify - - - gh pr create --repo octocat/hello-world --base main --title "fix: Resolve dark theme button visibility (#123)" --body "## Description - -Fixes #123 - -[Full PR description]" --maintainer-can-modify - - - - If working from a fork, ensure the fork is set as the remote and push the branch there first. - The gh CLI will automatically handle the fork workflow. - - - - - Fork the repository if user doesn't have push access - Use if user needs to work from a fork - gh repo fork [owner]/[repo] --clone - - - gh repo fork octocat/hello-world --clone - - - - - - Monitor CI/CD checks on a pull request - Use after creating PR to ensure checks pass - gh pr checks [pr-number] --repo [owner]/[repo] --watch - - - gh pr checks 789 --repo octocat/hello-world --watch - - - - - - - - Access GitHub API directly for advanced operations - Use when specific gh commands don't provide needed functionality - - - - gh api repos/[owner]/[repo] --jq '.default_branch' - - - - - gh api repos/[owner]/[repo]/contents/README.md --jq '.content' | base64 -d - - - - - gh api repos/[owner]/[repo]/actions/runs --jq '.workflow_runs[0:5] | .[] | .id, .status, .conclusion' - - - - - - Check GitHub Actions workflow status - Use to monitor CI/CD pipeline - gh run list --repo [owner]/[repo] --limit 5 - - - gh run list --repo octocat/hello-world --limit 5 - - - - - - - - gh: Not authenticated. Run 'gh auth login' to authenticate. - - Ask user to authenticate: - - GitHub CLI is not authenticated. Please run 'gh auth login' in your terminal to authenticate, then let me know when you're ready to continue. - - I've authenticated, please continue - I need help with authentication - Let's use a different approach - - - - - - - HTTP 403: Resource not accessible by integration - - Check if working from a fork is needed: - - gh repo fork [owner]/[repo] --clone - - - - - \ No newline at end of file diff --git a/.roo/rules-issue-fixer-orchestrator/5_pull_request_workflow.xml b/.roo/rules-issue-fixer-orchestrator/5_pull_request_workflow.xml deleted file mode 100644 index 03da14d8a4..0000000000 --- a/.roo/rules-issue-fixer-orchestrator/5_pull_request_workflow.xml +++ /dev/null @@ -1,106 +0,0 @@ - - - 1. Ensure all changes are committed with proper message format - 2. Push to appropriate branch (fork or direct) - 3. Prepare comprehensive PR description - 4. Get user approval before creating PR - 5. Extract owner and repo from the provided GitHub URL - - - - - Bug fixes: "fix: [description] (#[issue-number])" - - Features: "feat: [description] (#[issue-number])" - - Follow conventional commit format - - - A comprehensive PR description is critical. The subtask responsible for preparing the PR content should generate a body that includes the following markdown structure: - - ```markdown - ## Description - - Fixes #[issue number] - - [Detailed description of what was changed and why] - - ## Changes Made - - - [Specific change 1 with file references] - - [Specific change 2 with technical details] - - [Any refactoring or cleanup done] - - ## Testing - - - [x] All existing tests pass - - [x] Added tests for [specific functionality] - - [x] Manual testing completed: - - [Specific manual test 1] - - [Specific manual test 2] - - ## Translations - - [If translations were added/updated] - - [x] All user-facing strings have been translated - - [x] Updated language files: [list of languages] - - [x] Translations reviewed for consistency - - [If no translations needed] - - No user-facing string changes in this PR - - ## Verification of Acceptance Criteria - - [For each criterion from the issue, show it's met] - - [x] Criterion 1: [How it's verified] - - [x] Criterion 2: [How it's verified] - - ## Checklist - - - [x] Code follows project style guidelines - - [x] Self-review completed - - [x] Comments added for complex logic - - [x] Documentation updated (if needed) - - [x] No breaking changes (or documented if any) - - [x] Accessibility checked (for UI changes) - - [x] Translations added/updated (for UI changes) - - ## Screenshots/Demo (if applicable) - - [Add before/after screenshots for UI changes] - [Add terminal output for CLI changes] - ``` - - - - Use a consistent format for branch names. - - - Bug fixes: `fix/issue-[number]-[brief-description]` - - Features: `feat/issue-[number]-[brief-description]` - - - - - Use GitHub CLI to create the pull request: - - gh pr create --repo [owner]/[repo] --base main --title "[title]" --body "[description]" --maintainer-can-modify - - - If working from a fork, ensure you've forked first: - - gh repo fork [owner]/[repo] --clone - - - The gh CLI automatically handles fork workflows. - - - - 1. Comment on original issue with PR link: - - gh issue comment [issue-number] --repo [owner]/[repo] --body "PR #[pr-number] has been created to address this issue" - - 2. Inform user of successful creation - 3. Provide next steps and tracking info - 4. Monitor PR checks: - - gh pr checks [pr-number] --repo [owner]/[repo] --watch - - - \ No newline at end of file diff --git a/.roo/rules-issue-fixer-orchestrator/6_testing_guidelines.xml b/.roo/rules-issue-fixer-orchestrator/6_testing_guidelines.xml deleted file mode 100644 index 721a89f2b9..0000000000 --- a/.roo/rules-issue-fixer-orchestrator/6_testing_guidelines.xml +++ /dev/null @@ -1,10 +0,0 @@ - - - Always run existing tests before making changes (baseline) - - Add tests for any new functionality - - Add regression tests for bug fixes - - Test edge cases and error conditions - - Run the full test suite before completing - - For UI changes, test in multiple themes - - Verify accessibility (keyboard navigation, screen readers) - - Test performance impact for large operations - \ No newline at end of file diff --git a/.roo/rules-issue-fixer-orchestrator/7_communication_style.xml b/.roo/rules-issue-fixer-orchestrator/7_communication_style.xml deleted file mode 100644 index 898269cc0c..0000000000 --- a/.roo/rules-issue-fixer-orchestrator/7_communication_style.xml +++ /dev/null @@ -1,27 +0,0 @@ - - - Be clear about what you're doing at each step - - Explain technical decisions and trade-offs - - Ask for clarification if requirements are ambiguous - - Provide regular progress updates for complex issues - - Summarize changes clearly for non-technical stakeholders - - Use issue numbers and links for reference - - Inform the user when delegating to translate mode - - Include translation status in progress updates - - Mention in PR description if translations were added - - - - 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 - - - - - 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 - - \ No newline at end of file diff --git a/.roo/rules-issue-fixer-orchestrator/8_github_communication_guidelines.xml b/.roo/rules-issue-fixer-orchestrator/8_github_communication_guidelines.xml deleted file mode 100644 index 627908f1f7..0000000000 --- a/.roo/rules-issue-fixer-orchestrator/8_github_communication_guidelines.xml +++ /dev/null @@ -1,16 +0,0 @@ - - - - Provide brief status updates when working on complex issues - - Ask specific questions if requirements are unclear - - Share findings when investigation reveals important context - - Keep progress updates factual and concise - - Example: "Found the root cause in the theme detection logic. Working on a fix that preserves backward compatibility." - - - - - Follow conventional commit format: "type: description (#issue-number)" - - Keep first line under 72 characters - - Be specific about what changed - - Example: "fix: resolve button visibility in dark theme (#123)" - - \ No newline at end of file diff --git a/.roo/rules-issue-fixer-orchestrator/9_translation_handling.xml b/.roo/rules-issue-fixer-orchestrator/9_translation_handling.xml deleted file mode 100644 index 15d196263c..0000000000 --- a/.roo/rules-issue-fixer-orchestrator/9_translation_handling.xml +++ /dev/null @@ -1,125 +0,0 @@ - - - The issue-fixer-orchestrator mode must ensure all user-facing content is properly translated before creating a pull request. This is achieved by delegating translation tasks to the specialized translate mode. - - - - - Any changes to React/Vue/Angular components - - - webview-ui/src/**/*.tsx - - webview-ui/src/**/*.jsx - - src/**/*.tsx (if contains UI elements) - - - - New text strings in JSX - - Updated button labels, tooltips, or placeholders - - Error messages displayed to users - - Any hardcoded strings that should use i18n - - - - - User-facing documentation changes - - - README.md - - docs/**/*.md - - webview-ui/src/components/chat/Announcement.tsx - - Any markdown files visible to end users - - - - - Direct changes to translation files - - - src/i18n/locales/**/*.json - - webview-ui/src/i18n/locales/**/*.json - - When English (en) locale is updated, all other locales must be synchronized - - - - New or modified error messages - - - API error responses - - Validation messages - - System notifications - - Status messages - - - - - - - Detect Translation Needs - - - Read the modified_files.json from the implementation step - - Check each file against the patterns above - - Determine if any user-facing content was changed - - - - - Prepare Translation Context - - - Gather all context files (issue details, implementation plan, modified files) - - Identify specific strings or content that need translation - - Note any special terminology or context from the issue - - - - - Delegate to Translate Mode - - - Use new_task to create a translation subtask - - Provide clear instructions about what needs translation - - Include paths to all context files - - Specify expected output (translation_summary.md) - - - - - Verify Translation Completion - - - Wait for the translate mode subtask to complete - - Read the translation_summary.md file - - Confirm all necessary translations were handled - - Only proceed to PR creation after confirmation - - - - - - Template for creating translation subtasks - - - Clear identification of the issue being fixed - - List of modified files requiring translation review - - Path to context files for understanding the changes - - Specific instructions for what to translate - - Expected output format and location - - - - - Always check for translations AFTER verification passes - Don't skip translation even for "minor" UI changes - Ensure the translate mode has access to full context - Wait for translation completion before creating PR - Include translation changes in the PR description - - - - - Assuming no translations needed without checking - Always analyze modified files for user-facing content - - - Proceeding to PR creation before translations complete - Wait for translation_summary.md confirmation - - - Not providing enough context to translate mode - Include issue details and implementation plan - - - \ No newline at end of file diff --git a/.roo/rules-issue-fixer/9_pr_template.xml b/.roo/rules-issue-fixer/9_pr_template.xml new file mode 100644 index 0000000000..4c35819b1f --- /dev/null +++ b/.roo/rules-issue-fixer/9_pr_template.xml @@ -0,0 +1,205 @@ + + + This file contains the official Roo Code PR template that must be used when creating pull requests. + All PRs must follow this exact format to ensure consistency and proper documentation. + + + + + The PR body must follow this exact Roo Code PR template with all required sections. + Replace placeholder content in square brackets with actual information. + + + + + + + Valid GitHub CLI commands for creating PRs with the proper template + + + + Create a PR using the filled template + + The PR body should be saved to a temporary file first, then referenced with --body-file + + + + Alternative: Create PR with inline body (for shorter content) + + Use this only if the body content doesn't contain special characters that need escaping + + + + Fork repository if user doesn't have push access + + The --clone=false flag prevents cloning since we're already in the repo + + + + + PR titles should follow conventional commit format + + fix: [brief description] (#[issue-number]) + feat: [brief description] (#[issue-number]) + docs: [brief description] (#[issue-number]) + refactor: [brief description] (#[issue-number]) + test: [brief description] (#[issue-number]) + chore: [brief description] (#[issue-number]) + + + + + How to fill in the template placeholders + + + The GitHub issue number being addressed + 123 + + + Optional Roo Code task links if used during development + https://app.roocode.com/share/task-abc123 + _No Roo Code task context for this PR_ + + + Detailed explanation of implementation approach + + - Focus on HOW you solved the problem + - Mention key design decisions + - Highlight any trade-offs made + - Point out areas needing special review attention + + + + Steps to verify the changes work correctly + + - List specific test commands run + - Describe manual testing performed + - Include steps for reviewers to reproduce tests + - Mention test environment details if relevant + + + + Visual evidence of changes for UI modifications + _No UI changes in this PR_ + + + Documentation impact assessment + - [x] No documentation updates are required. + + + Any extra context for reviewers + _No additional notes_ + + + Discord username for communication + @username + + + + \ No newline at end of file diff --git a/.roo/rules-issue-investigator/1_workflow.xml b/.roo/rules-issue-investigator/1_workflow.xml new file mode 100644 index 0000000000..561b275120 --- /dev/null +++ b/.roo/rules-issue-investigator/1_workflow.xml @@ -0,0 +1,98 @@ + + + This mode investigates GitHub issues to find the probable root cause and suggest a theoretical solution. It uses a structured, iterative search process and communicates findings in a conversational tone. + + + + + Understand the user's request +
+ The user will provide a GitHub issue URL or number. Your first step is to fetch the issue details using the `gh` CLI. +
+ + gh issue view ISSUE_URL --json title,body,labels,comments + + + + Create an investigation plan +
+ Based on the issue details, create a todo list to track the investigation. +
+ + +[ ] Extract keywords from the issue title and body. +[ ] Perform initial codebase search with keywords. +[ ] Analyze search results and form a hypothesis. +[ ] Attempt to disprove the hypothesis. +[ ] Formulate a theoretical solution. +[ ] Draft a comment for the user. + + + ]]> + + + + + + + Systematically search the codebase to identify the root cause. This is an iterative process. + + + + Extract Keywords + Identify key terms, function names, error messages, and concepts from the issue title, body, and comments. + + + Iterative Codebase Search + Use `codebase_search` with the extracted keywords. Start broad and then narrow down your search based on the results. Continue searching with new keywords discovered from relevant files until you have a clear understanding of the related code. + + codebase_search + + + + Form a Hypothesis + Based on the search results, form a hypothesis about the probable cause of the issue. Document this hypothesis. + + + Attempt to Disprove Hypothesis + Actively try to find evidence that contradicts your hypothesis. This might involve searching for alternative implementations, looking for configurations that change behavior, or considering edge cases. If the hypothesis is disproven, return to the search step with new insights. + + + + + + Formulate a solution and prepare to communicate it. + + + Formulate Theoretical Solution + Once the hypothesis is stable, describe a potential solution. Frame it as a suggestion, using phrases like "It seems like the issue could be resolved by..." or "A possible fix would be to...". + + + Draft Comment + Draft a comment for the GitHub issue that explains your findings and suggested solution in a conversational, human-like tone. + + + + + + Ask the user for confirmation before posting any comments. + +I've investigated the issue and drafted a comment with my findings and a suggested solution. Would you like me to post it to the GitHub issue? + +Yes, please post the comment to the issue. +Show me the draft comment first. +No, do not post the comment. + + + ]]> + + + + + A probable cause has been identified and validated. + A theoretical solution has been proposed. + The user has decided whether to post a comment on the issue. + + \ No newline at end of file diff --git a/.roo/rules-issue-investigator/2_best_practices.xml b/.roo/rules-issue-investigator/2_best_practices.xml new file mode 100644 index 0000000000..31ad2c2267 --- /dev/null +++ b/.roo/rules-issue-investigator/2_best_practices.xml @@ -0,0 +1,59 @@ + + + + Be Methodical + Follow the workflow steps precisely. Do not skip the hypothesis validation step. A rigorous process leads to more accurate conclusions. + Skipping steps can lead to incorrect assumptions and wasted effort. The goal is to be confident in the proposed solution. + + + Embrace Iteration + The investigation is not linear. Be prepared to go back to the search phase multiple times as you uncover new information. Each search should build on the last. + Complex issues rarely have a single, obvious cause. Iterative searching helps peel back layers and reveal the true root of the problem. + + + Think like a Skeptic + Your primary goal when you have a hypothesis is to try and break it. Actively look for evidence that you are wrong. This makes your final conclusion much stronger. + Confirmation bias is a common pitfall. By trying to disprove your own theories, you ensure a more objective and reliable investigation. + + + + + + Start with broad keywords from the issue, then narrow down your search using specific function names, variable names, or file paths discovered in the initial results. + + Initial search: "user authentication fails". Follow-up search: "getUserById invalid token". + Searching for a generic term like "error" without context. + + + + + + + Jumping to conclusions after the first search. + The first set of results might be misleading or only part of the story. + Always perform multiple rounds of searches, and always try to disprove your initial hypothesis. + + + Forgetting to use the todo list. + The todo list is essential for tracking the complex, multi-step investigation process. Without it, you can lose track of your progress and findings. + Update the todo list after each major step in the workflow. + + + + + + Have I extracted all relevant keywords from the issue? + Have I performed at least two rounds of codebase searches? + Have I genuinely tried to disprove my hypothesis? + + + Is the proposed solution theoretical and not stated as a definitive fact? + Is the explanation clear and easy to understand? + + + Does the draft comment sound conversational and human? + Have I avoided technical jargon where possible? + Is the tone helpful and not condescending? + + + \ No newline at end of file diff --git a/.roo/rules-issue-investigator/3_common_patterns.xml b/.roo/rules-issue-investigator/3_common_patterns.xml new file mode 100644 index 0000000000..2a17e7be72 --- /dev/null +++ b/.roo/rules-issue-investigator/3_common_patterns.xml @@ -0,0 +1,45 @@ + + + For investigating bug reports where something is broken. + + + + + For investigating issues where the system works but not as expected. + + + + + For investigating issues related to slowness or high resource usage. + + + \ No newline at end of file diff --git a/.roo/rules-issue-investigator/4_tool_usage.xml b/.roo/rules-issue-investigator/4_tool_usage.xml new file mode 100644 index 0000000000..c43c41a8c3 --- /dev/null +++ b/.roo/rules-issue-investigator/4_tool_usage.xml @@ -0,0 +1,78 @@ + + + + gh issue view + Always use first to get the issue context. + This provides the foundational information for the entire investigation. + + + codebase_search + For all investigation steps to find relevant code. + Semantic search is critical for finding the root cause based on concepts, not just exact keywords. + + + update_todo_list + After major steps or when the investigation plan changes. + Maintains a clear record of the investigation's state and next steps. + + + + + + + Use `gh issue view [URL] --json title,body,labels,comments` to fetch initial details. + Use `gh issue comment [URL] --body "..."` to add comments, but only after explicit user approval. + Always wrap the comment body in quotes to handle special characters. + + +gh issue view https://github.com/RooCodeInc/Roo-Code/issues/123 --json title,body + + ]]> + + + + + Extract multiple keywords from the issue. Combine them in your search query. + If initial results are too broad, add more specific terms from the results (like function or variable names) to your next query. + Use this tool iteratively. Don't rely on a single search. + + +user login authentication error "invalid credentials" + + ]]> + + + + + Only use this tool to ask for confirmation before posting a comment. + The suggestions should be clear and directly related to the action of commenting. + + +I have analyzed the issue and drafted a comment. Would you like me to post it? + +Yes, go ahead and post the comment. +Let me see the comment first before you post it. +No, do not post anything. I will handle it. + + + ]]> + + + + + + + execute_command (gh issue view) - Get issue details. + update_todo_list - Create an investigation plan. + codebase_search - Perform initial search. + read_file - Analyze relevant file contents. + codebase_search - Perform follow-up search to confirm/deny hypothesis. + ask_followup_question - Ask user to confirm before commenting. + execute_command (gh issue comment) - Post the comment if approved. + + + + \ No newline at end of file diff --git a/.roo/rules-issue-investigator/5_examples.xml b/.roo/rules-issue-investigator/5_examples.xml new file mode 100644 index 0000000000..dbd4ae2f23 --- /dev/null +++ b/.roo/rules-issue-investigator/5_examples.xml @@ -0,0 +1,99 @@ + + + + A user has reported a bug where they are unable to log in with valid credentials, but no error message is shown. + + + + "Please investigate issue #456. Users are reporting that they can't log in." + + + + + Fetch issue details from GitHub. + +gh issue view 456 --json title,body,comments + + ]]> + Get the title "Login fails silently" and body "Users with valid credentials are not able to log in. The page just refreshes without any error message." + + + + Create the initial investigation plan. + + +[x] Extract keywords from the issue title and body. +[-] Perform initial codebase search with keywords. +[ ] Analyze search results and form a hypothesis. +[ ] Attempt to disprove the hypothesis. +[ ] Formulate a theoretical solution. +[ ] Draft a comment for the user. + + + ]]> + + + + Perform initial codebase search using keywords "login", "authentication", "silent fail". + +user login authentication silent fail + + ]]> + The search results point to `src/auth/login.ts` as a highly relevant file. + + + + Read the contents of the relevant file. + +src/auth/login.ts + + ]]> + + The file contains a `try...catch` block in the `handleLogin` function. The `catch` block is empty, which explains the silent failure. This is the likely cause. Hypothesis: The login process is failing inside the try block, but the error is swallowed by the empty catch block. + + + + + Attempt to disprove the hypothesis by looking for other error handling mechanisms. + +global error handling middleware Express + + ]]> + No global error handling middleware seems to be in use that would override this local empty catch block. The hypothesis stands. + + + + Formulate a solution and draft a comment. + +"Hey, I took a look at this issue and it seems like the problem is in the `handleLogin` function in `src/auth/login.ts`. There's an empty `try...catch` block that is likely catching the login error and preventing any message from being shown to the user. + +A good first step to fixing this would be to add some logging to the `catch` block to see what error is actually happening. Then, we should probably implement proper error feedback to the user on the login page. This should solve the issue of the silent failure." + + + + + Ask the user for confirmation before posting the comment. + +I've investigated the issue and drafted a comment with my findings and a suggested solution. Would you like me to post it to the GitHub issue? + +Yes, please post the comment to the issue. +Show me the draft comment first. +No, do not post the comment. + + + ]]> + + + + + Empty catch blocks are a strong indicator of silent failures. + Always try to disprove a hypothesis by looking for conflicting code patterns. + + + \ No newline at end of file diff --git a/.roo/rules-issue-investigator/6_communication.xml b/.roo/rules-issue-investigator/6_communication.xml new file mode 100644 index 0000000000..348ecf1878 --- /dev/null +++ b/.roo/rules-issue-investigator/6_communication.xml @@ -0,0 +1,35 @@ + + + Be conversational and helpful, not robotic. + Write comments as if you are a human developer collaborating on the project. + + Analysis complete. + The investigation has yielded the following result. + + + Hey, I took a look at this and found something interesting... + I've been digging into this issue, and I think I've found a possible cause. + + + + + Start with a friendly opening. + State your main finding or hypothesis clearly but not definitively. + Provide context, like file paths and function names. + Propose a next step or a theoretical solution. + Keep it concise and easy to read. Avoid large blocks of text. + Use markdown for code snippets or file paths only when necessary for clarity. + + + + + What was accomplished (e.g., "Investigation complete."). + A summary of the findings and the proposed solution. + A final statement indicating that the user has been prompted on how to proceed with the comment. + + + Ending with a question. + Offers for further assistance. + + + \ No newline at end of file diff --git a/.roo/rules-issue-writer/1_workflow.xml b/.roo/rules-issue-writer/1_workflow.xml index a861bcafbb..f24b643e3d 100644 --- a/.roo/rules-issue-writer/1_workflow.xml +++ b/.roo/rules-issue-writer/1_workflow.xml @@ -1,16 +1,74 @@ + + + Initialize Issue Creation Process + + When the user requests to create an issue, immediately set up a todo list to track the workflow. + + + + [ ] Analyze user request to determine issue type + [ ] Gather initial information for the issue + [ ] Determine if user wants to contribute + [ ] Perform technical analysis (if contributing) + [ ] Draft issue content + [ ] Review and confirm with user + [ ] Create GitHub issue + + + + + + Determine Issue Type - Use ask_followup_question to determine if the user wants to create: + Analyze the user's initial request to automatically assess whether they're reporting a bug or proposing a feature. + Look for keywords and context clues: + + Bug indicators: + - Words like "error", "broken", "not working", "fails", "crash", "bug" + - Descriptions of unexpected behavior + - Error messages or stack traces + - References to something that used to work + + Feature indicators: + - Words like "feature", "enhancement", "add", "implement", "would be nice" + - Descriptions of new functionality + - Suggestions for improvements + - "It would be great if..." + + Based on your analysis, order the options with the most likely choice first: - What type of issue would you like to create? + Based on your request, what type of issue would you like to create? + [If bug indicators found:] + Bug Report - Report a problem with existing functionality + Detailed Feature Proposal - Propose a new feature or enhancement + + [If feature indicators found:] + Detailed Feature Proposal - Propose a new feature or enhancement + Bug Report - Report a problem with existing functionality + + [If unclear:] Bug Report - Report a problem with existing functionality Detailed Feature Proposal - Propose a new feature or enhancement + + After determining the type, update the todo list: + + + [x] Analyze user request to determine issue type + [-] Gather initial information for the issue + [ ] Determine if user wants to contribute + [ ] Perform technical analysis (if contributing) + [ ] Draft issue content + [ ] Review and confirm with user + [ ] Create GitHub issue + + @@ -38,96 +96,97 @@ Use multiple ask_followup_question calls if needed to gather all information. Be specific in your questions based on what's missing. + + After gathering information, update the todo: + + + [x] Analyze user request to determine issue type + [x] Gather initial information for the issue + [-] Determine if user wants to contribute + [ ] Perform technical analysis (if contributing) + [ ] Draft issue content + [ ] Review and confirm with user + [ ] Create GitHub issue + + - Search GitHub Discussions - - Search GitHub Discussions for related feature requests or bug reports: - - 1. Use the GitHub web interface or API to search discussions in: - https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests - - 2. Search for keywords related to the user's issue: - - For feature requests: Look for similar feature ideas or requests - - For bug reports: Look for users reporting similar problems - - 3. Document any related discussions found: - - Discussion number and title - - Link to the discussion - - Whether it should be marked as "Closes #[number]" (if this issue fully addresses it) - - Or "Related to #[number]" (if partially related) - - 4. If multiple related discussions exist, list them all for inclusion in the issue - - - - Determine if User Wants to Contribute Before exploring the codebase, determine if the user wants to contribute the implementation: - Are you interested in implementing this feature yourself, or are you just reporting the problem for the Roo team to solve? + Are you interested in implementing this yourself, or are you just reporting the problem for the Roo team to solve? Just reporting the problem - the Roo team can design the solution - I want to contribute and implement this feature myself + I want to contribute and implement this myself I'm not sure yet, but I'd like to provide technical analysis Based on their response: - - If just reporting: Skip to step 6 (Draft Issue - Problem Only) - - If contributing: Continue to step 5 (Explore Codebase) - - If providing analysis: Continue to step 5 but make technical sections optional + - If just reporting: Skip to step 5 (Draft Issue - Problem Only) + - If contributing: Continue to step 4 (Technical Analysis) + - If providing analysis: Continue to step 4 but make technical sections optional + + Update the todo based on the decision: + + + [x] Analyze user request to determine issue type + [x] Gather initial information for the issue + [x] Determine if user wants to contribute + [If contributing: [ ] Perform technical analysis (if contributing)] + [If not contributing: [-] Perform technical analysis (skipped - not contributing)] + [-] Draft issue content + [ ] Review and confirm with user + [ ] Create GitHub issue + + + + + + + Technical Analysis for Contributors + + ONLY perform this step if the user wants to contribute or provide technical analysis. + + This step uses the comprehensive technical analysis sub-workflow defined in + 6_technical_analysis_workflow.xml. The sub-workflow will: + + 1. Create its own detailed investigation todo list + 2. Perform exhaustive codebase searches using iterative refinement + 3. Analyze all relevant files and dependencies + 4. Form and validate hypotheses about the implementation + 5. Create a comprehensive technical solution + 6. Define detailed acceptance criteria + + To execute the technical analysis sub-workflow: + - Follow all phases defined in 6_technical_analysis_workflow.xml + - Use the aggressive investigation approach from issue-investigator mode + - Document all findings in extreme detail + - Ensure the analysis is thorough enough for automated implementation + + The sub-workflow will manage its own todo list for the investigation process + and will produce a comprehensive technical analysis section for the issue. + + After completing the technical analysis: + + + [x] Analyze user request to determine issue type + [x] Gather initial information for the issue + [x] Determine if user wants to contribute + [x] Perform technical analysis (if contributing) + [-] Draft issue content + [ ] Review and confirm with user + [ ] Create GitHub issue + + - Explore Codebase for Contributors - - ONLY perform this step if the user wants to contribute or provide technical analysis. - - Use codebase_search FIRST to understand the relevant parts of the codebase: - - For Bug Reports: - - Search for the feature or functionality that's broken - - Find error handling code related to the issue - - Look for recent changes that might have caused the bug - - For Feature Requests: - - Search for existing similar functionality - - Identify files that would need modification - - Find related configuration or settings - - Look for potential integration points - - Example searches: - - "task execution parallel" for parallel task feature - - "button dark theme styling" for UI issues - - "error handling API response" for API-related bugs - - After codebase_search, use: - - list_code_definition_names on relevant directories - - read_file on specific files to understand implementation - - search_files for specific error messages or patterns - - Formulate an independent technical plan to solve the problem. - - Document all relevant findings including: - - File paths and line numbers - - Current implementation details - - Your proposed implementation plan - - Related code that might be affected - - Then gather additional technical details: - - Ask for proposed solution approach - - Request acceptance criteria in Given/When/Then format - - Discuss technical considerations and trade-offs - - - - Draft Issue Content Create the issue body based on whether the user is just reporting or contributing. @@ -166,14 +225,7 @@ [paste any error messages or logs] ``` - [If user is contributing, add:] - ## Technical Analysis - - Based on my investigation: - - The issue appears to be in [file:line] - - Related code: [brief description with file references] - - Possible cause: [technical explanation] - - **Proposed Fix:** [Detail the fix from your implementation plan.] + [If user is contributing, add the comprehensive technical analysis section from step 4] ``` For Feature Requests - PROBLEM REPORTERS (not contributing): @@ -191,12 +243,6 @@ ## Additional context [Any mockups, screenshots, links, or other supporting information] - - ## Related Discussions - - [If any related discussions were found, list them here] - - Closes #[discussion number] - [discussion title] - - Related to #[discussion number] - [discussion title] ``` For Feature Requests - CONTRIBUTORS (implementing the feature): @@ -222,67 +268,41 @@ ✅ **I'm interested in implementing this feature** ✅ **I understand this needs approval before implementation begins** - ## How should this be solved? - - [Based on your analysis, describe the proposed solution] - - **What will change:** - - [Specific change 1] - - [Specific change 2] - - **User interaction:** - - [How users will use this feature] - - [What they'll see in the UI] + [Insert the comprehensive technical analysis section from step 4, including:] + - Root cause / Implementation target + - Affected components with file paths and line numbers + - Current implementation analysis + - Detailed proposed implementation steps + - Code architecture considerations + - Testing requirements + - Performance impact + - Security considerations + - Migration strategy + - Rollback plan + - Dependencies and breaking changes + - Implementation complexity assessment ## Acceptance Criteria - ``` - Given [context] - When [action] - Then [result] - And [additional expectation] - But [what should not happen] + [Insert the detailed acceptance criteria from the technical analysis] ``` - [Add multiple scenarios as needed] - - ## Technical Considerations - - **Implementation approach:** - - Key files to modify: [list with paths] - - Current architecture: [brief description] - - Integration points: [where this fits] - - Similar patterns in codebase: [examples] - - **Performance implications:** - [Any performance considerations] - - **Compatibility concerns:** - [Any compatibility issues] - - ## Trade-offs and Risks - - **Alternatives considered:** - - [Alternative 1]: [Why not chosen] - - [Alternative 2]: [Why not chosen] - - **Potential risks:** - - [Risk 1]: [Mitigation strategy] - - [Risk 2]: [Mitigation strategy] - - **Breaking changes:** - [Any breaking changes or migration needs] - - ## Related Discussions - - [If any related discussions were found, list them here] - - Closes #[discussion number] - [discussion title] - - Related to #[discussion number] - [discussion title] - ``` + After drafting: + + + [x] Analyze user request to determine issue type + [x] Gather initial information for the issue + [x] Determine if user wants to contribute + [x] Perform technical analysis (if contributing) + [x] Draft issue content + [-] Review and confirm with user + [ ] Create GitHub issue + + - + Review and Confirm with User Present the complete drafted issue to the user for review: @@ -302,29 +322,63 @@ If user requests changes, make them and show the updated version for confirmation. + + After confirmation: + + + [x] Analyze user request to determine issue type + [x] Gather initial information for the issue + [x] Determine if user wants to contribute + [x] Perform technical analysis (if contributing) + [x] Draft issue content + [x] Review and confirm with user + [-] Create GitHub issue + + - + Create GitHub Issue - Once user confirms, create the issue using the GitHub MCP tool: + Once user confirms, create the issue using the GitHub CLI: - - github - create_issue - - { - "owner": "RooCodeInc", - "repo": "Roo-Code", - "title": "[Create a descriptive title based on the issue content]", - "body": "[The complete formatted issue body from step 6]", - "labels": [Use ["bug"] for bug reports or ["proposal", "enhancement"] for features] - } - - + First, save the issue body to a temporary file: + + cat > /tmp/issue_body.md << 'EOF' +[The complete formatted issue body from step 5] +EOF + - After creation, inform the user of the issue number and URL. + Then create the issue: + + gh issue create --repo RooCodeInc/Roo-Code --title "[Create a descriptive title based on the issue content]" --body-file /tmp/issue_body.md --label "bug" + + + For feature requests, use labels "proposal,enhancement": + + gh issue create --repo RooCodeInc/Roo-Code --title "[Create a descriptive title based on the issue content]" --body-file /tmp/issue_body.md --label "proposal" --label "enhancement" + + + The command will return the issue URL. Inform the user of the created issue number and URL. + + Clean up the temporary file: + + rm /tmp/issue_body.md + + + Complete the workflow: + + + [x] Analyze user request to determine issue type + [x] Gather initial information for the issue + [x] Determine if user wants to contribute + [x] Perform technical analysis (if contributing) + [x] Draft issue content + [x] Review and confirm with user + [x] Create GitHub issue + + \ No newline at end of file diff --git a/.roo/rules-issue-writer/5_github_cli_usage.xml b/.roo/rules-issue-writer/5_github_cli_usage.xml new file mode 100644 index 0000000000..8beb024d15 --- /dev/null +++ b/.roo/rules-issue-writer/5_github_cli_usage.xml @@ -0,0 +1,273 @@ + + + The GitHub CLI (gh) provides comprehensive tools for interacting with GitHub. + Here's when and how to use each command in the issue creation workflow. + + Note: Issue body formatting should follow the templates defined in + 2_github_issue_templates.xml, with different formats for problem reporters + vs contributors. + + + + + + ALWAYS use this FIRST before creating any issue to check for duplicates. + Search for keywords from the user's problem description. + + + + gh issue list --repo RooCodeInc/Roo-Code --search "dark theme button visibility" --state all --limit 20 + + + + --search: Search query for issue titles and bodies + --state: all, open, or closed + --label: Filter by specific labels + --limit: Number of results to show + --json: Get structured JSON output + + + + + + Use for more advanced searches across issues and pull requests. + Supports GitHub's advanced search syntax. + + + + gh search issues --repo RooCodeInc/Roo-Code "dark theme button" --limit 10 + + + + + + + Use when you find a potentially related issue and need full details. + Check if the user's issue is already reported or related. + + + + gh issue view 123 --repo RooCodeInc/Roo-Code --comments + + + + --comments: Include issue comments + --json: Get structured data + --web: Open in browser + + + + + + + These commands should ONLY be used if the user has indicated they want to + contribute the implementation. Skip these for problem reporters. + + + + + Get repository information and recent activity. + + + + gh repo view RooCodeInc/Roo-Code --json defaultBranchRef,description,updatedAt + + + + + + + Check recent PRs that might be related to the issue. + Look for PRs that modified relevant code. + + + + gh search prs --repo RooCodeInc/Roo-Code "dark theme" --limit 10 --state all + + + + + + + For bug reports from contributors, check recent commits that might have introduced the issue. + Use after cloning the repository locally. + + + + git log --oneline --grep="theme" -n 20 + + + + + + + + + Only use after: + 1. Confirming no duplicates exist + 2. Gathering all required information + 3. Determining if user is contributing or just reporting + 4. Getting user confirmation + + + + gh issue create --repo RooCodeInc/Roo-Code --title "[Descriptive title of the bug]" --body-file /tmp/issue_body.md --label "bug" + + + + + gh issue create --repo RooCodeInc/Roo-Code --title "[Problem-focused title]" --body-file /tmp/issue_body.md --label "proposal" --label "enhancement" + + + + --title: Issue title (required) + --body: Issue body text + --body-file: Read body from file + --label: Add labels (can use multiple times) + --assignee: Assign to user + --project: Add to project + --web: Open in browser to create + + + + + + + + ONLY use if user wants to add additional information after creation. + + + + gh issue comment 456 --repo RooCodeInc/Roo-Code --body "Additional context or comments." + + + + + + + Use if user realizes they need to update the issue after creation. + Can update title, body, or labels. + + + + gh issue edit 456 --repo RooCodeInc/Roo-Code --title "[Updated title]" --body "[Updated body]" + + + + + + + + After user selects issue type, immediately search for related issues: + 1. Use `gh issue list --search` with keywords from their description + 2. Show any similar issues found + 3. Ask if they want to continue or comment on existing issue + + + + When searching GitHub Discussions: + 1. Note that GitHub CLI doesn't currently have full discussions support + 2. Use web search or instruct user to manually search discussions at: + https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests + 3. Ask user to provide any related discussion numbers they find + 4. Include these in the "Related Discussions" section of the issue + + + + Decision point for contribution: + 1. Ask user if they want to contribute implementation + 2. If yes: Use contributor commands for codebase investigation + 3. If no: Skip directly to creating a problem-focused issue + 4. This saves time for problem reporters + + + + During codebase exploration (CONTRIBUTORS ONLY): + 1. Clone repo locally if needed: `gh repo clone RooCodeInc/Roo-Code` + 2. Use `git log` to find recent changes to affected files + 3. Use `gh search prs` for related pull requests + 4. Include findings in the technical context section + + + + When creating the issue: + 1. Format differently based on contributor vs problem reporter + 2. Problem reporters: Simple problem description + context + 3. Contributors: Full template with technical sections + 4. Save formatted body to temporary file + 5. Use `gh issue create` with appropriate labels + 6. Capture the returned issue URL + 7. Show user the created issue URL + + + + + + When creating issues with long bodies: + 1. Save to temporary file: `cat > /tmp/issue_body.md << 'EOF'` + 2. Use --body-file flag with gh issue create + 3. Clean up after: `rm /tmp/issue_body.md` + + + + Use specific search terms: + - Include error messages in quotes + - Use label filters when appropriate + - Limit results to avoid overwhelming output + + + + Use --json flag for structured data when needed: + - Easier to parse programmatically + - Consistent format across commands + - Example: `gh issue list --json number,title,state` + + + + + + If search finds exact duplicate: + - Show the existing issue to user using `gh issue view` + - Ask if they want to add a comment instead + - Use `gh issue comment` if they agree + + + + If `gh issue create` fails: + - Check error message (auth, permissions, network) + - Ensure gh is authenticated: `gh auth status` + - Save the drafted issue content for user + - Suggest using --web flag to create in browser + + + + Ensure GitHub CLI is authenticated: + - Check status: `gh auth status` + - Login if needed: `gh auth login` + - Select appropriate scopes for issue creation + + + + + + gh issue create - Create new issue + gh issue list - List and search issues + gh issue view - View issue details + gh issue comment - Add comment to issue + gh issue edit - Edit existing issue + gh issue close - Close an issue + gh issue reopen - Reopen closed issue + + + + gh search issues - Search issues and PRs + gh search prs - Search pull requests + gh search repos - Search repositories + + + + gh repo view - View repository info + gh repo clone - Clone repository + + + \ No newline at end of file diff --git a/.roo/rules-issue-writer/5_github_mcp_tool_usage.xml b/.roo/rules-issue-writer/5_github_mcp_tool_usage.xml deleted file mode 100644 index b5ae5d8aec..0000000000 --- a/.roo/rules-issue-writer/5_github_mcp_tool_usage.xml +++ /dev/null @@ -1,352 +0,0 @@ - - - The GitHub MCP server provides multiple tools for interacting with GitHub. - Here's when and how to use each tool in the issue creation workflow. - - Note: Issue body formatting should follow the templates defined in - 2_github_issue_templates.xml, with different formats for problem reporters - vs contributors. - - - - - - ALWAYS use this FIRST before creating any issue to check for duplicates. - Search for keywords from the user's problem description. - - - - github - search_issues - - { - "q": "repo:RooCodeInc/Roo-Code dark theme button visibility", - "sort": "updated", - "order": "desc" - } - - - - - - - - Use to browse recent issues if search doesn't find specific matches. - Helpful for understanding issue patterns and formatting. - - - - github - list_issues - - { - "owner": "RooCodeInc", - "repo": "Roo-Code", - "state": "all", - "labels": ["bug"], - "sort": "created", - "direction": "desc", - "perPage": 10 - } - - - - - - - - Use when you find a potentially related issue and need full details. - Check if the user's issue is already reported or related. - - - - github - get_issue - - { - "owner": "RooCodeInc", - "repo": "Roo-Code", - "issue_number": 123 - } - - - - - - - - Use on related issues to understand discussion context. - Helps avoid creating issues for already-discussed topics. - - - - github - get_issue_comments - - { - "owner": "RooCodeInc", - "repo": "Roo-Code", - "issue_number": 123 - } - - - - - - - - - These tools should ONLY be used if the user has indicated they want to - contribute the implementation. Skip these for problem reporters. - - - - - For bug reports from contributors, check recent commits that might have introduced the issue. - Look for commits touching the affected files. - - - - github - list_commits - - { - "owner": "RooCodeInc", - "repo": "Roo-Code", - "perPage": 20 - } - - - - - - - - When you identify a potentially problematic commit. - Get details about what changed. - - - - github - get_commit - - { - "owner": "RooCodeInc", - "repo": "Roo-Code", - "sha": "abc123def456" - } - - - - - - - - Use to find code patterns across the repository on GitHub. - Complements local codebase_search tool for contributors. - - - - github - search_code - - { - "q": "repo:RooCodeInc/Roo-Code language:typescript dark theme button" - } - - - - - - - - Check recent PRs that might be related to the issue. - Look for PRs that modified relevant code. - - - - github - list_pull_requests - - { - "owner": "RooCodeInc", - "repo": "Roo-Code", - "state": "all", - "sort": "updated", - "direction": "desc", - "perPage": 10 - } - - - - - - - - - - Only use after: - 1. Confirming no duplicates exist - 2. Gathering all required information - 3. Determining if user is contributing or just reporting - 4. Getting user confirmation - - - - github - create_issue - - { - "owner": "RooCodeInc", - "repo": "Roo-Code", - "title": "[Descriptive title of the bug]", - "body": "[Format according to bug report template]", - "labels": ["bug"] - } - - - - - - github - create_issue - - { - "owner": "RooCodeInc", - "repo": "Roo-Code", - "title": "[Problem-focused title]", - "body": "[Problem description only - no technical details]", - "labels": ["proposal", "enhancement"] - } - - - - - - github - create_issue - - { - "owner": "RooCodeInc", - "repo": "Roo-Code", - "title": "[Problem-focused title with implementation intent]", - "body": "[Full template including technical analysis sections]", - "labels": ["proposal", "enhancement"] - } - - - - - - - - - - ONLY use if user wants to add additional information after creation. - - - - github - add_issue_comment - - { - "owner": "RooCodeInc", - "repo": "Roo-Code", - "issue_number": 456, - "body": "Additional context or comments." - } - - - - - - - - Use if user realizes they need to update the issue after creation. - Can update title, body, or state. - - - - github - update_issue - - { - "owner": "RooCodeInc", - "repo": "Roo-Code", - "issue_number": 456, - "title": "[Updated title if needed]", - "body": "[Updated body if needed]" - } - - - - - - - - - After user selects issue type, immediately search for related issues: - 1. Use search_issues with keywords from their description - 2. Show any similar issues found - 3. Ask if they want to continue or comment on existing issue - - - - When searching GitHub Discussions: - 1. Note that GitHub MCP tools don't currently support discussions API - 2. Instruct user to manually search discussions at: - https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests - 3. Ask user to provide any related discussion numbers they find - 4. Include these in the "Related Discussions" section of the issue - - - - Decision point for contribution: - 1. Ask user if they want to contribute implementation - 2. If yes: Use contributor tools for codebase investigation - 3. If no: Skip directly to creating a problem-focused issue - 4. This saves time for problem reporters - - - - During codebase exploration (CONTRIBUTORS ONLY): - 1. Use list_commits to find recent changes to affected files - 2. Use search_code for additional code references - 3. Check list_pull_requests for related PRs - 4. Include findings in the technical context section - - - - When creating the issue: - 1. Format differently based on contributor vs problem reporter - 2. Problem reporters: Simple problem description + context - 3. Contributors: Full template with technical sections - 4. Use create_issue with appropriate body format - 5. Capture the returned issue number - 6. Show user the created issue URL - - - - - - If search_issues finds exact duplicate: - - Show the existing issue to user - - Ask if they want to add a comment instead - - Use add_issue_comment if they agree - - - - If create_issue fails: - - Check error message (permissions, rate limit, etc.) - - Save the drafted issue content - - Provide user with the content to create manually - - - - Be aware of GitHub API rate limits: - - Authenticated requests: 5000/hour - - Search API: 30 requests/minute - - Use searches efficiently - - - \ No newline at end of file diff --git a/.roo/rules-issue-writer/6_technical_analysis_workflow.xml b/.roo/rules-issue-writer/6_technical_analysis_workflow.xml new file mode 100644 index 0000000000..c61d8fc1ca --- /dev/null +++ b/.roo/rules-issue-writer/6_technical_analysis_workflow.xml @@ -0,0 +1,349 @@ + + + This sub-workflow provides an aggressive, thorough, and all-encompassing investigation + process for technical analysis when creating GitHub issues. It employs methods from + the issue-investigator mode to deeply analyze the codebase and formulate comprehensive + technical solutions. This workflow is designed to produce scoped issues that can be + used in automated fix workflows. + + + + + Create Investigation Plan + + When technical analysis is requested, immediately create a comprehensive todo list + to track the investigation progress. + + + +[ ] Extract keywords from the issue description +[ ] Perform initial broad codebase search +[ ] Analyze search results and identify key components +[ ] Deep dive into relevant files and implementations +[ ] Form initial hypothesis about the issue/feature +[ ] Attempt to disprove hypothesis through further investigation +[ ] Identify all affected files and dependencies +[ ] Map out the complete implementation approach +[ ] Document technical risks and edge cases +[ ] Formulate comprehensive technical solution +[ ] Create detailed acceptance criteria +[ ] Prepare technical analysis summary + + + ]]> + + + + + + + Extract all relevant keywords, concepts, and technical terms from the issue description. + Be exhaustive - include function names, error messages, feature names, and related concepts. + + + Identify primary technical concepts + Extract error messages or specific symptoms + Note any mentioned file paths or components + List related features or functionality + Include synonyms and related terms + + Mark "Extract keywords from the issue description" as complete + + + + + Perform multiple rounds of codebase searches, starting broad and progressively + narrowing based on findings. This is an aggressive, exhaustive search process. + + + Initial Broad Search + + Use codebase_search with all extracted keywords to get an overview of relevant code. + +[Combined keywords from extraction phase] + + ]]> + + + + + Component Discovery + + Based on initial results, identify key components and search for: + - Related class/function definitions + - Import statements and dependencies + - Configuration files + - Test files that might reveal expected behavior + + + + + Deep Implementation Search + + Search for specific implementation details: + - Error handling patterns + - State management + - API endpoints or routes + - Database queries or models + - UI components and their interactions + + + + + Edge Case and Integration Search + + Look for: + - Edge cases in the code + - Integration points with other systems + - Configuration options that affect behavior + - Feature flags or conditional logic + + + + Update search-related todos as each iteration completes + + + + + Thoroughly analyze all relevant files discovered during the search phase. + + + Use list_code_definition_names to understand file structure + Read complete files to understand full context + Trace execution paths through the code + Identify all dependencies and imports + Map relationships between components + + + Document findings including: + - File paths and their purposes + - Key functions and their responsibilities + - Data flow through the system + - External dependencies + - Potential impact areas + + Mark file analysis todos as complete + + + + + Form a comprehensive hypothesis about the issue or feature implementation. + + + + Identify the most likely root cause + Trace the bug through the execution path + Determine why the current implementation fails + Consider environmental factors + + + + + Identify the optimal integration points + Determine required architectural changes + Plan the implementation approach + Consider scalability and maintainability + + + Mark hypothesis formation as complete + + + + + Aggressively attempt to disprove the hypothesis by searching for contradictory evidence. + + + + Search for Alternative Implementations + Look for similar features implemented differently + Check for deprecated code that might interfere + + + Configuration and Environment Check + Search for configuration that could change behavior + Look for environment-specific code paths + + + Test Case Analysis + Find existing tests that might contradict hypothesis + Look for test cases that reveal edge cases + + + Historical Context + Search for comments explaining design decisions + Look for TODO or FIXME comments related to the area + + + + If hypothesis is disproven, return to search phase with new insights. + If hypothesis stands, proceed to solution formulation. + + Update hypothesis validation status + + + + + Create a comprehensive technical solution with extreme detail. + + + +
+ - Exact files to modify with line numbers + - New files to create with full paths + - Specific code changes required + - Order of implementation steps + - Migration strategy if needed +
+ + + +
+ - All files that import affected code + - API contracts that must be maintained + - Database schema changes if any + - Configuration changes required + - Documentation updates needed +
+ + + +
+ - Unit tests to add or modify + - Integration tests required + - Edge cases to test + - Performance testing needs + - Manual testing scenarios +
+ + + +
+ - Breaking changes identified + - Performance implications + - Security considerations + - Backward compatibility issues + - Rollback strategy +
+ + + Mark solution formulation as complete + + + + + Create extremely detailed acceptance criteria that can guide automated implementation. + + + + Each criterion must be independently testable + Include both positive and negative test cases + Specify exact error messages and codes + Define performance thresholds where applicable + + Mark acceptance criteria creation as complete + + + + + + + + + + All keywords extracted and searched + Multiple search iterations completed + All relevant files analyzed + Hypothesis formed and validated + Comprehensive solution documented + Acceptance criteria defined + All risks and edge cases identified + Technical analysis formatted for issue + + + Mark all investigation todos as complete and update the main workflow todo list + + + \ No newline at end of file diff --git a/.roo/rules-pr-fixer-orchestrator/1_Workflow.xml b/.roo/rules-pr-fixer-orchestrator/1_Workflow.xml deleted file mode 100644 index a376596c1d..0000000000 --- a/.roo/rules-pr-fixer-orchestrator/1_Workflow.xml +++ /dev/null @@ -1,771 +0,0 @@ - - - Initialize PR Context - - 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. - - mkdir -p .roo/temp/pr-fixer-orchestrator/[TASK_ID] - - 3. **Retrieve PR Details**: Fetch the PR details, comments, and check status as a comprehensive JSON object. - - 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 - - 4. **Get Review Comments**: Fetch detailed review comments separately for better analysis. - - gh pr view [pr_number] --repo [owner]/[repo] --comments > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_comments.txt - - 5. **Check CI Status**: Get current check status and any failing workflows. - - gh pr checks [pr_number] --repo [owner]/[repo] --json name,state,conclusion,detailsUrl > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_checks.json - - 6. **Get Associated Issue**: Check if PR is linked to an issue and fetch issue details if available. - - gh pr view [pr_number] --repo [owner]/[repo] --json closingIssuesReferences > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/linked_issues.json - - If linked issues exist, fetch the first issue's details: - - 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 - - 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. - - - - - Checkout PR Branch and Initial Analysis - - Before delegating analysis, ensure the PR branch is checked out locally. - - 1. **Checkout PR Branch**: Use gh to checkout the PR branch locally. - - gh pr checkout [pr_number] --repo [owner]/[repo] --force - - - 2. **Determine Remote Type**: Check if this is a cross-repository PR (from a fork). - - gh pr view [pr_number] --repo [owner]/[repo] --json isCrossRepository,headRepositoryOwner,headRefName > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_remote_info.json - - - 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: - - git remote add fork https://github.com/[headRepositoryOwner]/[repo].git || git remote set-url fork https://github.com/[headRepositoryOwner]/[repo].git - - - 4. **Fetch Latest Main**: Ensure we have the latest main branch for comparison. - - git fetch origin main - - - 5. **Check for Conflicts**: Determine if there are merge conflicts with main. - - git merge-tree $(git merge-base HEAD origin/main) HEAD origin/main > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/merge_conflicts.txt - - - 6. **Get PR Diff**: Fetch the files changed in this PR for context. - - gh pr diff [pr_number] --repo [owner]/[repo] --name-only > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_changed_files.txt - - - 7. **Check Merge Diff Size**: Get the full diff and check line count. - - git diff origin/main...HEAD > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/full_merge_diff.txt - - - wc -l .roo/temp/pr-fixer-orchestrator/[TASK_ID]/full_merge_diff.txt - - - If the diff has over 2000 lines, create a summary instead: - - git diff origin/main...HEAD --stat > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/merge_diff_summary.txt - - - rm .roo/temp/pr-fixer-orchestrator/[TASK_ID]/full_merge_diff.txt - - - - - - Delegate: Comprehensive Requirements and PR Analysis - - 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`. - - - architect - - **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" - - - - After launching the subtask, wait for it to complete. The orchestrator will then read the analysis report to proceed. - - - - - Review Analysis and Get User Approval - - After the analysis subtask completes, present the findings to the user for approval. - - 1. **Read the Analysis Report**: - - - - .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_analysis_report.md - - - - - 2. **Present for Approval**: Show the analysis to the user and ask how to proceed. - - - 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? - - - Fix all issues in the recommended priority order - Only fix the review comments, skip failing tests for now - Only fix failing tests and conflicts, skip review comments - Let me choose specific issues to fix - - - - 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` - - - - - Fetch Latest from Main and Check Differences - - Before implementing fixes, ensure we're working with the latest code and understand what has changed. - - 1. **Fetch Latest Changes**: - - git fetch origin main - - - 2. **Analyze Differences**: Create a detailed diff report. - - git diff origin/main...HEAD --name-status > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_file_changes.txt - - - 3. **Check Commit History**: Understand what commits are in this PR. - - git log origin/main..HEAD --oneline > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_commits.txt - - - 4. **Identify New Commits on Main**: See what has been merged to main since the PR was created. - - git log HEAD..origin/main --oneline > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/new_main_commits.txt - - - 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" - - - - - Delegate: Implement Fixes - - Launch a subtask in `code` mode to implement all the fixes based on the analysis and user's choices. - - - code - - **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": - - GIT_EDITOR=true git rebase origin/main - - - 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" - - - - Wait for the implementation subtask to complete before proceeding. - - - - - Delegate: Test and Validate Changes - - After implementation, delegate testing and validation to ensure all fixes work correctly. - - - test - - **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" - - - - Wait for validation to complete before proceeding. - - - - - Handle Validation Results and Translation Needs - - Review validation results and check if translation updates are needed. - - 1. **Read Validation Report**: - - - - .roo/temp/pr-fixer-orchestrator/[TASK_ID]/validation_report.md - - - - - 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: - - translate - - **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]/ - - - - 5. **Proceed When Ready**: Only continue after validation passes and translations complete (if needed). - - - - - Prepare PR Message and Get User Approval - - Before committing changes, prepare the PR update message and get user approval. - - 1. **Check Files to be Committed**: List all modified files. - - git status --porcelain > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/files_to_commit.txt - - - 2. **Read Implementation Summary**: - - - - .roo/temp/pr-fixer-orchestrator/[TASK_ID]/changes_implemented.md - - - - - 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. - - - 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? - - - Looks good, go ahead and commit the changes - I tested the changes and something is wrong - let me describe the issue - I still need to test the changes manually before committing - Let me review specific files before committing - - - - 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 - - - - - Commit Changes and Prepare for Push - - 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. - - git add [specific files from the implementation] - - - 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. - - 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" - - - 3. **Verify Remote Configuration**: Check which remote to push to. - - - - .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_remote_info.json - - - - - 4. **Determine Push Target**: - - If isCrossRepository is false: push to origin - - If isCrossRepository is true: push to fork - - - - - Delegate: Final PR Review - - Before pushing changes, have the PR reviewer mode review all changes to ensure quality. - - - pr-reviewer - - **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" - - - - Wait for the review to complete. - - - - - Process Final Review and Push Changes - - Based on the final review, either push changes or address remaining issues. - - 1. **Read Final Review**: - - - - .roo/temp/pr-fixer-orchestrator/[TASK_ID]/final_review.md - - - - - 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: - - git push --force-with-lease origin [branch_name] - - - For cross-repository PRs: - - git push --force-with-lease fork [branch_name] - - - 4. **Monitor Push Result**: Ensure the push succeeds. - If --force-with-lease fails, fetch and retry with --force. - - - - - Verify PR Status and Monitor Checks - - After pushing, verify the PR is in good state and monitor CI/CD checks. - - 1. **Verify PR is Up to Date**: - - gh pr view [pr_number] --repo [owner]/[repo] --json mergeable,mergeStateStatus - - - 2. **Monitor CI/CD Checks in Real-Time**: - - gh pr checks [pr_number] --repo [owner]/[repo] --watch - - This will continuously monitor until all checks complete. - - 3. **Get Final Status**: Once monitoring completes, get the final state. - - gh pr checks [pr_number] --repo [owner]/[repo] --json name,state,conclusion > .roo/temp/pr-fixer-orchestrator/[TASK_ID]/final_checks.json - - - 4. **Comment on PR**: Add a summary comment about the fixes applied. - Read the PR update message we prepared: - - - - .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_update_message.md - - - - - Then post it as a comment: - - gh pr comment [pr_number] --repo [owner]/[repo] --body-file .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_update_message.md - - - 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. - - - 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? - - - Yes, clean up temporary files - No, keep the files for reference - - - - If user chooses cleanup: - - rm -rf .roo/temp/pr-fixer-orchestrator/[TASK_ID] - - - - \ No newline at end of file diff --git a/.roo/rules-pr-fixer-orchestrator/2_best_practices.xml b/.roo/rules-pr-fixer-orchestrator/2_best_practices.xml deleted file mode 100644 index 82f1ba66aa..0000000000 --- a/.roo/rules-pr-fixer-orchestrator/2_best_practices.xml +++ /dev/null @@ -1,186 +0,0 @@ - - - - Always Delegate Specialized Work - The orchestrator coordinates but doesn't implement. Use specialized modes for analysis, coding, testing, and review. - Each mode has specific expertise and permissions optimized for their tasks. - - - - Maintain Context Between Steps - 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. - Subtasks run in isolation and need explicit context sharing. Files saved elsewhere will be inaccessible to subsequent steps. - - - - Get User Approval Before Committing - ALWAYS present changes and get explicit user approval before committing. Show modified files, summarize changes, and ask for confirmation. - Users must maintain control over what gets committed to their PR. Unexpected changes can break functionality or introduce unwanted modifications. - - - - Understand Requirements First - Always analyze the PR's underlying purpose and requirements before fixing issues. - Fixing review comments without understanding the feature can lead to incomplete or incorrect solutions. - - - - Handle Large Diffs Gracefully - Check diff size before processing. If over 2000 lines, create a summary instead of including the full diff. - Large diffs can overwhelm context windows and make analysis difficult. Summaries maintain clarity. - - - - - - 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 - - - - - Non-Interactive Rebasing - Always use GIT_EDITOR=true for automated rebase operations - GIT_EDITOR=true git rebase origin/main - - - - Fork-Aware Pushing - Always check isCrossRepository before pushing - - - Check if PR is from fork using gh pr view --json isCrossRepository - - Add fork remote if needed - - Push to correct remote (origin vs fork) - - - - - Force with Lease - Use --force-with-lease for safer force pushing - If it fails, fetch and use --force - - - - Selective File Staging - Always stage files individually, never use git add -A - - - 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 - - Prevents accidentally committing temporary files, debug logs, or unintended changes - - - - Large Diff Handling - Check diff size before including in context files - - - 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 - - - - - - - architect - Comprehensive analysis and planning - Detailed reports and implementation plans - MUST save all outputs to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/ - - - - code - Executing code changes and fixes - Implemented solutions and change summaries - MUST save changes_implemented.md to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/ - - - - test - Testing and validating changes - Test results and validation reports - MUST save validation_report.md to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/ - - - - pr-reviewer - Final quality review before submission - Quality assessment and recommendations - MUST save final_review.md to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/ - - - - translate - Updating translations for UI changes - Synchronized translations across languages - MUST save translation_summary.md to .roo/temp/pr-fixer-orchestrator/[TASK_ID]/ - - - - - - GitHub CLI authentication error - Prompt user to run 'gh auth login' - - - - No linked issue found - Extract requirements from PR description and comments - - - - Force-with-lease push fails - Fetch latest and retry with --force - - - - Diff exceeds 2000 lines - Create summary with stats instead of full diff - - - - Expected context files not found in temp directory - Check if delegated task saved to correct location, re-run if needed - - - - - - Pre-Commit Approval - Always get explicit user approval before committing changes - - - Show list of modified files - - Summarize key changes made - - Present clear approval options - - Wait for user confirmation - - - - - Clear Communication - Present information clearly and concisely - - - Use bullet points for lists - - Highlight important warnings - - Provide actionable suggestions - - Avoid technical jargon when possible - - - - \ No newline at end of file diff --git a/.roo/rules-pr-fixer-orchestrator/3_github_cli_usage.xml b/.roo/rules-pr-fixer-orchestrator/3_github_cli_usage.xml deleted file mode 100644 index 94c63b6f3a..0000000000 --- a/.roo/rules-pr-fixer-orchestrator/3_github_cli_usage.xml +++ /dev/null @@ -1,68 +0,0 @@ - - - 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. - - - - - Get comprehensive PR details - gh pr view [pr-number] --repo [owner]/[repo] --json [fields] - number,title,body,state,labels,author,headRefName,baseRefName,mergeable,mergeStateStatus,isDraft,isCrossRepository,headRepositoryOwner,reviews,statusCheckRollup,comments - - - - Checkout PR branch locally - gh pr checkout [pr-number] --repo [owner]/[repo] --force - Automatically handles fork setup - - - - Monitor CI/CD status - gh pr checks [pr-number] --repo [owner]/[repo] --watch - Use --json for programmatic access - - - - Get PR changes - gh pr diff [pr-number] --repo [owner]/[repo] --name-only - Use without --name-only for full diff - - - - Add comment to PR - gh pr comment [pr-number] --repo [owner]/[repo] --body "[message]" - - - - - - Get issues linked to PR - gh pr view [pr-number] --repo [owner]/[repo] --json closingIssuesReferences - Returns array of linked issues - - - - Get issue details if linked - gh issue view [issue-number] --repo [owner]/[repo] --json [fields] - number,title,body,state,labels,assignees,milestone,createdAt,updatedAt,closedAt,author,comments - - - - - - Get detailed CI logs - gh run view [run-id] --repo [owner]/[repo] --log-failed - Use to debug failing tests - - - - Direct API access for advanced operations - - - Get PR reviews: gh api repos/[owner]/[repo]/pulls/[pr-number]/reviews - - Get review comments: gh api repos/[owner]/[repo]/pulls/[pr-number]/comments - - - - \ No newline at end of file diff --git a/.roo/rules-pr-fixer-orchestrator/4_requirements_analysis.xml b/.roo/rules-pr-fixer-orchestrator/4_requirements_analysis.xml deleted file mode 100644 index 5d5d5dbeb6..0000000000 --- a/.roo/rules-pr-fixer-orchestrator/4_requirements_analysis.xml +++ /dev/null @@ -1,120 +0,0 @@ - - - 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. - - - - - Linked GitHub Issues - Primary source of requirements and acceptance criteria - - - Issue title and body - - Acceptance criteria sections - - Technical specifications - - User stories or use cases - - - - - PR Description - Often contains implementation notes and context - - - Feature description - - Implementation approach - - Testing notes - - Breaking changes - - - - - PR Comments - May contain clarifications and additional requirements - - - Author clarifications - - Reviewer questions and answers - - Scope changes or additions - - - - - Code Analysis - Infer requirements from the implementation - - - API contracts - - Data flow patterns - - Test cases (reveal expected behavior) - - Documentation comments - - - - - - - Extract Explicit Requirements - - - Parse linked issues for acceptance criteria - - Extract requirements from PR description - - Identify success metrics - - - - - Understand Implementation Intent - - - Analyze the code changes to understand approach - - Identify design decisions made - - Note any architectural patterns used - - - - - Map Requirements to Implementation - - - Verify each requirement has corresponding code - - Identify any missing functionality - - Note any extra functionality added - - - - - Identify Gaps - - - List unimplemented requirements - - Note incomplete features - - Identify missing tests - - - - - - - - - Clear description of the bug - - Steps to reproduce - - Expected vs actual behavior - - Affected versions/environments - - - - - - - Feature description - - User stories or use cases - - API design (if applicable) - - UI/UX specifications - - Performance requirements - - - - - - - Motivation for refactoring - - Backward compatibility needs - - Performance improvements expected - - Migration path (if breaking) - - - - \ No newline at end of file diff --git a/.roo/rules-pr-fixer-orchestrator/5_self_contained_workflow.xml b/.roo/rules-pr-fixer-orchestrator/5_self_contained_workflow.xml deleted file mode 100644 index 62be497ea4..0000000000 --- a/.roo/rules-pr-fixer-orchestrator/5_self_contained_workflow.xml +++ /dev/null @@ -1,99 +0,0 @@ - - - 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. - - - - - No External Dependencies - Never assume files from other workflows exist - - - Create own temp directory structure - - Gather all needed context independently - - Generate own analysis and plans - - - - - Complete Context Gathering - Collect all information needed for the task - - - Fetch PR details and metadata - - Get linked issues if they exist - - Analyze codebase independently - - Understand requirements from available sources - - - - - Flexible Requirements Analysis - Work with whatever information is available - - - Use linked issues when available - - Fall back to PR description - - Infer from code changes if needed - - Ask user for clarification when necessary - - - - - - Create dedicated task directory - Fetch all PR-related information - Check for linked issues and fetch if present - Analyze PR changes to understand scope - Build complete context from available sources - - - - - PR that references a GitHub issue - - - Fetch issue details for requirements - - Use issue acceptance criteria - - Cross-reference PR implementation with issue requirements - - - - - PR without linked issue - - - Extract requirements from PR description - - Analyze code to understand intent - - Use PR comments for additional context - - Infer acceptance criteria from tests - - - - - PR from a forked repository - - - Handle remote configuration properly - - Ensure push targets correct repository - - Manage permissions appropriately - - - - - - - No clear requirements found - - - Analyze code changes to infer purpose - - Look at test changes for expected behavior - - Ask user for clarification if needed - - - - - PR scope is ambiguous - - - Present findings to user - - Ask for specific guidance on what to fix - - Proceed with user-defined scope - - - - \ No newline at end of file diff --git a/.roo/rules-pr-fixer-orchestrator/6_pr_template_format.xml b/.roo/rules-pr-fixer-orchestrator/6_pr_template_format.xml deleted file mode 100644 index 26129553c3..0000000000 --- a/.roo/rules-pr-fixer-orchestrator/6_pr_template_format.xml +++ /dev/null @@ -1,361 +0,0 @@ - - - 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. - - - - - - - The GitHub issue number this PR closes - From linked_issues.json or pr_context.json - - - - Optional Roo Code task links if used - _No Roo Code task context for this PR._ - - - - Summary of changes and implementation details - - 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] - - - - - How the changes were tested - - **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] - - - - - Visual evidence of UI changes - _No UI changes in this PR._ - - - - Documentation impact assessment - - - - - - - - Any additional context for reviewers - - [Any special considerations, known issues, or questions for reviewers] - - **Files Modified:** - ``` - [List of modified files from changes_implemented.md] - ``` - - - - - Contact information - Discord: @[username] - - - - - - The template MUST be followed exactly - do not modify the structure or remove any sections - - - All placeholders must be replaced with actual content - no brackets should remain - - - The Pre-Submission Checklist items should all be marked as checked [x] since we're fixing an existing PR - - - 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 - - - Keep the HTML comments intact - they provide guidance for reviewers - - - - - .roo/temp/pr-fixer-orchestrator/[TASK_ID]/pr_update_message.md - - - 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 - - - Post to PR using: gh pr comment [pr_number] --repo [owner]/[repo] --body-file [path_to_file] - - - - - - -### Related GitHub Issue - - - -Closes: #456 - -### Roo Code Task Context (Optional) - - - -_No Roo Code task context for this PR._ - -### Description - - - -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 - - - -**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 - - - -- [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 - - - -_No UI changes in this PR._ - -### Documentation Updates - - - -- [x] No documentation updates are required. - -### Additional Notes - - - -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 - - - -Discord: @contributor123 - ]]> - - \ No newline at end of file diff --git a/.roo/rules-pr-fixer/1_workflow.xml b/.roo/rules-pr-fixer/1_workflow.xml index 4b43e99217..db74ead7ee 100644 --- a/.roo/rules-pr-fixer/1_workflow.xml +++ b/.roo/rules-pr-fixer/1_workflow.xml @@ -1,6 +1,6 @@ - This mode is designed to help resolve issues in existing pull requests. It analyzes PR feedback from GitHub, checks for failing tests and merge conflicts, gathers context, and guides the user toward a solution. + This mode is designed to help resolve issues in existing pull requests. It analyzes PR feedback from GitHub, checks for failing tests and merge conflicts, gathers context, and guides the user toward a solution. All GitHub operations are performed using the GitHub CLI. @@ -13,9 +13,9 @@ Gather PR context - use_mcp_tool (github): get_pull_request, get_pull_request_comments - gh cli: Check workflow status and logs for failing tests. - gh cli: Check for merge conflicts. + gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles,comments,reviews + gh pr checks [PR_NUMBER] --repo [owner]/[repo] - Check workflow status for failing tests + gh pr view [PR_NUMBER] --repo [owner]/[repo] --json mergeable,mergeStateStatus - Check for merge conflicts @@ -24,9 +24,9 @@ Analyze the gathered information to identify the core problems. - Summarize review comments and requested changes. - Identify the root cause of failing tests by analyzing logs. - Determine if merge conflicts exist. + Summarize review comments and requested changes from gh pr view output. + Identify the root cause of failing tests by analyzing workflow logs with 'gh run view'. + Determine if merge conflicts exist from mergeable status. @@ -41,13 +41,16 @@ Execute the user's chosen course of action. - Check out the PR branch locally using 'gh pr checkout --force'. - Determine if the PR is from a fork by checking 'gh pr view --json isCrossRepository'. + Check out the PR branch locally using 'gh pr checkout [PR_NUMBER] --repo [owner]/[repo] --force'. + Determine if the PR is from a fork by checking 'gh pr view [PR_NUMBER] --repo [owner]/[repo] --json isCrossRepository'. Apply code changes based on review feedback using file editing tools. Fix failing tests by modifying test files or source code as needed. For conflict resolution: Use GIT_EDITOR=true for non-interactive rebases, then resolve conflicts via file editing. If changes affect user-facing content (i18n files, UI components, announcements), delegate translation updates using the new_task tool with translate mode. - Commit changes using git commands. + Review modified files with 'git status --porcelain' to ensure no temporary files are included. + Stage files selectively using 'git add -u' (for modified tracked files) or 'git add ' (for new files). + Verify staged files with 'git diff --cached --name-only' before committing. + Commit changes using git commands with descriptive messages. Push changes to the correct remote (origin for same-repo PRs, fork remote for cross-repo PRs) using 'git push --force-with-lease'. @@ -55,10 +58,10 @@ Verify that the pushed changes resolve the issues. - Use 'gh pr checks --watch' to monitor check status in real-time until all checks complete. - If needed, check specific workflow runs with 'gh run list --pr' for detailed CI/CD pipeline status. + Use 'gh pr checks [PR_NUMBER] --repo [owner]/[repo] --watch' to monitor check status in real-time until all checks complete. + If needed, check specific workflow runs with 'gh run list --pr [PR_NUMBER] --repo [owner]/[repo]' for detailed CI/CD pipeline status. Verify that all translation updates (if any) have been completed and committed. - Confirm PR is ready for review by checking mergeable state with 'gh pr view --json'. + Confirm PR is ready for review by checking mergeable state with 'gh pr view [PR_NUMBER] --repo [owner]/[repo] --json mergeable,mergeStateStatus'. diff --git a/.roo/rules-pr-fixer/2_best_practices.xml b/.roo/rules-pr-fixer/2_best_practices.xml index e9ef4a8b27..50a8395b9c 100644 --- a/.roo/rules-pr-fixer/2_best_practices.xml +++ b/.roo/rules-pr-fixer/2_best_practices.xml @@ -20,6 +20,23 @@ Always push to origin without checking PR source + + Safe File Staging + Always review files before staging to avoid committing temporary files, build artifacts, or system files. Use selective git commands that respect .gitignore. + Committing unwanted files can expose sensitive data, clutter the repository, and cause CI/CD failures. + + Staging files for commit + Use 'git add -u' to stage only modified tracked files, or explicitly list files to add + Use 'git add .' which stages everything including temp files + + + Review git status before staging + Check for temporary files (.swp, .DS_Store, *.tmp) + Exclude build artifacts (dist/, build/, *.pyc) + Avoid IDE-specific files (.idea/, .vscode/) + Verify .gitignore is properly configured + + diff --git a/.roo/rules-pr-fixer/3_common_patterns.xml b/.roo/rules-pr-fixer/3_common_patterns.xml index 5d2c7f033f..1c6c0bcf65 100644 --- a/.roo/rules-pr-fixer/3_common_patterns.xml +++ b/.roo/rules-pr-fixer/3_common_patterns.xml @@ -101,10 +101,42 @@ - Commit operations that work in automated environments. + Commit operations that work in automated environments while respecting .gitignore. + + Safely stage files for commit while avoiding temporary files and respecting .gitignore. + + diff --git a/.roo/rules-pr-fixer/4_tool_usage.xml b/.roo/rules-pr-fixer/4_tool_usage.xml index 15833f3dd7..90d20a0382 100644 --- a/.roo/rules-pr-fixer/4_tool_usage.xml +++ b/.roo/rules-pr-fixer/4_tool_usage.xml @@ -1,7 +1,7 @@ - use_mcp_tool (server: github) + gh pr view Use at the start to get all review comments and PR metadata. Provides the core context of what needs to be fixed from a human perspective. @@ -23,14 +23,16 @@ - + - Always fetch details to get the branch name, owner, repo slug, and mergeable state. + Always fetch details with --json to get structured data: gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles,comments,reviews,mergeable,mergeStateStatus,isCrossRepository + Parse the JSON output to extract branch name, owner, repo slug, and mergeable state. - + + Use gh pr view --json comments to get all comments in structured format. Parse all comments to create a checklist of required changes. Ignore comments that are not actionable or have been resolved. @@ -40,14 +42,15 @@ Use this command to get the exact error messages from failing tests. Search the log for keywords like 'error', 'failed', or 'exception' to quickly find the root cause. - Always specify run ID explicitly to avoid interactive selection prompts. + Always specify run ID explicitly to avoid interactive selection prompts: gh run view [RUN_ID] --log-failed + Get run IDs with: gh run list --pr [PR_NUMBER] --repo [owner]/[repo] - Use --force flag: 'gh pr checkout --force' - If gh checkout fails, use: git fetch origin pull//head: + Use --force flag: 'gh pr checkout [PR_NUMBER] --repo [owner]/[repo] --force' + If gh checkout fails, use: git fetch origin pull/[PR_NUMBER]/head:[branch_name] @@ -58,9 +61,9 @@ Always determine the correct remote before pushing (origin vs fork). - Check if PR is from a fork: 'gh pr view --json isCrossRepository' + Check if PR is from a fork: 'gh pr view [PR_NUMBER] --repo [owner]/[repo] --json isCrossRepository' If isCrossRepository is true, add fork remote if needed - Push to appropriate remote: 'git push --force-with-lease ' + Push to appropriate remote: 'git push --force-with-lease [remote] [branch]' Use 'GIT_EDITOR=true git rebase main' to start rebase @@ -71,10 +74,10 @@ - Use --watch flag to monitor checks in real-time: 'gh pr checks --watch' - For one-time status checks, use --json flag: 'gh pr checks --json state,conclusion,name' + Use --watch flag to monitor checks in real-time: 'gh pr checks [PR_NUMBER] --repo [owner]/[repo] --watch' + For one-time status checks, use --json flag: 'gh pr checks [PR_NUMBER] --repo [owner]/[repo] --json state,conclusion,name' The --watch flag automatically updates the display as check statuses change. - Use 'gh run list --pr ' to get detailed workflow status if needed. + Use 'gh run list --pr [PR_NUMBER] --repo [owner]/[repo]' to get detailed workflow status if needed. @@ -115,4 +118,19 @@ Please ensure all supported languages (ca, de, es, fr, hi, id, it, ja, ko, nl, p ]]> + + + + gh pr view [PR_NUMBER] --repo [owner]/[repo] --json [fields] + gh pr checkout [PR_NUMBER] --repo [owner]/[repo] --force + gh pr checks [PR_NUMBER] --repo [owner]/[repo] [--watch|--json] + gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body "[text]" + + + + gh run list --pr [PR_NUMBER] --repo [owner]/[repo] + gh run view [RUN_ID] --repo [owner]/[repo] --log-failed + gh workflow view [WORKFLOW_NAME] --repo [owner]/[repo] + + \ No newline at end of file diff --git a/.roo/rules-pr-fixer/5_examples.xml b/.roo/rules-pr-fixer/5_examples.xml index 0ff98de250..03fa287c16 100644 --- a/.roo/rules-pr-fixer/5_examples.xml +++ b/.roo/rules-pr-fixer/5_examples.xml @@ -12,28 +12,9 @@ Get PR details and review comments. - - github - get_pull_request - - { - "owner": "RooCodeInc", - "repo": "Roo-Code", - "pullNumber": 4365 - } - - - - github - get_pull_request_comments - - { - "owner": "RooCodeInc", - "repo": "Roo-Code", - "pullNumber": 4365 - } - - + +gh pr view 4365 --repo RooCodeInc/Roo-Code --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles,comments,reviews,mergeable,mergeStateStatus + Get the branch name, list of review comments, and check for mergeability. @@ -42,7 +23,7 @@ Check CI status. -gh pr checks 4365 +gh pr checks 4365 --repo RooCodeInc/Roo-Code Identify which check is failing. @@ -52,7 +33,17 @@ Get logs for the failing check. -gh run view --log-failed +gh run list --pr 4365 --repo RooCodeInc/Roo-Code + + + Get the run ID of the failing workflow. + + + + View the failed logs. + + +gh run view [run_id] --repo RooCodeInc/Roo-Code --log-failed Find the specific error message causing the test to fail. @@ -62,7 +53,7 @@ Check out the pull request branch. - gh pr checkout 4365 --force + gh pr checkout 4365 --repo RooCodeInc/Roo-Code --force The PR branch is now ready for local edits. @@ -85,7 +76,7 @@ After pushing the changes, monitor PR checks in real-time. - gh pr checks 4365 --watch + gh pr checks 4365 --repo RooCodeInc/Roo-Code --watch Monitor checks continuously until all complete. The --watch flag provides real-time updates as check statuses change. @@ -94,7 +85,8 @@ Always gather all information before proposing a solution. - Use a combination of the GitHub MCP server and the `gh` CLI to get a complete picture of the PR's status. + Use the GitHub CLI to get a complete picture of the PR's status. + The --watch flag on gh pr checks provides real-time monitoring of CI status. @@ -111,17 +103,9 @@ Get PR details and analyze changes. - - github - get_pull_request - - { - "owner": "RooCodeInc", - "repo": "Roo-Code", - "pullNumber": 1234 - } - - + +gh pr view 1234 --repo RooCodeInc/Roo-Code --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles,comments,reviews + Identify the files changed and review feedback requiring UI text modifications. @@ -130,7 +114,7 @@ Check out PR and apply the requested changes. -gh pr checkout 1234 --force +gh pr checkout 1234 --repo RooCodeInc/Roo-Code --force Make the requested button text changes in the UI components. @@ -158,20 +142,30 @@ Ensure consistency across all language files and maintain the same context and t - Commit all changes including translations with automated git configuration. + Review and commit changes including translations. -git add . && git commit -m "fix: update button text and translations as requested in review" +git status --porcelain - All code changes and translation updates are now committed. + Review the list of modified files to ensure only intended changes are present. + + + + Stage only the intended files for commit. + + +git add -u && git commit -m "fix: update button text and translations as requested in review" + + + Using 'git add -u' stages only modified tracked files, avoiding any temporary files. Check if PR is from a fork and push to correct remote. -gh pr view 1234 --json isCrossRepository,headRepositoryOwner,headRefName +gh pr view 1234 --repo RooCodeInc/Roo-Code --json isCrossRepository,headRepositoryOwner,headRefName Determine if this is a cross-repository PR to know which remote to push to. @@ -181,7 +175,7 @@ Ensure consistency across all language files and maintain the same context and t Push changes to the appropriate remote. -git push --force-with-lease origin +git push --force-with-lease origin [branch_name] Push changes safely to update the pull request. Use 'fork' remote instead if PR is from a fork. @@ -191,7 +185,7 @@ Ensure consistency across all language files and maintain the same context and t Monitor CI status in real-time. -gh pr checks 1234 --watch +gh pr checks 1234 --repo RooCodeInc/Roo-Code --watch Watch CI checks continuously until all tests pass. The --watch flag provides automatic updates as check statuses change. @@ -203,6 +197,7 @@ Ensure consistency across all language files and maintain the same context and t Use new_task with translate mode to ensure consistent translation updates. Include detailed context about what changed and why in translation requests. Verify translation completeness before considering the PR fix complete. + Use gh pr view --json to get structured data about PR properties. diff --git a/.roo/rules-pr-reviewer/1_orchestrator_workflow.xml b/.roo/rules-pr-reviewer/1_orchestrator_workflow.xml index cea0486a26..8bb94694d6 100644 --- a/.roo/rules-pr-reviewer/1_orchestrator_workflow.xml +++ b/.roo/rules-pr-reviewer/1_orchestrator_workflow.xml @@ -3,7 +3,7 @@ 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. + avoiding redundant feedback. All GitHub operations are performed using the GitHub CLI. @@ -27,14 +27,12 @@ Fetch PR Details and Context - Try using GitHub MCP tools first. If unavailable or failing, fall back to GitHub CLI. + Use GitHub CLI to fetch comprehensive PR details. - - Use get_pull_request tool to fetch PR details - - + gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles - + + .roo/temp/pr-[PR_NUMBER]/pr-metadata.json @@ -42,12 +40,10 @@ If PR references an issue, fetch its details for context. - - Use get_issue tool if issue is referenced - - + gh issue view [issue_number] --repo [owner]/[repo] --json number,title,body,author,state - + + .roo/temp/pr-[PR_NUMBER]/linked-issue.json @@ -55,12 +51,10 @@ CRITICAL: Get all existing feedback to avoid redundancy. - - Use get_pull_request_comments and get_pull_request_reviews - - - gh pr review [PR_NUMBER] --repo [owner]/[repo] --json comments,reviews - + + gh pr view [PR_NUMBER] --repo [owner]/[repo] --json comments --jq '.comments' + gh pr view [PR_NUMBER] --repo [owner]/[repo] --json reviews --jq '.reviews' + .roo/temp/pr-[PR_NUMBER]/existing-feedback.json @@ -178,21 +172,26 @@ Post Review Comment (if approved) - If user approves and not called by another mode, post review. + If user approves and not called by another mode, post review using GitHub CLI. - - Use add_issue_comment or create PR review - - + gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body-file .roo/temp/pr-[PR_NUMBER]/final-review.md - + - - Always fall back to GitHub CLI commands - + + + Inform user to run 'gh auth login' and check authentication status + + + Verify PR number and repository, ask user to confirm details + + + Wait briefly and retry, inform user about rate limiting + + Continue with available analysis and note limitations diff --git a/.roo/rules-pr-reviewer/4_github_operations.xml b/.roo/rules-pr-reviewer/4_github_operations.xml index dd1c97e1bf..ad1fdc4459 100644 --- a/.roo/rules-pr-reviewer/4_github_operations.xml +++ b/.roo/rules-pr-reviewer/4_github_operations.xml @@ -1,226 +1,224 @@ - Guidelines for handling GitHub operations with fallback strategies - when MCP tools are unavailable or failing. + Guidelines for handling GitHub operations using the GitHub CLI (gh). + This mode exclusively uses command-line operations for all GitHub interactions. - - - Always try MCP tools first, fall back to GitHub CLI if they fail - - - - Structured data responses - - Better error handling - - Integrated with the system - - - - More reliable when MCP is down - - Direct GitHub API access - - Can handle complex queries - - + + + GitHub CLI must be installed and authenticated + gh auth status + https://cli.github.com/ + + + User must be authenticated with appropriate permissions + gh auth login + + - - get_pull_request - -github -get_pull_request - -{ - "owner": "RooCodeInc", - "repo": "Roo-Code", - "pullNumber": 123 -} - - - ]]> - - - gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles - true - + Fetch comprehensive PR metadata + gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles + JSON + .roo/temp/pr-[PR_NUMBER]/pr-metadata.json - - get_pull_request_diff - -github -get_pull_request_diff - -{ - "owner": "RooCodeInc", - "repo": "Roo-Code", - "pullNumber": 123 -} - - - ]]> - - - gh pr diff [PR_NUMBER] --repo [owner]/[repo] - .roo/temp/pr-[PR_NUMBER]/pr.diff - + Get the full diff of PR changes + gh pr diff [PR_NUMBER] --repo [owner]/[repo] + .roo/temp/pr-[PR_NUMBER]/pr.diff - - get_pull_request_files - - - gh pr view [PR_NUMBER] --repo [owner]/[repo] --json files --jq '.files[].path' - Lists all files changed in the PR - + List all files changed in the PR + gh pr view [PR_NUMBER] --repo [owner]/[repo] --json files --jq '.files[].path' + Line-separated file paths - - get_pull_request_comments - - - gh pr view [PR_NUMBER] --repo [owner]/[repo] --json comments --jq '.comments' - + Get all comments on the PR + gh pr view [PR_NUMBER] --repo [owner]/[repo] --json comments --jq '.comments' + JSON array of comments - - get_pull_request_reviews - - - gh pr view [PR_NUMBER] --repo [owner]/[repo] --json reviews --jq '.reviews' - + Get all reviews on the PR + gh pr view [PR_NUMBER] --repo [owner]/[repo] --json reviews --jq '.reviews' + JSON array of reviews - - gh pr checkout [PR_NUMBER] --repo [owner]/[repo] - No MCP equivalent - always use CLI - + Check out PR branch locally for analysis + gh pr checkout [PR_NUMBER] --repo [owner]/[repo] + This switches the current branch to the PR branch - - add_issue_comment - PRs use same comment system as issues - - - gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body-file [file_path] - gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body "[comment_text]" - + Post a comment on the PR + gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body-file [file_path] + gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body "[comment_text]" - - - 1. create_pending_pull_request_review - 2. add_pull_request_review_comment_to_pending_review (multiple times) - 3. submit_pending_pull_request_review - - - - gh pr review [PR_NUMBER] --repo [owner]/[repo] --comment --body-file [review_file] - + Create a PR review with comments + gh pr review [PR_NUMBER] --repo [owner]/[repo] --comment --body-file [review_file] + + + + + + + + + Get issue details (for linked issues) + gh issue view [issue_number] --repo [owner]/[repo] --json number,title,body,author,state + JSON - + - Error message contains "MCP server" or "github server not found" + Error contains "authentication" or "not logged in" - Immediately switch to CLI commands for all operations + 1. Inform user about auth issue + 2. Suggest running: gh auth login + 3. Check status with: gh auth status - Error contains "rate limit" or status code 403 + Error contains "rate limit" or "API rate limit exceeded" - 1. Wait briefly (30 seconds) - 2. Retry with CLI using --limit flag - 3. Reduce number of API calls - - - - - - Error contains "authentication" or status code 401 - - - 1. Inform user about auth issue - 2. Suggest checking gh auth status - 3. Continue with available data + 1. Wait 30-60 seconds before retry + 2. Inform user about rate limiting + 3. Consider reducing API calls - Error contains "not found" or status code 404 + Error contains "not found" or "could not find pull request" - 1. Verify PR number and repository - 2. Ask user to confirm details - 3. Check if PR is from a fork + 1. Verify PR number and repository format + 2. Check if repository is accessible + 3. Ensure correct owner/repo format + + + + + + Error contains "permission denied" or "403" + + + 1. Check repository permissions + 2. Verify authentication scope + 3. May need to re-authenticate with proper scopes - Always save API responses to temp files - Preserve data in case of failures + Always save command outputs to temp files + Preserve data for analysis and recovery - Use jq or built-in JSON parsing + Use jq for JSON parsing when available gh pr view --json files --jq '.files[].path' - For PRs with many files, process in batches + For PRs with many files, save outputs to files first More than 50 files + Save to file, then process in chunks + + + + Always validate JSON before parsing + jq empty < file.json || echo "Invalid JSON" - gh pr view [number] --json [fields] - + gh pr view [number] + + + + + + number, title, author, state, body, url, headRefName, baseRefName, files, additions, - deletions, changedFiles, comments, reviews - + deletions, changedFiles, comments, reviews, + isDraft, mergeable, mergeStateStatus + - gh pr checkout [number] - gh pr diff [number] - gh pr comment [number] --body "[text]" - gh pr review [number] --comment --body "[text]" + + gh pr checkout [number]: Check out PR locally + gh pr diff [number]: View PR diff + gh pr comment [number] --body "[text]": Add comment + gh pr review [number]: Create review + gh pr close [number]: Close PR + gh pr reopen [number]: Reopen PR + - gh issue view [number] --json [fields] - + gh issue view [number] + number, title, body, author, state, - labels, assignees, milestone - + labels, assignees, milestone, comments + + + + + + gh repo view --json [fields]: Get repo info + gh repo clone [owner]/[repo]: Clone repository + Always specify --repo to avoid ambiguity - Use --json for structured data - Save command outputs to temp files - Check gh auth status before operations - Handle both personal repos and org repos + Use --json for structured data that needs parsing + Save command outputs to temp files for reliability + Check gh auth status before starting operations + Handle both personal repos and organization repos + Use meaningful file names when saving outputs + Include error handling for all commands + Document the expected format of saved files + + + + Fetch all PR data for analysis + + gh pr view 123 --repo owner/repo --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles > .roo/temp/pr-123/metadata.json + gh pr view 123 --repo owner/repo --json comments > .roo/temp/pr-123/comments.json + gh pr view 123 --repo owner/repo --json reviews > .roo/temp/pr-123/reviews.json + gh pr diff 123 --repo owner/repo > .roo/temp/pr-123/pr.diff + + + + + Post a comprehensive review + + Create review content in .roo/temp/pr-123/review.md + gh pr review 123 --repo owner/repo --comment --body-file .roo/temp/pr-123/review.md + + + \ No newline at end of file diff --git a/.roomodes b/.roomodes index f2bbe35fd1..15d3673a09 100644 --- a/.roomodes +++ b/.roomodes @@ -18,6 +18,7 @@ customModes: - Ensuring instructions are well-organized with proper XML tags - Following established patterns from existing modes whenToUse: Use this mode when you need to create a new custom mode. + description: Create and implement custom modes. groups: - read - - edit @@ -33,6 +34,7 @@ customModes: Your focus is on maintaining high test quality and coverage across the codebase, working primarily with: - Test files in __tests__ directories - Mock implementations in __mocks__ - Test utilities and helpers - Vitest configuration and setup You ensure tests are: - Well-structured and maintainable - Following Vitest best practices - Properly typed with TypeScript - Providing meaningful coverage - Using appropriate mocking strategies whenToUse: Use this mode when you need to write, modify, or maintain tests for the codebase. + description: Write, modify, and maintain tests. groups: - read - browser @@ -55,6 +57,8 @@ customModes: - slug: design-engineer name: 🎨 Design Engineer roleDefinition: "You are Roo, an expert Design Engineer focused on VSCode Extension development. Your expertise includes: - Implementing UI designs with high fidelity using React, Shadcn, Tailwind and TypeScript. - Ensuring interfaces are responsive and adapt to different screen sizes. - Collaborating with team members to translate broad directives into robust and detailed designs capturing edge cases. - Maintaining uniformity and consistency across the user interface." + whenToUse: Implement UI designs and ensure consistency. + description: Implement UI designs; ensure consistency. groups: - read - - edit @@ -68,6 +72,8 @@ customModes: - slug: release-engineer name: 🚀 Release Engineer roleDefinition: You are Roo, a release engineer specialized in automating the release process for software projects. You have expertise in version control, changelogs, release notes, creating changesets, and coordinating with translation teams to ensure a smooth release process. + whenToUse: Automate the release process for software projects. + description: Automate the release process. customInstructions: |- When preparing a release: 1. Identify the SHA corresponding to the most recent release using GitHub CLI: `gh release view --json tagName,targetCommitish,publishedAt ` 2. Analyze changes since the last release using: `gh pr list --state merged --json number,title,author,url,mergedAt --limit 1000 -q '[.[] | select(.mergedAt > "TIMESTAMP") | {number, title, author: .author.login, url, mergedAt}] | sort_by(.number)'` 3. Summarize the changes and ask the user whether this should be a major, minor, or patch release 4. Create a changeset in .changeset/v[version].md instead of directly modifying package.json. The format is: ``` --- "roo-cline": patch|minor|major --- @@ -86,6 +92,8 @@ customModes: - slug: translate name: 🌐 Translate roleDefinition: You are Roo, a linguistic specialist focused on translating and managing localization files. Your responsibility is to help maintain and update translation files for the application, ensuring consistency and accuracy across all language resources. + whenToUse: Translate and manage localization files. + description: Translate and manage localization files. groups: - read - command @@ -107,6 +115,7 @@ customModes: You work with issues from any GitHub repository, transforming them into working code that addresses all requirements while maintaining code quality and consistency. You use the GitHub CLI (gh) for all GitHub operations instead of MCP tools. whenToUse: Use this mode when you have a GitHub issue (bug report or feature request) that needs to be fixed or implemented. Provide the issue URL, and this mode will guide you through understanding the requirements, implementing the solution, and preparing for submission. + description: Fix GitHub issues and implement features. groups: - read - edit @@ -118,6 +127,7 @@ customModes: You are Roo, a GitHub issue creation specialist focused on crafting well-structured, detailed issues based on the project's issue templates. Your expertise includes: - Understanding and analyzing user requirements for bug reports and feature requests - Exploring codebases thoroughly to gather relevant technical context - Creating comprehensive GitHub issues following XML-based templates - Ensuring issues contain all necessary information for developers - Using GitHub MCP tools to create issues programmatically You work with two primary issue types: - Bug Reports: Documenting reproducible bugs with clear steps and expected outcomes - Feature Proposals: Creating detailed, actionable feature requests with clear problem statements, solutions, and acceptance criteria whenToUse: Use this mode when you need to create a GitHub issue for bug reports or feature requests. This mode will guide you through gathering all necessary information, exploring the codebase for context, and creating a well-structured issue in the RooCodeInc/Roo-Code repository. + description: Create well-structured GitHub issues. groups: - read - command @@ -129,6 +139,8 @@ customModes: You are Roo, an integration testing specialist focused on VSCode E2E tests with expertise in: - Writing and maintaining integration tests using Mocha and VSCode Test framework - Testing Roo Code API interactions and event-driven workflows - Creating complex multi-step task scenarios and mode switching sequences - Validating message formats, API responses, and event emission patterns - Test data generation and fixture management - Coverage analysis and test scenario identification Your focus is on ensuring comprehensive integration test coverage for the Roo Code extension, working primarily with: - E2E test files in apps/vscode-e2e/src/suite/ - Test utilities and helpers - API type definitions in packages/types/ - Extension API testing patterns You ensure integration tests are: - Comprehensive and cover critical user workflows - Following established Mocha TDD patterns - Using async/await with proper timeout handling - Validating both success and failure scenarios - Properly typed with TypeScript + whenToUse: Write, modify, or maintain integration tests. + description: Write and maintain integration tests. groups: - read - command @@ -156,6 +168,7 @@ customModes: You work primarily with the RooCodeInc/Roo-Code repository, creating context reports to track findings and delegating complex pattern analysis to specialized modes while maintaining overall review coordination. When called by other modes (Issue Fixer, PR Fixer), you focus only on analysis without commenting on the PR. whenToUse: Use this mode to critically review pull requests, focusing on code organization, pattern consistency, and identifying redundancy or architectural issues. This mode orchestrates complex analysis tasks while maintaining review context. + description: Critically review pull requests. groups: - read - - edit @@ -168,6 +181,7 @@ customModes: name: 📚 Docs Extractor roleDefinition: You are Roo, a comprehensive documentation extraction specialist focused on analyzing and documenting all technical and non-technical information about features and components within codebases. whenToUse: Use this mode when you need to extract comprehensive documentation about any feature, component, or aspect of a codebase. + description: Extract comprehensive documentation. groups: - read - - edit @@ -179,26 +193,19 @@ customModes: name: 🛠️ PR Fixer roleDefinition: "You are Roo, a pull request resolution specialist. Your focus is on addressing feedback and resolving issues within existing pull requests. Your expertise includes: - Analyzing PR review comments to understand required changes. - Checking CI/CD workflow statuses to identify failing tests. - Fetching and analyzing test logs to diagnose failures. - Identifying and resolving merge conflicts. - Guiding the user through the resolution process." whenToUse: Use this mode to fix pull requests. It can analyze PR feedback from GitHub, check for failing tests, and help resolve merge conflicts before applying the necessary code changes. + description: Fix pull requests. groups: - read - edit - command - mcp - - 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: [] - source: project - - slug: issue-fixer-orchestrator - name: 🔧 Issue Fixer Orchestrator - roleDefinition: |- - You are an orchestrator for fixing GitHub issues. Your primary role is to coordinate a series of specialized subtasks to resolve an issue from start to finish. - **Your Orchestration Responsibilities:** - Delegate analysis, implementation, and testing to specialized subtasks using the `new_task` tool. - Manage the workflow and pass context between steps using temporary files. - Present plans, results, and pull requests to the user for approval at key milestones. - **Your Core Expertise Includes:** - Analyzing GitHub issues to understand requirements and acceptance criteria. - Exploring codebases to identify all affected files and dependencies. - Guiding the implementation of high-quality fixes and features. - Ensuring comprehensive test coverage. - Overseeing the creation of well-documented pull requests. - Using the GitHub CLI (gh) for all final GitHub operations like creating a pull request. - whenToUse: Use this mode to orchestrate the process of fixing a GitHub issue. Provide a GitHub issue URL, and this mode will coordinate a series of subtasks to analyze the issue, explore the code, create a plan, implement the solution, and prepare a pull request. - groups: [] + - slug: issue-investigator + name: 🕵️ Issue Investigator + roleDefinition: You are Roo, a GitHub issue investigator. Your purpose is to analyze GitHub issues, investigate the probable causes using extensive codebase searches, and propose well-reasoned, theoretical solutions. You methodically track your investigation using a todo list, attempting to disprove initial theories to ensure a thorough analysis. Your final output is a human-like, conversational comment for the GitHub issue. + whenToUse: Use this mode when you need to investigate a GitHub issue to understand its root cause and propose a solution. This mode is ideal for triaging issues, providing initial analysis, and suggesting fixes before implementation begins. It uses the `gh` CLI for issue interaction. + description: Investigates GitHub issues + groups: + - read + - command + - mcp source: project diff --git a/CHANGELOG.md b/CHANGELOG.md index 018b9330da..91091805e8 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,26 @@ # Roo Code Changelog +## [3.23.14] - 2025-07-17 + +- Log api-initiated tasks to a tmp directory + +## [3.23.13] - 2025-07-17 + +- Add the ability to "undo" enhance prompt changes +- Fix a bug where the path component of the baseURL for the LiteLLM provider contains path in it (thanks @ChuKhaLi) +- Add support for Vertex AI model name formatting when using Claude Code with Vertex AI (thanks @janaki-sasidhar) +- The list-files tool must include at least the first-level directory contents (thanks @qdaxb) +- Add a configurable limit that controls both consecutive errors and tool repetitions (thanks @MuriloFP) +- Add `.terraform/` and `.terragrunt-cache/` directories to the checkpoint exclusion patterns (thanks @MuriloFP) +- Increase Ollama API timeout values (thanks @daniel-lxs) +- Fix an issue where you need to "discard changes" before saving even though there are no settings changes +- Fix `DirectoryScanner` memory leak and improve file limit handling (thanks @daniel-lxs) +- Fix time formatting in environment (thanks @chrarnoldus) +- Prevent empty mode names from being saved (thanks @daniel-lxs) +- Improve auto-approve checkbox UX +- Improve the chat message edit / delete functionality (thanks @liwilliam2021) +- Add `commandExecutionTimeout` to `GlobalSettings` + ## [3.23.12] - 2025-07-15 - Update the max-token calculation in model-params to better support Kimi K2 and others diff --git a/packages/types/npm/package.json b/packages/types/npm/package.json index 54188d73bc..7f364e3d4f 100644 --- a/packages/types/npm/package.json +++ b/packages/types/npm/package.json @@ -1,6 +1,6 @@ { "name": "@roo-code/types", - "version": "1.32.0", + "version": "1.36.0", "description": "TypeScript type definitions for Roo Code.", "publishConfig": { "access": "public", diff --git a/packages/types/src/__tests__/provider-settings.test.ts b/packages/types/src/__tests__/provider-settings.test.ts new file mode 100644 index 0000000000..87c5bbcc1c --- /dev/null +++ b/packages/types/src/__tests__/provider-settings.test.ts @@ -0,0 +1,79 @@ +import { describe, it, expect } from "vitest" +import { getApiProtocol } from "../provider-settings.js" + +describe("getApiProtocol", () => { + describe("Anthropic-style providers", () => { + it("should return 'anthropic' for anthropic provider", () => { + expect(getApiProtocol("anthropic")).toBe("anthropic") + expect(getApiProtocol("anthropic", "gpt-4")).toBe("anthropic") + }) + + it("should return 'anthropic' for claude-code provider", () => { + expect(getApiProtocol("claude-code")).toBe("anthropic") + expect(getApiProtocol("claude-code", "some-model")).toBe("anthropic") + }) + }) + + describe("Vertex provider with Claude models", () => { + it("should return 'anthropic' for vertex provider with claude models", () => { + expect(getApiProtocol("vertex", "claude-3-opus")).toBe("anthropic") + expect(getApiProtocol("vertex", "Claude-3-Sonnet")).toBe("anthropic") + expect(getApiProtocol("vertex", "CLAUDE-instant")).toBe("anthropic") + expect(getApiProtocol("vertex", "anthropic/claude-3-haiku")).toBe("anthropic") + }) + + it("should return 'openai' for vertex provider with non-claude models", () => { + expect(getApiProtocol("vertex", "gpt-4")).toBe("openai") + expect(getApiProtocol("vertex", "gemini-pro")).toBe("openai") + expect(getApiProtocol("vertex", "llama-2")).toBe("openai") + }) + }) + + describe("Bedrock provider with Claude models", () => { + it("should return 'anthropic' for bedrock provider with claude models", () => { + expect(getApiProtocol("bedrock", "claude-3-opus")).toBe("anthropic") + expect(getApiProtocol("bedrock", "Claude-3-Sonnet")).toBe("anthropic") + expect(getApiProtocol("bedrock", "CLAUDE-instant")).toBe("anthropic") + expect(getApiProtocol("bedrock", "anthropic.claude-v2")).toBe("anthropic") + }) + + it("should return 'openai' for bedrock provider with non-claude models", () => { + expect(getApiProtocol("bedrock", "gpt-4")).toBe("openai") + expect(getApiProtocol("bedrock", "titan-text")).toBe("openai") + expect(getApiProtocol("bedrock", "llama-2")).toBe("openai") + }) + }) + + describe("Other providers with Claude models", () => { + it("should return 'openai' for non-vertex/bedrock providers with claude models", () => { + expect(getApiProtocol("openrouter", "claude-3-opus")).toBe("openai") + expect(getApiProtocol("openai", "claude-3-sonnet")).toBe("openai") + expect(getApiProtocol("litellm", "claude-instant")).toBe("openai") + expect(getApiProtocol("ollama", "claude-model")).toBe("openai") + }) + }) + + describe("Edge cases", () => { + it("should return 'openai' when provider is undefined", () => { + expect(getApiProtocol(undefined)).toBe("openai") + expect(getApiProtocol(undefined, "claude-3-opus")).toBe("openai") + }) + + it("should return 'openai' when model is undefined", () => { + expect(getApiProtocol("openai")).toBe("openai") + expect(getApiProtocol("vertex")).toBe("openai") + expect(getApiProtocol("bedrock")).toBe("openai") + }) + + it("should handle empty strings", () => { + expect(getApiProtocol("vertex", "")).toBe("openai") + expect(getApiProtocol("bedrock", "")).toBe("openai") + }) + + it("should be case-insensitive for claude detection", () => { + expect(getApiProtocol("vertex", "CLAUDE-3-OPUS")).toBe("anthropic") + expect(getApiProtocol("bedrock", "claude-3-opus")).toBe("anthropic") + expect(getApiProtocol("vertex", "ClAuDe-InStAnT")).toBe("anthropic") + }) + }) +}) diff --git a/packages/types/src/global-settings.ts b/packages/types/src/global-settings.ts index 514b15d783..bddb94cc9e 100644 --- a/packages/types/src/global-settings.ts +++ b/packages/types/src/global-settings.ts @@ -15,6 +15,13 @@ import { modeConfigSchema } from "./mode.js" import { customModePromptsSchema, customSupportPromptsSchema } from "./mode.js" import { languagesSchema } from "./vscode.js" +/** + * Default delay in milliseconds after writes to allow diagnostics to detect potential problems. + * This delay is particularly important for Go and other languages where tools like goimports + * need time to automatically clean up unused imports. + */ +export const DEFAULT_WRITE_DELAY_MS = 1000 + /** * GlobalSettings */ @@ -37,7 +44,7 @@ export const globalSettingsSchema = z.object({ alwaysAllowWrite: z.boolean().optional(), alwaysAllowWriteOutsideWorkspace: z.boolean().optional(), alwaysAllowWriteProtected: z.boolean().optional(), - writeDelayMs: z.number().optional(), + writeDelayMs: z.number().min(0).optional(), alwaysAllowBrowser: z.boolean().optional(), alwaysApproveResubmit: z.boolean().optional(), requestDelaySeconds: z.number().optional(), @@ -50,6 +57,9 @@ export const globalSettingsSchema = z.object({ alwaysAllowUpdateTodoList: z.boolean().optional(), allowedCommands: z.array(z.string()).optional(), deniedCommands: z.array(z.string()).optional(), + commandExecutionTimeout: z.number().optional(), + commandTimeoutAllowlist: z.array(z.string()).optional(), + preventCompletionWithOpenTodos: z.boolean().optional(), allowedMaxRequests: z.number().nullish(), autoCondenseContext: z.boolean().optional(), autoCondenseContextPercent: z.number().optional(), @@ -85,6 +95,8 @@ export const globalSettingsSchema = z.object({ terminalZdotdir: z.boolean().optional(), terminalCompressProgressBar: z.boolean().optional(), + diagnosticsEnabled: z.boolean().optional(), + rateLimitSeconds: z.number().optional(), diffEnabled: z.boolean().optional(), fuzzyMatchThreshold: z.number().optional(), @@ -200,6 +212,9 @@ export const EVALS_SETTINGS: RooCodeSettings = { alwaysAllowUpdateTodoList: true, followupAutoApproveTimeoutMs: 0, allowedCommands: ["*"], + commandExecutionTimeout: 30_000, + commandTimeoutAllowlist: [], + preventCompletionWithOpenTodos: false, browserToolEnabled: false, browserViewportSize: "900x600", @@ -222,6 +237,8 @@ export const EVALS_SETTINGS: RooCodeSettings = { terminalCompressProgressBar: true, terminalShellIntegrationDisabled: true, + diagnosticsEnabled: true, + diffEnabled: true, fuzzyMatchThreshold: 1, diff --git a/packages/types/src/provider-settings.ts b/packages/types/src/provider-settings.ts index 3b53627295..be74ae6bb4 100644 --- a/packages/types/src/provider-settings.ts +++ b/packages/types/src/provider-settings.ts @@ -303,7 +303,23 @@ export const getModelId = (settings: ProviderSettings): string | undefined => { // Providers that use Anthropic-style API protocol export const ANTHROPIC_STYLE_PROVIDERS: ProviderName[] = ["anthropic", "claude-code"] -// Helper function to determine API protocol for a provider -export const getApiProtocol = (provider: ProviderName | undefined): "anthropic" | "openai" => { - return provider && ANTHROPIC_STYLE_PROVIDERS.includes(provider) ? "anthropic" : "openai" +// Helper function to determine API protocol for a provider and model +export const getApiProtocol = (provider: ProviderName | undefined, modelId?: string): "anthropic" | "openai" => { + // First check if the provider is an Anthropic-style provider + if (provider && ANTHROPIC_STYLE_PROVIDERS.includes(provider)) { + return "anthropic" + } + + // For vertex and bedrock providers, check if the model ID contains "claude" (case-insensitive) + if ( + provider && + (provider === "vertex" || provider === "bedrock") && + modelId && + modelId.toLowerCase().includes("claude") + ) { + return "anthropic" + } + + // Default to OpenAI protocol + return "openai" } diff --git a/src/core/task/Task.ts b/src/core/task/Task.ts index 795c30c420..b8238689bf 100644 --- a/src/core/task/Task.ts +++ b/src/core/task/Task.ts @@ -23,6 +23,7 @@ import { TelemetryEventName, TodoItem, getApiProtocol, + getModelId, } from "@roo-code/types" import { TelemetryService } from "@roo-code/telemetry" import { CloudService } from "@roo-code/cloud" @@ -1242,8 +1243,9 @@ export class Task extends EventEmitter { // take a few seconds. For the best UX we show a placeholder api_req_started // message with a loading spinner as this happens. - // Determine API protocol based on provider - const apiProtocol = getApiProtocol(this.apiConfiguration.apiProvider) + // Determine API protocol based on provider and model + const modelId = getModelId(this.apiConfiguration) + const apiProtocol = getApiProtocol(this.apiConfiguration.apiProvider, modelId) await this.say( "api_req_started", diff --git a/src/core/task/__tests__/Task.spec.ts b/src/core/task/__tests__/Task.spec.ts index dc2597c435..8da5801ed0 100644 --- a/src/core/task/__tests__/Task.spec.ts +++ b/src/core/task/__tests__/Task.spec.ts @@ -1497,5 +1497,100 @@ describe("Cline", () => { expect(result.response).toBe("messageResponse") }) }) + + describe("getApiProtocol", () => { + it("should determine API protocol based on provider and model", async () => { + // Test with Anthropic provider + const anthropicConfig = { + ...mockApiConfig, + apiProvider: "anthropic" as const, + apiModelId: "gpt-4", + } + const anthropicTask = new Task({ + provider: mockProvider, + apiConfiguration: anthropicConfig, + task: "test task", + startTask: false, + }) + // Should use anthropic protocol even with non-claude model + expect(anthropicTask.apiConfiguration.apiProvider).toBe("anthropic") + + // Test with OpenRouter provider and Claude model + const openrouterClaudeConfig = { + apiProvider: "openrouter" as const, + openRouterModelId: "anthropic/claude-3-opus", + } + const openrouterClaudeTask = new Task({ + provider: mockProvider, + apiConfiguration: openrouterClaudeConfig, + task: "test task", + startTask: false, + }) + expect(openrouterClaudeTask.apiConfiguration.apiProvider).toBe("openrouter") + + // Test with OpenRouter provider and non-Claude model + const openrouterGptConfig = { + apiProvider: "openrouter" as const, + openRouterModelId: "openai/gpt-4", + } + const openrouterGptTask = new Task({ + provider: mockProvider, + apiConfiguration: openrouterGptConfig, + task: "test task", + startTask: false, + }) + expect(openrouterGptTask.apiConfiguration.apiProvider).toBe("openrouter") + + // Test with various Claude model formats + const claudeModelFormats = [ + "claude-3-opus", + "Claude-3-Sonnet", + "CLAUDE-instant", + "anthropic/claude-3-haiku", + "some-provider/claude-model", + ] + + for (const modelId of claudeModelFormats) { + const config = { + apiProvider: "openai" as const, + openAiModelId: modelId, + } + const task = new Task({ + provider: mockProvider, + apiConfiguration: config, + task: "test task", + startTask: false, + }) + // Verify the model ID contains claude (case-insensitive) + expect(modelId.toLowerCase()).toContain("claude") + } + }) + + it("should handle edge cases for API protocol detection", async () => { + // Test with undefined provider + const undefinedProviderConfig = { + apiModelId: "claude-3-opus", + } + const undefinedProviderTask = new Task({ + provider: mockProvider, + apiConfiguration: undefinedProviderConfig, + task: "test task", + startTask: false, + }) + expect(undefinedProviderTask.apiConfiguration.apiProvider).toBeUndefined() + + // Test with no model ID + const noModelConfig = { + apiProvider: "openai" as const, + } + const noModelTask = new Task({ + provider: mockProvider, + apiConfiguration: noModelConfig, + task: "test task", + startTask: false, + }) + expect(noModelTask.apiConfiguration.apiProvider).toBe("openai") + }) + }) }) }) diff --git a/src/core/tools/__tests__/attemptCompletionTool.spec.ts b/src/core/tools/__tests__/attemptCompletionTool.spec.ts new file mode 100644 index 0000000000..b39c1acac6 --- /dev/null +++ b/src/core/tools/__tests__/attemptCompletionTool.spec.ts @@ -0,0 +1,412 @@ +import { describe, it, expect, vi, beforeEach } from "vitest" +import { TodoItem } from "@roo-code/types" +import { AttemptCompletionToolUse } from "../../../shared/tools" + +// Mock the formatResponse module before importing the tool +vi.mock("../../prompts/responses", () => ({ + formatResponse: { + toolError: vi.fn((msg: string) => `Error: ${msg}`), + }, +})) + +// Mock vscode module +vi.mock("vscode", () => ({ + workspace: { + getConfiguration: vi.fn(() => ({ + get: vi.fn(), + })), + }, +})) + +// Mock Package module +vi.mock("../../../shared/package", () => ({ + Package: { + name: "roo-cline", + }, +})) + +import { attemptCompletionTool } from "../attemptCompletionTool" +import { Task } from "../../task/Task" +import * as vscode from "vscode" + +describe("attemptCompletionTool", () => { + let mockTask: Partial + let mockPushToolResult: ReturnType + let mockAskApproval: ReturnType + let mockHandleError: ReturnType + let mockRemoveClosingTag: ReturnType + let mockToolDescription: ReturnType + let mockAskFinishSubTaskApproval: ReturnType + let mockGetConfiguration: ReturnType + + beforeEach(() => { + mockPushToolResult = vi.fn() + mockAskApproval = vi.fn() + mockHandleError = vi.fn() + mockRemoveClosingTag = vi.fn() + mockToolDescription = vi.fn() + mockAskFinishSubTaskApproval = vi.fn() + mockGetConfiguration = vi.fn(() => ({ + get: vi.fn((key: string, defaultValue: any) => { + if (key === "preventCompletionWithOpenTodos") { + return defaultValue // Default to false unless overridden in test + } + return defaultValue + }), + })) + + // Setup vscode mock + vi.mocked(vscode.workspace.getConfiguration).mockImplementation(mockGetConfiguration) + + mockTask = { + consecutiveMistakeCount: 0, + recordToolError: vi.fn(), + todoList: undefined, + } + }) + + describe("todo list validation", () => { + it("should allow completion when there is no todo list", async () => { + const block: AttemptCompletionToolUse = { + type: "tool_use", + name: "attempt_completion", + params: { result: "Task completed successfully" }, + partial: false, + } + + mockTask.todoList = undefined + + await attemptCompletionTool( + mockTask as Task, + block, + mockAskApproval, + mockHandleError, + mockPushToolResult, + mockRemoveClosingTag, + mockToolDescription, + mockAskFinishSubTaskApproval, + ) + + // Should not call pushToolResult with an error for empty todo list + expect(mockTask.consecutiveMistakeCount).toBe(0) + expect(mockTask.recordToolError).not.toHaveBeenCalled() + }) + + it("should allow completion when todo list is empty", async () => { + const block: AttemptCompletionToolUse = { + type: "tool_use", + name: "attempt_completion", + params: { result: "Task completed successfully" }, + partial: false, + } + + mockTask.todoList = [] + + await attemptCompletionTool( + mockTask as Task, + block, + mockAskApproval, + mockHandleError, + mockPushToolResult, + mockRemoveClosingTag, + mockToolDescription, + mockAskFinishSubTaskApproval, + ) + + expect(mockTask.consecutiveMistakeCount).toBe(0) + expect(mockTask.recordToolError).not.toHaveBeenCalled() + }) + + it("should allow completion when all todos are completed", async () => { + const block: AttemptCompletionToolUse = { + type: "tool_use", + name: "attempt_completion", + params: { result: "Task completed successfully" }, + partial: false, + } + + const completedTodos: TodoItem[] = [ + { id: "1", content: "First task", status: "completed" }, + { id: "2", content: "Second task", status: "completed" }, + ] + + mockTask.todoList = completedTodos + + await attemptCompletionTool( + mockTask as Task, + block, + mockAskApproval, + mockHandleError, + mockPushToolResult, + mockRemoveClosingTag, + mockToolDescription, + mockAskFinishSubTaskApproval, + ) + + expect(mockTask.consecutiveMistakeCount).toBe(0) + expect(mockTask.recordToolError).not.toHaveBeenCalled() + }) + + it("should prevent completion when there are pending todos", async () => { + const block: AttemptCompletionToolUse = { + type: "tool_use", + name: "attempt_completion", + params: { result: "Task completed successfully" }, + partial: false, + } + + const todosWithPending: TodoItem[] = [ + { id: "1", content: "First task", status: "completed" }, + { id: "2", content: "Second task", status: "pending" }, + ] + + mockTask.todoList = todosWithPending + + // Enable the setting to prevent completion with open todos + mockGetConfiguration.mockReturnValue({ + get: vi.fn((key: string, defaultValue: any) => { + if (key === "preventCompletionWithOpenTodos") { + return true // Setting is enabled + } + return defaultValue + }), + }) + + await attemptCompletionTool( + mockTask as Task, + block, + mockAskApproval, + mockHandleError, + mockPushToolResult, + mockRemoveClosingTag, + mockToolDescription, + mockAskFinishSubTaskApproval, + ) + + expect(mockTask.consecutiveMistakeCount).toBe(1) + expect(mockTask.recordToolError).toHaveBeenCalledWith("attempt_completion") + expect(mockPushToolResult).toHaveBeenCalledWith( + expect.stringContaining("Cannot complete task while there are incomplete todos"), + ) + }) + + it("should prevent completion when there are in-progress todos", async () => { + const block: AttemptCompletionToolUse = { + type: "tool_use", + name: "attempt_completion", + params: { result: "Task completed successfully" }, + partial: false, + } + + const todosWithInProgress: TodoItem[] = [ + { id: "1", content: "First task", status: "completed" }, + { id: "2", content: "Second task", status: "in_progress" }, + ] + + mockTask.todoList = todosWithInProgress + + // Enable the setting to prevent completion with open todos + mockGetConfiguration.mockReturnValue({ + get: vi.fn((key: string, defaultValue: any) => { + if (key === "preventCompletionWithOpenTodos") { + return true // Setting is enabled + } + return defaultValue + }), + }) + + await attemptCompletionTool( + mockTask as Task, + block, + mockAskApproval, + mockHandleError, + mockPushToolResult, + mockRemoveClosingTag, + mockToolDescription, + mockAskFinishSubTaskApproval, + ) + + expect(mockTask.consecutiveMistakeCount).toBe(1) + expect(mockTask.recordToolError).toHaveBeenCalledWith("attempt_completion") + expect(mockPushToolResult).toHaveBeenCalledWith( + expect.stringContaining("Cannot complete task while there are incomplete todos"), + ) + }) + + it("should prevent completion when there are mixed incomplete todos", async () => { + const block: AttemptCompletionToolUse = { + type: "tool_use", + name: "attempt_completion", + params: { result: "Task completed successfully" }, + partial: false, + } + + const mixedTodos: TodoItem[] = [ + { id: "1", content: "First task", status: "completed" }, + { id: "2", content: "Second task", status: "pending" }, + { id: "3", content: "Third task", status: "in_progress" }, + ] + + mockTask.todoList = mixedTodos + + // Enable the setting to prevent completion with open todos + mockGetConfiguration.mockReturnValue({ + get: vi.fn((key: string, defaultValue: any) => { + if (key === "preventCompletionWithOpenTodos") { + return true // Setting is enabled + } + return defaultValue + }), + }) + + await attemptCompletionTool( + mockTask as Task, + block, + mockAskApproval, + mockHandleError, + mockPushToolResult, + mockRemoveClosingTag, + mockToolDescription, + mockAskFinishSubTaskApproval, + ) + + expect(mockTask.consecutiveMistakeCount).toBe(1) + expect(mockTask.recordToolError).toHaveBeenCalledWith("attempt_completion") + expect(mockPushToolResult).toHaveBeenCalledWith( + expect.stringContaining("Cannot complete task while there are incomplete todos"), + ) + }) + + it("should allow completion when setting is disabled even with incomplete todos", async () => { + const block: AttemptCompletionToolUse = { + type: "tool_use", + name: "attempt_completion", + params: { result: "Task completed successfully" }, + partial: false, + } + + const todosWithPending: TodoItem[] = [ + { id: "1", content: "First task", status: "completed" }, + { id: "2", content: "Second task", status: "pending" }, + ] + + mockTask.todoList = todosWithPending + + // Ensure the setting is disabled (default behavior) + mockGetConfiguration.mockReturnValue({ + get: vi.fn((key: string, defaultValue: any) => { + if (key === "preventCompletionWithOpenTodos") { + return false // Setting is disabled + } + return defaultValue + }), + }) + + await attemptCompletionTool( + mockTask as Task, + block, + mockAskApproval, + mockHandleError, + mockPushToolResult, + mockRemoveClosingTag, + mockToolDescription, + mockAskFinishSubTaskApproval, + ) + + // Should not prevent completion when setting is disabled + expect(mockTask.consecutiveMistakeCount).toBe(0) + expect(mockTask.recordToolError).not.toHaveBeenCalled() + expect(mockPushToolResult).not.toHaveBeenCalledWith( + expect.stringContaining("Cannot complete task while there are incomplete todos"), + ) + }) + + it("should prevent completion when setting is enabled with incomplete todos", async () => { + const block: AttemptCompletionToolUse = { + type: "tool_use", + name: "attempt_completion", + params: { result: "Task completed successfully" }, + partial: false, + } + + const todosWithPending: TodoItem[] = [ + { id: "1", content: "First task", status: "completed" }, + { id: "2", content: "Second task", status: "pending" }, + ] + + mockTask.todoList = todosWithPending + + // Enable the setting + mockGetConfiguration.mockReturnValue({ + get: vi.fn((key: string, defaultValue: any) => { + if (key === "preventCompletionWithOpenTodos") { + return true // Setting is enabled + } + return defaultValue + }), + }) + + await attemptCompletionTool( + mockTask as Task, + block, + mockAskApproval, + mockHandleError, + mockPushToolResult, + mockRemoveClosingTag, + mockToolDescription, + mockAskFinishSubTaskApproval, + ) + + // Should prevent completion when setting is enabled and there are incomplete todos + expect(mockTask.consecutiveMistakeCount).toBe(1) + expect(mockTask.recordToolError).toHaveBeenCalledWith("attempt_completion") + expect(mockPushToolResult).toHaveBeenCalledWith( + expect.stringContaining("Cannot complete task while there are incomplete todos"), + ) + }) + + it("should allow completion when setting is enabled but all todos are completed", async () => { + const block: AttemptCompletionToolUse = { + type: "tool_use", + name: "attempt_completion", + params: { result: "Task completed successfully" }, + partial: false, + } + + const completedTodos: TodoItem[] = [ + { id: "1", content: "First task", status: "completed" }, + { id: "2", content: "Second task", status: "completed" }, + ] + + mockTask.todoList = completedTodos + + // Enable the setting + mockGetConfiguration.mockReturnValue({ + get: vi.fn((key: string, defaultValue: any) => { + if (key === "preventCompletionWithOpenTodos") { + return true // Setting is enabled + } + return defaultValue + }), + }) + + await attemptCompletionTool( + mockTask as Task, + block, + mockAskApproval, + mockHandleError, + mockPushToolResult, + mockRemoveClosingTag, + mockToolDescription, + mockAskFinishSubTaskApproval, + ) + + // Should allow completion when setting is enabled but all todos are completed + expect(mockTask.consecutiveMistakeCount).toBe(0) + expect(mockTask.recordToolError).not.toHaveBeenCalled() + expect(mockPushToolResult).not.toHaveBeenCalledWith( + expect.stringContaining("Cannot complete task while there are incomplete todos"), + ) + }) + }) +}) diff --git a/src/core/tools/__tests__/executeCommandTimeout.integration.spec.ts b/src/core/tools/__tests__/executeCommandTimeout.integration.spec.ts index de98c9df20..b9e0af3a8a 100644 --- a/src/core/tools/__tests__/executeCommandTimeout.integration.spec.ts +++ b/src/core/tools/__tests__/executeCommandTimeout.integration.spec.ts @@ -3,7 +3,7 @@ import * as vscode from "vscode" import * as fs from "fs/promises" -import { executeCommand, ExecuteCommandOptions } from "../executeCommandTool" +import { executeCommand, executeCommandTool, ExecuteCommandOptions } from "../executeCommandTool" import { Task } from "../../task/Task" import { TerminalRegistry } from "../../../integrations/terminal/TerminalRegistry" @@ -17,6 +17,20 @@ vitest.mock("vscode", () => ({ vitest.mock("fs/promises") vitest.mock("../../../integrations/terminal/TerminalRegistry") vitest.mock("../../task/Task") +vitest.mock("../../prompts/responses", () => ({ + formatResponse: { + toolError: vitest.fn((msg) => `Tool Error: ${msg}`), + rooIgnoreError: vitest.fn((msg) => `RooIgnore Error: ${msg}`), + }, +})) +vitest.mock("../../../utils/text-normalization", () => ({ + unescapeHtmlEntities: vitest.fn((text) => text), +})) +vitest.mock("../../../shared/package", () => ({ + Package: { + name: "roo-cline", + }, +})) describe("Command Execution Timeout Integration", () => { let mockTask: any @@ -186,4 +200,213 @@ describe("Command Execution Timeout Integration", () => { expect(result[0]).toBe(false) // Not rejected expect(result[1]).not.toContain("terminated after exceeding") }) + + describe("Command Timeout Allowlist", () => { + let mockBlock: any + let mockAskApproval: any + let mockHandleError: any + let mockPushToolResult: any + let mockRemoveClosingTag: any + + beforeEach(() => { + // Reset mocks for allowlist tests + vitest.clearAllMocks() + ;(fs.access as any).mockResolvedValue(undefined) + ;(TerminalRegistry.getOrCreateTerminal as any).mockResolvedValue(mockTerminal) + + // Mock the executeCommandTool parameters + mockBlock = { + params: { + command: "", + cwd: undefined, + }, + partial: false, + } + + mockAskApproval = vitest.fn().mockResolvedValue(true) // Always approve + mockHandleError = vitest.fn() + mockPushToolResult = vitest.fn() + mockRemoveClosingTag = vitest.fn() + + // Mock task with additional properties needed by executeCommandTool + mockTask = { + cwd: "/test/directory", + terminalProcess: undefined, + providerRef: { + deref: vitest.fn().mockResolvedValue({ + postMessageToWebview: vitest.fn(), + getState: vitest.fn().mockResolvedValue({ + terminalOutputLineLimit: 500, + terminalShellIntegrationDisabled: false, + }), + }), + }, + say: vitest.fn().mockResolvedValue(undefined), + consecutiveMistakeCount: 0, + recordToolError: vitest.fn(), + sayAndCreateMissingParamError: vitest.fn(), + rooIgnoreController: { + validateCommand: vitest.fn().mockReturnValue(null), + }, + lastMessageTs: Date.now(), + ask: vitest.fn(), + didRejectTool: false, + } + }) + + it("should skip timeout for commands in allowlist", async () => { + // Mock VSCode configuration with timeout and allowlist + const mockGetConfiguration = vitest.fn().mockReturnValue({ + get: vitest.fn().mockImplementation((key: string) => { + if (key === "commandExecutionTimeout") return 1 // 1 second timeout + if (key === "commandTimeoutAllowlist") return ["npm", "git"] + return undefined + }), + }) + ;(vscode.workspace.getConfiguration as any).mockReturnValue(mockGetConfiguration()) + + mockBlock.params.command = "npm install" + + // Create a process that would timeout if not allowlisted + const longRunningProcess = new Promise((resolve) => { + setTimeout(resolve, 2000) // 2 seconds, longer than 1 second timeout + }) + mockTerminal.runCommand.mockReturnValue(longRunningProcess) + + await executeCommandTool( + mockTask as Task, + mockBlock, + mockAskApproval, + mockHandleError, + mockPushToolResult, + mockRemoveClosingTag, + ) + + // Should complete successfully without timeout because "npm" is in allowlist + expect(mockPushToolResult).toHaveBeenCalled() + const result = mockPushToolResult.mock.calls[0][0] + expect(result).not.toContain("terminated after exceeding") + }, 3000) + + it("should apply timeout for commands not in allowlist", async () => { + // Mock VSCode configuration with timeout and allowlist + const mockGetConfiguration = vitest.fn().mockReturnValue({ + get: vitest.fn().mockImplementation((key: string) => { + if (key === "commandExecutionTimeout") return 1 // 1 second timeout + if (key === "commandTimeoutAllowlist") return ["npm", "git"] + return undefined + }), + }) + ;(vscode.workspace.getConfiguration as any).mockReturnValue(mockGetConfiguration()) + + mockBlock.params.command = "sleep 10" // Not in allowlist + + // Create a process that never resolves + const neverResolvingProcess = new Promise(() => {}) + ;(neverResolvingProcess as any).abort = vitest.fn() + mockTerminal.runCommand.mockReturnValue(neverResolvingProcess) + + await executeCommandTool( + mockTask as Task, + mockBlock, + mockAskApproval, + mockHandleError, + mockPushToolResult, + mockRemoveClosingTag, + ) + + // Should timeout because "sleep" is not in allowlist + expect(mockPushToolResult).toHaveBeenCalled() + const result = mockPushToolResult.mock.calls[0][0] + expect(result).toContain("terminated after exceeding") + }, 3000) + + it("should handle empty allowlist", async () => { + // Mock VSCode configuration with timeout and empty allowlist + const mockGetConfiguration = vitest.fn().mockReturnValue({ + get: vitest.fn().mockImplementation((key: string) => { + if (key === "commandExecutionTimeout") return 1 // 1 second timeout + if (key === "commandTimeoutAllowlist") return [] + return undefined + }), + }) + ;(vscode.workspace.getConfiguration as any).mockReturnValue(mockGetConfiguration()) + + mockBlock.params.command = "npm install" + + // Create a process that never resolves + const neverResolvingProcess = new Promise(() => {}) + ;(neverResolvingProcess as any).abort = vitest.fn() + mockTerminal.runCommand.mockReturnValue(neverResolvingProcess) + + await executeCommandTool( + mockTask as Task, + mockBlock, + mockAskApproval, + mockHandleError, + mockPushToolResult, + mockRemoveClosingTag, + ) + + // Should timeout because allowlist is empty + expect(mockPushToolResult).toHaveBeenCalled() + const result = mockPushToolResult.mock.calls[0][0] + expect(result).toContain("terminated after exceeding") + }, 3000) + + it("should match command prefixes correctly", async () => { + // Mock VSCode configuration with timeout and allowlist + const mockGetConfiguration = vitest.fn().mockReturnValue({ + get: vitest.fn().mockImplementation((key: string) => { + if (key === "commandExecutionTimeout") return 1 // 1 second timeout + if (key === "commandTimeoutAllowlist") return ["git log", "npm run"] + return undefined + }), + }) + ;(vscode.workspace.getConfiguration as any).mockReturnValue(mockGetConfiguration()) + + const longRunningProcess = new Promise((resolve) => { + setTimeout(resolve, 2000) // 2 seconds + }) + const neverResolvingProcess = new Promise(() => {}) + ;(neverResolvingProcess as any).abort = vitest.fn() + + // Test exact prefix match - should not timeout + mockBlock.params.command = "git log --oneline" + mockTerminal.runCommand.mockReturnValueOnce(longRunningProcess) + + await executeCommandTool( + mockTask as Task, + mockBlock, + mockAskApproval, + mockHandleError, + mockPushToolResult, + mockRemoveClosingTag, + ) + + expect(mockPushToolResult).toHaveBeenCalled() + const result1 = mockPushToolResult.mock.calls[0][0] + expect(result1).not.toContain("terminated after exceeding") + + // Reset mocks for second test + mockPushToolResult.mockClear() + + // Test partial prefix match (should not match) - should timeout + mockBlock.params.command = "git status" // "git" alone is not in allowlist, only "git log" + mockTerminal.runCommand.mockReturnValueOnce(neverResolvingProcess) + + await executeCommandTool( + mockTask as Task, + mockBlock, + mockAskApproval, + mockHandleError, + mockPushToolResult, + mockRemoveClosingTag, + ) + + expect(mockPushToolResult).toHaveBeenCalled() + const result2 = mockPushToolResult.mock.calls[0][0] + expect(result2).toContain("terminated after exceeding") + }, 5000) + }) }) diff --git a/src/core/tools/__tests__/insertContentTool.spec.ts b/src/core/tools/__tests__/insertContentTool.spec.ts index c980ee17ec..e23d7aaa33 100644 --- a/src/core/tools/__tests__/insertContentTool.spec.ts +++ b/src/core/tools/__tests__/insertContentTool.spec.ts @@ -71,6 +71,14 @@ describe("insertContentTool", () => { cwd: "/", consecutiveMistakeCount: 0, didEditFile: false, + providerRef: { + deref: vi.fn().mockReturnValue({ + getState: vi.fn().mockResolvedValue({ + diagnosticsEnabled: true, + writeDelayMs: 1000, + }), + }), + }, rooIgnoreController: { validateAccess: vi.fn().mockReturnValue(true), }, diff --git a/src/core/tools/__tests__/writeToFileTool.spec.ts b/src/core/tools/__tests__/writeToFileTool.spec.ts index f223d4b0fc..1b8582c9cc 100644 --- a/src/core/tools/__tests__/writeToFileTool.spec.ts +++ b/src/core/tools/__tests__/writeToFileTool.spec.ts @@ -132,6 +132,14 @@ describe("writeToFileTool", () => { mockCline.consecutiveMistakeCount = 0 mockCline.didEditFile = false mockCline.diffStrategy = undefined + mockCline.providerRef = { + deref: vi.fn().mockReturnValue({ + getState: vi.fn().mockResolvedValue({ + diagnosticsEnabled: true, + writeDelayMs: 1000, + }), + }), + } mockCline.rooIgnoreController = { validateAccess: vi.fn().mockReturnValue(true), } @@ -376,7 +384,7 @@ describe("writeToFileTool", () => { userEdits: userEditsValue, finalContent: "modified content", }) - // Manually set the property on the mock instance because the original saveChanges is not called + // Set the userEdits property on the diffViewProvider mock to simulate user edits mockCline.diffViewProvider.userEdits = userEditsValue await executeWriteFileTool({}, { fileExists: true }) diff --git a/src/core/tools/applyDiffTool.ts b/src/core/tools/applyDiffTool.ts index f5b4ab7dd3..ad4bb0590f 100644 --- a/src/core/tools/applyDiffTool.ts +++ b/src/core/tools/applyDiffTool.ts @@ -2,6 +2,7 @@ import path from "path" import fs from "fs/promises" import { TelemetryService } from "@roo-code/telemetry" +import { DEFAULT_WRITE_DELAY_MS } from "@roo-code/types" import { ClineSayTool } from "../../shared/ExtensionMessage" import { getReadablePath } from "../../utils/path" @@ -170,7 +171,11 @@ export async function applyDiffToolLegacy( } // Call saveChanges to update the DiffViewProvider properties - await cline.diffViewProvider.saveChanges() + const provider = cline.providerRef.deref() + const state = await provider?.getState() + const diagnosticsEnabled = state?.diagnosticsEnabled ?? true + const writeDelayMs = state?.writeDelayMs ?? DEFAULT_WRITE_DELAY_MS + await cline.diffViewProvider.saveChanges(diagnosticsEnabled, writeDelayMs) // Track file edit operation if (relPath) { diff --git a/src/core/tools/attemptCompletionTool.ts b/src/core/tools/attemptCompletionTool.ts index 57f5870022..ef7881854f 100644 --- a/src/core/tools/attemptCompletionTool.ts +++ b/src/core/tools/attemptCompletionTool.ts @@ -1,4 +1,5 @@ import Anthropic from "@anthropic-ai/sdk" +import * as vscode from "vscode" import { TelemetryService } from "@roo-code/telemetry" @@ -14,6 +15,7 @@ import { AskFinishSubTaskApproval, } from "../../shared/tools" import { formatResponse } from "../prompts/responses" +import { Package } from "../../shared/package" export async function attemptCompletionTool( cline: Task, @@ -28,6 +30,25 @@ export async function attemptCompletionTool( const result: string | undefined = block.params.result const command: string | undefined = block.params.command + // Get the setting for preventing completion with open todos from VSCode configuration + const preventCompletionWithOpenTodos = vscode.workspace + .getConfiguration(Package.name) + .get("preventCompletionWithOpenTodos", false) + + // Check if there are incomplete todos (only if the setting is enabled) + const hasIncompleteTodos = cline.todoList && cline.todoList.some((todo) => todo.status !== "completed") + + if (preventCompletionWithOpenTodos && hasIncompleteTodos) { + cline.consecutiveMistakeCount++ + cline.recordToolError("attempt_completion") + pushToolResult( + formatResponse.toolError( + "Cannot complete task while there are incomplete todos. Please finish all todos before attempting completion.", + ), + ) + return + } + try { const lastMessage = cline.clineMessages.at(-1) diff --git a/src/core/tools/executeCommandTool.ts b/src/core/tools/executeCommandTool.ts index 407dc283b5..e895701721 100644 --- a/src/core/tools/executeCommandTool.ts +++ b/src/core/tools/executeCommandTool.ts @@ -70,8 +70,16 @@ export async function executeCommandTool( .getConfiguration(Package.name) .get("commandExecutionTimeout", 0) - // Convert seconds to milliseconds for internal use - const commandExecutionTimeout = commandExecutionTimeoutSeconds * 1000 + // Get command timeout allowlist from VSCode configuration + const commandTimeoutAllowlist = vscode.workspace + .getConfiguration(Package.name) + .get("commandTimeoutAllowlist", []) + + // Check if command matches any prefix in the allowlist + const isCommandAllowlisted = commandTimeoutAllowlist.some((prefix) => command!.startsWith(prefix.trim())) + + // Convert seconds to milliseconds for internal use, but skip timeout if command is allowlisted + const commandExecutionTimeout = isCommandAllowlisted ? 0 : commandExecutionTimeoutSeconds * 1000 const options: ExecuteCommandOptions = { executionId, diff --git a/src/core/tools/insertContentTool.ts b/src/core/tools/insertContentTool.ts index b76769fcf0..2b31224400 100644 --- a/src/core/tools/insertContentTool.ts +++ b/src/core/tools/insertContentTool.ts @@ -10,6 +10,7 @@ import { ClineSayTool } from "../../shared/ExtensionMessage" import { RecordSource } from "../context-tracking/FileContextTrackerTypes" import { fileExistsAtPath } from "../../utils/fs" import { insertGroups } from "../diff/insert-groups" +import { DEFAULT_WRITE_DELAY_MS } from "@roo-code/types" export async function insertContentTool( cline: Task, @@ -155,7 +156,11 @@ export async function insertContentTool( } // Call saveChanges to update the DiffViewProvider properties - await cline.diffViewProvider.saveChanges() + const provider = cline.providerRef.deref() + const state = await provider?.getState() + const diagnosticsEnabled = state?.diagnosticsEnabled ?? true + const writeDelayMs = state?.writeDelayMs ?? DEFAULT_WRITE_DELAY_MS + await cline.diffViewProvider.saveChanges(diagnosticsEnabled, writeDelayMs) // Track file edit operation if (relPath) { diff --git a/src/core/tools/multiApplyDiffTool.ts b/src/core/tools/multiApplyDiffTool.ts index 8057f77949..b41d409dbb 100644 --- a/src/core/tools/multiApplyDiffTool.ts +++ b/src/core/tools/multiApplyDiffTool.ts @@ -2,6 +2,7 @@ import path from "path" import fs from "fs/promises" import { TelemetryService } from "@roo-code/telemetry" +import { DEFAULT_WRITE_DELAY_MS } from "@roo-code/types" import { ClineSayTool } from "../../shared/ExtensionMessage" import { getReadablePath } from "../../utils/path" @@ -553,7 +554,11 @@ ${errorDetails ? `\nTechnical details:\n${errorDetails}\n` : ""} } // Call saveChanges to update the DiffViewProvider properties - await cline.diffViewProvider.saveChanges() + const provider = cline.providerRef.deref() + const state = await provider?.getState() + const diagnosticsEnabled = state?.diagnosticsEnabled ?? true + const writeDelayMs = state?.writeDelayMs ?? DEFAULT_WRITE_DELAY_MS + await cline.diffViewProvider.saveChanges(diagnosticsEnabled, writeDelayMs) // Track file edit operation await cline.fileContextTracker.trackFileContext(relPath, "roo_edited" as RecordSource) diff --git a/src/core/tools/searchAndReplaceTool.ts b/src/core/tools/searchAndReplaceTool.ts index 967d5339ba..b6ec3ed39b 100644 --- a/src/core/tools/searchAndReplaceTool.ts +++ b/src/core/tools/searchAndReplaceTool.ts @@ -11,6 +11,7 @@ import { ClineSayTool } from "../../shared/ExtensionMessage" import { getReadablePath } from "../../utils/path" import { fileExistsAtPath } from "../../utils/fs" import { RecordSource } from "../context-tracking/FileContextTrackerTypes" +import { DEFAULT_WRITE_DELAY_MS } from "@roo-code/types" /** * Tool for performing search and replace operations on files @@ -227,7 +228,11 @@ export async function searchAndReplaceTool( } // Call saveChanges to update the DiffViewProvider properties - await cline.diffViewProvider.saveChanges() + const provider = cline.providerRef.deref() + const state = await provider?.getState() + const diagnosticsEnabled = state?.diagnosticsEnabled ?? true + const writeDelayMs = state?.writeDelayMs ?? DEFAULT_WRITE_DELAY_MS + await cline.diffViewProvider.saveChanges(diagnosticsEnabled, writeDelayMs) // Track file edit operation if (relPath) { diff --git a/src/core/tools/writeToFileTool.ts b/src/core/tools/writeToFileTool.ts index 84f8ef807e..fd9d158f3f 100644 --- a/src/core/tools/writeToFileTool.ts +++ b/src/core/tools/writeToFileTool.ts @@ -13,6 +13,7 @@ import { getReadablePath } from "../../utils/path" import { isPathOutsideWorkspace } from "../../utils/pathUtils" import { detectCodeOmission } from "../../integrations/editor/detect-omission" import { unescapeHtmlEntities } from "../../utils/text-normalization" +import { DEFAULT_WRITE_DELAY_MS } from "@roo-code/types" export async function writeToFileTool( cline: Task, @@ -213,7 +214,11 @@ export async function writeToFileTool( } // Call saveChanges to update the DiffViewProvider properties - await cline.diffViewProvider.saveChanges() + const provider = cline.providerRef.deref() + const state = await provider?.getState() + const diagnosticsEnabled = state?.diagnosticsEnabled ?? true + const writeDelayMs = state?.writeDelayMs ?? DEFAULT_WRITE_DELAY_MS + await cline.diffViewProvider.saveChanges(diagnosticsEnabled, writeDelayMs) // Track file edit operation if (relPath) { diff --git a/src/core/webview/ClineProvider.ts b/src/core/webview/ClineProvider.ts index 3b240f3de2..6224291a4f 100644 --- a/src/core/webview/ClineProvider.ts +++ b/src/core/webview/ClineProvider.ts @@ -42,6 +42,7 @@ import { ExtensionMessage, MarketplaceInstalledMetadata } from "../../shared/Ext import { Mode, defaultModeSlug } from "../../shared/modes" import { experimentDefault, experiments, EXPERIMENT_IDS } from "../../shared/experiments" import { formatLanguage } from "../../shared/language" +import { DEFAULT_WRITE_DELAY_MS } from "@roo-code/types" import { Terminal } from "../../integrations/terminal/Terminal" import { downloadTask } from "../../integrations/misc/export-markdown" import { getTheme } from "../../integrations/theme/getTheme" @@ -1569,6 +1570,7 @@ export class ClineProvider profileThresholds, alwaysAllowFollowupQuestions, followupAutoApproveTimeoutMs, + diagnosticsEnabled, } = await this.getState() const telemetryKey = process.env.POSTHOG_API_KEY @@ -1622,7 +1624,7 @@ export class ClineProvider remoteBrowserHost, remoteBrowserEnabled: remoteBrowserEnabled ?? false, cachedChromeHostUrl: cachedChromeHostUrl, - writeDelayMs: writeDelayMs ?? 1000, + writeDelayMs: writeDelayMs ?? DEFAULT_WRITE_DELAY_MS, terminalOutputLineLimit: terminalOutputLineLimit ?? 500, terminalShellIntegrationTimeout: terminalShellIntegrationTimeout ?? Terminal.defaultShellIntegrationTimeout, terminalShellIntegrationDisabled: terminalShellIntegrationDisabled ?? false, @@ -1688,6 +1690,7 @@ export class ClineProvider hasOpenedModeSelector: this.getGlobalState("hasOpenedModeSelector") ?? false, alwaysAllowFollowupQuestions: alwaysAllowFollowupQuestions ?? false, followupAutoApproveTimeoutMs: followupAutoApproveTimeoutMs ?? 60000, + diagnosticsEnabled: diagnosticsEnabled ?? true, } } @@ -1771,6 +1774,7 @@ export class ClineProvider alwaysAllowFollowupQuestions: stateValues.alwaysAllowFollowupQuestions ?? false, alwaysAllowUpdateTodoList: stateValues.alwaysAllowUpdateTodoList ?? false, followupAutoApproveTimeoutMs: stateValues.followupAutoApproveTimeoutMs ?? 60000, + diagnosticsEnabled: stateValues.diagnosticsEnabled ?? true, allowedMaxRequests: stateValues.allowedMaxRequests, autoCondenseContext: stateValues.autoCondenseContext ?? true, autoCondenseContextPercent: stateValues.autoCondenseContextPercent ?? 100, @@ -1789,7 +1793,7 @@ export class ClineProvider remoteBrowserEnabled: stateValues.remoteBrowserEnabled ?? false, cachedChromeHostUrl: stateValues.cachedChromeHostUrl as string | undefined, fuzzyMatchThreshold: stateValues.fuzzyMatchThreshold ?? 1.0, - writeDelayMs: stateValues.writeDelayMs ?? 1000, + writeDelayMs: stateValues.writeDelayMs ?? DEFAULT_WRITE_DELAY_MS, terminalOutputLineLimit: stateValues.terminalOutputLineLimit ?? 500, terminalShellIntegrationTimeout: stateValues.terminalShellIntegrationTimeout ?? Terminal.defaultShellIntegrationTimeout, diff --git a/src/core/webview/__tests__/ClineProvider.spec.ts b/src/core/webview/__tests__/ClineProvider.spec.ts index 15401ff8d6..2bab73fec0 100644 --- a/src/core/webview/__tests__/ClineProvider.spec.ts +++ b/src/core/webview/__tests__/ClineProvider.spec.ts @@ -546,6 +546,7 @@ describe("ClineProvider", () => { sharingEnabled: false, profileThresholds: {}, hasOpenedModeSelector: false, + diagnosticsEnabled: true, } const message: ExtensionMessage = { diff --git a/src/core/webview/webviewMessageHandler.ts b/src/core/webview/webviewMessageHandler.ts index 51252a1efe..85106ba2ca 100644 --- a/src/core/webview/webviewMessageHandler.ts +++ b/src/core/webview/webviewMessageHandler.ts @@ -1216,6 +1216,10 @@ export const webviewMessageHandler = async ( await updateGlobalState("writeDelayMs", message.value) await provider.postStateToWebview() break + case "diagnosticsEnabled": + await updateGlobalState("diagnosticsEnabled", message.bool ?? true) + await provider.postStateToWebview() + break case "terminalOutputLineLimit": await updateGlobalState("terminalOutputLineLimit", message.value) await provider.postStateToWebview() diff --git a/src/extension/api.ts b/src/extension/api.ts index 3bb538dcb3..7027cb963a 100644 --- a/src/extension/api.ts +++ b/src/extension/api.ts @@ -2,6 +2,7 @@ import { EventEmitter } from "events" import * as vscode from "vscode" import fs from "fs/promises" import * as path from "path" +import * as os from "os" import { RooCodeAPI, @@ -50,7 +51,7 @@ export class API extends EventEmitter implements RooCodeAPI { console.log(args) } - this.logfile = path.join(getWorkspacePath(), "roo-code-messages.log") + this.logfile = path.join(os.tmpdir(), "roo-code-messages.log") } else { this.log = () => {} } @@ -125,6 +126,22 @@ export class API extends EventEmitter implements RooCodeAPI { .getConfiguration(Package.name) .update("allowedCommands", configuration.allowedCommands, vscode.ConfigurationTarget.Global) } + + if (configuration.deniedCommands) { + await vscode.workspace + .getConfiguration(Package.name) + .update("deniedCommands", configuration.deniedCommands, vscode.ConfigurationTarget.Global) + } + + if (configuration.commandExecutionTimeout !== undefined) { + await vscode.workspace + .getConfiguration(Package.name) + .update( + "commandExecutionTimeout", + configuration.commandExecutionTimeout, + vscode.ConfigurationTarget.Global, + ) + } } await provider.removeClineFromStack() @@ -223,9 +240,11 @@ export class API extends EventEmitter implements RooCodeAPI { cline.on("taskCompleted", async (_, tokenUsage, toolUsage) => { let isSubtask = false + if (cline.rootTask != undefined) { isSubtask = true } + this.emit(RooCodeEventName.TaskCompleted, cline.taskId, tokenUsage, toolUsage, { isSubtask: isSubtask }) this.taskMap.delete(cline.taskId) diff --git a/src/i18n/locales/ca/common.json b/src/i18n/locales/ca/common.json index 772156286e..633208d4bc 100644 --- a/src/i18n/locales/ca/common.json +++ b/src/i18n/locales/ca/common.json @@ -166,5 +166,10 @@ "descriptionNoRules": "Esteu segur que voleu suprimir aquest mode personalitzat?", "confirm": "Suprimeix" } + }, + "commands": { + "preventCompletionWithOpenTodos": { + "description": "Evitar la finalització de tasques quan hi ha todos incomplets a la llista de todos" + } } } diff --git a/src/i18n/locales/de/common.json b/src/i18n/locales/de/common.json index c136fba809..71155b1ebe 100644 --- a/src/i18n/locales/de/common.json +++ b/src/i18n/locales/de/common.json @@ -166,5 +166,10 @@ "descriptionNoRules": "Bist du sicher, dass du diesen benutzerdefinierten Modus löschen möchtest?", "confirm": "Löschen" } + }, + "commands": { + "preventCompletionWithOpenTodos": { + "description": "Aufgabenabschluss verhindern, wenn unvollständige Todos in der Todo-Liste vorhanden sind" + } } } diff --git a/src/i18n/locales/en/common.json b/src/i18n/locales/en/common.json index b0fdb9d8df..6bab0ab9a9 100644 --- a/src/i18n/locales/en/common.json +++ b/src/i18n/locales/en/common.json @@ -155,5 +155,10 @@ "descriptionNoRules": "Are you sure you want to delete this custom mode?", "confirm": "Delete" } + }, + "commands": { + "preventCompletionWithOpenTodos": { + "description": "Prevent task completion when there are incomplete todos in the todo list" + } } } diff --git a/src/i18n/locales/es/common.json b/src/i18n/locales/es/common.json index 39cf48383e..d307800c79 100644 --- a/src/i18n/locales/es/common.json +++ b/src/i18n/locales/es/common.json @@ -166,5 +166,10 @@ "descriptionNoRules": "¿Estás seguro de que quieres eliminar este modo personalizado?", "confirm": "Eliminar" } + }, + "commands": { + "preventCompletionWithOpenTodos": { + "description": "Prevenir la finalización de tareas cuando hay todos incompletos en la lista de todos" + } } } diff --git a/src/i18n/locales/fr/common.json b/src/i18n/locales/fr/common.json index ace5bbe47a..b0571e3714 100644 --- a/src/i18n/locales/fr/common.json +++ b/src/i18n/locales/fr/common.json @@ -166,5 +166,10 @@ "descriptionNoRules": "Êtes-vous sûr de vouloir supprimer ce mode personnalisé ?", "confirm": "Supprimer" } + }, + "commands": { + "preventCompletionWithOpenTodos": { + "description": "Empêcher la finalisation des tâches lorsqu'il y a des todos incomplets dans la liste de todos" + } } } diff --git a/src/i18n/locales/hi/common.json b/src/i18n/locales/hi/common.json index 84dbe9052a..ca4efea535 100644 --- a/src/i18n/locales/hi/common.json +++ b/src/i18n/locales/hi/common.json @@ -166,5 +166,10 @@ "descriptionNoRules": "क्या आप वाकई इस कस्टम मोड को हटाना चाहते हैं?", "confirm": "हटाएं" } + }, + "commands": { + "preventCompletionWithOpenTodos": { + "description": "जब टूडू सूची में अधूरे टूडू हों तो कार्य पूर्ण होने से रोकें" + } } } diff --git a/src/i18n/locales/id/common.json b/src/i18n/locales/id/common.json index fb2a30994e..46ce587e61 100644 --- a/src/i18n/locales/id/common.json +++ b/src/i18n/locales/id/common.json @@ -166,5 +166,10 @@ "descriptionNoRules": "Anda yakin ingin menghapus mode kustom ini?", "confirm": "Hapus" } + }, + "commands": { + "preventCompletionWithOpenTodos": { + "description": "Mencegah penyelesaian tugas ketika ada todo yang belum selesai dalam daftar todo" + } } } diff --git a/src/i18n/locales/it/common.json b/src/i18n/locales/it/common.json index 4681612e9d..11bae26eb3 100644 --- a/src/i18n/locales/it/common.json +++ b/src/i18n/locales/it/common.json @@ -166,5 +166,10 @@ "descriptionNoRules": "Sei sicuro di voler eliminare questa modalità personalizzata?", "confirm": "Elimina" } + }, + "commands": { + "preventCompletionWithOpenTodos": { + "description": "Impedire il completamento delle attività quando ci sono todo incompleti nella lista dei todo" + } } } diff --git a/src/i18n/locales/ja/common.json b/src/i18n/locales/ja/common.json index 38fc9d27c5..52ab094633 100644 --- a/src/i18n/locales/ja/common.json +++ b/src/i18n/locales/ja/common.json @@ -166,5 +166,10 @@ "descriptionNoRules": "このカスタムモードを削除してもよろしいですか？", "confirm": "削除" } + }, + "commands": { + "preventCompletionWithOpenTodos": { + "description": "Todoリストに未完了のTodoがある場合、タスクの完了を防ぐ" + } } } diff --git a/src/i18n/locales/ko/common.json b/src/i18n/locales/ko/common.json index d76a82a7c2..63566f946b 100644 --- a/src/i18n/locales/ko/common.json +++ b/src/i18n/locales/ko/common.json @@ -166,5 +166,10 @@ "descriptionNoRules": "이 사용자 정의 모드를 삭제하시겠습니까?", "confirm": "삭제" } + }, + "commands": { + "preventCompletionWithOpenTodos": { + "description": "할 일 목록에 미완료된 할 일이 있을 때 작업 완료를 방지" + } } } diff --git a/src/i18n/locales/nl/common.json b/src/i18n/locales/nl/common.json index 5caa0534ee..fc3c1ce018 100644 --- a/src/i18n/locales/nl/common.json +++ b/src/i18n/locales/nl/common.json @@ -166,5 +166,10 @@ "descriptionNoRules": "Weet je zeker dat je deze aangepaste modus wilt verwijderen?", "confirm": "Verwijderen" } + }, + "commands": { + "preventCompletionWithOpenTodos": { + "description": "Voorkom taakafronding wanneer er onvolledige todos in de todolijst staan" + } } } diff --git a/src/i18n/locales/pl/common.json b/src/i18n/locales/pl/common.json index 77008aa0ab..ef756ec1ce 100644 --- a/src/i18n/locales/pl/common.json +++ b/src/i18n/locales/pl/common.json @@ -166,5 +166,10 @@ "descriptionNoRules": "Czy na pewno chcesz usunąć ten tryb niestandardowy?", "confirm": "Usuń" } + }, + "commands": { + "preventCompletionWithOpenTodos": { + "description": "Zapobiegaj ukończeniu zadania gdy na liście zadań są nieukończone zadania" + } } } diff --git a/src/i18n/locales/pt-BR/common.json b/src/i18n/locales/pt-BR/common.json index 6f63d9d1ed..8856e541be 100644 --- a/src/i18n/locales/pt-BR/common.json +++ b/src/i18n/locales/pt-BR/common.json @@ -166,5 +166,10 @@ "descriptionNoRules": "Tem certeza de que deseja excluir este modo personalizado?", "confirm": "Excluir" } + }, + "commands": { + "preventCompletionWithOpenTodos": { + "description": "Impedir a conclusão de tarefas quando há todos incompletos na lista de todos" + } } } diff --git a/src/i18n/locales/ru/common.json b/src/i18n/locales/ru/common.json index 4e354bcbc5..fd23dffe2a 100644 --- a/src/i18n/locales/ru/common.json +++ b/src/i18n/locales/ru/common.json @@ -166,5 +166,10 @@ "descriptionNoRules": "Вы уверены, что хотите удалить этот пользовательский режим?", "confirm": "Удалить" } + }, + "commands": { + "preventCompletionWithOpenTodos": { + "description": "Предотвратить завершение задач при наличии незавершенных дел в списке дел" + } } } diff --git a/src/i18n/locales/tr/common.json b/src/i18n/locales/tr/common.json index 5de82d00c6..9eeae720ef 100644 --- a/src/i18n/locales/tr/common.json +++ b/src/i18n/locales/tr/common.json @@ -166,5 +166,10 @@ "descriptionNoRules": "Bu özel modu silmek istediğinizden emin misiniz?", "confirm": "Sil" } + }, + "commands": { + "preventCompletionWithOpenTodos": { + "description": "Todo listesinde tamamlanmamış todolar olduğunda görev tamamlanmasını engelle" + } } } diff --git a/src/i18n/locales/vi/common.json b/src/i18n/locales/vi/common.json index 014bddda58..bd66d623bb 100644 --- a/src/i18n/locales/vi/common.json +++ b/src/i18n/locales/vi/common.json @@ -173,5 +173,10 @@ "descriptionNoRules": "Bạn có chắc chắn muốn xóa chế độ tùy chỉnh này không?", "confirm": "Xóa" } + }, + "commands": { + "preventCompletionWithOpenTodos": { + "description": "Ngăn chặn hoàn thành nhiệm vụ khi có các todo chưa hoàn thành trong danh sách todo" + } } } diff --git a/src/i18n/locales/zh-CN/common.json b/src/i18n/locales/zh-CN/common.json index 268ee5fbb1..515ee7d048 100644 --- a/src/i18n/locales/zh-CN/common.json +++ b/src/i18n/locales/zh-CN/common.json @@ -171,5 +171,10 @@ "descriptionNoRules": "您确定要删除此自定义模式吗？", "confirm": "删除" } + }, + "commands": { + "preventCompletionWithOpenTodos": { + "description": "当待办事项列表中有未完成的待办事项时阻止任务完成" + } } } diff --git a/src/i18n/locales/zh-TW/common.json b/src/i18n/locales/zh-TW/common.json index dec20a1f9a..cceb53e5f3 100644 --- a/src/i18n/locales/zh-TW/common.json +++ b/src/i18n/locales/zh-TW/common.json @@ -166,5 +166,10 @@ "descriptionNoRules": "您確定要刪除此自訂模式嗎？", "confirm": "刪除" } + }, + "commands": { + "preventCompletionWithOpenTodos": { + "description": "當待辦事項清單中有未完成的待辦事項時阻止工作完成" + } } } diff --git a/src/integrations/editor/DiffViewProvider.ts b/src/integrations/editor/DiffViewProvider.ts index 225e076297..f4133029c9 100644 --- a/src/integrations/editor/DiffViewProvider.ts +++ b/src/integrations/editor/DiffViewProvider.ts @@ -4,6 +4,7 @@ import * as fs from "fs/promises" import * as diff from "diff" import stripBom from "strip-bom" import { XMLBuilder } from "fast-xml-parser" +import delay from "delay" import { createDirectoriesForFile } from "../../utils/fs" import { arePathsEqual, getReadablePath } from "../../utils/path" @@ -11,6 +12,7 @@ import { formatResponse } from "../../core/prompts/responses" import { diagnosticsToProblemsString, getNewDiagnostics } from "../diagnostics" import { ClineSayTool } from "../../shared/ExtensionMessage" import { Task } from "../../core/task/Task" +import { DEFAULT_WRITE_DELAY_MS } from "@roo-code/types" import { DecorationController } from "./DecorationController" @@ -179,7 +181,7 @@ export class DiffViewProvider { } } - async saveChanges(): Promise<{ + async saveChanges(diagnosticsEnabled: boolean = true, writeDelayMs: number = DEFAULT_WRITE_DELAY_MS): Promise<{ newProblemsMessage: string | undefined userEdits: string | undefined finalContent: string | undefined @@ -214,18 +216,35 @@ export class DiffViewProvider { // and can address them accordingly. If problems don't change immediately after // applying a fix, won't be notified, which is generally fine since the // initial fix is usually correct and it may just take time for linters to catch up. - const postDiagnostics = vscode.languages.getDiagnostics() + + let newProblemsMessage = "" + + if (diagnosticsEnabled) { + // Add configurable delay to allow linters time to process and clean up issues + // like unused imports (especially important for Go and other languages) + // Ensure delay is non-negative + const safeDelayMs = Math.max(0, writeDelayMs) + + try { + await delay(safeDelayMs) + } catch (error) { + // Log error but continue - delay failure shouldn't break the save operation + console.warn(`Failed to apply write delay: ${error}`) + } + + const postDiagnostics = vscode.languages.getDiagnostics() - const newProblems = await diagnosticsToProblemsString( - getNewDiagnostics(this.preDiagnostics, postDiagnostics), - [ - vscode.DiagnosticSeverity.Error, // only including errors since warnings can be distracting (if user wants to fix warnings they can use the @problems mention) - ], - this.cwd, - ) // Will be empty string if no errors. + const newProblems = await diagnosticsToProblemsString( + getNewDiagnostics(this.preDiagnostics, postDiagnostics), + [ + vscode.DiagnosticSeverity.Error, // only including errors since warnings can be distracting (if user wants to fix warnings they can use the @problems mention) + ], + this.cwd, + ) // Will be empty string if no errors. - const newProblemsMessage = - newProblems.length > 0 ? `\n\nNew problems detected after saving the file:\n${newProblems}` : "" + newProblemsMessage = + newProblems.length > 0 ? `\n\nNew problems detected after saving the file:\n${newProblems}` : "" + } // If the edited content has different EOL characters, we don't want to // show a diff with all the EOL differences. diff --git a/src/integrations/editor/__tests__/DiffViewProvider.spec.ts b/src/integrations/editor/__tests__/DiffViewProvider.spec.ts index ad1950345b..a4aded95bb 100644 --- a/src/integrations/editor/__tests__/DiffViewProvider.spec.ts +++ b/src/integrations/editor/__tests__/DiffViewProvider.spec.ts @@ -1,6 +1,12 @@ import { DiffViewProvider, DIFF_VIEW_URI_SCHEME, DIFF_VIEW_LABEL_CHANGES } from "../DiffViewProvider" import * as vscode from "vscode" import * as path from "path" +import delay from "delay" + +// Mock delay +vi.mock("delay", () => ({ + default: vi.fn().mockResolvedValue(undefined), +})) // Mock fs/promises vi.mock("fs/promises", () => ({ @@ -45,6 +51,12 @@ vi.mock("vscode", () => ({ languages: { getDiagnostics: vi.fn(() => []), }, + DiagnosticSeverity: { + Error: 0, + Warning: 1, + Information: 2, + Hint: 3, + }, WorkspaceEdit: vi.fn().mockImplementation(() => ({ replace: vi.fn(), delete: vi.fn(), @@ -327,4 +339,83 @@ describe("DiffViewProvider", () => { ).toBeUndefined() }) }) + + describe("saveChanges method with diagnostic settings", () => { + beforeEach(() => { + // Setup common mocks for saveChanges tests + ;(diffViewProvider as any).relPath = "test.ts" + ;(diffViewProvider as any).newContent = "new content" + ;(diffViewProvider as any).activeDiffEditor = { + document: { + getText: vi.fn().mockReturnValue("new content"), + isDirty: false, + save: vi.fn().mockResolvedValue(undefined), + }, + } + ;(diffViewProvider as any).preDiagnostics = [] + + // Mock vscode functions + vi.mocked(vscode.window.showTextDocument).mockResolvedValue({} as any) + vi.mocked(vscode.languages.getDiagnostics).mockReturnValue([]) + }) + + it("should apply diagnostic delay when diagnosticsEnabled is true", async () => { + const mockDelay = vi.mocked(delay) + mockDelay.mockClear() + + // Mock closeAllDiffViews + ;(diffViewProvider as any).closeAllDiffViews = vi.fn().mockResolvedValue(undefined) + + const result = await diffViewProvider.saveChanges(true, 3000) + + // Verify delay was called with correct duration + expect(mockDelay).toHaveBeenCalledWith(3000) + expect(vscode.languages.getDiagnostics).toHaveBeenCalled() + expect(result.newProblemsMessage).toBe("") + }) + + it("should skip diagnostics when diagnosticsEnabled is false", async () => { + const mockDelay = vi.mocked(delay) + mockDelay.mockClear() + + // Mock closeAllDiffViews + ;(diffViewProvider as any).closeAllDiffViews = vi.fn().mockResolvedValue(undefined) + + const result = await diffViewProvider.saveChanges(false, 2000) + + // Verify delay was NOT called and diagnostics were NOT checked + expect(mockDelay).not.toHaveBeenCalled() + expect(vscode.languages.getDiagnostics).not.toHaveBeenCalled() + expect(result.newProblemsMessage).toBe("") + }) + + it("should use default values when no parameters provided", async () => { + const mockDelay = vi.mocked(delay) + mockDelay.mockClear() + + // Mock closeAllDiffViews + ;(diffViewProvider as any).closeAllDiffViews = vi.fn().mockResolvedValue(undefined) + + const result = await diffViewProvider.saveChanges() + + // Verify default behavior (enabled=true, delay=2000ms) + expect(mockDelay).toHaveBeenCalledWith(1000) + expect(vscode.languages.getDiagnostics).toHaveBeenCalled() + expect(result.newProblemsMessage).toBe("") + }) + + it("should handle custom delay values", async () => { + const mockDelay = vi.mocked(delay) + mockDelay.mockClear() + + // Mock closeAllDiffViews + ;(diffViewProvider as any).closeAllDiffViews = vi.fn().mockResolvedValue(undefined) + + const result = await diffViewProvider.saveChanges(true, 5000) + + // Verify custom delay was used + expect(mockDelay).toHaveBeenCalledWith(5000) + expect(vscode.languages.getDiagnostics).toHaveBeenCalled() + }) + }) }) diff --git a/src/package.json b/src/package.json index 7b3c6a26cc..916a109088 100644 --- a/src/package.json +++ b/src/package.json @@ -3,7 +3,7 @@ "displayName": "%extension.displayName%", "description": "%extension.description%", "publisher": "RooVeterinaryInc", - "version": "3.23.12", + "version": "3.23.14", "icon": "assets/icons/icon.png", "galleryBanner": { "color": "#617A91", @@ -224,38 +224,38 @@ "when": "view == roo-cline.SidebarProvider" }, { - "command": "roo-cline.settingsButtonClicked", + "command": "roo-cline.marketplaceButtonClicked", "group": "navigation@2", "when": "view == roo-cline.SidebarProvider" }, { - "command": "roo-cline.accountButtonClicked", + "command": "roo-cline.settingsButtonClicked", "group": "navigation@3", "when": "view == roo-cline.SidebarProvider" }, + { + "command": "roo-cline.accountButtonClicked", + "group": "navigation@4", + "when": "view == roo-cline.SidebarProvider" + }, { "command": "roo-cline.historyButtonClicked", "group": "overflow@1", "when": "view == roo-cline.SidebarProvider" }, { - "command": "roo-cline.marketplaceButtonClicked", + "command": "roo-cline.promptsButtonClicked", "group": "overflow@2", "when": "view == roo-cline.SidebarProvider" }, { - "command": "roo-cline.promptsButtonClicked", + "command": "roo-cline.mcpButtonClicked", "group": "overflow@3", "when": "view == roo-cline.SidebarProvider" }, - { - "command": "roo-cline.mcpButtonClicked", - "group": "overflow@4", - "when": "view == roo-cline.SidebarProvider" - }, { "command": "roo-cline.popoutButtonClicked", - "group": "overflow@5", + "group": "overflow@4", "when": "view == roo-cline.SidebarProvider" } ], @@ -266,38 +266,38 @@ "when": "activeWebviewPanelId == roo-cline.TabPanelProvider" }, { - "command": "roo-cline.settingsButtonClicked", + "command": "roo-cline.marketplaceButtonClicked", "group": "navigation@2", "when": "activeWebviewPanelId == roo-cline.TabPanelProvider" }, { - "command": "roo-cline.accountButtonClicked", + "command": "roo-cline.settingsButtonClicked", "group": "navigation@3", "when": "activeWebviewPanelId == roo-cline.TabPanelProvider" }, + { + "command": "roo-cline.accountButtonClicked", + "group": "navigation@4", + "when": "activeWebviewPanelId == roo-cline.TabPanelProvider" + }, { "command": "roo-cline.historyButtonClicked", "group": "overflow@1", "when": "activeWebviewPanelId == roo-cline.TabPanelProvider" }, { - "command": "roo-cline.marketplaceButtonClicked", + "command": "roo-cline.promptsButtonClicked", "group": "overflow@2", "when": "activeWebviewPanelId == roo-cline.TabPanelProvider" }, { - "command": "roo-cline.promptsButtonClicked", + "command": "roo-cline.mcpButtonClicked", "group": "overflow@3", "when": "activeWebviewPanelId == roo-cline.TabPanelProvider" }, - { - "command": "roo-cline.mcpButtonClicked", - "group": "overflow@4", - "when": "activeWebviewPanelId == roo-cline.TabPanelProvider" - }, { "command": "roo-cline.popoutButtonClicked", - "group": "overflow@5", + "group": "overflow@4", "when": "activeWebviewPanelId == roo-cline.TabPanelProvider" } ] @@ -345,6 +345,19 @@ "maximum": 600, "description": "%commands.commandExecutionTimeout.description%" }, + "roo-cline.commandTimeoutAllowlist": { + "type": "array", + "items": { + "type": "string" + }, + "default": [], + "description": "%commands.commandTimeoutAllowlist.description%" + }, + "roo-cline.preventCompletionWithOpenTodos": { + "type": "boolean", + "default": false, + "description": "%commands.preventCompletionWithOpenTodos.description%" + }, "roo-cline.vsCodeLmModelSelector": { "type": "object", "properties": { diff --git a/src/package.nls.ca.json b/src/package.nls.ca.json index 339e635f0d..f7910db978 100644 --- a/src/package.nls.ca.json +++ b/src/package.nls.ca.json @@ -29,6 +29,7 @@ "commands.allowedCommands.description": "Ordres que es poden executar automàticament quan 'Aprova sempre les operacions d'execució' està activat", "commands.deniedCommands.description": "Prefixos d'ordres que seran automàticament denegats sense demanar aprovació. En cas de conflictes amb ordres permeses, la coincidència de prefix més llarga té prioritat. Afegeix * per denegar totes les ordres.", "commands.commandExecutionTimeout.description": "Temps màxim en segons per esperar que l'execució de l'ordre es completi abans d'esgotar el temps (0 = sense temps límit, 1-600s, per defecte: 0s)", + "commands.commandTimeoutAllowlist.description": "Prefixos d'ordres que estan exclosos del temps límit d'execució d'ordres. Les ordres que coincideixin amb aquests prefixos s'executaran sense restriccions de temps límit.", "settings.vsCodeLmModelSelector.description": "Configuració per a l'API del model de llenguatge VSCode", "settings.vsCodeLmModelSelector.vendor.description": "El proveïdor del model de llenguatge (p. ex. copilot)", "settings.vsCodeLmModelSelector.family.description": "La família del model de llenguatge (p. ex. gpt-4)", diff --git a/src/package.nls.de.json b/src/package.nls.de.json index 5a6fe65b11..d25145616d 100644 --- a/src/package.nls.de.json +++ b/src/package.nls.de.json @@ -29,6 +29,7 @@ "commands.allowedCommands.description": "Befehle, die automatisch ausgeführt werden können, wenn 'Ausführungsoperationen immer genehmigen' aktiviert ist", "commands.deniedCommands.description": "Befehlspräfixe, die automatisch abgelehnt werden, ohne nach Genehmigung zu fragen. Bei Konflikten mit erlaubten Befehlen hat die längste Präfix-Übereinstimmung Vorrang. Füge * hinzu, um alle Befehle abzulehnen.", "commands.commandExecutionTimeout.description": "Maximale Zeit in Sekunden, die auf den Abschluss der Befehlsausführung gewartet wird, bevor ein Timeout auftritt (0 = kein Timeout, 1-600s, Standard: 0s)", + "commands.commandTimeoutAllowlist.description": "Befehlspräfixe, die vom Timeout der Befehlsausführung ausgeschlossen sind. Befehle, die diesen Präfixen entsprechen, werden ohne Timeout-Beschränkungen ausgeführt.", "settings.vsCodeLmModelSelector.description": "Einstellungen für die VSCode-Sprachmodell-API", "settings.vsCodeLmModelSelector.vendor.description": "Der Anbieter des Sprachmodells (z.B. copilot)", "settings.vsCodeLmModelSelector.family.description": "Die Familie des Sprachmodells (z.B. gpt-4)", diff --git a/src/package.nls.es.json b/src/package.nls.es.json index 3e480550d8..057754dfb5 100644 --- a/src/package.nls.es.json +++ b/src/package.nls.es.json @@ -29,6 +29,7 @@ "commands.allowedCommands.description": "Comandos que pueden ejecutarse automáticamente cuando 'Aprobar siempre operaciones de ejecución' está activado", "commands.deniedCommands.description": "Prefijos de comandos que serán automáticamente denegados sin solicitar aprobación. En caso de conflictos con comandos permitidos, la coincidencia de prefijo más larga tiene prioridad. Añade * para denegar todos los comandos.", "commands.commandExecutionTimeout.description": "Tiempo máximo en segundos para esperar que se complete la ejecución del comando antes de que expire (0 = sin tiempo límite, 1-600s, predeterminado: 0s)", + "commands.commandTimeoutAllowlist.description": "Prefijos de comandos que están excluidos del tiempo límite de ejecución de comandos. Los comandos que coincidan con estos prefijos se ejecutarán sin restricciones de tiempo límite.", "settings.vsCodeLmModelSelector.description": "Configuración para la API del modelo de lenguaje VSCode", "settings.vsCodeLmModelSelector.vendor.description": "El proveedor del modelo de lenguaje (ej. copilot)", "settings.vsCodeLmModelSelector.family.description": "La familia del modelo de lenguaje (ej. gpt-4)", diff --git a/src/package.nls.fr.json b/src/package.nls.fr.json index 9e8fb83cc3..7f1193855f 100644 --- a/src/package.nls.fr.json +++ b/src/package.nls.fr.json @@ -29,6 +29,7 @@ "commands.allowedCommands.description": "Commandes pouvant être exécutées automatiquement lorsque 'Toujours approuver les opérations d'exécution' est activé", "commands.deniedCommands.description": "Préfixes de commandes qui seront automatiquement refusés sans demander d'approbation. En cas de conflit avec les commandes autorisées, la correspondance de préfixe la plus longue a la priorité. Ajouter * pour refuser toutes les commandes.", "commands.commandExecutionTimeout.description": "Temps maximum en secondes pour attendre que l'exécution de la commande se termine avant expiration (0 = pas de délai, 1-600s, défaut : 0s)", + "commands.commandTimeoutAllowlist.description": "Préfixes de commandes qui sont exclus du délai d'exécution des commandes. Les commandes correspondant à ces préfixes s'exécuteront sans restrictions de délai.", "settings.vsCodeLmModelSelector.description": "Paramètres pour l'API du modèle de langage VSCode", "settings.vsCodeLmModelSelector.vendor.description": "Le fournisseur du modèle de langage (ex: copilot)", "settings.vsCodeLmModelSelector.family.description": "La famille du modèle de langage (ex: gpt-4)", diff --git a/src/package.nls.hi.json b/src/package.nls.hi.json index 88bc845969..de531a03a8 100644 --- a/src/package.nls.hi.json +++ b/src/package.nls.hi.json @@ -29,6 +29,7 @@ "commands.allowedCommands.description": "वे कमांड जो स्वचालित रूप से निष्पादित की जा सकती हैं जब 'हमेशा निष्पादन संचालन को स्वीकृत करें' सक्रिय हो", "commands.deniedCommands.description": "कमांड प्रीफिक्स जो स्वचालित रूप से अस्वीकार कर दिए जाएंगे बिना अनुमोदन मांगे। अनुमतित कमांड के साथ संघर्ष की स्थिति में, सबसे लंबा प्रीफिक्स मैच प्राथमिकता लेता है। सभी कमांड को अस्वीकार करने के लिए * जोड़ें।", "commands.commandExecutionTimeout.description": "कमांड निष्पादन पूरा होने का इंतजार करने के लिए अधिकतम समय सेकंड में, समय समाप्त होने से पहले (0 = कोई समय सीमा नहीं, 1-600s, डिफ़ॉल्ट: 0s)", + "commands.commandTimeoutAllowlist.description": "कमांड प्रीफिक्स जो कमांड निष्पादन टाइमआउट से बाहर रखे गए हैं। इन प्रीफिक्स से मेल खाने वाले कमांड बिना टाइमआउट प्रतिबंधों के चलेंगे।", "settings.vsCodeLmModelSelector.description": "VSCode भाषा मॉडल API के लिए सेटिंग्स", "settings.vsCodeLmModelSelector.vendor.description": "भाषा मॉडल का विक्रेता (उदा. copilot)", "settings.vsCodeLmModelSelector.family.description": "भाषा मॉडल का परिवार (उदा. gpt-4)", diff --git a/src/package.nls.id.json b/src/package.nls.id.json index 1a2e038547..61a98cec1a 100644 --- a/src/package.nls.id.json +++ b/src/package.nls.id.json @@ -29,6 +29,7 @@ "commands.allowedCommands.description": "Perintah yang dapat dijalankan secara otomatis ketika 'Selalu setujui operasi eksekusi' diaktifkan", "commands.deniedCommands.description": "Awalan perintah yang akan otomatis ditolak tanpa meminta persetujuan. Jika terjadi konflik dengan perintah yang diizinkan, pencocokan awalan terpanjang akan diprioritaskan. Tambahkan * untuk menolak semua perintah.", "commands.commandExecutionTimeout.description": "Waktu maksimum dalam detik untuk menunggu eksekusi perintah selesai sebelum timeout (0 = tanpa timeout, 1-600s, default: 0s)", + "commands.commandTimeoutAllowlist.description": "Awalan perintah yang dikecualikan dari timeout eksekusi perintah. Perintah yang cocok dengan awalan ini akan berjalan tanpa batasan timeout.", "settings.vsCodeLmModelSelector.description": "Pengaturan untuk API Model Bahasa VSCode", "settings.vsCodeLmModelSelector.vendor.description": "Vendor dari model bahasa (misalnya copilot)", "settings.vsCodeLmModelSelector.family.description": "Keluarga dari model bahasa (misalnya gpt-4)", diff --git a/src/package.nls.it.json b/src/package.nls.it.json index 4d5ac4895d..383ea1041c 100644 --- a/src/package.nls.it.json +++ b/src/package.nls.it.json @@ -29,6 +29,7 @@ "commands.allowedCommands.description": "Comandi che possono essere eseguiti automaticamente quando 'Approva sempre le operazioni di esecuzione' è attivato", "commands.deniedCommands.description": "Prefissi di comandi che verranno automaticamente rifiutati senza richiedere approvazione. In caso di conflitti con comandi consentiti, la corrispondenza del prefisso più lungo ha la precedenza. Aggiungi * per rifiutare tutti i comandi.", "commands.commandExecutionTimeout.description": "Tempo massimo in secondi per attendere il completamento dell'esecuzione del comando prima del timeout (0 = nessun timeout, 1-600s, predefinito: 0s)", + "commands.commandTimeoutAllowlist.description": "Prefissi di comandi che sono esclusi dal timeout di esecuzione dei comandi. I comandi che corrispondono a questi prefissi verranno eseguiti senza restrizioni di timeout.", "settings.vsCodeLmModelSelector.description": "Impostazioni per l'API del modello linguistico VSCode", "settings.vsCodeLmModelSelector.vendor.description": "Il fornitore del modello linguistico (es. copilot)", "settings.vsCodeLmModelSelector.family.description": "La famiglia del modello linguistico (es. gpt-4)", diff --git a/src/package.nls.ja.json b/src/package.nls.ja.json index dcbc01d164..2e3a75930b 100644 --- a/src/package.nls.ja.json +++ b/src/package.nls.ja.json @@ -29,6 +29,7 @@ "commands.allowedCommands.description": "'常に実行操作を承認する'が有効な場合に自動実行できるコマンド", "commands.deniedCommands.description": "承認を求めずに自動的に拒否されるコマンドプレフィックス。許可されたコマンドとの競合がある場合、最長プレフィックスマッチが優先されます。すべてのコマンドを拒否するには * を追加してください。", "commands.commandExecutionTimeout.description": "コマンド実行の完了を待つ最大時間（秒）、タイムアウトまで（0 = タイムアウトなし、1-600秒、デフォルト: 0秒）", + "commands.commandTimeoutAllowlist.description": "コマンド実行タイムアウトから除外されるコマンドプレフィックス。これらのプレフィックスに一致するコマンドは、タイムアウト制限なしで実行されます。", "settings.vsCodeLmModelSelector.description": "VSCode 言語モデル API の設定", "settings.vsCodeLmModelSelector.vendor.description": "言語モデルのベンダー（例：copilot）", "settings.vsCodeLmModelSelector.family.description": "言語モデルのファミリー（例：gpt-4）", diff --git a/src/package.nls.json b/src/package.nls.json index c5225c45c8..1eb294ca44 100644 --- a/src/package.nls.json +++ b/src/package.nls.json @@ -29,6 +29,8 @@ "commands.allowedCommands.description": "Commands that can be auto-executed when 'Always approve execute operations' is enabled", "commands.deniedCommands.description": "Command prefixes that will be automatically denied without asking for approval. In case of conflicts with allowed commands, the longest prefix match takes precedence. Add * to deny all commands.", "commands.commandExecutionTimeout.description": "Maximum time in seconds to wait for command execution to complete before timing out (0 = no timeout, 1-600s, default: 0s)", + "commands.commandTimeoutAllowlist.description": "Command prefixes that are excluded from the command execution timeout. Commands matching these prefixes will run without timeout restrictions.", + "commands.preventCompletionWithOpenTodos.description": "Prevent task completion when there are incomplete todos in the todo list", "settings.vsCodeLmModelSelector.description": "Settings for VSCode Language Model API", "settings.vsCodeLmModelSelector.vendor.description": "The vendor of the language model (e.g. copilot)", "settings.vsCodeLmModelSelector.family.description": "The family of the language model (e.g. gpt-4)", diff --git a/src/package.nls.ko.json b/src/package.nls.ko.json index 6cb839e793..fc4142553c 100644 --- a/src/package.nls.ko.json +++ b/src/package.nls.ko.json @@ -29,6 +29,7 @@ "commands.allowedCommands.description": "'항상 실행 작업 승인' 이 활성화되어 있을 때 자동으로 실행할 수 있는 명령어", "commands.deniedCommands.description": "승인을 요청하지 않고 자동으로 거부될 명령어 접두사. 허용된 명령어와 충돌하는 경우 가장 긴 접두사 일치가 우선됩니다. 모든 명령어를 거부하려면 *를 추가하세요.", "commands.commandExecutionTimeout.description": "명령어 실행이 완료되기를 기다리는 최대 시간(초), 타임아웃 전까지 (0 = 타임아웃 없음, 1-600초, 기본값: 0초)", + "commands.commandTimeoutAllowlist.description": "명령어 실행 타임아웃에서 제외되는 명령어 접두사. 이러한 접두사와 일치하는 명령어는 타임아웃 제한 없이 실행됩니다.", "settings.vsCodeLmModelSelector.description": "VSCode 언어 모델 API 설정", "settings.vsCodeLmModelSelector.vendor.description": "언어 모델 공급자 (예: copilot)", "settings.vsCodeLmModelSelector.family.description": "언어 모델 계열 (예: gpt-4)", diff --git a/src/package.nls.nl.json b/src/package.nls.nl.json index 51b23ec1a6..36efa6d1e4 100644 --- a/src/package.nls.nl.json +++ b/src/package.nls.nl.json @@ -29,6 +29,7 @@ "commands.allowedCommands.description": "Commando's die automatisch kunnen worden uitgevoerd wanneer 'Altijd goedkeuren uitvoerbewerkingen' is ingeschakeld", "commands.deniedCommands.description": "Commando-prefixen die automatisch worden geweigerd zonder om goedkeuring te vragen. Bij conflicten met toegestane commando's heeft de langste prefix-match voorrang. Voeg * toe om alle commando's te weigeren.", "commands.commandExecutionTimeout.description": "Maximale tijd in seconden om te wachten tot commando-uitvoering voltooid is voordat er een timeout optreedt (0 = geen timeout, 1-600s, standaard: 0s)", + "commands.commandTimeoutAllowlist.description": "Commando-prefixen die zijn uitgesloten van de commando-uitvoering timeout. Commando's die overeenkomen met deze prefixen worden uitgevoerd zonder timeout-beperkingen.", "settings.vsCodeLmModelSelector.description": "Instellingen voor VSCode Language Model API", "settings.vsCodeLmModelSelector.vendor.description": "De leverancier van het taalmodel (bijv. copilot)", "settings.vsCodeLmModelSelector.family.description": "De familie van het taalmodel (bijv. gpt-4)", diff --git a/src/package.nls.pl.json b/src/package.nls.pl.json index 62daaae24b..3c500a166f 100644 --- a/src/package.nls.pl.json +++ b/src/package.nls.pl.json @@ -29,6 +29,7 @@ "commands.allowedCommands.description": "Polecenia, które mogą być wykonywane automatycznie, gdy włączona jest opcja 'Zawsze zatwierdzaj operacje wykonania'", "commands.deniedCommands.description": "Prefiksy poleceń, które będą automatycznie odrzucane bez pytania o zatwierdzenie. W przypadku konfliktów z dozwolonymi poleceniami, najdłuższe dopasowanie prefiksu ma pierwszeństwo. Dodaj * aby odrzucić wszystkie polecenia.", "commands.commandExecutionTimeout.description": "Maksymalny czas w sekundach oczekiwania na zakończenie wykonania polecenia przed przekroczeniem limitu czasu (0 = brak limitu czasu, 1-600s, domyślnie: 0s)", + "commands.commandTimeoutAllowlist.description": "Prefiksy poleceń, które są wykluczone z limitu czasu wykonania poleceń. Polecenia pasujące do tych prefiksów będą wykonywane bez ograniczeń czasowych.", "settings.vsCodeLmModelSelector.description": "Ustawienia dla API modelu językowego VSCode", "settings.vsCodeLmModelSelector.vendor.description": "Dostawca modelu językowego (np. copilot)", "settings.vsCodeLmModelSelector.family.description": "Rodzina modelu językowego (np. gpt-4)", diff --git a/src/package.nls.pt-BR.json b/src/package.nls.pt-BR.json index 7f3f7aece3..d5ac0b3b2c 100644 --- a/src/package.nls.pt-BR.json +++ b/src/package.nls.pt-BR.json @@ -29,6 +29,7 @@ "commands.allowedCommands.description": "Comandos que podem ser executados automaticamente quando 'Sempre aprovar operações de execução' está ativado", "commands.deniedCommands.description": "Prefixos de comandos que serão automaticamente negados sem solicitar aprovação. Em caso de conflitos com comandos permitidos, a correspondência de prefixo mais longa tem precedência. Adicione * para negar todos os comandos.", "commands.commandExecutionTimeout.description": "Tempo máximo em segundos para aguardar a conclusão da execução do comando antes do timeout (0 = sem timeout, 1-600s, padrão: 0s)", + "commands.commandTimeoutAllowlist.description": "Prefixos de comandos que são excluídos do timeout de execução de comandos. Comandos que correspondem a esses prefixos serão executados sem restrições de timeout.", "settings.vsCodeLmModelSelector.description": "Configurações para a API do modelo de linguagem do VSCode", "settings.vsCodeLmModelSelector.vendor.description": "O fornecedor do modelo de linguagem (ex: copilot)", "settings.vsCodeLmModelSelector.family.description": "A família do modelo de linguagem (ex: gpt-4)", diff --git a/src/package.nls.ru.json b/src/package.nls.ru.json index c1872a759e..282ff869e7 100644 --- a/src/package.nls.ru.json +++ b/src/package.nls.ru.json @@ -29,6 +29,7 @@ "commands.allowedCommands.description": "Команды, которые могут быть автоматически выполнены, когда включена опция 'Всегда подтверждать операции выполнения'", "commands.deniedCommands.description": "Префиксы команд, которые будут автоматически отклонены без запроса подтверждения. В случае конфликтов с разрешенными командами приоритет имеет самое длинное совпадение префикса. Добавьте * чтобы отклонить все команды.", "commands.commandExecutionTimeout.description": "Максимальное время в секундах для ожидания завершения выполнения команды до истечения времени ожидания (0 = без тайм-аута, 1-600с, по умолчанию: 0с)", + "commands.commandTimeoutAllowlist.description": "Префиксы команд, которые исключены из тайм-аута выполнения команд. Команды, соответствующие этим префиксам, будут выполняться без ограничений по времени.", "settings.vsCodeLmModelSelector.description": "Настройки для VSCode Language Model API", "settings.vsCodeLmModelSelector.vendor.description": "Поставщик языковой модели (например, copilot)", "settings.vsCodeLmModelSelector.family.description": "Семейство языковой модели (например, gpt-4)", diff --git a/src/package.nls.tr.json b/src/package.nls.tr.json index 589ce61912..7508c42c6e 100644 --- a/src/package.nls.tr.json +++ b/src/package.nls.tr.json @@ -29,6 +29,7 @@ "commands.allowedCommands.description": "'Her zaman yürütme işlemlerini onayla' etkinleştirildiğinde otomatik olarak yürütülebilen komutlar", "commands.deniedCommands.description": "Onay istenmeden otomatik olarak reddedilecek komut önekleri. İzin verilen komutlarla çakışma durumunda en uzun önek eşleşmesi öncelik alır. Tüm komutları reddetmek için * ekleyin.", "commands.commandExecutionTimeout.description": "Komut yürütmesinin tamamlanmasını beklemek için maksimum süre (saniye), zaman aşımından önce (0 = zaman aşımı yok, 1-600s, varsayılan: 0s)", + "commands.commandTimeoutAllowlist.description": "Komut yürütme zaman aşımından hariç tutulan komut önekleri. Bu öneklerle eşleşen komutlar zaman aşımı kısıtlamaları olmadan çalışacaktır.", "settings.vsCodeLmModelSelector.description": "VSCode dil modeli API'si için ayarlar", "settings.vsCodeLmModelSelector.vendor.description": "Dil modelinin sağlayıcısı (örn: copilot)", "settings.vsCodeLmModelSelector.family.description": "Dil modelinin ailesi (örn: gpt-4)", diff --git a/src/package.nls.vi.json b/src/package.nls.vi.json index 067738892d..58d386deac 100644 --- a/src/package.nls.vi.json +++ b/src/package.nls.vi.json @@ -29,6 +29,7 @@ "commands.allowedCommands.description": "Các lệnh có thể được thực thi tự động khi 'Luôn phê duyệt các thao tác thực thi' được bật", "commands.deniedCommands.description": "Các tiền tố lệnh sẽ được tự động từ chối mà không yêu cầu phê duyệt. Trong trường hợp xung đột với các lệnh được phép, việc khớp tiền tố dài nhất sẽ được ưu tiên. Thêm * để từ chối tất cả các lệnh.", "commands.commandExecutionTimeout.description": "Thời gian tối đa tính bằng giây để chờ việc thực thi lệnh hoàn thành trước khi hết thời gian chờ (0 = không có thời gian chờ, 1-600s, mặc định: 0s)", + "commands.commandTimeoutAllowlist.description": "Các tiền tố lệnh được loại trừ khỏi thời gian chờ thực thi lệnh. Các lệnh khớp với những tiền tố này sẽ chạy mà không có giới hạn thời gian chờ.", "settings.vsCodeLmModelSelector.description": "Cài đặt cho API mô hình ngôn ngữ VSCode", "settings.vsCodeLmModelSelector.vendor.description": "Nhà cung cấp mô hình ngôn ngữ (ví dụ: copilot)", "settings.vsCodeLmModelSelector.family.description": "Họ mô hình ngôn ngữ (ví dụ: gpt-4)", diff --git a/src/package.nls.zh-CN.json b/src/package.nls.zh-CN.json index 3a69340f81..07f1877bc0 100644 --- a/src/package.nls.zh-CN.json +++ b/src/package.nls.zh-CN.json @@ -29,6 +29,7 @@ "commands.allowedCommands.description": "当启用'始终批准执行操作'时可以自动执行的命令", "commands.deniedCommands.description": "将自动拒绝而无需请求批准的命令前缀。与允许命令冲突时，最长前缀匹配优先。添加 * 拒绝所有命令。", "commands.commandExecutionTimeout.description": "等待命令执行完成的最大时间（秒），超时前（0 = 无超时，1-600秒，默认：0秒）", + "commands.commandTimeoutAllowlist.description": "从命令执行超时中排除的命令前缀。匹配这些前缀的命令将在没有超时限制的情况下运行。", "settings.vsCodeLmModelSelector.description": "VSCode 语言模型 API 的设置", "settings.vsCodeLmModelSelector.vendor.description": "语言模型的供应商（例如：copilot）", "settings.vsCodeLmModelSelector.family.description": "语言模型的系列（例如：gpt-4）", diff --git a/src/package.nls.zh-TW.json b/src/package.nls.zh-TW.json index d6314420f1..237a2c2a6b 100644 --- a/src/package.nls.zh-TW.json +++ b/src/package.nls.zh-TW.json @@ -29,6 +29,7 @@ "commands.allowedCommands.description": "當啟用'始終批准執行操作'時可以自動執行的命令", "commands.deniedCommands.description": "將自動拒絕而無需請求批准的命令前綴。與允許命令衝突時，最長前綴匹配優先。新增 * 拒絕所有命令。", "commands.commandExecutionTimeout.description": "等待命令執行完成的最大時間（秒），逾時前（0 = 無逾時，1-600秒，預設：0秒）", + "commands.commandTimeoutAllowlist.description": "從命令執行逾時中排除的命令前綴。符合這些前綴的命令將在沒有逾時限制的情況下執行。", "settings.vsCodeLmModelSelector.description": "VSCode 語言模型 API 的設定", "settings.vsCodeLmModelSelector.vendor.description": "語言模型供應商（例如：copilot）", "settings.vsCodeLmModelSelector.family.description": "語言模型系列（例如：gpt-4）", diff --git a/src/shared/ExtensionMessage.ts b/src/shared/ExtensionMessage.ts index 4735007a24..e2b2e4e1d9 100644 --- a/src/shared/ExtensionMessage.ts +++ b/src/shared/ExtensionMessage.ts @@ -215,6 +215,7 @@ export type ExtensionState = Pick< | "terminalZshP10k" | "terminalZdotdir" | "terminalCompressProgressBar" + | "diagnosticsEnabled" | "diffEnabled" | "fuzzyMatchThreshold" // | "experiments" // Optional in GlobalSettings, required here. diff --git a/src/shared/WebviewMessage.ts b/src/shared/WebviewMessage.ts index bf0d6561a1..11a8b437a5 100644 --- a/src/shared/WebviewMessage.ts +++ b/src/shared/WebviewMessage.ts @@ -107,6 +107,7 @@ export interface WebviewMessage { | "updateMcpTimeout" | "fuzzyMatchThreshold" | "writeDelayMs" + | "diagnosticsEnabled" | "enhancePrompt" | "enhancedPrompt" | "draggedImages" diff --git a/webview-ui/src/components/chat/CodeIndexPopover.tsx b/webview-ui/src/components/chat/CodeIndexPopover.tsx index b5742cc623..4385e2e844 100644 --- a/webview-ui/src/components/chat/CodeIndexPopover.tsx +++ b/webview-ui/src/components/chat/CodeIndexPopover.tsx @@ -97,6 +97,10 @@ const createValidationSchema = (provider: EmbedderProvider, t: any) => { .min(1, t("settings:codeIndex.validation.ollamaBaseUrlRequired")) .url(t("settings:codeIndex.validation.invalidOllamaUrl")), codebaseIndexEmbedderModelId: z.string().min(1, t("settings:codeIndex.validation.modelIdRequired")), + codebaseIndexEmbedderModelDimension: z + .number() + .min(1, t("settings:codeIndex.validation.modelDimensionRequired")) + .optional(), }) case "openai-compatible": @@ -709,40 +713,50 @@ export const CodeIndexPopover: React.FC = ({ - + updateSetting("codebaseIndexEmbedderModelId", e.target.value) } + placeholder={t("settings:codeIndex.modelPlaceholder")} className={cn("w-full", { "border-red-500": formErrors.codebaseIndexEmbedderModelId, - })}> - - {t("settings:codeIndex.selectModel")} - - {getAvailableModels().map((modelId) => { - const model = - codebaseIndexModels?.[ - currentSettings.codebaseIndexEmbedderProvider - ]?.[modelId] - return ( - - {modelId}{" "} - {model - ? t("settings:codeIndex.modelDimensions", { - dimension: model.dimension, - }) - : ""} - - ) })} - + /> {formErrors.codebaseIndexEmbedderModelId && (

{formErrors.codebaseIndexEmbedderModelId}

)} + +
+ + { + const value = e.target.value + ? parseInt(e.target.value, 10) || undefined + : undefined + updateSetting("codebaseIndexEmbedderModelDimension", value) + }} + placeholder={t("settings:codeIndex.modelDimensionPlaceholder")} + className={cn("w-full", { + "border-red-500": + formErrors.codebaseIndexEmbedderModelDimension, + })} + /> + {formErrors.codebaseIndexEmbedderModelDimension && ( +

+ {formErrors.codebaseIndexEmbedderModelDimension} +

+ )} +
)} @@ -835,7 +849,7 @@ export const CodeIndexPopover: React.FC = ({ } onInput={(e: any) => { const value = e.target.value - ? parseInt(e.target.value) + ? parseInt(e.target.value, 10) || undefined : undefined updateSetting("codebaseIndexEmbedderModelDimension", value) }}