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

Merge branch 'RooCodeInc:main' into feat/finer-grained-control-gemini

Browse source
This commit is contained in:
Ton Hoang Nguyen (Bill) 2025-07-08 11:04:39 +01:00 • committed by GitHub
commit bf0161831e
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
219 changed files with 14415 additions and 4054 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
.changeset/large-olives-wink.md Normal file
View file

@ -0,0 +1,5 @@
---
"roo-cline": patch
---
Fix model search being prefilled in dropdown to prevent confusion in available models

5
.changeset/stale-rivers-travel.md Normal file
View file

@ -0,0 +1,5 @@
---
roo-code: minor
---
Add copy prompt button to task actions. Based on [@vultrnerd's feedback](https://github.com/Kilo-Org/kilocode/discussions/850).

1
.github/workflows/nightly-publish.yml vendored
View file

@ -11,7 +11,6 @@ on:
jobs:
publish-nightly:
runs-on: ubuntu-latest
if: ${{ github.event_name == 'workflow_dispatch' || github.event.workflow_run.conclusion == 'success' }}
permissions:
contents: read # No tags pushed → read is enough.

184
.roo/rules-docs-extractor/1_extraction_workflow.xml
View file

@ -1,30 +1,28 @@
<extraction_workflow>
<mode_overview>
The Docs Extractor mode performs comprehensive analysis of features and components
to generate multi-audience documentation. It extracts technical details, business logic,
user workflows, and all related information to create documentation suitable for
end-users, developers, administrators, and stakeholders.
The Docs Extractor mode analyzes features to generate documentation.
It extracts technical details, business logic, and user workflows
for different audiences.
</mode_overview>
<initialization_phase>
<step number="1">
<title>Understand Documentation Request</title>
<title>Parse Request</title>
<actions>
<action>Parse the user's request to identify the feature or component.</action>
<action>Determine if the user has provided a documentation section for review or is requesting new documentation.</action>
<action>Default to user-friendly documentation unless technical docs are specifically requested.</action>
<action>Focus on practical benefits and real-world usage.</action>
<action>Note any specific aspects the user wants emphasized.</action>
<action>Identify the feature or component in the user's request.</action>
<action>Determine if the request is for a review or to generate new documentation.</action>
<action>Default to user-friendly docs unless technical output is requested.</action>
<action>Note any specific areas to emphasize.</action>
</actions>
<note>The user will specify what they want documented in their initial message. The workflow branches based on whether a review is requested or new documentation is to be generated.</note>
<note>The initial request determines the workflow path (review vs. generation).</note>
</step>
<step number="2">
<title>Initial Feature Discovery</title>
<title>Discover Feature</title>
<actions>
<action>Use semantic search to find all related code</action>
<action>Identify entry points and main components</action>
<action>Map high-level architecture</action>
<action>Find related code with semantic search.</action>
<action>Identify entry points and components.</action>
<action>Map the high-level architecture.</action>
</actions>
<tool_use><![CDATA[
<codebase_search>
@ -36,32 +34,32 @@
<analysis_phases>
<phase name="code_analysis">
<title>Technical Implementation Analysis</title>
<title>Code Analysis</title>
<steps>
<step>
<action>Analyze source code structure</action>
<action>Analyze code structure</action>
<details>
- Identify classes, functions, and modules
- Extract method signatures and parameters
- Document return types and data structures
- Map inheritance and composition relationships
- Identify classes, functions, modules
- Extract method signatures, parameters
- Document return types, data structures
- Map inheritance and composition
</details>
</step>
<step>
<action>Extract API specifications</action>
<action>Extract APIs</action>
<details>
- REST endpoints with methods and parameters
- GraphQL schemas and resolvers
- WebSocket events and handlers
- RPC interfaces and protocols
- REST endpoints
- GraphQL schemas
- WebSocket events
- RPC interfaces
</details>
</step>
<step>
<action>Document configuration options</action>
<action>Document configuration</action>
<details>
- Environment variables
- Configuration files and schemas
- Feature flags and toggles
- Config files and schemas
- Feature flags
- Runtime parameters
</details>
</step>
@ -69,78 +67,78 @@
</phase>
<phase name="business_logic_analysis">
<title>Business Logic and Workflow Extraction</title>
<title>Business Logic Extraction</title>
<steps>
<step>
<action>Map user workflows</action>
<action>Map workflows</action>
<details>
- User journey through the feature
- Decision points and branching logic
- State transitions and lifecycle
- User roles and permissions
- User journey
- Decision points and branching
- State transitions
- Roles and permissions
</details>
</step>
<step>
<action>Document business rules</action>
<details>
- Validation logic and constraints
- Calculation formulas and algorithms
- Validation logic
- Formulas and algorithms
- Business process implementations
- Compliance and regulatory requirements
- Compliance requirements
</details>
</step>
<step>
<action>Identify use cases</action>
<details>
- Primary use cases and scenarios
- Edge cases and special conditions
- Error scenarios and recovery
- Performance considerations
- Primary use cases
- Edge cases
- Error scenarios
- Performance factors
</details>
</step>
</steps>
</phase>
<phase name="integration_analysis">
<title>Dependencies and Integration Analysis</title>
<title>Dependency Analysis</title>
<steps>
<step>
<action>Map external dependencies</action>
<action>Map dependencies</action>
<details>
- Third-party libraries and versions
- Third-party libraries
- External services and APIs
- Database connections and schemas
- Message queues and event systems
- Database connections
- Message queues
</details>
</step>
<step>
<action>Document integration points</action>
<details>
- Incoming webhooks and callbacks
- Incoming webhooks
- Outgoing API calls
- Event publishers and subscribers
- Shared data stores and caches
- Event publishers/subscribers
- Shared data stores
</details>
</step>
<step>
<action>Analyze data flow</action>
<details>
- Input data sources and formats
- Data transformations and mappings
- Data sources and formats
- Data transformations
- Output formats and destinations
- Data retention and lifecycle
- Data retention policies
</details>
</step>
</steps>
</phase>
<phase name="quality_analysis">
<title>Quality and Testing Analysis</title>
<title>Test Analysis</title>
<steps>
<step>
<action>Assess test coverage</action>
<details>
- Unit test coverage and quality
- Unit test coverage
- Integration test scenarios
- End-to-end test flows
- Performance test results
@ -150,7 +148,7 @@
<action>Document error handling</action>
<details>
- Error types and codes
- Exception handling strategies
- Exception handling
- Fallback mechanisms
- Recovery procedures
</details>
@ -158,43 +156,43 @@
<step>
<action>Identify quality metrics</action>
<details>
- Code complexity metrics
- Code complexity
- Performance benchmarks
- Security vulnerability assessments
- Maintainability indices
- Security vulnerabilities
- Maintainability scores
</details>
</step>
</steps>
</phase>
<phase name="security_analysis">
<title>Security and Compliance Analysis</title>
<title>Security Analysis</title>
<steps>
<step>
<action>Document security measures</action>
<action>Document security</action>
<details>
- Authentication mechanisms
- Authorization and access control
- Data encryption methods
- Security headers and policies
- Auth mechanisms
- Access control
- Data encryption
- Security policies
</details>
</step>
<step>
<action>Identify vulnerabilities</action>
<details>
- Known security issues
- Potential attack vectors
- Mitigation strategies
- Security best practices
- Attack vectors
- Mitigation
- Best practices
</details>
</step>
<step>
<action>Compliance requirements</action>
<action>Check compliance</action>
<details>
- Regulatory compliance (GDPR, HIPAA, etc.)
- Industry standards adherence
- Regulatory compliance (GDPR, etc.)
- Industry standards
- Audit trail requirements
- Data privacy considerations
- Data privacy
</details>
</step>
</steps>
@ -202,37 +200,37 @@
</analysis_phases>
<documentation_generation>
<note>This phase has two paths: Reviewing existing docs or Generating new docs. The path taken is determined in the initialization phase.</note>
<note>Workflow branches here: review existing docs or generate new docs.</note>
<step number="1">
<title>Path 1: Review and Recommend Improvements</title>
<note>This path is followed if the user provided a documentation section for review.</note>
<title>Path 1: Review and Recommend</title>
<note>Used when a document is provided for review.</note>
<actions>
<action>Compare the provided documentation against the analysis of the codebase.</action>
<action>Identify inaccuracies (technical, logical), omissions, and areas for improvement.</action>
<action>Categorize inaccuracies by severity (e.g., Critical, Major, Minor, Suggestion).</action>
<action>Formulate a structured recommendation in the chat, suitable for being copied to the docs team.</action>
<action>Do not write any files or make changes yourself.</action>
<action>The final output in the chat should ONLY be the structured recommendation, without any preceding conversational text.</action>
<action>Compare provided docs against codebase analysis.</action>
<action>Identify inaccuracies, omissions, and areas for improvement.</action>
<action>Categorize issues by severity (Critical, Major, Minor).</action>
<action>Formulate a structured recommendation in chat.</action>
<action>Do not write files.</action>
<action>Final output is only the recommendation.</action>
</actions>
</step>
<step number="2">
<title>Path 2: Generate New Documentation</title>
<note>This path is followed if the user requested new documentation.</note>
<title>Path 2: Generate Documentation</title>
<note>Used when new documentation is requested.</note>
<actions>
<action>Choose a documentation style (e.g., user-focused or comprehensive) from `2_documentation_patterns.xml`.</action>
<action>Structure the documentation with clear sections, examples, and user-friendly elements.</action>
<action>Create a `DOCS-TEMP-[feature].md` file with the generated content.</action>
<action>Use a conversational tone and practical examples from `7_user_friendly_examples.xml`.</action>
<action>Select a template from `2_documentation_patterns.xml`.</action>
<action>Structure the document with clear sections and examples.</action>
<action>Create `DOCS-TEMP-[feature].md` with generated content.</action>
<action>Apply tone and examples from `7_user_friendly_examples.xml`.</action>
</actions>
</step>
</documentation_generation>
<completion_criteria>
<criterion>All code paths have been analyzed</criterion>
<criterion>Business logic is fully documented</criterion>
<criterion>Integration points are mapped</criterion>
<criterion>Security considerations are addressed</criterion>
<criterion>Documentation serves all target audiences</criterion>
<criterion>Metadata and cross-references are complete</criterion>
<criterion>Code paths analyzed</criterion>
<criterion>Business logic documented</criterion>
<criterion>Integration points mapped</criterion>
<criterion>Security addressed</criterion>
<criterion>Audience needs met</criterion>
<criterion>Metadata and links are complete</criterion>
</completion_criteria>
</extraction_workflow>

344
.roo/rules-docs-extractor/2_documentation_patterns.xml
View file

@ -1,287 +1,255 @@
<documentation_patterns>
<overview>
Standard patterns and templates for structuring extracted documentation
to serve end-users with clear, practical information.
Standard templates for structuring extracted documentation.
</overview>
<output_structure>
<user_focused_template><![CDATA[
# [Feature Name]
[Brief, clear description of what the feature does and why it matters to users]
[Description of what the feature does and why a user should care.]
### Key Features
- [Feature 1 - written in user-friendly terms]
- [Feature 2 - focus on benefits]
- [Feature 3 - avoid technical jargon]
- [Benefit-oriented feature 1]
- [Benefit-oriented feature 2]
- [Benefit-oriented feature 3]
---
## Why This Matters
## Use Case
[Explain the problem this solves with a real-world example, like:]
**[Before scenario]**: [Description of the old/manual way]
**Before**: [Description of the old way]
- [Pain point 1]
- [Pain point 2]
**[With this feature]**: [Description of the improved experience]
**With this feature]**: [Description of the new experience.]
## How it Works
[Simple explanation of the feature's operation, avoiding implementation details]
[Simple explanation of the feature's operation.]
[Include visual representation if helpful - suggest where diagrams would help]
[Suggest visual representations where helpful.]
---
## Configuration
[User-friendly explanation of settings]
[Explanation of relevant settings.]
1. **[Setting Name]**:
- **Setting**: `[Technical name if needed]`
- **Description**: [What this does in plain language]
- **Default**: [Default value and what it means]
- **Setting**: `[technical_name]`
- **Description**: [What this does.]
- **Default**: [Default value and its meaning.]
2. **[Setting Name]**:
- **Setting**: `[Technical name if needed]`
- **Description**: [What this does in plain language]
- **Default**: [Default value and what it means]
- **Setting**: `[technical_name]`
- **Description**: [What this does.]
- **Default**: [Default value and its meaning.]
---
## Benefits
## FAQ
- **[Benefit 1]**: [Explanation of how this helps]
- **[Benefit 2]**: [Explanation of how this helps]
- **[Benefit 3]**: [Explanation of how this helps]
**"[User question]"**
- [Answer.]
- [Optional tip.]
## Common Questions
**"[User question]"**
- [Answer.]
- [Optional tip.]
**"[Common user question]"**
- [Clear, helpful answer]
- [Additional tips if relevant]
**"[Common user question]"**
- [Clear, helpful answer]
- [Additional tips if relevant]
**"[Common user question]"**
- [Clear, helpful answer]
- [Additional tips if relevant]
## Need Help?
If you run into issues:
1. [First troubleshooting step]
2. [Second troubleshooting step]
3. [Where to get help - e.g., GitHub Issues link]
]]></user_focused_template>
<comprehensive_template><![CDATA[
# [Feature Name] Documentation
# [Feature Name] Technical Documentation
## Table of Contents
1. [Overview](#overview)
2. [Quick Start](#quick-start)
3. [Architecture](#architecture)
4. [API Reference](#api-reference)
5. [Configuration](#configuration)
6. [User Guide](#user-guide)
7. [Developer Guide](#developer-guide)
8. [Administrator Guide](#administrator-guide)
9. [Security](#security)
10. [Performance](#performance)
11. [Troubleshooting](#troubleshooting)
12. [FAQ](#faq)
13. [Changelog](#changelog)
14. [References](#references)
1. Overview
2. Quick Start
3. Architecture
4. API Reference
5. Configuration
6. User Guide
7. Developer Guide
8. Administrator Guide
9. Security
10. Performance
11. Troubleshooting
12. FAQ
13. Changelog
14. References
[Rest of comprehensive template remains available for technical documentation needs]
[This template remains available for generating detailed technical documentation.]
]]></comprehensive_template>
</output_structure>
<user_friendly_patterns>
<before_after_examples>
<documentation_patterns>
<before_after>
<template><![CDATA[
**Previously**: When Roo needed to understand your project, you'd see multiple requests like:
- "Can I read `src/app.js`?" → You approve
- "Now can I read `src/utils.js`?" → You approve
- "And can I read `src/config.json`?" → You approve
**Before**: Multiple, sequential file read requests:
- "Read `src/app.js`?" → Approve
- "Read `src/utils.js`?" → Approve
- "Read `src/config.json`?" → Approve
**Now**: Roo asks once to read all related files together, getting the full picture immediately.
**Now**: One request to read all related files.
]]></template>
</before_after_examples>
</before_after>
<visual_separators>
<use_case>Between major sections</use_case>
<visual_separator>
<format>---</format>
<purpose>Improve readability and scanning</purpose>
</visual_separators>
<purpose>Separate sections.</purpose>
</visual_separator>
<conversational_questions>
<faq>
<template><![CDATA[
## Common Questions
## FAQ
**"Why would I want to disable this feature?"**
- You're using a less capable AI model that works better with single files
- You want more control over which files are accessed
- You're working with very large files that might exceed memory limits
**"Why disable this?"**
- Your AI model handles single files better.
- You need more control over file access.
- You are working with very large files.
**"What happens if some files are blocked?"**
- Roo will read the files you approve and work with those
- Files blocked by `.rooignore` will be automatically excluded
- You can still approve/deny individual files in the batch
**"What if some files are blocked?"**
- Roo reads approved files and works with what it has.
- `.rooignore` files are excluded automatically.
- Individual files can still be denied in the batch dialog.
]]></template>
</conversational_questions>
</faq>
<practical_examples>
<guideline>Show real tool output or interface elements</guideline>
<guideline>Use actual file paths and settings names</guideline>
<guideline>Include common error messages and solutions</guideline>
</practical_examples>
<examples>
<guideline>Show tool output or UI elements.</guideline>
<guideline>Use actual file paths and setting names.</guideline>
<guideline>Include common errors and solutions.</guideline>
</examples>
<benefit_focused_lists>
<template><![CDATA[
## Benefits
- **Faster Results**: Get answers in one step instead of multiple back-and-forth approvals
- **Better Context**: Roo understands relationships between files immediately
- **Less Interruption**: Approve once and let Roo work uninterrupted
]]></template>
</benefit_focused_lists>
<troubleshooting_section>
<troubleshooting>
<template><![CDATA[
## Troubleshooting
**"Roo is asking for too many files at once"**
- Lower the concurrent file limit in settings
- You can still approve or deny individual files in the batch dialog
**"Too many files requested"**
- Lower the concurrent file limit in settings.
- Deny individual files in the batch dialog.
**"The feature isn't working as expected"**
- Check that "Enable concurrent file reads" is turned on in settings
- Verify your concurrent file limit is set appropriately (default: 100)
- Some AI models may not support this feature effectively
**"Feature isn't working"**
- Ensure "Enable concurrent file reads" is on in settings.
- Verify the file limit is set correctly (default: 100).
- Some AI models may not support this feature.
]]></template>
</troubleshooting_section>
</troubleshooting>
<help_section>
<help>
<template><![CDATA[
## Need Help?
## Help
If you run into issues:
1. Check the [FAQ section](/faq) for common solutions
2. Report problems on [GitHub Issues](https://github.com/RooCodeInc/Roo-Code/issues)
3. Include what you were trying to do and any error messages
- See the [FAQ](#faq) for common issues.
- Report problems on [GitHub Issues](https://github.com/RooCodeInc/Roo-Code/issues).
- Include reproduction steps and error messages.
]]></template>
</help_section>
</user_friendly_patterns>
</help>
</documentation_patterns>
<audience_specific_sections>
<audience type="end_users">
<focus_areas>
<area>Step-by-step tutorials with screenshots</area>
<area>Common use case examples</area>
<area>Troubleshooting guides for user errors</area>
<area>Feature benefits and value propositions</area>
</focus_areas>
<writing_style>
<guideline>Use simple, non-technical language</guideline>
<guideline>Include visual aids and examples</guideline>
<guideline>Focus on outcomes rather than implementation</guideline>
<guideline>Provide clear action steps</guideline>
</writing_style>
<audience_sections>
<audience type="end_user">
<focus>
<area>Tutorials</area>
<area>Use cases</area>
<area>Troubleshooting</area>
<area>Benefits</area>
</focus>
<style>
<guideline>Simple language</guideline>
<guideline>Visual aids</guideline>
<guideline>Focus on outcomes</guideline>
<guideline>Clear action steps</guideline>
</style>
</audience>
<audience type="developers">
<focus_areas>
<area>Code examples and snippets</area>
<area>API specifications and contracts</area>
<area>Integration patterns and best practices</area>
<area>Performance optimization techniques</area>
</focus_areas>
<writing_style>
<guideline>Use precise technical terminology</guideline>
<guideline>Include code samples in multiple languages</guideline>
<guideline>Document edge cases and limitations</guideline>
<guideline>Provide debugging and testing guidance</guideline>
</writing_style>
<audience type="developer">
<focus>
<area>Code examples</area>
<area>API specs</area>
<area>Integration patterns</area>
<area>Performance</area>
</focus>
<style>
<guideline>Precise terminology</guideline>
<guideline>Code samples</guideline>
<guideline>Document edge cases</guideline>
<guideline>Debugging guidance</guideline>
</style>
</audience>
<audience type="administrators">
<focus_areas>
<area>Deployment and configuration procedures</area>
<area>Monitoring and maintenance tasks</area>
<area>Security hardening guidelines</area>
<area>Backup and disaster recovery</area>
</focus_areas>
<writing_style>
<guideline>Focus on operational aspects</guideline>
<guideline>Include command-line examples</guideline>
<guideline>Document automation opportunities</guideline>
<guideline>Emphasize security and compliance</guideline>
</writing_style>
<audience type="administrator">
<focus>
<area>Deployment</area>
<area>Monitoring</area>
<area>Security hardening</area>
<area>Backup and recovery</area>
</focus>
<style>
<guideline>Operational focus</guideline>
<guideline>CLI examples</guideline>
<guideline>Automation opportunities</guideline>
<guideline>Security and compliance</guideline>
</style>
</audience>
<audience type="stakeholders">
<focus_areas>
<area>Business value and ROI</area>
<area>Feature capabilities and limitations</area>
<audience type="stakeholder">
<focus>
<area>Business value</area>
<area>Capabilities and limits</area>
<area>Competitive advantages</area>
<area>Risk assessment and mitigation</area>
</focus_areas>
<writing_style>
<guideline>Use business-oriented language</guideline>
<guideline>Include metrics and KPIs</guideline>
<guideline>Focus on strategic benefits</guideline>
<guideline>Provide executive summaries</guideline>
</writing_style>
<area>Risk assessment</area>
</focus>
<style>
<guideline>Business language</guideline>
<guideline>Metrics and KPIs</guideline>
<guideline>Strategic benefits</guideline>
<guideline>Executive summaries</guideline>
</style>
</audience>
</audience_specific_sections>
</audience_sections>
<metadata_patterns>
<version_info>
<template><![CDATA[
### Version Compatibility Matrix
| Component | Min Version | Recommended | Max Version | Notes |
|-----------|-------------|-------------|-------------|-------|
### Version Compatibility
| Component | Min | Recommended | Max | Notes |
|-----------|-----|-------------|-----|-------|
| [Component] | [version] | [version] | [version] | [notes] |
]]></template>
</version_info>
<deprecation_notice>
<template><![CDATA[
> ⚠️ **Deprecation Notice**
>
> This feature/method is deprecated as of version [X.Y.Z].
> - **Deprecated**: [date]
> - **Removal Target**: [version/date]
> - **Migration Path**: [See migration guide](#migration)
> - **Replacement**: [new feature/method]
> ⚠️ **Deprecated**
>
> Deprecated since: [vX.Y.Z] on [date]
> Removal target: [vA.B.C]
> Migration: See [migration guide](#migration).
> Replacement: [new feature/method].
]]></template>
</deprecation_notice>
<security_warning>
<template><![CDATA[
> 🔒 **Security Consideration**
>
> [Description of security concern]
> - **Risk Level**: [High/Medium/Low]
> - **Affected Versions**: [versions]
> - **Mitigation**: [steps to address]
> - **References**: [CVE/advisory links]
> 🔒 **Security Warning**
>
> [Description of concern]
> - **Risk**: [High/Medium/Low]
> - **Affected**: [versions]
> - **Mitigation**: [steps]
> - **References**: [links]
]]></template>
</security_warning>
<performance_note>
<template><![CDATA[
> ⚡ **Performance Impact**
>
> ⚡ **Performance Note**
>
> [Description of performance consideration]
> - **Impact**: [metrics/benchmarks]
> - **Optimization**: [recommended approach]
> - **Impact**: [metrics]
> - **Optimization**: [approach]
> - **Trade-offs**: [considerations]
]]></template>
</performance_note>

206
.roo/rules-docs-extractor/3_analysis_techniques.xml
View file

@ -1,19 +1,18 @@
<analysis_techniques>
<overview>
Comprehensive techniques for analyzing code and extracting documentation-worthy
information from various aspects of a codebase.
Techniques for analyzing code to extract documentation.
</overview>
<code_analysis_techniques>
<technique name="entry_point_analysis">
<description>
Identify and analyze main entry points to understand feature flow
Analyze entry points to understand feature flow.
</description>
<steps>
<step>Search for main functions, controllers, or route handlers</step>
<step>Trace execution flow from entry to exit</step>
<step>Map decision branches and conditionals</step>
<step>Document input validation and preprocessing</step>
<step>Find main functions, controllers, or route handlers.</step>
<step>Trace execution flow.</step>
<step>Map decision branches.</step>
<step>Document input validation.</step>
</steps>
<tools><![CDATA[
<!-- Find entry points -->
@ -36,7 +35,7 @@
<technique name="api_extraction">
<description>
Extract API specifications from code implementations
Extract API specifications from code.
</description>
<patterns>
<pattern type="rest">
@ -46,10 +45,8 @@
<extraction>
- HTTP method
- Route path
- Path parameters
- Query parameters
- Request body schema
- Response schemas
- Path/query parameters
- Request/response schemas
- Status codes
</extraction>
</pattern>
@ -58,9 +55,8 @@
type\s+(Query|Mutation|Subscription)\s*{[^}]+}|@(Query|Mutation|Resolver)
]]></search_regex>
<extraction>
- Schema types
- Schema and input types
- Resolvers
- Input types
- Return types
- Field arguments
</extraction>
@ -70,15 +66,15 @@ type\s+(Query|Mutation|Subscription)\s*{[^}]+}|@(Query|Mutation|Resolver)
<technique name="dependency_mapping">
<description>
Map all dependencies and integration points
Map dependencies and integration points.
</description>
<analysis_points>
<point>Import statements and require calls</point>
<point>Package.json dependencies</point>
<point>Import/require statements</point>
<point>package.json dependencies</point>
<point>External API calls</point>
<point>Database connections</point>
<point>DB connections</point>
<point>Message queue integrations</point>
<point>File system operations</point>
<point>Filesystem operations</point>
</analysis_points>
<tools><![CDATA[
<!-- Find all imports -->
@ -102,31 +98,22 @@ type\s+(Query|Mutation|Subscription)\s*{[^}]+}|@(Query|Mutation|Resolver)
<technique name="data_model_extraction">
<description>
Extract data models, schemas, and type definitions
Extract data models, schemas, and type definitions.
</description>
<sources>
<source type="typescript">
<patterns>
- interface definitions
- type aliases
- class declarations
- enum definitions
- interfaces, types, classes, enums
</patterns>
</source>
<source type="database">
<patterns>
- Schema definitions
- Migration files
- Model definitions (ORM)
- SQL CREATE statements
- Schema definitions, migration files, ORM models
</patterns>
</source>
<source type="validation">
<patterns>
- JSON Schema
- Joi/Yup schemas
- Validation decorators
- Custom validators
- JSON Schema, Joi/Yup/Zod schemas, validation decorators
</patterns>
</source>
</sources>
@ -147,37 +134,33 @@ type\s+(Query|Mutation|Subscription)\s*{[^}]+}|@(Query|Mutation|Resolver)
<technique name="business_logic_extraction">
<description>
Identify and document business rules and logic
Identify and document business rules.
</description>
<indicators>
<indicator>Complex conditional statements</indicator>
<indicator>Complex conditionals</indicator>
<indicator>Calculation functions</indicator>
<indicator>Validation rules</indicator>
<indicator>State machines</indicator>
<indicator>Business-specific constants</indicator>
<indicator>Domain-specific algorithms</indicator>
<indicator>Domain-specific constants and algorithms</indicator>
</indicators>
<documentation_focus>
<focus>Why the logic exists (business requirement)</focus>
<focus>When the logic applies (conditions)</focus>
<focus>What the logic does (transformation)</focus>
<focus>Edge cases and exceptions</focus>
<focus>Business impact of changes</focus>
<focus>Why logic exists (business need)</focus>
<focus>When logic applies (conditions)</focus>
<focus>What logic does (transformation)</focus>
<focus>Edge cases</focus>
<focus>Impact of changes</focus>
</documentation_focus>
</technique>
<technique name="error_handling_analysis">
<description>
Document error handling strategies and recovery mechanisms
Document error handling and recovery.
</description>
<analysis_areas>
<area>Try-catch blocks and error boundaries</area>
<area>Custom error classes and types</area>
<area>try/catch blocks, error boundaries</area>
<area>Custom error classes</area>
<area>Error codes and messages</area>
<area>Logging strategies</area>
<area>Fallback mechanisms</area>
<area>Retry logic</area>
<area>Circuit breakers</area>
<area>Logging, fallbacks, retries, circuit breakers</area>
</analysis_areas>
<search_patterns><![CDATA[
<!-- Find error handling -->
@ -196,81 +179,68 @@ type\s+(Query|Mutation|Subscription)\s*{[^}]+}|@(Query|Mutation|Resolver)
<technique name="security_analysis">
<description>
Identify security measures and potential vulnerabilities
Identify security measures and vulnerabilities.
</description>
<security_checks>
<check category="authentication">
<patterns>
- JWT implementation
- Session management
- OAuth flows
- API key handling
- JWT, sessions, OAuth, API keys
</patterns>
</check>
<check category="authorization">
<patterns>
- Role-based access control
- Permission checks
- Resource ownership validation
- Access control lists
- RBAC, permission checks, ownership validation
</patterns>
</check>
<check category="data_protection">
<patterns>
- Encryption usage
- Hashing algorithms
- Sensitive data handling
- PII protection
- Encryption, hashing, sensitive data handling
</patterns>
</check>
<check category="input_validation">
<patterns>
- Input sanitization
- SQL injection prevention
- XSS protection
- CSRF tokens
</patterns>
- Sanitization, SQLi/XSS/CSRF prevention
</parents>
</check>
</security_checks>
</technique>
<technique name="performance_analysis">
<description>
Identify performance characteristics and optimization opportunities
Identify performance factors and optimization opportunities.
</description>
<analysis_points>
<point>Database query patterns (N+1 queries)</point>
<point>DB query patterns (N+1)</point>
<point>Caching strategies</point>
<point>Async/await usage</point>
<point>Async usage</point>
<point>Batch processing</point>
<point>Resource pooling</point>
<point>Memory management</point>
<point>Algorithm complexity</point>
</analysis_points>
<metrics_to_document>
<metric>Time complexity of algorithms</metric>
<metric>Space complexity</metric>
<metric>Database query counts</metric>
<metric>Time/space complexity</metric>
<metric>DB query counts</metric>
<metric>API response times</metric>
<metric>Memory usage patterns</metric>
<metric>Concurrent request handling</metric>
<metric>Memory usage</metric>
<metric>Concurrency handling</metric>
</metrics_to_document>
</technique>
<technique name="test_coverage_analysis">
<description>
Analyze test coverage and quality
Analyze test coverage.
</description>
<test_types>
<type name="unit_tests">
<type name="unit">
<location>__tests__, *.test.ts, *.spec.ts</location>
<analysis>Function-level coverage</analysis>
<analysis>Function coverage</analysis>
</type>
<type name="integration_tests">
<type name="integration">
<location>integration/, e2e/</location>
<analysis>Feature workflow coverage</analysis>
<analysis>Workflow coverage</analysis>
</type>
<type name="api_tests">
<type name="api">
<location>api-tests/, *.api.test.ts</location>
<analysis>Endpoint coverage</analysis>
</type>
@ -293,20 +263,16 @@ type\s+(Query|Mutation|Subscription)\s*{[^}]+}|@(Query|Mutation|Resolver)
<technique name="configuration_extraction">
<description>
Extract all configuration options and their impacts
Extract configuration options and their impacts.
</description>
<configuration_sources>
<source>Environment variables (.env files)</source>
<source>Configuration files (config.json, settings.yml)</source>
<source>Command-line arguments</source>
<source>Feature flags</source>
<source>Build-time constants</source>
<source>.env files, config files, CLI args, feature flags</source>
</configuration_sources>
<documentation_requirements>
<requirement>Default values</requirement>
<requirement>Valid value ranges</requirement>
<requirement>Impact on behavior</requirement>
<requirement>Dependencies between configs</requirement>
<requirement>Valid values</requirement>
<requirement>Behavior impact</requirement>
<requirement>Config dependencies</requirement>
<requirement>Security implications</requirement>
</documentation_requirements>
</technique>
@ -315,40 +281,29 @@ type\s+(Query|Mutation|Subscription)\s*{[^}]+}|@(Query|Mutation|Resolver)
<workflow_analysis>
<technique name="user_journey_mapping">
<description>
Map complete user workflows through the feature
Map user workflows through the feature.
</description>
<steps>
<step>Identify user entry points (UI, API, CLI)</step>
<step>Trace user actions through the system</step>
<step>Document decision points and branches</step>
<step>Map data transformations at each step</step>
<step>Identify exit points and outcomes</step>
<step>Identify entry points (UI, API, CLI).</step>
<step>Trace user actions.</step>
<step>Document decision points.</step>
<step>Map data transformations.</step>
<step>Identify outcomes.</step>
</steps>
<deliverables>
<deliverable>User flow diagrams</deliverable>
<deliverable>Step-by-step procedures</deliverable>
<deliverable>Decision trees</deliverable>
<deliverable>State transition diagrams</deliverable>
<deliverable>Flow diagrams, procedures, decision trees, state diagrams.</deliverable>
</deliverables>
</technique>
<technique name="integration_flow_analysis">
<description>
Document how the feature integrates with other systems
Document integration with other systems.
</description>
<integration_types>
<type>Synchronous API calls</type>
<type>Asynchronous messaging</type>
<type>Event-driven interactions</type>
<type>Batch processing</type>
<type>Real-time streaming</type>
<type>Sync API calls, async messaging, events, batch processing, streaming.</type>
</integration_types>
<documentation_focus>
<focus>Integration protocols and formats</focus>
<focus>Authentication mechanisms</focus>
<focus>Error handling and retries</focus>
<focus>Data transformation requirements</focus>
<focus>SLA and performance expectations</focus>
<focus>Protocols, auth, error handling, data transforms, SLAs.</focus>
</documentation_focus>
</technique>
</workflow_analysis>
@ -356,10 +311,7 @@ type\s+(Query|Mutation|Subscription)\s*{[^}]+}|@(Query|Mutation|Resolver)
<metadata_extraction>
<technique name="version_compatibility">
<sources>
<source>Package.json engines field</source>
<source>README compatibility sections</source>
<source>Migration guides</source>
<source>Breaking change documentation</source>
<source>package.json, READMEs, migration guides, breaking changes docs.</source>
</sources>
<extraction_pattern><![CDATA[
<!-- Find version requirements -->
@ -372,16 +324,10 @@ type\s+(Query|Mutation|Subscription)\s*{[^}]+}|@(Query|Mutation|Resolver)
<technique name="deprecation_tracking">
<indicators>
<indicator>@deprecated annotations</indicator>
<indicator>TODO: deprecate comments</indicator>
<indicator>Legacy code markers</indicator>
<indicator>Migration warnings</indicator>
<indicator>@deprecated, TODO comments, legacy code markers.</indicator>
</indicators>
<documentation_requirements>
<requirement>Deprecation date</requirement>
<requirement>Removal timeline</requirement>
<requirement>Migration path</requirement>
<requirement>Alternative solutions</requirement>
<requirement>Deprecation date, removal timeline, migration path, alternatives.</requirement>
</documentation_requirements>
</technique>
</metadata_extraction>
@ -389,21 +335,17 @@ type\s+(Query|Mutation|Subscription)\s*{[^}]+}|@(Query|Mutation|Resolver)
<quality_indicators>
<indicator name="documentation_completeness">
<checks>
<check>All public APIs documented</check>
<check>Examples provided for complex features</check>
<check>Error scenarios covered</check>
<check>Configuration options explained</check>
<check>Security considerations addressed</check>
<check>Public APIs documented.</check>
<check>Examples for complex features.</check>
<check>Error scenarios covered.</check>
<check>Config options explained.</check>
<check>Security addressed.</check>
</checks>
</indicator>
<indicator name="code_quality_metrics">
<metrics>
<metric>Cyclomatic complexity</metric>
<metric>Code duplication</metric>
<metric>Test coverage percentage</metric>
<metric>Documentation coverage</metric>
<metric>Technical debt indicators</metric>
<metric>Cyclomatic complexity, code duplication, test coverage, doc coverage, tech debt.</metric>
</metrics>
</indicator>
</quality_indicators>

166
.roo/rules-docs-extractor/4_tool_usage_guide.xml
View file

@ -1,16 +1,15 @@
<tool_usage_guide>
<overview>
Specific guidance on using tools effectively for comprehensive documentation extraction,
with emphasis on gathering complete information across all aspects of a feature.
Guidance on using tools for documentation extraction.
</overview>
<tool_sequence>
<priority level="1">
<tool>codebase_search</tool>
<purpose>Initial discovery of feature-related code</purpose>
<purpose>Initial code discovery.</purpose>
<usage_patterns>
<pattern>
<scenario>Finding feature entry points</scenario>
<scenario>Find feature entry points</scenario>
<example><![CDATA[
<codebase_search>
<query>authentication login user session JWT token</query>
@ -18,7 +17,7 @@
]]></example>
</pattern>
<pattern>
<scenario>Locating business logic</scenario>
<scenario>Find business logic</scenario>
<example><![CDATA[
<codebase_search>
<query>calculate pricing discount tax invoice billing</query>
@ -26,7 +25,7 @@
]]></example>
</pattern>
<pattern>
<scenario>Finding configuration</scenario>
<scenario>Find configuration</scenario>
<example><![CDATA[
<codebase_search>
<query>config settings environment variables .env process.env</query>
@ -38,11 +37,11 @@
<priority level="2">
<tool>list_code_definition_names</tool>
<purpose>Understanding code structure and organization</purpose>
<purpose>Understand code structure.</purpose>
<best_practices>
<practice>Use on directories containing core feature logic</practice>
<practice>Analyze both implementation and test directories</practice>
<practice>Look for patterns in naming conventions</practice>
<practice>Use on core feature directories.</practice>
<practice>Analyze implementation and test directories.</practice>
<practice>Look for naming patterns.</practice>
</best_practices>
<example><![CDATA[
<list_code_definition_names>
@ -53,12 +52,12 @@
<priority level="3">
<tool>read_file</tool>
<purpose>Deep analysis of specific implementations</purpose>
<purpose>Analyze specific implementations.</purpose>
<strategy>
<step>Read main feature files first</step>
<step>Follow imports to understand dependencies</step>
<step>Read test files to understand expected behavior</step>
<step>Examine configuration and type definition files</step>
<step>Read main feature files.</step>
<step>Follow imports to find dependencies.</step>
<step>Read test files for expected behavior.</step>
<step>Examine config and type definition files.</step>
</strategy>
<batch_reading><![CDATA[
<read_file>
@ -85,10 +84,10 @@
<priority level="4">
<tool>search_files</tool>
<purpose>Finding specific patterns and implementations</purpose>
<purpose>Find specific patterns.</purpose>
<use_cases>
<use_case>
<description>Find all API endpoints</description>
<description>Find API endpoints</description>
<example><![CDATA[
<search_files>
<path>src</path>
@ -97,7 +96,7 @@
]]></example>
</use_case>
<use_case>
<description>Find error handling patterns</description>
<description>Find error handling</description>
<example><![CDATA[
<search_files>
<path>src</path>
@ -106,7 +105,7 @@
]]></example>
</use_case>
<use_case>
<description>Find configuration usage</description>
<description>Find config usage</description>
<example><![CDATA[
<search_files>
<path>src</path>
@ -120,14 +119,14 @@
<documentation_generation_tools>
<tool name="write_to_file">
<purpose>Create the final documentation file when generating new documentation from scratch.</purpose>
<note>This tool is NOT used when reviewing a user-provided document section. In that scenario, feedback is provided directly in the chat.</note>
<purpose>Create documentation file for new docs.</purpose>
<note>Not used for reviews. Feedback for reviews is provided in chat.</note>
<file_naming>DOCS-TEMP-[feature-name].md</file_naming>
<best_practices>
<practice>Use descriptive feature names in filename</practice>
<practice>Include table of contents with anchors</practice>
<practice>Use consistent markdown formatting</practice>
<practice>Include code examples with syntax highlighting</practice>
<practice>Use descriptive feature name in filename.</practice>
<practice>Include table of contents.</practice>
<practice>Use consistent Markdown formatting.</practice>
<practice>Include syntax-highlighted code examples.</practice>
</best_practices>
<example><![CDATA[
<write_to_file>
@ -149,32 +148,32 @@ The authentication system provides secure user authentication using JWT tokens..
</tool>
<tool name="ask_followup_question">
<purpose>Clarify requirements when multiple interpretations exist</purpose>
<purpose>Clarify ambiguous requirements.</purpose>
<when_to_use>
<scenario>Multiple features with similar names exist</scenario>
<scenario>Documentation depth needs clarification</scenario>
<scenario>Target audience priorities need definition</scenario>
<scenario>Multiple features have similar names.</scenario>
<scenario>Documentation depth is unclear.</scenario>
<scenario>Audience priorities are undefined.</scenario>
</when_to_use>
<examples>
<example><![CDATA[
<ask_followup_question>
<question>Which aspects of the authentication system should I focus on?</question>
<question>Which authentication aspects should be the focus?</question>
<follow_up>
<suggest>Complete authentication flow including JWT tokens, session management, and OAuth integration</suggest>
<suggest>Only the JWT token implementation and validation</suggest>
<suggest>OAuth2 integration with external providers</suggest>
<suggest>Password reset and account recovery workflows</suggest>
<suggest>The complete flow (JWT, sessions, OAuth).</suggest>
<suggest>Only JWT implementation and validation.</suggest>
<suggest>Only OAuth2 integration.</suggest>
<suggest>Password reset and recovery workflows.</suggest>
</follow_up>
</ask_followup_question>
]]></example>
<example><![CDATA[
<ask_followup_question>
<question>What level of technical detail should the documentation include?</question>
<question>What level of technical detail is needed?</question>
<follow_up>
<suggest>High-level overview suitable for all audiences</suggest>
<suggest>Detailed technical implementation for developers</suggest>
<suggest>API reference with code examples</suggest>
<suggest>Complete coverage for all audience types</suggest>
<suggest>High-level overview for all audiences.</suggest>
<suggest>Detailed developer implementation.</suggest>
<suggest>API reference with code examples.</suggest>
<suggest>Full coverage for all audiences.</suggest>
</follow_up>
</ask_followup_question>
]]></example>
@ -183,21 +182,21 @@ The authentication system provides secure user authentication using JWT tokens..
</documentation_generation_tools>
<analysis_strategies>
<strategy name="comprehensive_file_discovery">
<strategy name="file_discovery">
<description>
Systematic approach to finding all files related to a feature
Find all files related to a feature.
</description>
<steps>
<step>
<action>Start with semantic search</action>
<action>Start with semantic search.</action>
<tool_use><![CDATA[
<codebase_search>
<query>feature implementation main logic core functionality</query>
<query>feature implementation main logic</query>
</codebase_search>
]]></tool_use>
</step>
<step>
<action>List directory structure</action>
<action>List directory structure.</action>
<tool_use><![CDATA[
<list_files>
<path>src/features</path>
@ -206,7 +205,7 @@ The authentication system provides secure user authentication using JWT tokens..
]]></tool_use>
</step>
<step>
<action>Find related tests</action>
<action>Find related tests.</action>
<tool_use><![CDATA[
<search_files>
<path>src</path>
@ -216,7 +215,7 @@ The authentication system provides secure user authentication using JWT tokens..
]]></tool_use>
</step>
<step>
<action>Locate configuration files</action>
<action>Find config files.</action>
<tool_use><![CDATA[
<search_files>
<path>.</path>
@ -230,14 +229,14 @@ The authentication system provides secure user authentication using JWT tokens..
<strategy name="dependency_chain_analysis">
<description>
Follow import chains to understand all dependencies
Follow import chains to map dependencies.
</description>
<process>
<step>Read main feature file</step>
<step>Extract all imports</step>
<step>Read each imported file</step>
<step>Recursively analyze their imports</step>
<step>Build dependency graph</step>
<step>Read main file.</step>
<step>Extract all imports.</step>
<step>Read each imported file.</step>
<step>Recursively analyze imports.</step>
<step>Build dependency graph.</step>
</process>
<import_patterns><![CDATA[
<!-- TypeScript/JavaScript imports -->
@ -256,35 +255,31 @@ The authentication system provides secure user authentication using JWT tokens..
<strategy name="api_documentation_extraction">
<description>
Extract complete API documentation from code
Extract API documentation from code.
</description>
<extraction_points>
<point>Route definitions</point>
<point>Request/response schemas</point>
<point>Authentication requirements</point>
<point>Rate limiting rules</point>
<point>Error responses</point>
<point>Route definitions, request/response schemas, auth requirements, rate limiting, error responses.</point>
</extraction_points>
<tools_sequence>
<sequence>
<step>Find all route files</step>
<step>Extract route definitions</step>
<step>Find associated controllers</step>
<step>Analyze request validation</step>
<step>Document response formats</step>
<step>Find route files.</step>
<step>Extract route definitions.</step>
<step>Find controllers.</step>
<step>Analyze request validation.</step>
<step>Document response formats.</step>
</sequence>
</tools_sequence>
</strategy>
<strategy name="test_driven_documentation">
<description>
Use tests to understand expected behavior
Use tests to document expected behavior.
</description>
<benefits>
<benefit>Tests show real usage examples</benefit>
<benefit>Test descriptions explain functionality</benefit>
<benefit>Edge cases are often tested</benefit>
<benefit>Expected outputs are documented</benefit>
<benefit>Tests provide usage examples.</benefit>
<benefit>Test descriptions explain functionality.</benefit>
<benefit>Tests cover edge cases.</benefit>
<benefit>Tests document expected outputs.</benefit>
</benefits>
<extraction_approach><![CDATA[
<!-- Find test descriptions -->
@ -354,44 +349,31 @@ config\.(\w+)\.(\w+)
</common_patterns>
<output_optimization>
<guideline name="structured_sections">
<description>Organize output for easy navigation</description>
<guideline name="structure">
<description>Organize output for navigation.</description>
<structure>
- Clear hierarchy with numbered sections
- Consistent heading levels
- Table of contents with links
- Cross-references between sections
- Clear hierarchy, consistent headings, ToC with links, cross-references.
</structure>
</guideline>
<guideline name="code_examples">
<description>Include relevant code examples</description>
<description>Include relevant code examples.</description>
<best_practices>
- Use syntax highlighting
- Show both request and response
- Include error cases
- Provide language-specific examples
- Use syntax highlighting, show request/response, include error cases.
</best_practices>
</guideline>
<guideline name="visual_aids">
<description>Suggest where diagrams would help</description>
<guideline name="visuals">
<description>Suggest diagrams where helpful.</description>
<diagram_types>
- Architecture diagrams
- Sequence diagrams
- Data flow diagrams
- State machines
- Architecture, sequence, data flow, state machine diagrams.
</diagram_types>
</guideline>
<guideline name="metadata_inclusion">
<description>Always include important metadata</description>
<guideline name="metadata">
<description>Include important metadata.</description>
<required_metadata>
- Version compatibility
- Last updated date
- Feature status (stable/beta/deprecated)
- Performance characteristics
- Security considerations
- Version compatibility, last updated, status, performance, security.
</required_metadata>
</guideline>
</output_optimization>

55
.roo/rules-docs-extractor/5_complete_extraction_examples.xml
View file

@ -1,48 +1,42 @@
<complete_extraction_examples>
<overview>
Complete examples demonstrating the full documentation extraction workflow
for different types of features and components.
Examples of the documentation extraction workflow.
</overview>
<example name="authentication_system_extraction">
<scenario>
Extract comprehensive documentation for a JWT-based authentication system
including login, logout, token refresh, and role-based access control.
Extract documentation for a JWT-based authentication system, including login, token refresh, and RBAC.
</scenario>
<workflow>
<step number="1">
<description>Initial feature discovery</description>
<description>Discover feature</description>
<tool_use><![CDATA[
<codebase_search>
<query>authentication JWT login logout token refresh auth middleware</query>
</codebase_search>
]]></tool_use>
<expected_findings>
- Auth controller files
- JWT service implementations
- Middleware functions
- User model with auth fields
- Auth route definitions
- Auth controllers, services, middleware, models, and routes.
</expected_findings>
</step>
<step number="2">
<description>Analyze authentication structure</description>
<description>Analyze structure</description>
<tool_use><![CDATA[
<list_code_definition_names>
<path>src/auth</path>
</list_code_definition_names>
]]></tool_use>
<analysis>
- Identify main classes and functions
- Map authentication flow
- Find token generation/validation logic
- Identify main classes/functions.
- Map auth flow.
- Find token generation/validation logic.
</analysis>
</step>
<step number="3">
<description>Read core implementation files</description>
<description>Read core files</description>
<tool_use><![CDATA[
<read_file>
<args>
@ -75,16 +69,12 @@
</search_files>
]]></tool_use>
<findings>
- POST /auth/login
- POST /auth/logout
- POST /auth/refresh
- GET /auth/profile
- POST /auth/register
- POST /auth/login, POST /auth/logout, POST /auth/refresh, GET /auth/profile, POST /auth/register
</findings>
</step>
<step number="5">
<description>Document configuration</description>
<description>Extract configuration</description>
<tool_use><![CDATA[
<search_files>
<path>src</path>
@ -94,7 +84,7 @@
</step>
<step number="6">
<description>Analyze security measures</description>
<description>Analyze security</description>
<tool_use><![CDATA[
<search_files>
<path>src/auth</path>
@ -104,7 +94,7 @@
</step>
<step number="7">
<description>Generate documentation</description>
<description>Generate docs</description>
<tool_use><![CDATA[
<write_to_file>
<path>DOCS-TEMP-authentication-system.md</path>
@ -552,24 +542,23 @@ DEBUG=auth:* npm start
</workflow>
<key_takeaways>
<takeaway>Start with semantic search to find all related files</takeaway>
<takeaway>Read multiple files together for context</takeaway>
<takeaway>Extract API documentation from route definitions</takeaway>
<takeaway>Use tests to understand expected behavior</takeaway>
<takeaway>Document security measures comprehensively</takeaway>
<takeaway>Include troubleshooting based on common errors</takeaway>
<takeaway>Use semantic search to find related files.</takeaway>
<takeaway>Read multiple files for context.</takeaway>
<takeaway>Extract API docs from route definitions.</takeaway>
<takeaway>Use tests to understand behavior.</takeaway>
<takeaway>Document security measures.</takeaway>
<takeaway>Include troubleshooting for common errors.</takeaway>
</key_takeaways>
</example>
<example name="database_schema_extraction">
<scenario>
Extract documentation for database models, relationships, migrations,
and data access patterns.
Extract documentation for database models, relationships, and migrations.
</scenario>
<workflow>
<step number="1">
<description>Find database-related files</description>
<description>Find DB files</description>
<tool_use><![CDATA[
<codebase_search>
<query>database schema model entity migration table column relationship</query>
@ -578,7 +567,7 @@ DEBUG=auth:* npm start
</step>
<step number="2">
<description>Analyze model definitions</description>
<description>Analyze models</description>
<tool_use><![CDATA[
<search_files>
<path>src/models</path>

272
.roo/rules-docs-extractor/6_communication_guidelines.xml
View file

@ -1,90 +1,87 @@
<communication_guidelines>
<overview>
Guidelines for communicating with users and formatting documentation output
during the extraction process.
Guidelines for user communication and output formatting.
</overview>
<user_interaction>
<initial_understanding>
<principle>Users will specify what they want documented in their initial message</principle>
<principle>Start working immediately based on their request</principle>
<principle>Only ask for clarification if genuinely ambiguous</principle>
</initial_understanding>
<initial_contact>
<principle>Act on the user's request immediately.</principle>
<principle>Only ask for clarification if the request is ambiguous.</principle>
</initial_contact>
<clarification_only_when_needed>
<clarification>
<when_to_ask>
<scenario>Multiple features with identical names found</scenario>
<scenario>Request is genuinely ambiguous (rare)</scenario>
<scenario>User explicitly asks for options</scenario>
<scenario>Multiple features with similar names are found.</scenario>
<scenario>The request is ambiguous.</scenario>
<scenario>The user explicitly asks for options.</scenario>
</when_to_ask>
<question_example><![CDATA[
<ask_followup_question>
<question>I found multiple authentication systems. Which one should I document?</question>
<question>Found multiple auth systems. Which to document?</question>
<follow_up>
<suggest>JWT-based authentication system (src/auth/jwt/*)</suggest>
<suggest>JWT-based system (src/auth/jwt/*)</suggest>
<suggest>OAuth2 integration (src/auth/oauth/*)</suggest>
<suggest>Basic authentication middleware (src/middleware/basic-auth.ts)</suggest>
<suggest>All authentication features comprehensively</suggest>
<suggest>Basic auth middleware (src/middleware/basic-auth.ts)</suggest>
<suggest>All of them</suggest>
</follow_up>
</ask_followup_question>
]]></question_example>
</clarification_only_when_needed>
</clarification>
<progress_updates>
<when_to_update>
<trigger>Starting major analysis phase</trigger>
<trigger>Completed significant extraction</trigger>
<trigger>Found unexpected complexity</trigger>
<trigger>Discovered related features</trigger>
<trigger>Starting a major analysis phase.</trigger>
<trigger>Extraction is complete.</trigger>
<trigger>Unexpected complexity is found.</trigger>
</when_to_update>
<update_format>
<template>
Analyzing [component/feature]...
- Found [X] files related to [feature]
- Identified [Y] API endpoints
- Discovered [Z] configuration options
Analyzing [component]...
- Found [X] related files.
- Identified [Y] API endpoints.
- Found [Z] config options.
</template>
</update_format>
</progress_updates>
<findings_communication>
<important_discoveries>
<important_findings>
<discovery type="security_issue">
Alert user to potential security concerns found during analysis
Alert user to security concerns found during analysis.
</discovery>
<discovery type="deprecated_code">
Note deprecated features that need migration documentation
Note deprecated features needing migration docs.
</discovery>
<discovery type="missing_documentation">
Highlight areas where code lacks inline documentation
<discovery type="missing_docs">
Highlight code that lacks inline documentation.
</discovery>
<discovery type="complex_dependencies">
Warn about intricate dependency chains affecting the feature
Warn about complex dependency chains.
</discovery>
</important_discoveries>
</important_findings>
<review_findings>
<template><![CDATA[
I have reviewed the documentation section provided. Here are my recommendations for improvement:
Review of the provided documentation section is complete.
**Overall Assessment**: [Brief summary of the document's quality]
**Assessment**: [Summary of document quality]
**Recommendations for Improvement**:
**Recommendations**:
* **Critical Inaccuracies**:
* [Inaccuracy 1]: The documentation states [X], but the code implements [Y].
* [Inaccuracy 2]: ...
* [Inaccuracy 1]: Docs state [X], but code implements [Y].
* ...
* **Major Omissions**:
* The documentation is missing information about [Missing Feature/Concept].
* ...
* **Omissions**:
* Missing info about [Missing Feature].
* ...
* **Suggestions for Clarity**:
* The section on [Topic] could be clarified by [Suggestion].
* ...
* **Clarity Suggestions**:
* The section on [Topic] can be clarified by [Suggestion].
* ...
This feedback can be copied and pasted for your documentation team.
Copy this feedback for your documentation team.
]]></template>
</review_findings>
</findings_communication>
@ -92,18 +89,14 @@ This feedback can be copied and pasted for your documentation team.
<output_formatting>
<markdown_standards>
<heading_hierarchy>
<rule>Use # for main title only</rule>
<rule>Use ## for major sections</rule>
<rule>Use ### for subsections</rule>
<rule>Use #### sparingly for minor subsections</rule>
<rule>Never skip heading levels</rule>
</heading_hierarchy>
<headings>
<rule>Use # for main title, ## for major sections, ### for subsections.</rule>
<rule>Never skip heading levels.</rule>
</headings>
<code_blocks>
<rule>Always specify language for syntax highlighting</rule>
<rule>Use appropriate language identifiers (typescript, javascript, json, yaml, bash)</rule>
<rule>Include file paths as comments when relevant</rule>
<rule>Always specify language for syntax highlighting (e.g., typescript, json, bash).</rule>
<rule>Include file paths as comments where relevant.</rule>
<example><![CDATA[
```typescript
// src/auth/auth.service.ts
@ -117,9 +110,9 @@ export class AuthService {
</code_blocks>
<tables>
<rule>Use tables for structured data like configurations</rule>
<rule>Include headers with proper alignment</rule>
<rule>Keep cell content concise</rule>
<rule>Use tables for structured data like configs.</rule>
<rule>Include headers and align columns.</rule>
<rule>Keep cell content brief.</rule>
<example><![CDATA[
| Variable | Type | Default | Description |
|----------|------|---------|-------------|
@ -129,30 +122,25 @@ export class AuthService {
</tables>
<lists>
<rule>Use bullet points for unordered lists</rule>
<rule>Use numbers for sequential steps</rule>
<rule>Nest lists with proper indentation</rule>
<rule>Keep list items parallel in structure</rule>
<rule>Use bullets for unordered lists, numbers for sequential steps.</rule>
<rule>Keep list items parallel in structure.</rule>
</lists>
</markdown_standards>
<cross_references>
<internal_links>
<format>[Link text](#section-anchor)</format>
<rule>Use lowercase, hyphenated anchors</rule>
<rule>Test all internal links</rule>
<rule>Use lowercase, hyphenated anchors. Test all links.</rule>
</internal_links>
<external_links>
<format>[Link text](https://example.com)</format>
<rule>Use HTTPS when available</rule>
<rule>Link to official documentation</rule>
<rule>Use HTTPS. Link to official docs.</rule>
</external_links>
<file_references>
<format>`path/to/file.ts`</format>
<rule>Use relative paths from project root</rule>
<rule>Use backticks for inline file references</rule>
<rule>Use relative paths from project root, in backticks.</rule>
</file_references>
</cross_references>
@ -160,15 +148,15 @@ export class AuthService {
<alerts>
<type name="warning">
<format>> ⚠️ **Warning**: [message]</format>
<use_for>Security concerns, breaking changes, deprecations</use_for>
<use_for>Security, breaking changes, deprecations.</use_for>
</type>
<type name="note">
<format>> 📝 **Note**: [message]</format>
<use_for>Important information, clarifications</use_for>
<use_for>Important info, clarifications.</use_for>
</type>
<type name="tip">
<format>> 💡 **Tip**: [message]</format>
<use_for>Best practices, optimization suggestions</use_for>
<use_for>Best practices, optimizations.</use_for>
</type>
</alerts>
@ -186,138 +174,110 @@ Status: Stable
</output_formatting>
<documentation_tone>
<general_principles>
<principle>Be conversational and approachable</principle>
<principle>Use active voice and "you" to address the reader</principle>
<principle>Lead with benefits, not features</principle>
<principle>Use concrete examples and scenarios</principle>
<principle>Keep paragraphs short and scannable</principle>
<principle>Avoid unnecessary technical details</principle>
</general_principles>
<general>
<principle>Be direct, not conversational.</principle>
<principle>Use active voice.</principle>
<principle>Lead with benefits.</principle>
<principle>Use concrete examples.</principle>
<principle>Keep paragraphs short.</principle>
<principle>Avoid unnecessary technical details.</principle>
</general>
<user_focused_tone>
<guideline>Write as if explaining to a colleague who isn't technical</guideline>
<guideline>Use analogies and comparisons to familiar concepts</guideline>
<guideline>Focus on "what" and "why" before "how"</guideline>
<guideline>Include practical examples users can relate to</guideline>
<guideline>Address common concerns and questions directly</guideline>
</user_focused_tone>
<audience_specific_tone>
<audience type="default_user">
<tone>Friendly, helpful, encouraging</tone>
<vocabulary>Plain language, minimal jargon</vocabulary>
<examples>Real-world scenarios, before/after comparisons</examples>
<structure>Problem → Solution → Benefits → How to use</structure>
<audience_tone>
<audience type="developer">
<tone>Technical and direct.</tone>
<vocabulary>Standard programming terms.</vocabulary>
<examples>Code snippets, implementation details.</examples>
</audience>
<audience type="developers">
<tone>Technical when needed, but still approachable</tone>
<vocabulary>Use standard programming terminology</vocabulary>
<examples>Include code snippets and implementation details</examples>
<audience type="end_user">
<tone>Instructional, step-by-step.</tone>
<vocabulary>Simple language, no jargon.</vocabulary>
<examples>Screenshots, real-world scenarios.</examples>
</audience>
<audience type="end_users">
<tone>Friendly, instructional, step-by-step</tone>
<vocabulary>Avoid technical jargon, explain concepts simply</vocabulary>
<examples>Use screenshots and real-world scenarios</examples>
<audience type="administrator">
<tone>Operational focus.</tone>
<vocabulary>IT/DevOps terms.</vocabulary>
<examples>CLI examples, configs.</examples>
</audience>
<audience type="administrators">
<tone>Professional, operational focus</tone>
<vocabulary>Use IT/DevOps terminology</vocabulary>
<examples>Include command-line examples and configurations</examples>
</audience>
<audience type="stakeholders">
<tone>Business-oriented, value-focused</tone>
<vocabulary>Use business terminology, avoid implementation details</vocabulary>
<examples>Include metrics, ROI, and business benefits</examples>
</audience>
</audience_specific_tone>
</audience_tone>
</documentation_tone>
<completion_message>
<structure>
<element>Summary of what was documented</element>
<element>Key findings or insights</element>
<element>File location and name</element>
<element>Suggestions for next steps (if applicable)</element>
<element>Summary of documented feature.</element>
<element>Key findings.</element>
<element>File location.</element>
<element>Next step suggestions (if applicable).</element>
</structure>
<example><![CDATA[
I've completed the comprehensive documentation extraction for the authentication system.
Documentation extracted for the authentication system.
**Documentation Generated**: `DOCS-TEMP-authentication-system.md`
**Generated File**: `DOCS-TEMP-authentication-system.md`
**Key Findings**:
- The system uses JWT tokens with refresh token rotation
- Found 5 main API endpoints for authentication
- Identified 12 configuration options
- Documented security measures including bcrypt hashing and rate limiting
- Included troubleshooting for 3 common issues
- System uses JWT with refresh token rotation.
- 5 API endpoints found.
- 12 configuration options identified.
- Security measures (bcrypt, rate limiting) documented.
- Troubleshooting for 3 common issues included.
**Coverage**:
- ✅ Technical implementation details
- ✅ API reference with examples
- ✅ Technical details
- ✅ API reference
- ✅ Configuration guide
- ✅ Security considerations
- ✅ Security guide
- ✅ User and developer guides
- ✅ Troubleshooting section
The documentation is structured for multiple audiences and includes all requested metadata, version information, and cross-references.
- ✅ Troubleshooting
]]></example>
<example_review><![CDATA[
I have completed the review of the provided documentation section.
Review of the documentation section is complete.
**Action Taken**:
- Analyzed the provided text against the current codebase for accuracy.
- Identified several areas for improvement and outlined them as a recommendation.
**Action**:
- Analyzed text against codebase.
- Identified inaccuracies and omissions.
- Formulated recommendations.
**Next Steps**:
- The detailed feedback has been provided in the chat. You can copy and paste it to your documentation team. No files were created.
- Feedback is in the chat. No files were created.
]]></example_review>
</completion_message>
<error_handling>
<common_scenarios>
<scenarios>
<scenario type="feature_not_found">
<response>
I couldn't find a feature matching "[feature name]". Here are some similar features I found:
Could not find a feature matching "[feature name]". Similar features found:
- [List similar features]
Would you like me to document one of these instead?
Document one of these instead?
</response>
</scenario>
<scenario type="insufficient_code_documentation">
<scenario type="insufficient_docs">
<response>
The code for [feature] has limited inline documentation. I'll extract what I can from:
- Code structure and naming
- Test files
- Related documentation
- Usage patterns
Code for [feature] has limited inline documentation. Extracting from code structure, tests, and usage patterns.
</response>
</scenario>
<scenario type="complex_feature">
<response>
This feature is quite complex with [X] components. Would you like me to:
- Document everything comprehensively (may result in a large document)
- Focus on the core functionality
- Split into multiple documentation files
This feature is complex. Choose documentation scope:
- Document comprehensively
- Focus on core functionality
- Split into multiple documents
</response>
</scenario>
</common_scenarios>
</scenarios>
</error_handling>
<quality_checks>
<before_completion>
<check>All sections have content (no placeholders)</check>
<check>Code examples are syntactically correct</check>
<check>Links and cross-references work</check>
<check>Tables are properly formatted</check>
<check>Version information is included</check>
<check>File naming follows convention</check>
<check>No placeholder content remains.</check>
<check>Code examples are correct.</check>
<check>Links and cross-references work.</check>
<check>Tables are formatted correctly.</check>
<check>Version info is included.</check>
<check>Filename follows conventions.</check>
</before_completion>
</quality_checks>
</communication_guidelines>

252
.roo/rules-docs-extractor/7_user_friendly_examples.xml
View file

@ -1,93 +1,87 @@
<user_friendly_examples>
<overview>
Examples and patterns for creating documentation that prioritizes user experience
and practical understanding over technical completeness.
Examples for creating user-focused, practical documentation.
</overview>
<writing_principles>
<principle name="lead_with_benefits">
<bad>The concurrent file read feature uses parallel processing to read multiple files.</bad>
<good>Read multiple files at once, saving time and reducing interruptions.</good>
<principle name="benefits_over_features">
<bad>The concurrent file read feature uses parallel processing.</bad>
<good>Read multiple files at once, reducing interruptions.</good>
</principle>
<principle name="use_scenarios">
<bad>This feature improves efficiency.</bad>
<good>Instead of approving 10 file reads one by one, approve them all at once and get your answer faster.</good>
<bad>This improves efficiency.</bad>
<good>Instead of approving 10 file reads one-by-one, approve them all at once.</good>
</principle>
<principle name="avoid_implementation_details">
<bad>The feature uses a thread pool with configurable concurrency limits to process file I/O operations.</bad>
<good>Roo can read up to 100 files at once (you can change this limit in settings).</good>
<principle name="hide_implementation_details">
<bad>The feature uses a thread pool with configurable concurrency limits.</bad>
<good>Roo reads up to 100 files at once (changeable in settings).</good>
</principle>
<principle name="conversational_tone">
<principle name="direct_tone">
<bad>Users must configure the concurrent file read limit parameter.</bad>
<good>You can adjust how many files Roo reads at once in the settings.</good>
<good>Adjust how many files Roo reads at once in settings.</good>
</principle>
</writing_principles>
<structure_examples>
<example name="feature_introduction">
<example name="feature_intro">
<template><![CDATA[
# [Feature Name]
[One-sentence description of what it does for the user]
[One-sentence description of what it does.]
### Key Features
- [Benefit 1 - what users can do]
- [Benefit 2 - what problem it solves]
- [Benefit 3 - how it makes life easier]
- [Benefit 1]
- [Benefit 2]
- [Benefit 3]
---
]]></template>
</example>
<example name="why_it_matters">
<example name="use_case">
<template><![CDATA[
## Why This Matters
## Use Case
**Without [feature]**: [Description of the painful old way]
- [Specific pain point]
- [Another pain point]
- [Time/effort wasted]
**Before**: [Description of the old way]
- [Pain point]
- [Pain point]
**With [feature]**: [Description of the better experience]
**Now**: [Description of the new way]
]]></template>
</example>
<example name="configuration_section">
<example name="configuration">
<template><![CDATA[
## Configuration
You can customize this feature in Roo's settings:
Customize this feature in settings:
1. **[Human-friendly setting name]**
- What it does: [Plain language explanation]
- Default: [Default value] (this works well for most users)
- When to change: [Specific scenarios when users might want to adjust this]
1. **[Setting Name]**
- **Does**: [Plain language explanation.]
- **Default**: [Default value.] (Works for most.)
- **Change if**: [Specific scenarios to adjust this.]
2. **[Another setting]**
- What it does: [Plain language explanation]
- Default: [Default value]
- Try changing this if: [Specific use case]
2. **[Setting Name]**
- **Does**: [Plain language explanation.]
- **Default**: [Default value.]
- **Change if**: [Specific use case.]
]]></template>
</example>
<example name="common_questions">
<example name="faq">
<template><![CDATA[
## Common Questions
## FAQ
**"[Actual question users ask]"**
[Direct, helpful answer]
[Optional: Additional tip or context]
**"[User question]"**
- [Direct answer.]
- [Optional tip.]
**"[Another real question]"**
[Answer that addresses the concern]
[Optional: Link to more info]
**"[Technical question simplified]"**
[Non-technical explanation]
[Optional: "For developers:" with technical details]
**"[Another question]"**
- [Direct answer.]
- [Optional link.]
]]></template>
</example>
@ -95,160 +89,130 @@ You can customize this feature in Roo's settings:
<template><![CDATA[
## Troubleshooting
### [Problem symptom users would recognize]
**What's happening**: [Brief explanation]
**Quick fix**: [Immediate solution]
**If that doesn't work**: [Alternative solution]
### [Problem symptom]
**Cause**: [Brief explanation.]
**Fix**: [Immediate solution.]
**Alternate fix**: [Alternative solution.]
### [Another common issue]
**You might see this when**: [Scenario]
**Solution**:
1. [First step]
2. [Second step]
3. [If needed, third step]
### [Another issue]
**Scenario**: [When this happens.]
**Solution**:
1. [Step 1]
2. [Step 2]
]]></template>
</example>
<example name="help_section">
<template><![CDATA[
## Need Help?
Still having issues? Here's how to get help:
1. **Check our FAQ**: [Link to FAQ] - answers to common questions
2. **Report a bug**: [GitHub Issues link] - we typically respond within 24 hours
3. **Join the community**: [Discord/Forum link] - get help from other users
When reporting an issue, please include:
- What you were trying to do
- What happened instead
- Any error messages you saw
]]></template>
</example>
</structure_examples>
<tone_examples>
<friendly_explanations>
<example context="explaining a limit">
<explanations>
<example context="limit">
<technical>The system imposes a hard limit of 100 concurrent operations.</technical>
<friendly>Roo can handle up to 100 files at once - more than enough for most projects!</friendly>
<direct>Roo handles up to 100 files at once.</direct>
</example>
<example context="describing an error">
<example context="error">
<technical>Error: Maximum concurrency threshold exceeded.</technical>
<friendly>Oops! That's too many files at once. Try lowering the file limit in settings.</friendly>
<direct>Too many files requested. Lower the file limit in settings.</direct>
</example>
<example context="explaining a benefit">
<example context="benefit">
<technical>Reduces API call overhead through request batching.</technical>
<friendly>Get answers faster by reading all the files Roo needs in one go.</friendly>
<direct>Get answers faster by reading all needed files at once.</direct>
</example>
</friendly_explanations>
</explanations>
<visual_elements>
<use_emojis_sparingly>
<when>Error messages: ⚠️</when>
<when>Tips: 💡</when>
<when>Important notes: 📝</when>
<visuals>
<emojis>
<when>Error: ⚠️</when>
<when>Tip: 💡</when>
<when>Note: 📝</when>
<when>Security: 🔒</when>
</use_emojis_sparingly>
</emojis>
<use_formatting>
<bold>For emphasis on key points</bold>
<code>For settings names, file paths, or commands</code>
<blockquotes>For important callouts or warnings</blockquotes>
</use_formatting>
</visual_elements>
<formatting>
<bold>For emphasis</bold>
<code>For settings, file paths, or commands</code>
<blockquotes>For callouts or warnings</blockquotes>
</formatting>
</visuals>
</tone_examples>
<real_world_example>
<title>Concurrent File Reads Documentation</title>
<title>Concurrent File Reads Doc</title>
<content><![CDATA[
# Concurrent File Reads
The Concurrent File Reads feature allows Roo to read multiple files from your workspace in a single step. This significantly improves efficiency when working on tasks that require context from several files.
Read multiple files from your workspace in a single step.
### Key Features
- Read up to 100 files in a single request
- Enabled by default for a faster, more streamlined workflow
- Configurable to match your preferences and system capabilities
- Read up to 100 files in one request.
- Enabled by default for faster workflow.
- Configurable to match system capabilities.
---
## Why This Matters
## Use Case
**Previously**: When Roo needed to understand your project, you'd see multiple requests like:
- "Can I read `src/app.js`?" → You approve
- "Now can I read `src/utils.js`?" → You approve
- "And can I read `src/config.json`?" → You approve
**Before**: Multiple, sequential requests to read files:
- "Read `src/app.js`?" → Approve
- "Read `src/utils.js`?" → Approve
- "Read `src/config.json`?" → Approve
**With concurrent file reads**: Roo asks once to read all related files together, getting the full picture immediately and providing better assistance faster.
**Now**: Roo asks once to read all related files.
## How it Works
When you ask Roo to perform a task that involves multiple files, it will automatically identify the relevant files and read them together. This is especially useful for:
Roo automatically identifies and reads relevant files together for tasks requiring multi-file context, such as:
- Understanding components split across multiple files
- Refactoring code with dependencies
- Answering questions that require broad project context
- Understanding components split across multiple files.
- Refactoring code with dependencies.
- Answering questions requiring broad project context.
The [`read_file`](/advanced-usage/available-tools/read-file) tool automatically accepts multiple files in a single request.
The [`read_file`](/tools/read-file) tool accepts multiple files in a single request.
---
## Configuration
You can customize this feature in Roo's settings:
Customize in Roo's settings:
1. **Enable/Disable Concurrent File Reads**
- What it does: Controls whether Roo can read multiple files at once
- Default: Enabled (recommended for most users)
- When to disable: If using a less capable AI model or wanting more control
- **Does**: Toggles whether Roo can read multiple files at once.
- **Default**: Enabled.
- **Disable if**: Using a less capable AI model or requiring more access control.
2. **Concurrent File Reads Limit**
- What it does: Sets the maximum number of files Roo can read at once
- Default: 100 files
- When to adjust: Lower if you have memory constraints, raise for very large projects
- **Does**: Sets max number of files Roo can read at once.
- **Default**: 100.
- **Adjust**: Lower for memory constraints; raise for very large projects.
---
## Benefits
## FAQ
- **Faster Results**: Get comprehensive answers without multiple approval steps
- **Better Context**: Roo understands file relationships immediately
- **Less Interruption**: Approve once and continue working while Roo analyzes
**"Too many files are requested at once."**
- Lower the file limit in settings.
- Deny individual files in the batch dialog.
## Common Questions
**"Some files were denied but others were approved."**
- Normal behavior. Roo works with approved files.
- Files may be blocked by `.rooignore` settings.
**"Roo is asking for too many files at once"**
- Lower the concurrent file limit in settings
- You can still approve or deny individual files in the batch dialog
**"Does this use more memory?"**
- Yes, but the impact is usually minimal.
- If you see slowdowns, reduce the file limit.
**"Some files were denied but others approved"**
- This is normal - Roo works with the files you approve
- Files might be blocked by your `.rooignore` settings
**"Will this use more memory?"**
- Yes, but the impact is usually minimal
- If you notice slowdowns, try reducing the file limit
## Need Help?
If you run into issues:
1. Check the [FAQ section](/faq) for common solutions
2. Report problems on [GitHub Issues](https://github.com/RooCodeInc/Roo-Code/issues)
3. Include what you were trying to do and any error messages
]]></content>
</real_world_example>
<checklist>
<item>Does it start with benefits, not features?</item>
<item>Are technical terms explained or avoided?</item>
<item>Does it use "you" to address the reader?</item>
<item>Are there practical examples or scenarios?</item>
<item>Is the tone conversational and friendly?</item>
<item>Does it start with benefits?</item>
<item>Are technical terms avoided?</item>
<item>Is the tone direct?</item>
<item>Are there practical examples?</item>
<item>Are sections short and scannable?</item>
<item>Does it answer common user questions?</item>
<item>Is help easily accessible?</item>
<item>Does it answer user questions?</item>
<item>Is help accessible?</item>
</checklist>
</user_friendly_examples>

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

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

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

@ -27,7 +27,7 @@
<step number="2">
<name>Delegate: Analyze Requirements & Explore Codebase</name>
<instructions>
Launch a subtask in `code` 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.
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`.
@ -36,19 +36,50 @@
<message>
**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.
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. **Explore Codebase**: Use `codebase_search`, `read_file`, and other tools to explore the codebase. Identify all files that will need to be modified or created to address the issue. Analyze existing patterns and conventions.
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. **Create Implementation Plan**: Based on your analysis, create a comprehensive implementation plan. The plan should be detailed enough for another developer to execute. It must include:
- A summary of the issue and the proposed solution.
- A list of all files to be created or modified.
- A step-by-step guide for the code changes required in each file.
- A plan for writing or updating tests.
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. **Save the Plan**: Write the complete implementation plan to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md`.
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.
@ -110,19 +141,43 @@
<message>
**Task: Implement Code Changes Based on Plan**
You are an expert software developer. Your task is to implement the code changes exactly as described in the provided implementation 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`. Follow its instructions carefully.
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. **Implement Changes**: Use `apply_diff` and `write_to_file` to make the specified code changes. Adhere to all coding standards and patterns mentioned in the plan.
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 Tests**: Write new unit and integration tests as specified in the plan to ensure quality and prevent regressions.
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. **Track Modified Files**: As you modify or create files, keep a running list.
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. **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.
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.
</message>
</new_task>
@ -292,32 +347,59 @@
<message>
**Task: Prepare Pull Request Title and Body**
You are an expert at writing clear and concise pull request summaries.
You are an expert at writing clear and concise pull request summaries following the Roo Code contribution guidelines.
**Context Files:**
- **Issue**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json`
- **Plan**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/implementation_plan.md`
- **Verification**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/verification_results.md`
- **Translation Summary** (if exists): `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/translation_summary.md`
- **Modified Files**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json`
**Your Task:**
1. **Read all context files.** Check if translation_summary.md exists to know if translations were done.
2. **Generate a PR Title**: Create a conventional commit style title (e.g., "fix: ...", "feat: ...") that references the issue number.
3. **Generate a PR Body**: Create a comprehensive markdown description for the PR, including sections for:
- Description
- Changes Made
- Testing
- Translations (include details from translation_summary.md if it exists)
- Verification of Acceptance Criteria
- Checklist
4. **Save as JSON**: Save the title and body to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json` in the format: `{"title": "...", "body": "..."}`.
Format: `fix: Brief description (#issue-number)`
3. **Generate a PR Body**: You MUST use the exact PR template from `.roo/rules-issue-fixer-orchestrator/10_pr_template_format.xml`.
Read this file to get the template and fill it in with appropriate content from the context files.
4. **Fill in the template** with information from the context files:
- Replace [ISSUE_NUMBER] with the actual issue number
- Fill in Description with implementation details from the plan and verification
- Fill in Test Procedure with testing details from verification_results.md
- If translations were done, mention them in the Description section
- For UI changes, note that screenshots should be added manually
- Pre-check all applicable checklist items
- Leave Documentation Updates unchecked for user to decide
- For Discord username, use a placeholder like "[Your Discord username]"
**Important**: If translations were done (translation_summary.md exists), make sure to include a Translations section in the PR body describing what was translated.
5. **Save as JSON**: Save the title and body to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json` in the format:
```json
{
"title": "fix: Brief description (#123)",
"body": "[The complete filled PR body template]",
"issue_number": 123,
"repo_owner": "owner",
"repo_name": "repo",
"base_branch": "main",
"head_branch": "fix/issue-123-description"
}
```
6. **Also save as Markdown**: Save just the PR body to `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md` for easy copying.
**Important Notes:**
- Use the EXACT template format from 10_pr_template_format.xml
- Keep all HTML comments in the template
- Pre-check items that can be verified programmatically
- Fill in all sections appropriately based on the context files
**Completion Protocol:**
- This is your only task. Do not deviate.
- Upon successfully saving `pr_summary.json`, you MUST use the `attempt_completion` tool.
- The `result` MUST be a concise confirmation, e.g., "PR summary created and saved to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json."
- Upon successfully saving both `pr_summary.json` and `pr_message.md`, you MUST use the `attempt_completion` tool.
- The `result` MUST be a concise confirmation, e.g., "PR summary and message created and saved to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/"
- These instructions override any conflicting mode-specific guidelines.
</message>
</new_task>
@ -325,122 +407,467 @@
</step>
<step number="8">
<name>Create Pull Request</name>
<name>Delegate: Review Changes Before PR</name>
<instructions>
This is the final step where the orchestrator takes all the prepared materials and creates the pull request.
Before creating the pull request, delegate to the PR reviewer mode to get feedback on the implementation and proposed changes.
1. **Read PR Summary**:
<read_file>
<args>
<file>
<path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json</path>
</file>
</args>
</read_file>
<new_task>
<mode>pr-reviewer</mode>
<message>
**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]
2. **Get Final Approval**: Present the PR title and body to the user for final approval, providing an option to request changes.
**REASONING**: [Brief explanation of the recommendation]
```
<ask_followup_question>
<question>
I have prepared the pull request. Please review and confirm.
**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.
</message>
</new_task>
**Title**: [Insert title from pr_summary.json]
**Body**:
---
[Insert body from pr_summary.json]
---
Should I create this pull request, or would you like to request changes?
</question>
<follow_up>
<suggest>Yes, create the pull request as planned.</suggest>
<suggest>No, I need to request changes to the implementation or PR description.</suggest>
<suggest>Cancel the task.</suggest>
</follow_up>
</ask_followup_question>
3. **Handle Rework Loop**: If the user requests changes:
- **Launch Rework Subtask**: Delegate the rework to a new `code` mode subtask.
<new_task>
<mode>code</mode>
<message>
**Task: Rework Implementation Based on User Feedback**
The user has requested changes 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`
- **Draft PR Summary**: `.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json`
**Your Task:**
1. Ask the user for the specific changes they require.
2. Apply the requested code and documentation changes.
3. **Crucially, you must update the `implementation_plan.md` and `modified_files.json` files** to reflect the rework you have performed.
4. Do *not* proceed with any other steps.
**Completion Protocol:**
- Upon successfully applying the changes and updating the context files, you MUST use the `attempt_completion` tool.
- The `result` MUST be a concise confirmation, e.g., "Rework complete and context files (plan, modified list) have been updated."
</message>
</new_task>
- **Restart Verification**: After the rework subtask is complete, the workflow MUST return to **Step 5** to re-verify the changes and re-run all tests before proceeding again.
4. **Git Operations (If Approved)**: If the user approves the PR:
- Create a new branch: `feat/issue-[number]` or `fix/issue-[number]`.
- **Selectively add only the applicable files** to the git stage.
- Commit the staged changes.
- Push the new branch to the remote repository.
<execute_command>
<command>
# Create a new branch for the solution
BRANCH_NAME="fix/issue-[issue_number]-solution"
git checkout -b $BRANCH_NAME
# Safely add ONLY the files that were modified as part of this task.
# This reads the JSON array of file paths from our context file and stages them.
# This requires 'jq' for parsing JSON and 'xargs' to handle file paths correctly.
cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json | jq -r '.[]' | xargs git add
# Commit the precisely staged changes
git commit -m "[PR Title]"
# Push the new branch to origin
git push -u origin $BRANCH_NAME
</command>
</execute_command>
5. **Create PR**: Use the `gh` CLI to create the pull request.
<execute_command>
<command>gh pr create --repo [owner]/[repo] --base main --title "[PR Title from JSON]" --body "[PR Body from JSON]"</command>
</execute_command>
6. **Link to Issue**: Comment on the original issue with the PR link.
<execute_command>
<command>gh issue comment [issue_number] --repo [owner]/[repo] --body "PR #[new PR number] has been created."</command>
</execute_command>
After the review subtask completes, read and process the feedback.
</instructions>
</step>
<step number="9">
<name>Monitor PR Checks and Cleanup</name>
<name>Process Review Feedback and Decide Next Steps</name>
<instructions>
After creating the PR, monitor the CI checks and then clean up the temporary files.
After the PR review is complete, read the feedback and decide whether to make changes or proceed with PR creation.
1. **Monitor Checks**: Use `--watch` to monitor CI status in real-time.
<execute_command>
<command>gh pr checks [PR URL or number] --repo [owner]/[repo] --watch</command>
</execute_command>
1. **Read Review Feedback**:
<read_file>
<args>
<file>
<path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_review_feedback.md</path>
</file>
</args>
</read_file>
2. **Report Status**: Inform the user of the final status of the checks.
2. **Present Feedback to User**: Show the review feedback and ask for direction.
<ask_followup_question>
<question>
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?
</question>
<follow_up>
<suggest>Implement the suggested changes before creating the PR</suggest>
<suggest>Create the PR as-is, ignoring the review feedback</suggest>
<suggest>Discuss specific feedback points before deciding</suggest>
<suggest>Cancel the task</suggest>
</follow_up>
</ask_followup_question>
3. **Handle User Decision**:
**If user chooses to implement changes:**
- Launch a rework subtask to address the review feedback
<new_task>
<mode>code</mode>
<message>
**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."
</message>
</new_task>
- **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
</instructions>
</step>
<step number="10">
<name>Prepare Branch and Review Changes</name>
<instructions>
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:
<execute_command>
<command>
# Extract issue number from context
ISSUE_NUM=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json | jq -r '.number')
# Determine branch type based on labels or title
BRANCH_NAME="fix/issue-${ISSUE_NUM}-solution"
git checkout -b $BRANCH_NAME
</command>
</execute_command>
3. Review Files to be Committed:
a. Read the modified files list:
<read_file>
<path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json</path>
</read_file>
b. Check git status to ensure only intended files are staged:
<execute_command>
<command>git status --porcelain</command>
</execute_command>
c. Stage only the files from modified_files.json:
<execute_command>
<command>
# Stage only the files we actually modified
cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/modified_files.json | jq -r '.[]' | while read file; do
if [ -f "$file" ]; then
git add "$file"
fi
done
# Show what will be committed
git status --short
</command>
</execute_command>
4. Generate and Save Merge Diff:
<execute_command>
<command>
# Generate diff of staged changes
git diff --cached > .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes.diff
# Count lines in diff
LINE_COUNT=$(wc -l < .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes.diff)
echo "Diff contains $LINE_COUNT lines"
# If diff is too large, create a summary instead
if [ $LINE_COUNT -gt 2000 ]; then
echo "Creating summary due to large diff size..."
git diff --cached --stat > .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes_summary.txt
git diff --cached --name-status >> .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes_summary.txt
echo -e "\n\nNote: Full diff exceeds 2000 lines. Showing summary only." >> .roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes_summary.txt
fi
</command>
</execute_command>
5. Save PR Message to File:
Read the PR summary and save the formatted PR message:
<execute_command>
<command>
# Extract title and body from pr_summary.json
PR_TITLE=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json | jq -r '.title')
PR_BODY=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json | jq -r '.body')
# Save PR message to file
echo "PR Title: $PR_TITLE" > .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md
echo -e "\n---\n" >> .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md
echo "$PR_BODY" >> .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md
echo "PR message saved to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md"
</command>
</execute_command>
6. Present Changes for User Confirmation:
Read the diff (or summary) and PR message, then ask for confirmation:
a. Read the appropriate diff file:
<read_file>
<path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes.diff</path>
</read_file>
OR (if summary exists):
<read_file>
<path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/staged_changes_summary.txt</path>
</read_file>
b. Read the PR message:
<read_file>
<path>.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md</path>
</read_file>
c. Ask for user confirmation:
<ask_followup_question>
<question>
I've prepared the changes for commit. Here's what will be included:
**Files to be committed:**
[List files from modified_files.json]
**Changes summary:**
[Include diff or summary content]
**Proposed PR message:**
[Include PR message content]
How would you like to proceed?
</question>
<follow_up>
<suggest>Looks good, go ahead and commit the changes</suggest>
<suggest>I tested the changes, and something is wrong - let me explain...</suggest>
<suggest>I still need to test the changes manually before committing</suggest>
<suggest>I want to modify the PR message before proceeding</suggest>
<suggest>Cancel this task</suggest>
</follow_up>
</ask_followup_question>
7. Handle User Decision:
Based on user response:
**If "Looks good, go ahead and commit":**
- Proceed to commit and push:
<execute_command>
<command>
# Get PR title for commit message
PR_TITLE=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json | jq -r '.title')
git commit -m "$PR_TITLE"
git push -u origin $(git branch --show-current)
</command>
</execute_command>
- Continue to next step
**If "something is wrong":**
- Ask for details about the issue
- Launch a fix subtask in code mode to address the problems
- Return to Step 5 (Verify and Test) after fixes
**If "need to test manually":**
- Inform user that changes are staged but not committed
- Provide instructions for testing
- Wait for user to confirm testing is complete
**If "modify PR message":**
- Ask for the new PR title and body
- Update pr_summary.json with new content
- Return to step 5 of this workflow
**If "cancel":**
- Clean up staged changes and branch
- End workflow
</instructions>
</step>
<step number="11">
<name>Finalize and Create PR</name>
<instructions>
After user confirmation and successful commit, finalize the process.
1. Verify Push Success:
<execute_command>
<command>
# Verify the branch was pushed
git branch -r | grep $(git branch --show-current)
# Get the remote URL for PR creation
git remote get-url origin
</command>
</execute_command>
2. Present Final PR Creation Options:
<ask_followup_question>
<question>
The changes have been committed and pushed to the branch. The PR message has been saved to:
`.roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md`
You can now:
1. Create the PR manually using the saved message
2. Let me create the PR automatically
3. Make additional changes before creating the PR
What would you like to do?
</question>
<follow_up>
<suggest>Create the PR automatically using the saved message</suggest>
<suggest>I'll create the PR manually - just show me the branch name</suggest>
<suggest>I want to make more changes first</suggest>
</follow_up>
</ask_followup_question>
3. Handle Final Decision:
**If "Create PR automatically":**
- Read PR details and create:
<execute_command>
<command>
# Extract PR details
PR_TITLE=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json | jq -r '.title')
PR_BODY=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_summary.json | jq -r '.body')
ISSUE_NUM=$(cat .roo/temp/issue-fixer-orchestrator/[TASK_ID]/issue_context.json | jq -r '.number')
# Create PR
gh pr create --title "$PR_TITLE" --body "$PR_BODY" --base main
# Get PR number and link to issue
PR_NUM=$(gh pr list --head $(git branch --show-current) --json number -q '.[0].number')
gh issue comment $ISSUE_NUM --body "PR #$PR_NUM has been created to address this issue."
</command>
</execute_command>
**If "Create manually":**
- Show branch name and location of PR message:
<execute_command>
<command>
echo "Branch name: $(git branch --show-current)"
echo "PR message saved at: .roo/temp/issue-fixer-orchestrator/[TASK_ID]/pr_message.md"
echo "You can copy the PR message from the file above when creating the PR."
</command>
</execute_command>
**If "Make more changes":**
- Inform user they can continue working on the branch
- Provide the task directory location for reference
4. Cleanup:
Ask if user wants to clean up the temporary files:
<ask_followup_question>
<question>
Would you like me to clean up the temporary task files now, or keep them for reference?
</question>
<follow_up>
<suggest>Yes, clean up the temporary files</suggest>
<suggest>No, keep the files for now</suggest>
</follow_up>
</ask_followup_question>
If yes, clean up:
<execute_command>
<command>rm -rf .roo/temp/issue-fixer-orchestrator/[TASK_ID]</command>
</execute_command>
</instructions>
</step>
<step number="12">
<name>Monitor PR (Optional)</name>
<instructions>
If a PR was created automatically, offer to monitor its status.
1. Check if PR exists:
<execute_command>
<command>
# Check if there's a PR for the current branch
BRANCH=$(git branch --show-current)
gh pr list --head $BRANCH --json number,state,checks
</command>
</execute_command>
2. If PR exists, offer monitoring:
<ask_followup_question>
<question>
Would you like me to monitor the PR checks and CI status?
</question>
<follow_up>
<suggest>Yes, monitor the PR checks</suggest>
<suggest>No, I'll check it myself</suggest>
</follow_up>
</ask_followup_question>
3. If user wants monitoring:
<execute_command>
<command>
PR_NUM=$(gh pr list --head $(git branch --show-current) --json number -q '.[0].number')
echo "Monitoring PR #$PR_NUM checks..."
gh pr checks $PR_NUM --watch
</command>
</execute_command>
3. **Cleanup**: Remove the temporary task directory.
<execute_command>
<command>rm -rf .roo/temp/issue-fixer-orchestrator/[TASK_ID]</command>
</execute_command>
This concludes the orchestration workflow.
</instructions>
</step>

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

@ -24,9 +24,60 @@
- Adding translations to all supported language files
- Ensuring consistency with existing terminology
- Maintaining sync across all language resources
<commit_and_pr_best_practices>
<principle>Always verify files before committing</principle>
<guidelines>
- Review git status to ensure only intended files are staged
- Stage only files listed in modified_files.json
- Never commit unrelated changes or temporary files
- Always get user confirmation before committing
</guidelines>
<diff_management>
- Save full diff to staged_changes.diff for review
- If diff exceeds 2000 lines, create a summary instead
- Summary should include file stats and change types
- Always inform user when showing summary vs full diff
</diff_management>
<pr_message_handling>
- Save PR message in both JSON and Markdown formats
- pr_summary.json for programmatic use
- pr_message.md for manual PR creation
- Include all standard template sections
- Make PR message self-contained and ready to use
</pr_message_handling>
<user_confirmation_flow>
- Always ask for confirmation with clear options
- First option should be "Looks good, go ahead"
- Provide options for testing and issue reporting
- Allow PR message modification before proceeding
- Handle each user response appropriately
</user_confirmation_flow>
<temp_file_management>
- All delegated tasks must save outputs to .roo/temp/issue-fixer-orchestrator/[TASK_ID]/
- Keep all context files until user confirms cleanup
- Offer cleanup option after PR creation
- Never delete files without user permission
</temp_file_management>
</commit_and_pr_best_practices>
<codebase_exploration_guidelines>
<principle>Always use `codebase_search` FIRST to understand the codebase structure and find all related files before using other tools like `read_file`.</principle>
<architectural_understanding>
<title>Critical: Understand Component Interactions</title>
<mandatory_steps>
<step>Map the complete data flow from input to output</step>
<step>Identify ALL paired operations (import/export, save/load, encode/decode)</step>
<step>Find all consumers and dependencies of the affected code</step>
<step>Trace how data transformations occur throughout the system</step>
<step>Understand error propagation and handling patterns</step>
</mandatory_steps>
</architectural_understanding>
<for_bug_fixes>
<title>Investigation Checklist for Bug Fixes</title>
<item>Search for the specific error message or broken functionality.</item>
@ -34,6 +85,8 @@
<item>Locate related test files to understand expected behavior.</item>
<item>Identify all dependencies and import/export patterns for the affected code.</item>
<item>Find similar, working patterns in the codebase to use as a reference.</item>
<item>**CRITICAL**: For any operation being fixed, find and analyze its paired operations</item>
<item>Trace the complete data flow to understand all affected components</item>
</for_bug_fixes>
<for_features>
@ -42,10 +95,26 @@
<item>Find potential integration points (e.g., API routes, UI component registries).</item>
<item>Locate relevant configuration files that may need to be updated.</item>
<item>Identify common patterns, components, and utilities that should be reused.</item>
<item>**CRITICAL**: Design paired operations together (e.g., both import AND export)</item>
<item>Map all data transformations and state changes</item>
<item>Identify all downstream consumers of the new functionality</item>
</for_features>
<paired_operations_principle>
<title>Always Implement Paired Operations Together</title>
<examples>
<example>When fixing export, ALWAYS check and update import</example>
<example>When modifying save, ALWAYS verify load handles the changes</example>
<example>When changing serialization, ALWAYS update deserialization</example>
<example>When updating create, consider read/update/delete operations</example>
</examples>
<rationale>
Paired operations must maintain consistency. Changes to one without the other leads to data corruption, import failures, or broken functionality.
</rationale>
</paired_operations_principle>
<critical_note>
Always read multiple related files together to understand the full context, including coding conventions, testing patterns, and error handling approaches.
Always read multiple related files together to understand the full context. Never assume a change is isolated - trace its impact through the entire system.
</critical_note>
</codebase_exploration_guidelines>
</best_practices>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@ -1,229 +0,0 @@
<workflow>
<step number="1">
<name>Fetch Pull Request Information</name>
<instructions>
By default, use the GitHub MCP server to fetch and review pull requests from the
https://github.com/RooCodeInc/Roo-Code repository.
If the user provides a PR number or URL, extract the necessary information:
- Repository owner and name
- Pull request number
Use the GitHub MCP tool to fetch the PR details:
<use_mcp_tool>
<server_name>github</server_name>
<tool_name>get_pull_request</tool_name>
<arguments>
{
"owner": "[owner]",
"repo": "[repo]",
"pullNumber": [number]
}
</arguments>
</use_mcp_tool>
</instructions>
</step>
<step number="2">
<name>Fetch Associated Issue (If Any)</name>
<instructions>
Check the pull request body for a reference to a GitHub issue (e.g., "Fixes #123", "Closes #456").
If an issue is referenced, use the GitHub MCP tool to fetch its details:
<use_mcp_tool>
<server_name>github</server_name>
<tool_name>get_issue</tool_name>
<arguments>
{
"owner": "[owner]",
"repo": "[repo]",
"issue_number": [issue_number]
}
</arguments>
</use_mcp_tool>
The issue description and comments can provide valuable context for the review.
</instructions>
</step>
<step number="3">
<name>Fetch Pull Request Diff</name>
<instructions>
Get the pull request diff to understand the changes:
<use_mcp_tool>
<server_name>github</server_name>
<tool_name>get_pull_request_diff</tool_name>
<arguments>
{
"owner": "[owner]",
"repo": "[repo]",
"pullNumber": [number]
}
</arguments>
</use_mcp_tool>
</instructions>
</step>
<step number="4">
<name>Check Out Pull Request Locally</name>
<instructions>
Use the GitHub CLI (e.g. `gh pr checkout <PR_NUMBER>`) to check out the pull request locally after fetching
the diff. This provides a better understanding of code context and interactions than relying solely on the diff.
<execute_command>
<command>gh pr checkout [PR_NUMBER]</command>
</execute_command>
This allows you to:
- Navigate the actual code structure
- Understand how changes interact with existing code
- Get better context for your review
</instructions>
</step>
<step number="5">
<name>Fetch Existing PR Comments</name>
<instructions>
Get existing comments to understand the current discussion state:
<use_mcp_tool>
<server_name>github</server_name>
<tool_name>get_pull_request_comments</tool_name>
<arguments>
{
"owner": "[owner]",
"repo": "[repo]",
"pullNumber": [number]
}
</arguments>
</use_mcp_tool>
Examine existing PR comments to understand the current state of discussion. When reading the comments and reviews, you must verify which are resolved by reading the files they refer to, since they might already be resolved. This prevents you from making redundant suggestions.
</instructions>
</step>
<step number="6">
<name>Perform Comprehensive Review</name>
<instructions>
Review the pull request thoroughly:
- Verify that the changes are directly related to the linked issue and do not include unrelated modifications.
- Focus primarily on the changes made in the PR.
- Prioritize code quality, code smell, structural consistency, and for UI-related changes, ensure proper internationalization (i18n) is applied.
- Watch for signs of technical debt (e.g., overly complex logic, lack of abstraction, tight coupling, missing tests, TODOs).
- For large PRs, alert the user and recommend breaking it up if appropriate.
- NEVER run tests or execute code in PR Reviewer mode. The repository likely has automated testing. Your role is limited to:
- Code review and analysis
- Leaving review comments
- Checking code quality and structure
- Reviewing test coverage and quality (without execution)
Document your findings:
- Code quality issues
- Structural improvements
- Missing tests or documentation
- Potential bugs or edge cases
- Performance concerns
- Security considerations
</instructions>
</step>
<step number="7">
<name>Prepare Review Comments</name>
<instructions>
Format your review comments following these guidelines:
Your suggestions should:
- Use a **friendly, curious tone** — prefer asking: "Is this intentional?" or "Could we approach this differently to improve X?"
- Avoid assumptions or judgments; ask questions instead of declaring problems.
- Skip ALL praise and positive comments. Focus exclusively on issues that need attention.
- Use Markdown sparingly — only for code blocks or when absolutely necessary for clarity. Avoid markdown headings (###, ##, etc.) entirely.
- Avoid including internal evaluation terminology (e.g., scores or internal tags) in public comments.
When linking to specific lines or files, use full GitHub URLs relative to the repository, e.g.
`https://github.com/RooCodeInc/Roo-Code/blob/main/src/api/providers/human-relay.ts#L50`.
Group your comments by:
- Critical issues (must fix)
- Important suggestions (should consider)
- Minor improvements (nice to have)
</instructions>
</step>
<step number="8">
<name>Preview Review with User</name>
<instructions>
Always show the user a preview of your review suggestions and comments before taking any action.
Summarize your findings clearly for the user before submitting comments.
<ask_followup_question>
<question>I've completed my review of PR #[number]. Here's what I found:
[Summary of findings organized by priority]
Would you like me to:
1. Create a comprehensive review with all comments
2. Modify any of the suggestions
3. Skip the review submission</question>
<follow_up>
<suggest>Create a comprehensive review</suggest>
<suggest>Let me modify the suggestions first</suggest>
<suggest>Skip submission - just wanted the analysis</suggest>
</follow_up>
</ask_followup_question>
</instructions>
</step>
<step number="9">
<name>Submit Review</name>
<instructions>
Based on user preference, submit the review as a comprehensive review:
1. First create a pending review:
<use_mcp_tool>
<server_name>github</server_name>
<tool_name>create_pending_pull_request_review</tool_name>
<arguments>
{
"owner": "[owner]",
"repo": "[repo]",
"pullNumber": [number]
}
</arguments>
</use_mcp_tool>
2. Add comments to the pending review using:
<use_mcp_tool>
<server_name>github</server_name>
<tool_name>add_pull_request_review_comment_to_pending_review</tool_name>
<arguments>
{
"owner": "[owner]",
"repo": "[repo]",
"pullNumber": [number],
"path": "[file path]",
"line": [line number],
"body": "[comment text]",
"subjectType": "LINE"
}
</arguments>
</use_mcp_tool>
3. Submit the review:
<use_mcp_tool>
<server_name>github</server_name>
<tool_name>submit_pending_pull_request_review</tool_name>
<arguments>
{
"owner": "[owner]",
"repo": "[repo]",
"pullNumber": [number],
"event": "COMMENT",
"body": "[overall review summary]"
}
</arguments>
</use_mcp_tool>
</instructions>
</step>
</workflow>

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

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

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

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

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

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

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

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

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

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

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

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

39
.roomodes
View file

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

25
packages/cloud/src/CloudService.ts
View file

@ -12,7 +12,9 @@ import { TelemetryService } from "@roo-code/telemetry"
import { CloudServiceCallbacks } from "./types"
import type { AuthService } from "./auth"
import { WebAuthService, StaticTokenAuthService } from "./auth"
import { SettingsService } from "./SettingsService"
import type { SettingsService } from "./SettingsService"
import { CloudSettingsService } from "./CloudSettingsService"
import { StaticSettingsService } from "./StaticSettingsService"
import { TelemetryClient } from "./TelemetryClient"
import { ShareService, TaskNotFoundError } from "./ShareService"
@ -59,13 +61,20 @@ export class CloudService {
this.authService.on("logged-out", this.authListener)
this.authService.on("user-info", this.authListener)
this.settingsService = new SettingsService(
this.context,
this.authService,
() => this.callbacks.stateChanged?.(),
this.log,
)
this.settingsService.initialize()
// Check for static settings environment variable
const staticOrgSettings = process.env.ROO_CODE_CLOUD_ORG_SETTINGS
if (staticOrgSettings && staticOrgSettings.length > 0) {
this.settingsService = new StaticSettingsService(staticOrgSettings, this.log)
} else {
const cloudSettingsService = new CloudSettingsService(
this.context,
this.authService,
() => this.callbacks.stateChanged?.(),
this.log,
)
cloudSettingsService.initialize()
this.settingsService = cloudSettingsService
}
this.telemetryClient = new TelemetryClient(this.authService, this.settingsService)

136
packages/cloud/src/CloudSettingsService.ts Normal file
View file

@ -0,0 +1,136 @@
import * as vscode from "vscode"
import {
ORGANIZATION_ALLOW_ALL,
OrganizationAllowList,
OrganizationSettings,
organizationSettingsSchema,
} from "@roo-code/types"
import { getRooCodeApiUrl } from "./Config"
import type { AuthService } from "./auth"
import { RefreshTimer } from "./RefreshTimer"
import type { SettingsService } from "./SettingsService"
const ORGANIZATION_SETTINGS_CACHE_KEY = "organization-settings"
export class CloudSettingsService implements SettingsService {
private context: vscode.ExtensionContext
private authService: AuthService
private settings: OrganizationSettings | undefined = undefined
private timer: RefreshTimer
private log: (...args: unknown[]) => void
constructor(
context: vscode.ExtensionContext,
authService: AuthService,
callback: () => void,
log?: (...args: unknown[]) => void,
) {
this.context = context
this.authService = authService
this.log = log || console.log
this.timer = new RefreshTimer({
callback: async () => {
return await this.fetchSettings(callback)
},
successInterval: 30000,
initialBackoffMs: 1000,
maxBackoffMs: 30000,
})
}
public initialize(): void {
this.loadCachedSettings()
// Clear cached settings if we have missed a log out.
if (this.authService.getState() == "logged-out" && this.settings) {
this.removeSettings()
}
this.authService.on("active-session", () => {
this.timer.start()
})
this.authService.on("logged-out", () => {
this.timer.stop()
this.removeSettings()
})
if (this.authService.hasActiveSession()) {
this.timer.start()
}
}
private async fetchSettings(callback: () => void): Promise<boolean> {
const token = this.authService.getSessionToken()
if (!token) {
return false
}
try {
const response = await fetch(`${getRooCodeApiUrl()}/api/organization-settings`, {
headers: {
Authorization: `Bearer ${token}`,
},
})
if (!response.ok) {
this.log(
"[cloud-settings] Failed to fetch organization settings:",
response.status,
response.statusText,
)
return false
}
const data = await response.json()
const result = organizationSettingsSchema.safeParse(data)
if (!result.success) {
this.log("[cloud-settings] Invalid organization settings format:", result.error)
return false
}
const newSettings = result.data
if (!this.settings || this.settings.version !== newSettings.version) {
this.settings = newSettings
await this.cacheSettings()
callback()
}
return true
} catch (error) {
this.log("[cloud-settings] Error fetching organization settings:", error)
return false
}
}
private async cacheSettings(): Promise<void> {
await this.context.globalState.update(ORGANIZATION_SETTINGS_CACHE_KEY, this.settings)
}
private loadCachedSettings(): void {
this.settings = this.context.globalState.get<OrganizationSettings>(ORGANIZATION_SETTINGS_CACHE_KEY)
}
public getAllowList(): OrganizationAllowList {
return this.settings?.allowList || ORGANIZATION_ALLOW_ALL
}
public getSettings(): OrganizationSettings | undefined {
return this.settings
}
private async removeSettings(): Promise<void> {
this.settings = undefined
await this.cacheSettings()
}
public dispose(): void {
this.timer.stop()
}
}

150
packages/cloud/src/SettingsService.ts
View file

@ -1,135 +1,23 @@
import * as vscode from "vscode"
import type { OrganizationAllowList, OrganizationSettings } from "@roo-code/types"
import {
ORGANIZATION_ALLOW_ALL,
OrganizationAllowList,
OrganizationSettings,
organizationSettingsSchema,
} from "@roo-code/types"
/**
* Interface for settings services that provide organization settings
*/
export interface SettingsService {
/**
* Get the organization allow list
* @returns The organization allow list or default if none available
*/
getAllowList(): OrganizationAllowList
import { getRooCodeApiUrl } from "./Config"
import type { AuthService } from "./auth"
import { RefreshTimer } from "./RefreshTimer"
/**
* Get the current organization settings
* @returns The organization settings or undefined if none available
*/
getSettings(): OrganizationSettings | undefined
const ORGANIZATION_SETTINGS_CACHE_KEY = "organization-settings"
export class SettingsService {
private context: vscode.ExtensionContext
private authService: AuthService
private settings: OrganizationSettings | undefined = undefined
private timer: RefreshTimer
private log: (...args: unknown[]) => void
constructor(
context: vscode.ExtensionContext,
authService: AuthService,
callback: () => void,
log?: (...args: unknown[]) => void,
) {
this.context = context
this.authService = authService
this.log = log || console.log
this.timer = new RefreshTimer({
callback: async () => {
return await this.fetchSettings(callback)
},
successInterval: 30000,
initialBackoffMs: 1000,
maxBackoffMs: 30000,
})
}
public initialize(): void {
this.loadCachedSettings()
// Clear cached settings if we have missed a log out.
if (this.authService.getState() == "logged-out" && this.settings) {
this.removeSettings()
}
this.authService.on("active-session", () => {
this.timer.start()
})
this.authService.on("logged-out", () => {
this.timer.stop()
this.removeSettings()
})
if (this.authService.hasActiveSession()) {
this.timer.start()
}
}
private async fetchSettings(callback: () => void): Promise<boolean> {
const token = this.authService.getSessionToken()
if (!token) {
return false
}
try {
const response = await fetch(`${getRooCodeApiUrl()}/api/organization-settings`, {
headers: {
Authorization: `Bearer ${token}`,
},
})
if (!response.ok) {
this.log(
"[cloud-settings] Failed to fetch organization settings:",
response.status,
response.statusText,
)
return false
}
const data = await response.json()
const result = organizationSettingsSchema.safeParse(data)
if (!result.success) {
this.log("[cloud-settings] Invalid organization settings format:", result.error)
return false
}
const newSettings = result.data
if (!this.settings || this.settings.version !== newSettings.version) {
this.settings = newSettings
await this.cacheSettings()
callback()
}
return true
} catch (error) {
this.log("[cloud-settings] Error fetching organization settings:", error)
return false
}
}
private async cacheSettings(): Promise<void> {
await this.context.globalState.update(ORGANIZATION_SETTINGS_CACHE_KEY, this.settings)
}
private loadCachedSettings(): void {
this.settings = this.context.globalState.get<OrganizationSettings>(ORGANIZATION_SETTINGS_CACHE_KEY)
}
public getAllowList(): OrganizationAllowList {
return this.settings?.allowList || ORGANIZATION_ALLOW_ALL
}
public getSettings(): OrganizationSettings | undefined {
return this.settings
}
public async removeSettings(): Promise<void> {
this.settings = undefined
await this.cacheSettings()
}
public dispose(): void {
this.timer.stop()
}
/**
* Dispose of the settings service and clean up resources
*/
dispose(): void
}

41
packages/cloud/src/StaticSettingsService.ts Normal file
View file

@ -0,0 +1,41 @@
import {
ORGANIZATION_ALLOW_ALL,
OrganizationAllowList,
OrganizationSettings,
organizationSettingsSchema,
} from "@roo-code/types"
import type { SettingsService } from "./SettingsService"
export class StaticSettingsService implements SettingsService {
private settings: OrganizationSettings
private log: (...args: unknown[]) => void
constructor(envValue: string, log?: (...args: unknown[]) => void) {
this.log = log || console.log
this.settings = this.parseEnvironmentSettings(envValue)
}
private parseEnvironmentSettings(envValue: string): OrganizationSettings {
try {
const decodedValue = Buffer.from(envValue, "base64").toString("utf-8")
const parsedJson = JSON.parse(decodedValue)
return organizationSettingsSchema.parse(parsedJson)
} catch (error) {
this.log(`[StaticSettingsService] failed to parse static settings: ${error.message}`, error)
throw new Error("Failed to parse static settings", { cause: error })
}
}
public getAllowList(): OrganizationAllowList {
return this.settings?.allowList || ORGANIZATION_ALLOW_ALL
}
public getSettings(): OrganizationSettings | undefined {
return this.settings
}
public dispose(): void {
// No resources to clean up for static settings
}
}

2
packages/cloud/src/TelemetryClient.ts
View file

@ -8,7 +8,7 @@ import { BaseTelemetryClient } from "@roo-code/telemetry"
import { getRooCodeApiUrl } from "./Config"
import type { AuthService } from "./auth"
import { SettingsService } from "./SettingsService"
import type { SettingsService } from "./SettingsService"
export class TelemetryClient extends BaseTelemetryClient {
constructor(

146
packages/cloud/src/__tests__/CloudService.integration.test.ts Normal file
View file

@ -0,0 +1,146 @@
// npx vitest run src/__tests__/CloudService.integration.test.ts
import * as vscode from "vscode"
import { CloudService } from "../CloudService"
import { StaticSettingsService } from "../StaticSettingsService"
import { CloudSettingsService } from "../CloudSettingsService"
vi.mock("vscode", () => ({
ExtensionContext: vi.fn(),
window: {
showInformationMessage: vi.fn(),
showErrorMessage: vi.fn(),
},
env: {
openExternal: vi.fn(),
},
Uri: {
parse: vi.fn(),
},
}))
describe("CloudService Integration - Settings Service Selection", () => {
let mockContext: vscode.ExtensionContext
beforeEach(() => {
CloudService.resetInstance()
mockContext = {
subscriptions: [],
workspaceState: {
get: vi.fn(),
update: vi.fn(),
keys: vi.fn().mockReturnValue([]),
},
secrets: {
get: vi.fn(),
store: vi.fn(),
delete: vi.fn(),
onDidChange: vi.fn().mockReturnValue({ dispose: vi.fn() }),
},
globalState: {
get: vi.fn(),
update: vi.fn(),
setKeysForSync: vi.fn(),
keys: vi.fn().mockReturnValue([]),
},
extensionUri: { scheme: "file", path: "/mock/path" },
extensionPath: "/mock/path",
extensionMode: 1,
asAbsolutePath: vi.fn((relativePath: string) => `/mock/path/${relativePath}`),
storageUri: { scheme: "file", path: "/mock/storage" },
extension: {
packageJSON: {
version: "1.0.0",
},
},
} as unknown as vscode.ExtensionContext
})
afterEach(() => {
CloudService.resetInstance()
delete process.env.ROO_CODE_CLOUD_ORG_SETTINGS
delete process.env.ROO_CODE_CLOUD_TOKEN
})
it("should use CloudSettingsService when no environment variable is set", async () => {
// Ensure no environment variables are set
delete process.env.ROO_CODE_CLOUD_ORG_SETTINGS
delete process.env.ROO_CODE_CLOUD_TOKEN
const cloudService = await CloudService.createInstance(mockContext)
// Access the private settingsService to check its type
const settingsService = (cloudService as unknown as { settingsService: unknown }).settingsService
expect(settingsService).toBeInstanceOf(CloudSettingsService)
})
it("should use StaticSettingsService when ROO_CODE_CLOUD_ORG_SETTINGS is set", async () => {
const validSettings = {
version: 1,
cloudSettings: {
recordTaskMessages: true,
enableTaskSharing: true,
taskShareExpirationDays: 30,
},
defaultSettings: {
enableCheckpoints: true,
},
allowList: {
allowAll: true,
providers: {},
},
}
// Set the environment variable
process.env.ROO_CODE_CLOUD_ORG_SETTINGS = Buffer.from(JSON.stringify(validSettings)).toString("base64")
const cloudService = await CloudService.createInstance(mockContext)
// Access the private settingsService to check its type
const settingsService = (cloudService as unknown as { settingsService: unknown }).settingsService
expect(settingsService).toBeInstanceOf(StaticSettingsService)
// Verify the settings are correctly loaded
expect(cloudService.getAllowList()).toEqual(validSettings.allowList)
})
it("should throw error when ROO_CODE_CLOUD_ORG_SETTINGS contains invalid data", async () => {
// Set invalid environment variable
process.env.ROO_CODE_CLOUD_ORG_SETTINGS = "invalid-base64-data"
await expect(CloudService.createInstance(mockContext)).rejects.toThrow("Failed to initialize CloudService")
})
it("should prioritize static token auth when both environment variables are set", async () => {
const validSettings = {
version: 1,
cloudSettings: {
recordTaskMessages: true,
enableTaskSharing: true,
taskShareExpirationDays: 30,
},
defaultSettings: {
enableCheckpoints: true,
},
allowList: {
allowAll: true,
providers: {},
},
}
// Set both environment variables
process.env.ROO_CODE_CLOUD_TOKEN = "test-token"
process.env.ROO_CODE_CLOUD_ORG_SETTINGS = Buffer.from(JSON.stringify(validSettings)).toString("base64")
const cloudService = await CloudService.createInstance(mockContext)
// Should use StaticSettingsService for settings
const settingsService = (cloudService as unknown as { settingsService: unknown }).settingsService
expect(settingsService).toBeInstanceOf(StaticSettingsService)
// Should use StaticTokenAuthService for auth (from the existing logic)
expect(cloudService.isAuthenticated()).toBe(true)
expect(cloudService.hasActiveSession()).toBe(true)
})
})

8
packages/cloud/src/__tests__/CloudService.test.ts
View file

@ -5,7 +5,7 @@ import type { ClineMessage } from "@roo-code/types"
import { CloudService } from "../CloudService"
import { WebAuthService } from "../auth/WebAuthService"
import { SettingsService } from "../SettingsService"
import { CloudSettingsService } from "../CloudSettingsService"
import { ShareService, TaskNotFoundError } from "../ShareService"
import { TelemetryClient } from "../TelemetryClient"
import { TelemetryService } from "@roo-code/telemetry"
@ -29,7 +29,7 @@ vi.mock("@roo-code/telemetry")
vi.mock("../auth/WebAuthService")
vi.mock("../SettingsService")
vi.mock("../CloudSettingsService")
vi.mock("../ShareService")
@ -150,7 +150,7 @@ describe("CloudService", () => {
}
vi.mocked(WebAuthService).mockImplementation(() => mockAuthService as unknown as WebAuthService)
vi.mocked(SettingsService).mockImplementation(() => mockSettingsService as unknown as SettingsService)
vi.mocked(CloudSettingsService).mockImplementation(() => mockSettingsService as unknown as CloudSettingsService)
vi.mocked(ShareService).mockImplementation(() => mockShareService as unknown as ShareService)
vi.mocked(TelemetryClient).mockImplementation(() => mockTelemetryClient as unknown as TelemetryClient)
@ -176,7 +176,7 @@ describe("CloudService", () => {
expect(cloudService).toBeInstanceOf(CloudService)
expect(WebAuthService).toHaveBeenCalledWith(mockContext, expect.any(Function))
expect(SettingsService).toHaveBeenCalledWith(
expect(CloudSettingsService).toHaveBeenCalledWith(
mockContext,
mockAuthService,
expect.any(Function),

102
packages/cloud/src/__tests__/StaticSettingsService.test.ts Normal file
View file

@ -0,0 +1,102 @@
// npx vitest run src/__tests__/StaticSettingsService.test.ts
import { StaticSettingsService } from "../StaticSettingsService"
describe("StaticSettingsService", () => {
const validSettings = {
version: 1,
cloudSettings: {
recordTaskMessages: true,
enableTaskSharing: true,
taskShareExpirationDays: 30,
},
defaultSettings: {
enableCheckpoints: true,
maxOpenTabsContext: 10,
},
allowList: {
allowAll: false,
providers: {
anthropic: {
allowAll: true,
},
},
},
}
const validBase64 = Buffer.from(JSON.stringify(validSettings)).toString("base64")
describe("constructor", () => {
it("should parse valid base64 encoded JSON settings", () => {
const service = new StaticSettingsService(validBase64)
expect(service.getSettings()).toEqual(validSettings)
})
it("should throw error for invalid base64", () => {
expect(() => new StaticSettingsService("invalid-base64!@#")).toThrow("Failed to parse static settings")
})
it("should throw error for invalid JSON", () => {
const invalidJson = Buffer.from("{ invalid json }").toString("base64")
expect(() => new StaticSettingsService(invalidJson)).toThrow("Failed to parse static settings")
})
it("should throw error for invalid schema", () => {
const invalidSettings = { invalid: "schema" }
const invalidBase64 = Buffer.from(JSON.stringify(invalidSettings)).toString("base64")
expect(() => new StaticSettingsService(invalidBase64)).toThrow("Failed to parse static settings")
})
})
describe("getAllowList", () => {
it("should return the allow list from settings", () => {
const service = new StaticSettingsService(validBase64)
expect(service.getAllowList()).toEqual(validSettings.allowList)
})
})
describe("getSettings", () => {
it("should return the parsed settings", () => {
const service = new StaticSettingsService(validBase64)
expect(service.getSettings()).toEqual(validSettings)
})
})
describe("dispose", () => {
it("should be a no-op for static settings", () => {
const service = new StaticSettingsService(validBase64)
expect(() => service.dispose()).not.toThrow()
})
})
describe("logging", () => {
it("should use provided logger for errors", () => {
const mockLog = vi.fn()
expect(() => new StaticSettingsService("invalid-base64!@#", mockLog)).toThrow()
expect(mockLog).toHaveBeenCalledWith(
expect.stringContaining("[StaticSettingsService] failed to parse static settings:"),
expect.any(Error),
)
})
it("should use console.log as default logger for errors", () => {
const consoleSpy = vi.spyOn(console, "log").mockImplementation(() => {})
expect(() => new StaticSettingsService("invalid-base64!@#")).toThrow()
expect(consoleSpy).toHaveBeenCalledWith(
expect.stringContaining("[StaticSettingsService] failed to parse static settings:"),
expect.any(Error),
)
consoleSpy.mockRestore()
})
it("should not log anything for successful parsing", () => {
const mockLog = vi.fn()
new StaticSettingsService(validBase64, mockLog)
expect(mockLog).not.toHaveBeenCalled()
})
})
})

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

@ -1,5 +1,19 @@
import { z } from "zod"
/**
* Codebase Index Constants
*/
export const CODEBASE_INDEX_DEFAULTS = {
MIN_SEARCH_RESULTS: 10,
MAX_SEARCH_RESULTS: 200,
DEFAULT_SEARCH_RESULTS: 50,
SEARCH_RESULTS_STEP: 10,
MIN_SEARCH_SCORE: 0,
MAX_SEARCH_SCORE: 1,
DEFAULT_SEARCH_MIN_SCORE: 0.4,
SEARCH_SCORE_STEP: 0.05,
} as const
/**
* CodebaseIndexConfig
*/
@ -10,7 +24,16 @@ export const codebaseIndexConfigSchema = z.object({
codebaseIndexEmbedderProvider: z.enum(["openai", "ollama", "openai-compatible", "gemini"]).optional(),
codebaseIndexEmbedderBaseUrl: z.string().optional(),
codebaseIndexEmbedderModelId: z.string().optional(),
codebaseIndexEmbedderModelDimension: z.number().optional(),
codebaseIndexSearchMinScore: z.number().min(0).max(1).optional(),
codebaseIndexSearchMaxResults: z
.number()
.min(CODEBASE_INDEX_DEFAULTS.MIN_SEARCH_RESULTS)
.max(CODEBASE_INDEX_DEFAULTS.MAX_SEARCH_RESULTS)
.optional(),
// OpenAI Compatible specific fields
codebaseIndexOpenAiCompatibleBaseUrl: z.string().optional(),
codebaseIndexOpenAiCompatibleModelDimension: z.number().optional(),
})
export type CodebaseIndexConfig = z.infer<typeof codebaseIndexConfigSchema>

2
packages/types/src/global-settings.ts
View file

@ -47,6 +47,7 @@ export const globalSettingsSchema = z.object({
alwaysAllowExecute: z.boolean().optional(),
alwaysAllowFollowupQuestions: z.boolean().optional(),
followupAutoApproveTimeoutMs: z.number().optional(),
alwaysAllowUpdateTodoList: z.boolean().optional(),
allowedCommands: z.array(z.string()).optional(),
allowedMaxRequests: z.number().nullish(),
autoCondenseContext: z.boolean().optional(),
@ -195,6 +196,7 @@ export const EVALS_SETTINGS: RooCodeSettings = {
alwaysAllowSubtasks: true,
alwaysAllowExecute: true,
alwaysAllowFollowupQuestions: true,
alwaysAllowUpdateTodoList: true,
followupAutoApproveTimeoutMs: 0,
allowedCommands: ["*"],

1
packages/types/src/index.ts
View file

@ -20,3 +20,4 @@ export * from "./terminal.js"
export * from "./tool.js"
export * from "./type-fu.js"
export * from "./vscode.js"
export * from "./todo.js"

1
packages/types/src/message.ts
View file

@ -106,6 +106,7 @@ export const clineSays = [
"condense_context",
"condense_context_error",
"codebase_search_result",
"user_edit_todos",
] as const
export const clineSaySchema = z.enum(clineSays)

19
packages/types/src/todo.ts Normal file
View file

@ -0,0 +1,19 @@
import { z } from "zod"
/**
* TodoStatus
*/
export const todoStatusSchema = z.enum(["pending", "in_progress", "completed"] as const)
export type TodoStatus = z.infer<typeof todoStatusSchema>
/**
* TodoItem
*/
export const todoItemSchema = z.object({
id: z.string(),
content: z.string(),
status: todoStatusSchema,
})
export type TodoItem = z.infer<typeof todoItemSchema>

1
packages/types/src/tool.ts
View file

@ -33,6 +33,7 @@ export const toolNames = [
"new_task",
"fetch_instructions",
"codebase_search",
"update_todo_list",
] as const
export const toolNamesSchema = z.enum(toolNames)

4
src/api/providers/fetchers/openrouter.ts
View file

@ -190,10 +190,8 @@ export const parseOpenRouterModel = ({
const supportsPromptCache = typeof cacheWritesPrice !== "undefined" && typeof cacheReadsPrice !== "undefined"
const useMaxTokens = OPEN_ROUTER_REASONING_BUDGET_MODELS.has(id) || id.startsWith("anthropic/")
const modelInfo: ModelInfo = {
maxTokens: useMaxTokens ? maxTokens || 0 : 0,
maxTokens: maxTokens || Math.ceil(model.context_length * 0.2),
contextWindow: model.context_length,
supportsImages: modality?.includes("image") ?? false,
supportsPromptCache,

6
src/core/assistant-message/presentAssistantMessage.ts
View file

@ -26,6 +26,7 @@ import { attemptCompletionTool } from "../tools/attemptCompletionTool"
import { newTaskTool } from "../tools/newTaskTool"
import { checkpointSave } from "../checkpoints"
import { updateTodoListTool } from "../tools/updateTodoListTool"
import { formatResponse } from "../prompts/responses"
import { validateToolUse } from "../tools/validateToolUse"
@ -205,6 +206,8 @@ export async function presentAssistantMessage(cline: Task) {
return `[${block.name} to '${block.params.mode_slug}'${block.params.reason ? ` because: ${block.params.reason}` : ""}]`
case "codebase_search": // Add case for the new tool
return `[${block.name} for '${block.params.query}']`
case "update_todo_list":
return `[${block.name}]`
case "new_task": {
const mode = block.params.mode ?? defaultModeSlug
const message = block.params.message ?? "(no message)"
@ -410,6 +413,9 @@ export async function presentAssistantMessage(cline: Task) {
case "write_to_file":
await writeToFileTool(cline, block, askApproval, handleError, pushToolResult, removeClosingTag)
break
case "update_todo_list":
await updateTodoListTool(cline, block, askApproval, handleError, pushToolResult, removeClosingTag)
break
case "apply_diff": {
// Get the provider and state to check experiment settings
const provider = cline.providerRef.deref()

17
src/core/config/ContextProxy.ts
View file

@ -147,6 +147,23 @@ export class ContextProxy {
: this.originalContext.secrets.store(key, value)
}
/**
* Refresh secrets from storage and update cache
* This is useful when you need to ensure the cache has the latest values
*/
async refreshSecrets(): Promise<void> {
const promises = SECRET_STATE_KEYS.map(async (key) => {
try {
this.secretCache[key] = await this.originalContext.secrets.get(key)
} catch (error) {
logger.error(
`Error refreshing secret ${key}: ${error instanceof Error ? error.message : String(error)}`,
)
}
})
await Promise.all(promises)
}
private getAllSecretState(): SecretState {
return Object.fromEntries(SECRET_STATE_KEYS.map((key) => [key, this.getSecret(key)]))
}

1019
src/core/config/__tests__/importExport.spec.ts
View file

File diff suppressed because it is too large Load diff

11
src/core/config/importExport.ts
View file

@ -68,6 +68,9 @@ export async function importSettingsFromPath(
(globalSettings.customModes ?? []).map((mode) => customModesManager.updateCustomMode(mode.slug, mode)),
)
// OpenAI Compatible settings are now correctly stored in codebaseIndexConfig
// They will be imported automatically with the config - no special handling needed
await providerSettingsManager.import(providerProfiles)
await contextProxy.setValues(globalSettings)
@ -161,10 +164,16 @@ export const exportSettings = async ({ providerSettingsManager, contextProxy }:
return
}
// OpenAI Compatible settings are now correctly stored in codebaseIndexConfig
// No workaround needed - they will be exported automatically with the config
const dirname = path.dirname(uri.fsPath)
await fs.mkdir(dirname, { recursive: true })
await safeWriteJson(uri.fsPath, { providerProfiles, globalSettings })
} catch (e) {}
} catch (e) {
console.error("Failed to export settings:", e)
// Don't re-throw - the UI will handle showing error messages
}
}
/**

32
src/core/environment/__tests__/getEnvironmentDetails.spec.ts
View file

@ -190,6 +190,19 @@ describe("getEnvironmentDetails", () => {
expect(listFiles).not.toHaveBeenCalled()
})
it("should skip file listing when maxWorkspaceFiles is 0", async () => {
mockProvider.getState.mockResolvedValue({
...mockState,
maxWorkspaceFiles: 0,
})
const result = await getEnvironmentDetails(mockCline as Task, true)
expect(listFiles).not.toHaveBeenCalled()
expect(result).toContain("Workspace files context disabled")
expect(formatResponse.formatFilesList).not.toHaveBeenCalled()
})
it("should include recently modified files if any", async () => {
;(mockCline.fileContextTracker!.getAndClearRecentlyModifiedFiles as Mock).mockReturnValue([
"modified1.ts",
@ -300,25 +313,6 @@ describe("getEnvironmentDetails", () => {
expect(mockInactiveTerminal.getCurrentWorkingDirectory).toHaveBeenCalled()
})
it("should include warning when file writing is not allowed", async () => {
;(isToolAllowedForMode as Mock).mockReturnValue(false)
;(getModeBySlug as Mock).mockImplementation((slug: string) => {
if (slug === "code") {
return { name: "💻 Code" }
}
if (slug === defaultModeSlug) {
return { name: "Default Mode" }
}
return null
})
const result = await getEnvironmentDetails(mockCline as Task)
expect(result).toContain("NOTE: You are currently in '💻 Code' mode, which does not allow write operations")
})
it("should include experiment-specific details when Power Steering is enabled", async () => {
mockState.experiments = { [EXPERIMENT_IDS.POWER_STEERING]: true }
;(experiments.isEnabled as Mock).mockReturnValue(true)

40
src/core/environment/getEnvironmentDetails.ts
View file

@ -18,6 +18,7 @@ import { arePathsEqual } from "../../utils/path"
import { formatResponse } from "../prompts/responses"
import { Task } from "../task/Task"
import { formatReminderSection } from "./reminder"
export async function getEnvironmentDetails(cline: Task, includeFileDetails: boolean = false) {
let details = ""
@ -232,16 +233,6 @@ export async function getEnvironmentDetails(cline: Task, includeFileDetails: boo
}
}
// Add warning if not in code mode.
if (
!isToolAllowedForMode("write_to_file", currentMode, customModes ?? [], { apply_diff: cline.diffEnabled }) &&
!isToolAllowedForMode("apply_diff", currentMode, customModes ?? [], { apply_diff: cline.diffEnabled })
) {
const currentModeName = getModeBySlug(currentMode, customModes)?.name ?? currentMode
const defaultModeName = getModeBySlug(defaultModeSlug, customModes)?.name ?? defaultModeSlug
details += `\n\nNOTE: You are currently in '${currentModeName}' mode, which does not allow write operations. To write files, the user will need to switch to a mode that supports file writing, such as '${defaultModeName}' mode.`
}
if (includeFileDetails) {
details += `\n\n# Current Workspace Directory (${cline.cwd.toPosix()}) Files\n`
const isDesktop = arePathsEqual(cline.cwd, path.join(os.homedir(), "Desktop"))
@ -252,20 +243,27 @@ export async function getEnvironmentDetails(cline: Task, includeFileDetails: boo
details += "(Desktop files not shown automatically. Use list_files to explore if needed.)"
} else {
const maxFiles = maxWorkspaceFiles ?? 200
const [files, didHitLimit] = await listFiles(cline.cwd, true, maxFiles)
const { showRooIgnoredFiles = true } = state ?? {}
const result = formatResponse.formatFilesList(
cline.cwd,
files,
didHitLimit,
cline.rooIgnoreController,
showRooIgnoredFiles,
)
// Early return for limit of 0
if (maxFiles === 0) {
details += "(Workspace files context disabled. Use list_files to explore if needed.)"
} else {
const [files, didHitLimit] = await listFiles(cline.cwd, true, maxFiles)
const { showRooIgnoredFiles = true } = state ?? {}
details += result
const result = formatResponse.formatFilesList(
cline.cwd,
files,
didHitLimit,
cline.rooIgnoreController,
showRooIgnoredFiles,
)
details += result
}
}
}
return `<environment_details>\n${details.trim()}\n</environment_details>`
const reminderSection = formatReminderSection(cline.todoList)
return `<environment_details>\n${details.trim()}\n${reminderSection}\n</environment_details>`
}

38
src/core/environment/reminder.ts Normal file
View file

@ -0,0 +1,38 @@
import { TodoItem, TodoStatus } from "@roo-code/types"
/**
* Format the reminders section as a markdown block in English, with basic instructions.
*/
export function formatReminderSection(todoList?: TodoItem[]): string {
if (!todoList || todoList.length === 0) {
return ""
}
const statusMap: Record<TodoStatus, string> = {
pending: "Pending",
in_progress: "In Progress",
completed: "Completed",
}
const lines: string[] = [
"====",
"",
"REMINDERS",
"",
"Below is your current list of reminders for this task. Keep them updated as you progress.",
"",
]
lines.push("| # | Content | Status |")
lines.push("|---|---------|--------|")
todoList.forEach((item, idx) => {
const escapedContent = item.content.replace(/\\/g, "\\\\").replace(/\|/g, "\\|")
lines.push(`| ${idx + 1} | ${escapedContent} | ${statusMap[item.status] || item.status} |`)
})
lines.push("")
lines.push(
"",
"IMPORTANT: When task status changes, remember to call the `update_todo_list` tool to update your progress.",
"",
)
return lines.join("\n")
}

70
src/core/prompts/__tests__/__snapshots__/add-custom-instructions/architect-mode-prompt.snap
View file

@ -368,6 +368,76 @@ Example:
</new_task>
## update_todo_list
**Description:**
Replace the entire TODO list with an updated checklist reflecting the current state. Always provide the full list; the system will overwrite the previous one. This tool is designed for step-by-step task tracking, allowing you to confirm completion of each step before updating, update multiple task statuses at once (e.g., mark one as completed and start the next), and dynamically add new todos discovered during long or complex tasks.
**Checklist Format:**
- Use a single-level markdown checklist (no nesting or subtasks).
- List todos in the intended execution order.
- Status options:
- [ ] Task description (pending)
- [x] Task description (completed)
- [-] Task description (in progress)
**Status Rules:**
- [ ] = pending (not started)
- [x] = completed (fully finished, no unresolved issues)
- [-] = in_progress (currently being worked on)
**Core Principles:**
- Before updating, always confirm which todos have been completed since the last update.
- You may update multiple statuses in a single update (e.g., mark the previous as completed and the next as in progress).
- When a new actionable item is discovered during a long or complex task, add it to the todo list immediately.
- Do not remove any unfinished todos unless explicitly instructed.
- Always retain all unfinished tasks, updating their status as needed.
- Only mark a task as completed when it is fully accomplished (no partials, no unresolved dependencies).
- If a task is blocked, keep it as in_progress and add a new todo describing what needs to be resolved.
- Remove tasks only if they are no longer relevant or if the user requests deletion.
**Usage Example:**
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[-] Implement core logic
[ ] Write tests
[ ] Update documentation
</todos>
</update_todo_list>
*After completing "Implement core logic" and starting "Write tests":*
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[x] Implement core logic
[-] Write tests
[ ] Update documentation
[ ] Add performance benchmarks
</todos>
</update_todo_list>
**When to Use:**
- The task involves multiple steps or requires ongoing tracking.
- You need to update the status of several todos at once.
- New actionable items are discovered during task execution.
- The user requests a todo list or provides multiple tasks.
- The task is complex and benefits from clear, stepwise progress tracking.
**When NOT to Use:**
- There is only a single, trivial task.
- The task can be completed in one or two simple steps.
- The request is purely conversational or informational.
**Task Management Guidelines:**
- Mark task as completed immediately after all work of the current task is done.
- Start the next task by marking it as in_progress.
- Add new todos as soon as they are identified.
- Use clear, descriptive task names.
# Tool Use Guidelines
1. In <thinking> tags, assess what information you already have and what information you need to proceed with the task.

70
src/core/prompts/__tests__/__snapshots__/add-custom-instructions/ask-mode-prompt.snap
View file

@ -265,6 +265,76 @@ Example:
</new_task>
## update_todo_list
**Description:**
Replace the entire TODO list with an updated checklist reflecting the current state. Always provide the full list; the system will overwrite the previous one. This tool is designed for step-by-step task tracking, allowing you to confirm completion of each step before updating, update multiple task statuses at once (e.g., mark one as completed and start the next), and dynamically add new todos discovered during long or complex tasks.
**Checklist Format:**
- Use a single-level markdown checklist (no nesting or subtasks).
- List todos in the intended execution order.
- Status options:
- [ ] Task description (pending)
- [x] Task description (completed)
- [-] Task description (in progress)
**Status Rules:**
- [ ] = pending (not started)
- [x] = completed (fully finished, no unresolved issues)
- [-] = in_progress (currently being worked on)
**Core Principles:**
- Before updating, always confirm which todos have been completed since the last update.
- You may update multiple statuses in a single update (e.g., mark the previous as completed and the next as in progress).
- When a new actionable item is discovered during a long or complex task, add it to the todo list immediately.
- Do not remove any unfinished todos unless explicitly instructed.
- Always retain all unfinished tasks, updating their status as needed.
- Only mark a task as completed when it is fully accomplished (no partials, no unresolved dependencies).
- If a task is blocked, keep it as in_progress and add a new todo describing what needs to be resolved.
- Remove tasks only if they are no longer relevant or if the user requests deletion.
**Usage Example:**
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[-] Implement core logic
[ ] Write tests
[ ] Update documentation
</todos>
</update_todo_list>
*After completing "Implement core logic" and starting "Write tests":*
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[x] Implement core logic
[-] Write tests
[ ] Update documentation
[ ] Add performance benchmarks
</todos>
</update_todo_list>
**When to Use:**
- The task involves multiple steps or requires ongoing tracking.
- You need to update the status of several todos at once.
- New actionable items are discovered during task execution.
- The user requests a todo list or provides multiple tasks.
- The task is complex and benefits from clear, stepwise progress tracking.
**When NOT to Use:**
- There is only a single, trivial task.
- The task can be completed in one or two simple steps.
- The request is purely conversational or informational.
**Task Management Guidelines:**
- Mark task as completed immediately after all work of the current task is done.
- Start the next task by marking it as in_progress.
- Add new todos as soon as they are identified.
- Use clear, descriptive task names.
# Tool Use Guidelines
1. In <thinking> tags, assess what information you already have and what information you need to proceed with the task.

70
src/core/prompts/__tests__/__snapshots__/add-custom-instructions/mcp-server-creation-disabled.snap
View file

@ -417,6 +417,76 @@ Example:
</new_task>
## update_todo_list
**Description:**
Replace the entire TODO list with an updated checklist reflecting the current state. Always provide the full list; the system will overwrite the previous one. This tool is designed for step-by-step task tracking, allowing you to confirm completion of each step before updating, update multiple task statuses at once (e.g., mark one as completed and start the next), and dynamically add new todos discovered during long or complex tasks.
**Checklist Format:**
- Use a single-level markdown checklist (no nesting or subtasks).
- List todos in the intended execution order.
- Status options:
- [ ] Task description (pending)
- [x] Task description (completed)
- [-] Task description (in progress)
**Status Rules:**
- [ ] = pending (not started)
- [x] = completed (fully finished, no unresolved issues)
- [-] = in_progress (currently being worked on)
**Core Principles:**
- Before updating, always confirm which todos have been completed since the last update.
- You may update multiple statuses in a single update (e.g., mark the previous as completed and the next as in progress).
- When a new actionable item is discovered during a long or complex task, add it to the todo list immediately.
- Do not remove any unfinished todos unless explicitly instructed.
- Always retain all unfinished tasks, updating their status as needed.
- Only mark a task as completed when it is fully accomplished (no partials, no unresolved dependencies).
- If a task is blocked, keep it as in_progress and add a new todo describing what needs to be resolved.
- Remove tasks only if they are no longer relevant or if the user requests deletion.
**Usage Example:**
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[-] Implement core logic
[ ] Write tests
[ ] Update documentation
</todos>
</update_todo_list>
*After completing "Implement core logic" and starting "Write tests":*
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[x] Implement core logic
[-] Write tests
[ ] Update documentation
[ ] Add performance benchmarks
</todos>
</update_todo_list>
**When to Use:**
- The task involves multiple steps or requires ongoing tracking.
- You need to update the status of several todos at once.
- New actionable items are discovered during task execution.
- The user requests a todo list or provides multiple tasks.
- The task is complex and benefits from clear, stepwise progress tracking.
**When NOT to Use:**
- There is only a single, trivial task.
- The task can be completed in one or two simple steps.
- The request is purely conversational or informational.
**Task Management Guidelines:**
- Mark task as completed immediately after all work of the current task is done.
- Start the next task by marking it as in_progress.
- Add new todos as soon as they are identified.
- Use clear, descriptive task names.
# Tool Use Guidelines
1. In <thinking> tags, assess what information you already have and what information you need to proceed with the task.

70
src/core/prompts/__tests__/__snapshots__/add-custom-instructions/mcp-server-creation-enabled.snap
View file

@ -417,6 +417,76 @@ Example:
</new_task>
## update_todo_list
**Description:**
Replace the entire TODO list with an updated checklist reflecting the current state. Always provide the full list; the system will overwrite the previous one. This tool is designed for step-by-step task tracking, allowing you to confirm completion of each step before updating, update multiple task statuses at once (e.g., mark one as completed and start the next), and dynamically add new todos discovered during long or complex tasks.
**Checklist Format:**
- Use a single-level markdown checklist (no nesting or subtasks).
- List todos in the intended execution order.
- Status options:
- [ ] Task description (pending)
- [x] Task description (completed)
- [-] Task description (in progress)
**Status Rules:**
- [ ] = pending (not started)
- [x] = completed (fully finished, no unresolved issues)
- [-] = in_progress (currently being worked on)
**Core Principles:**
- Before updating, always confirm which todos have been completed since the last update.
- You may update multiple statuses in a single update (e.g., mark the previous as completed and the next as in progress).
- When a new actionable item is discovered during a long or complex task, add it to the todo list immediately.
- Do not remove any unfinished todos unless explicitly instructed.
- Always retain all unfinished tasks, updating their status as needed.
- Only mark a task as completed when it is fully accomplished (no partials, no unresolved dependencies).
- If a task is blocked, keep it as in_progress and add a new todo describing what needs to be resolved.
- Remove tasks only if they are no longer relevant or if the user requests deletion.
**Usage Example:**
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[-] Implement core logic
[ ] Write tests
[ ] Update documentation
</todos>
</update_todo_list>
*After completing "Implement core logic" and starting "Write tests":*
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[x] Implement core logic
[-] Write tests
[ ] Update documentation
[ ] Add performance benchmarks
</todos>
</update_todo_list>
**When to Use:**
- The task involves multiple steps or requires ongoing tracking.
- You need to update the status of several todos at once.
- New actionable items are discovered during task execution.
- The user requests a todo list or provides multiple tasks.
- The task is complex and benefits from clear, stepwise progress tracking.
**When NOT to Use:**
- There is only a single, trivial task.
- The task can be completed in one or two simple steps.
- The request is purely conversational or informational.
**Task Management Guidelines:**
- Mark task as completed immediately after all work of the current task is done.
- Start the next task by marking it as in_progress.
- Add new todos as soon as they are identified.
- Use clear, descriptive task names.
# Tool Use Guidelines
1. In <thinking> tags, assess what information you already have and what information you need to proceed with the task.

70
src/core/prompts/__tests__/__snapshots__/add-custom-instructions/partial-reads-enabled.snap
View file

@ -373,6 +373,76 @@ Example:
</new_task>
## update_todo_list
**Description:**
Replace the entire TODO list with an updated checklist reflecting the current state. Always provide the full list; the system will overwrite the previous one. This tool is designed for step-by-step task tracking, allowing you to confirm completion of each step before updating, update multiple task statuses at once (e.g., mark one as completed and start the next), and dynamically add new todos discovered during long or complex tasks.
**Checklist Format:**
- Use a single-level markdown checklist (no nesting or subtasks).
- List todos in the intended execution order.
- Status options:
- [ ] Task description (pending)
- [x] Task description (completed)
- [-] Task description (in progress)
**Status Rules:**
- [ ] = pending (not started)
- [x] = completed (fully finished, no unresolved issues)
- [-] = in_progress (currently being worked on)
**Core Principles:**
- Before updating, always confirm which todos have been completed since the last update.
- You may update multiple statuses in a single update (e.g., mark the previous as completed and the next as in progress).
- When a new actionable item is discovered during a long or complex task, add it to the todo list immediately.
- Do not remove any unfinished todos unless explicitly instructed.
- Always retain all unfinished tasks, updating their status as needed.
- Only mark a task as completed when it is fully accomplished (no partials, no unresolved dependencies).
- If a task is blocked, keep it as in_progress and add a new todo describing what needs to be resolved.
- Remove tasks only if they are no longer relevant or if the user requests deletion.
**Usage Example:**
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[-] Implement core logic
[ ] Write tests
[ ] Update documentation
</todos>
</update_todo_list>
*After completing "Implement core logic" and starting "Write tests":*
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[x] Implement core logic
[-] Write tests
[ ] Update documentation
[ ] Add performance benchmarks
</todos>
</update_todo_list>
**When to Use:**
- The task involves multiple steps or requires ongoing tracking.
- You need to update the status of several todos at once.
- New actionable items are discovered during task execution.
- The user requests a todo list or provides multiple tasks.
- The task is complex and benefits from clear, stepwise progress tracking.
**When NOT to Use:**
- There is only a single, trivial task.
- The task can be completed in one or two simple steps.
- The request is purely conversational or informational.
**Task Management Guidelines:**
- Mark task as completed immediately after all work of the current task is done.
- Start the next task by marking it as in_progress.
- Add new todos as soon as they are identified.
- Use clear, descriptive task names.
# Tool Use Guidelines
1. In <thinking> tags, assess what information you already have and what information you need to proceed with the task.

70
src/core/prompts/__tests__/__snapshots__/system-prompt/consistent-system-prompt.snap
View file

@ -368,6 +368,76 @@ Example:
</new_task>
## update_todo_list
**Description:**
Replace the entire TODO list with an updated checklist reflecting the current state. Always provide the full list; the system will overwrite the previous one. This tool is designed for step-by-step task tracking, allowing you to confirm completion of each step before updating, update multiple task statuses at once (e.g., mark one as completed and start the next), and dynamically add new todos discovered during long or complex tasks.
**Checklist Format:**
- Use a single-level markdown checklist (no nesting or subtasks).
- List todos in the intended execution order.
- Status options:
- [ ] Task description (pending)
- [x] Task description (completed)
- [-] Task description (in progress)
**Status Rules:**
- [ ] = pending (not started)
- [x] = completed (fully finished, no unresolved issues)
- [-] = in_progress (currently being worked on)
**Core Principles:**
- Before updating, always confirm which todos have been completed since the last update.
- You may update multiple statuses in a single update (e.g., mark the previous as completed and the next as in progress).
- When a new actionable item is discovered during a long or complex task, add it to the todo list immediately.
- Do not remove any unfinished todos unless explicitly instructed.
- Always retain all unfinished tasks, updating their status as needed.
- Only mark a task as completed when it is fully accomplished (no partials, no unresolved dependencies).
- If a task is blocked, keep it as in_progress and add a new todo describing what needs to be resolved.
- Remove tasks only if they are no longer relevant or if the user requests deletion.
**Usage Example:**
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[-] Implement core logic
[ ] Write tests
[ ] Update documentation
</todos>
</update_todo_list>
*After completing "Implement core logic" and starting "Write tests":*
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[x] Implement core logic
[-] Write tests
[ ] Update documentation
[ ] Add performance benchmarks
</todos>
</update_todo_list>
**When to Use:**
- The task involves multiple steps or requires ongoing tracking.
- You need to update the status of several todos at once.
- New actionable items are discovered during task execution.
- The user requests a todo list or provides multiple tasks.
- The task is complex and benefits from clear, stepwise progress tracking.
**When NOT to Use:**
- There is only a single, trivial task.
- The task can be completed in one or two simple steps.
- The request is purely conversational or informational.
**Task Management Guidelines:**
- Mark task as completed immediately after all work of the current task is done.
- Start the next task by marking it as in_progress.
- Add new todos as soon as they are identified.
- Use clear, descriptive task names.
# Tool Use Guidelines
1. In <thinking> tags, assess what information you already have and what information you need to proceed with the task.

70
src/core/prompts/__tests__/__snapshots__/system-prompt/with-computer-use-support.snap
View file

@ -421,6 +421,76 @@ Example:
</new_task>
## update_todo_list
**Description:**
Replace the entire TODO list with an updated checklist reflecting the current state. Always provide the full list; the system will overwrite the previous one. This tool is designed for step-by-step task tracking, allowing you to confirm completion of each step before updating, update multiple task statuses at once (e.g., mark one as completed and start the next), and dynamically add new todos discovered during long or complex tasks.
**Checklist Format:**
- Use a single-level markdown checklist (no nesting or subtasks).
- List todos in the intended execution order.
- Status options:
- [ ] Task description (pending)
- [x] Task description (completed)
- [-] Task description (in progress)
**Status Rules:**
- [ ] = pending (not started)
- [x] = completed (fully finished, no unresolved issues)
- [-] = in_progress (currently being worked on)
**Core Principles:**
- Before updating, always confirm which todos have been completed since the last update.
- You may update multiple statuses in a single update (e.g., mark the previous as completed and the next as in progress).
- When a new actionable item is discovered during a long or complex task, add it to the todo list immediately.
- Do not remove any unfinished todos unless explicitly instructed.
- Always retain all unfinished tasks, updating their status as needed.
- Only mark a task as completed when it is fully accomplished (no partials, no unresolved dependencies).
- If a task is blocked, keep it as in_progress and add a new todo describing what needs to be resolved.
- Remove tasks only if they are no longer relevant or if the user requests deletion.
**Usage Example:**
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[-] Implement core logic
[ ] Write tests
[ ] Update documentation
</todos>
</update_todo_list>
*After completing "Implement core logic" and starting "Write tests":*
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[x] Implement core logic
[-] Write tests
[ ] Update documentation
[ ] Add performance benchmarks
</todos>
</update_todo_list>
**When to Use:**
- The task involves multiple steps or requires ongoing tracking.
- You need to update the status of several todos at once.
- New actionable items are discovered during task execution.
- The user requests a todo list or provides multiple tasks.
- The task is complex and benefits from clear, stepwise progress tracking.
**When NOT to Use:**
- There is only a single, trivial task.
- The task can be completed in one or two simple steps.
- The request is purely conversational or informational.
**Task Management Guidelines:**
- Mark task as completed immediately after all work of the current task is done.
- Start the next task by marking it as in_progress.
- Add new todos as soon as they are identified.
- Use clear, descriptive task names.
# Tool Use Guidelines
1. In <thinking> tags, assess what information you already have and what information you need to proceed with the task.

70
src/core/prompts/__tests__/__snapshots__/system-prompt/with-diff-enabled-false.snap
View file

@ -368,6 +368,76 @@ Example:
</new_task>
## update_todo_list
**Description:**
Replace the entire TODO list with an updated checklist reflecting the current state. Always provide the full list; the system will overwrite the previous one. This tool is designed for step-by-step task tracking, allowing you to confirm completion of each step before updating, update multiple task statuses at once (e.g., mark one as completed and start the next), and dynamically add new todos discovered during long or complex tasks.
**Checklist Format:**
- Use a single-level markdown checklist (no nesting or subtasks).
- List todos in the intended execution order.
- Status options:
- [ ] Task description (pending)
- [x] Task description (completed)
- [-] Task description (in progress)
**Status Rules:**
- [ ] = pending (not started)
- [x] = completed (fully finished, no unresolved issues)
- [-] = in_progress (currently being worked on)
**Core Principles:**
- Before updating, always confirm which todos have been completed since the last update.
- You may update multiple statuses in a single update (e.g., mark the previous as completed and the next as in progress).
- When a new actionable item is discovered during a long or complex task, add it to the todo list immediately.
- Do not remove any unfinished todos unless explicitly instructed.
- Always retain all unfinished tasks, updating their status as needed.
- Only mark a task as completed when it is fully accomplished (no partials, no unresolved dependencies).
- If a task is blocked, keep it as in_progress and add a new todo describing what needs to be resolved.
- Remove tasks only if they are no longer relevant or if the user requests deletion.
**Usage Example:**
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[-] Implement core logic
[ ] Write tests
[ ] Update documentation
</todos>
</update_todo_list>
*After completing "Implement core logic" and starting "Write tests":*
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[x] Implement core logic
[-] Write tests
[ ] Update documentation
[ ] Add performance benchmarks
</todos>
</update_todo_list>
**When to Use:**
- The task involves multiple steps or requires ongoing tracking.
- You need to update the status of several todos at once.
- New actionable items are discovered during task execution.
- The user requests a todo list or provides multiple tasks.
- The task is complex and benefits from clear, stepwise progress tracking.
**When NOT to Use:**
- There is only a single, trivial task.
- The task can be completed in one or two simple steps.
- The request is purely conversational or informational.
**Task Management Guidelines:**
- Mark task as completed immediately after all work of the current task is done.
- Start the next task by marking it as in_progress.
- Add new todos as soon as they are identified.
- Use clear, descriptive task names.
# Tool Use Guidelines
1. In <thinking> tags, assess what information you already have and what information you need to proceed with the task.

70
src/core/prompts/__tests__/__snapshots__/system-prompt/with-diff-enabled-true.snap
View file

@ -456,6 +456,76 @@ Example:
</new_task>
## update_todo_list
**Description:**
Replace the entire TODO list with an updated checklist reflecting the current state. Always provide the full list; the system will overwrite the previous one. This tool is designed for step-by-step task tracking, allowing you to confirm completion of each step before updating, update multiple task statuses at once (e.g., mark one as completed and start the next), and dynamically add new todos discovered during long or complex tasks.
**Checklist Format:**
- Use a single-level markdown checklist (no nesting or subtasks).
- List todos in the intended execution order.
- Status options:
- [ ] Task description (pending)
- [x] Task description (completed)
- [-] Task description (in progress)
**Status Rules:**
- [ ] = pending (not started)
- [x] = completed (fully finished, no unresolved issues)
- [-] = in_progress (currently being worked on)
**Core Principles:**
- Before updating, always confirm which todos have been completed since the last update.
- You may update multiple statuses in a single update (e.g., mark the previous as completed and the next as in progress).
- When a new actionable item is discovered during a long or complex task, add it to the todo list immediately.
- Do not remove any unfinished todos unless explicitly instructed.
- Always retain all unfinished tasks, updating their status as needed.
- Only mark a task as completed when it is fully accomplished (no partials, no unresolved dependencies).
- If a task is blocked, keep it as in_progress and add a new todo describing what needs to be resolved.
- Remove tasks only if they are no longer relevant or if the user requests deletion.
**Usage Example:**
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[-] Implement core logic
[ ] Write tests
[ ] Update documentation
</todos>
</update_todo_list>
*After completing "Implement core logic" and starting "Write tests":*
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[x] Implement core logic
[-] Write tests
[ ] Update documentation
[ ] Add performance benchmarks
</todos>
</update_todo_list>
**When to Use:**
- The task involves multiple steps or requires ongoing tracking.
- You need to update the status of several todos at once.
- New actionable items are discovered during task execution.
- The user requests a todo list or provides multiple tasks.
- The task is complex and benefits from clear, stepwise progress tracking.
**When NOT to Use:**
- There is only a single, trivial task.
- The task can be completed in one or two simple steps.
- The request is purely conversational or informational.
**Task Management Guidelines:**
- Mark task as completed immediately after all work of the current task is done.
- Start the next task by marking it as in_progress.
- Add new todos as soon as they are identified.
- Use clear, descriptive task names.
# Tool Use Guidelines
1. In <thinking> tags, assess what information you already have and what information you need to proceed with the task.

70
src/core/prompts/__tests__/__snapshots__/system-prompt/with-diff-enabled-undefined.snap
View file

@ -368,6 +368,76 @@ Example:
</new_task>
## update_todo_list
**Description:**
Replace the entire TODO list with an updated checklist reflecting the current state. Always provide the full list; the system will overwrite the previous one. This tool is designed for step-by-step task tracking, allowing you to confirm completion of each step before updating, update multiple task statuses at once (e.g., mark one as completed and start the next), and dynamically add new todos discovered during long or complex tasks.
**Checklist Format:**
- Use a single-level markdown checklist (no nesting or subtasks).
- List todos in the intended execution order.
- Status options:
- [ ] Task description (pending)
- [x] Task description (completed)
- [-] Task description (in progress)
**Status Rules:**
- [ ] = pending (not started)
- [x] = completed (fully finished, no unresolved issues)
- [-] = in_progress (currently being worked on)
**Core Principles:**
- Before updating, always confirm which todos have been completed since the last update.
- You may update multiple statuses in a single update (e.g., mark the previous as completed and the next as in progress).
- When a new actionable item is discovered during a long or complex task, add it to the todo list immediately.
- Do not remove any unfinished todos unless explicitly instructed.
- Always retain all unfinished tasks, updating their status as needed.
- Only mark a task as completed when it is fully accomplished (no partials, no unresolved dependencies).
- If a task is blocked, keep it as in_progress and add a new todo describing what needs to be resolved.
- Remove tasks only if they are no longer relevant or if the user requests deletion.
**Usage Example:**
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[-] Implement core logic
[ ] Write tests
[ ] Update documentation
</todos>
</update_todo_list>
*After completing "Implement core logic" and starting "Write tests":*
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[x] Implement core logic
[-] Write tests
[ ] Update documentation
[ ] Add performance benchmarks
</todos>
</update_todo_list>
**When to Use:**
- The task involves multiple steps or requires ongoing tracking.
- You need to update the status of several todos at once.
- New actionable items are discovered during task execution.
- The user requests a todo list or provides multiple tasks.
- The task is complex and benefits from clear, stepwise progress tracking.
**When NOT to Use:**
- There is only a single, trivial task.
- The task can be completed in one or two simple steps.
- The request is purely conversational or informational.
**Task Management Guidelines:**
- Mark task as completed immediately after all work of the current task is done.
- Start the next task by marking it as in_progress.
- Add new todos as soon as they are identified.
- Use clear, descriptive task names.
# Tool Use Guidelines
1. In <thinking> tags, assess what information you already have and what information you need to proceed with the task.

70
src/core/prompts/__tests__/__snapshots__/system-prompt/with-different-viewport-size.snap
View file

@ -421,6 +421,76 @@ Example:
</new_task>
## update_todo_list
**Description:**
Replace the entire TODO list with an updated checklist reflecting the current state. Always provide the full list; the system will overwrite the previous one. This tool is designed for step-by-step task tracking, allowing you to confirm completion of each step before updating, update multiple task statuses at once (e.g., mark one as completed and start the next), and dynamically add new todos discovered during long or complex tasks.
**Checklist Format:**
- Use a single-level markdown checklist (no nesting or subtasks).
- List todos in the intended execution order.
- Status options:
- [ ] Task description (pending)
- [x] Task description (completed)
- [-] Task description (in progress)
**Status Rules:**
- [ ] = pending (not started)
- [x] = completed (fully finished, no unresolved issues)
- [-] = in_progress (currently being worked on)
**Core Principles:**
- Before updating, always confirm which todos have been completed since the last update.
- You may update multiple statuses in a single update (e.g., mark the previous as completed and the next as in progress).
- When a new actionable item is discovered during a long or complex task, add it to the todo list immediately.
- Do not remove any unfinished todos unless explicitly instructed.
- Always retain all unfinished tasks, updating their status as needed.
- Only mark a task as completed when it is fully accomplished (no partials, no unresolved dependencies).
- If a task is blocked, keep it as in_progress and add a new todo describing what needs to be resolved.
- Remove tasks only if they are no longer relevant or if the user requests deletion.
**Usage Example:**
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[-] Implement core logic
[ ] Write tests
[ ] Update documentation
</todos>
</update_todo_list>
*After completing "Implement core logic" and starting "Write tests":*
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[x] Implement core logic
[-] Write tests
[ ] Update documentation
[ ] Add performance benchmarks
</todos>
</update_todo_list>
**When to Use:**
- The task involves multiple steps or requires ongoing tracking.
- You need to update the status of several todos at once.
- New actionable items are discovered during task execution.
- The user requests a todo list or provides multiple tasks.
- The task is complex and benefits from clear, stepwise progress tracking.
**When NOT to Use:**
- There is only a single, trivial task.
- The task can be completed in one or two simple steps.
- The request is purely conversational or informational.
**Task Management Guidelines:**
- Mark task as completed immediately after all work of the current task is done.
- Start the next task by marking it as in_progress.
- Add new todos as soon as they are identified.
- Use clear, descriptive task names.
# Tool Use Guidelines
1. In <thinking> tags, assess what information you already have and what information you need to proceed with the task.

70
src/core/prompts/__tests__/__snapshots__/system-prompt/with-mcp-hub-provided.snap
View file

@ -417,6 +417,76 @@ Example:
</new_task>
## update_todo_list
**Description:**
Replace the entire TODO list with an updated checklist reflecting the current state. Always provide the full list; the system will overwrite the previous one. This tool is designed for step-by-step task tracking, allowing you to confirm completion of each step before updating, update multiple task statuses at once (e.g., mark one as completed and start the next), and dynamically add new todos discovered during long or complex tasks.
**Checklist Format:**
- Use a single-level markdown checklist (no nesting or subtasks).
- List todos in the intended execution order.
- Status options:
- [ ] Task description (pending)
- [x] Task description (completed)
- [-] Task description (in progress)
**Status Rules:**
- [ ] = pending (not started)
- [x] = completed (fully finished, no unresolved issues)
- [-] = in_progress (currently being worked on)
**Core Principles:**
- Before updating, always confirm which todos have been completed since the last update.
- You may update multiple statuses in a single update (e.g., mark the previous as completed and the next as in progress).
- When a new actionable item is discovered during a long or complex task, add it to the todo list immediately.
- Do not remove any unfinished todos unless explicitly instructed.
- Always retain all unfinished tasks, updating their status as needed.
- Only mark a task as completed when it is fully accomplished (no partials, no unresolved dependencies).
- If a task is blocked, keep it as in_progress and add a new todo describing what needs to be resolved.
- Remove tasks only if they are no longer relevant or if the user requests deletion.
**Usage Example:**
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[-] Implement core logic
[ ] Write tests
[ ] Update documentation
</todos>
</update_todo_list>
*After completing "Implement core logic" and starting "Write tests":*
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[x] Implement core logic
[-] Write tests
[ ] Update documentation
[ ] Add performance benchmarks
</todos>
</update_todo_list>
**When to Use:**
- The task involves multiple steps or requires ongoing tracking.
- You need to update the status of several todos at once.
- New actionable items are discovered during task execution.
- The user requests a todo list or provides multiple tasks.
- The task is complex and benefits from clear, stepwise progress tracking.
**When NOT to Use:**
- There is only a single, trivial task.
- The task can be completed in one or two simple steps.
- The request is purely conversational or informational.
**Task Management Guidelines:**
- Mark task as completed immediately after all work of the current task is done.
- Start the next task by marking it as in_progress.
- Add new todos as soon as they are identified.
- Use clear, descriptive task names.
# Tool Use Guidelines
1. In <thinking> tags, assess what information you already have and what information you need to proceed with the task.

70
src/core/prompts/__tests__/__snapshots__/system-prompt/with-undefined-mcp-hub.snap
View file

@ -368,6 +368,76 @@ Example:
</new_task>
## update_todo_list
**Description:**
Replace the entire TODO list with an updated checklist reflecting the current state. Always provide the full list; the system will overwrite the previous one. This tool is designed for step-by-step task tracking, allowing you to confirm completion of each step before updating, update multiple task statuses at once (e.g., mark one as completed and start the next), and dynamically add new todos discovered during long or complex tasks.
**Checklist Format:**
- Use a single-level markdown checklist (no nesting or subtasks).
- List todos in the intended execution order.
- Status options:
- [ ] Task description (pending)
- [x] Task description (completed)
- [-] Task description (in progress)
**Status Rules:**
- [ ] = pending (not started)
- [x] = completed (fully finished, no unresolved issues)
- [-] = in_progress (currently being worked on)
**Core Principles:**
- Before updating, always confirm which todos have been completed since the last update.
- You may update multiple statuses in a single update (e.g., mark the previous as completed and the next as in progress).
- When a new actionable item is discovered during a long or complex task, add it to the todo list immediately.
- Do not remove any unfinished todos unless explicitly instructed.
- Always retain all unfinished tasks, updating their status as needed.
- Only mark a task as completed when it is fully accomplished (no partials, no unresolved dependencies).
- If a task is blocked, keep it as in_progress and add a new todo describing what needs to be resolved.
- Remove tasks only if they are no longer relevant or if the user requests deletion.
**Usage Example:**
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[-] Implement core logic
[ ] Write tests
[ ] Update documentation
</todos>
</update_todo_list>
*After completing "Implement core logic" and starting "Write tests":*
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[x] Implement core logic
[-] Write tests
[ ] Update documentation
[ ] Add performance benchmarks
</todos>
</update_todo_list>
**When to Use:**
- The task involves multiple steps or requires ongoing tracking.
- You need to update the status of several todos at once.
- New actionable items are discovered during task execution.
- The user requests a todo list or provides multiple tasks.
- The task is complex and benefits from clear, stepwise progress tracking.
**When NOT to Use:**
- There is only a single, trivial task.
- The task can be completed in one or two simple steps.
- The request is purely conversational or informational.
**Task Management Guidelines:**
- Mark task as completed immediately after all work of the current task is done.
- Start the next task by marking it as in_progress.
- Add new todos as soon as they are identified.
- Use clear, descriptive task names.
# Tool Use Guidelines
1. In <thinking> tags, assess what information you already have and what information you need to proceed with the task.

6
src/core/prompts/instructions/create-mode.ts
View file

@ -26,6 +26,7 @@ If asked to create a project mode, create it in .roomodes in the workspace root.
* groups: Array of allowed tool groups (can be empty). Each group can be specified either as a string (e.g., "edit" to allow editing any file) or with file restrictions (e.g., ["edit", { fileRegex: "\\.md$", description: "Markdown files only" }] to only allow editing markdown files)
- The following fields are optional but highly recommended:
* description: A short, human-readable description of what this mode does (5 words)
* whenToUse: A clear description of when this mode should be selected and what types of tasks it's best suited for. This helps the Orchestrator mode make better decisions.
* customInstructions: Additional instructions for how the mode should operate
@ -36,6 +37,7 @@ Both files should follow this structure (in YAML format):
customModes:
- slug: designer # Required: unique slug with lowercase letters, numbers, and hyphens
name: Designer # Required: mode display name
description: UI/UX design systems expert # Optional but recommended: short description (5 words)
roleDefinition: >-
You are Roo, a UI/UX expert specializing in design systems and frontend development. Your expertise includes:
- Creating and maintaining design systems
@ -43,8 +45,8 @@ customModes:
- Working with CSS, HTML, and modern frontend frameworks
- Ensuring consistent user experiences across platforms # Required: non-empty
whenToUse: >-
Use this mode when creating or modifying UI components, implementing design systems,
or ensuring responsive web interfaces. This mode is especially effective with CSS,
Use this mode when creating or modifying UI components, implementing design systems,
or ensuring responsive web interfaces. This mode is especially effective with CSS,
HTML, and modern frontend frameworks. # Optional but recommended
groups: # Required: array of tool groups (can be empty)
- read # Read files group (read_file, fetch_instructions, search_files, list_files, list_code_definition_names)

5
src/core/prompts/system.ts
View file

@ -1,7 +1,7 @@
import * as vscode from "vscode"
import * as os from "os"
import type { ModeConfig, PromptComponent, CustomModePrompts } from "@roo-code/types"
import type { ModeConfig, PromptComponent, CustomModePrompts, TodoItem } from "@roo-code/types"
import { Mode, modes, defaultModeSlug, getModeBySlug, getGroupName, getModeSelection } from "../../shared/modes"
import { DiffStrategy } from "../../shared/tools"
@ -44,6 +44,7 @@ async function generatePrompt(
rooIgnoreInstructions?: string,
partialReadsEnabled?: boolean,
settings?: Record<string, any>,
todoList?: TodoItem[],
): Promise<string> {
if (!context) {
throw new Error("Extension context is required for generating system prompt")
@ -122,6 +123,7 @@ export const SYSTEM_PROMPT = async (
rooIgnoreInstructions?: string,
partialReadsEnabled?: boolean,
settings?: Record<string, any>,
todoList?: TodoItem[],
): Promise<string> => {
if (!context) {
throw new Error("Extension context is required for generating system prompt")
@ -195,5 +197,6 @@ ${customInstructions}`
rooIgnoreInstructions,
partialReadsEnabled,
settings,
todoList,
)
}

2
src/core/prompts/tools/index.ts
View file

@ -22,6 +22,7 @@ import { getAccessMcpResourceDescription } from "./access-mcp-resource"
import { getSwitchModeDescription } from "./switch-mode"
import { getNewTaskDescription } from "./new-task"
import { getCodebaseSearchDescription } from "./codebase-search"
import { getUpdateTodoListDescription } from "./update-todo-list"
import { CodeIndexManager } from "../../../services/code-index/manager"
// Map of tool names to their description functions
@ -45,6 +46,7 @@ const toolDescriptionMap: Record<string, (args: ToolArgs) => string | undefined>
search_and_replace: (args) => getSearchAndReplaceDescription(args),
apply_diff: (args) =>
args.diffStrategy ? args.diffStrategy.getToolDescription({ cwd: args.cwd, toolOptions: args.toolOptions }) : "",
update_todo_list: (args) => getUpdateTodoListDescription(args),
}
export function getToolDescriptionsForMode(

76
src/core/prompts/tools/update-todo-list.ts Normal file
View file

@ -0,0 +1,76 @@
import { ToolArgs } from "./types"
/**
* Get the description for the update_todo_list tool.
*/
export function getUpdateTodoListDescription(args?: ToolArgs): string {
return `## update_todo_list
**Description:**
Replace the entire TODO list with an updated checklist reflecting the current state. Always provide the full list; the system will overwrite the previous one. This tool is designed for step-by-step task tracking, allowing you to confirm completion of each step before updating, update multiple task statuses at once (e.g., mark one as completed and start the next), and dynamically add new todos discovered during long or complex tasks.
**Checklist Format:**
- Use a single-level markdown checklist (no nesting or subtasks).
- List todos in the intended execution order.
- Status options:
- [ ] Task description (pending)
- [x] Task description (completed)
- [-] Task description (in progress)
**Status Rules:**
- [ ] = pending (not started)
- [x] = completed (fully finished, no unresolved issues)
- [-] = in_progress (currently being worked on)
**Core Principles:**
- Before updating, always confirm which todos have been completed since the last update.
- You may update multiple statuses in a single update (e.g., mark the previous as completed and the next as in progress).
- When a new actionable item is discovered during a long or complex task, add it to the todo list immediately.
- Do not remove any unfinished todos unless explicitly instructed.
- Always retain all unfinished tasks, updating their status as needed.
- Only mark a task as completed when it is fully accomplished (no partials, no unresolved dependencies).
- If a task is blocked, keep it as in_progress and add a new todo describing what needs to be resolved.
- Remove tasks only if they are no longer relevant or if the user requests deletion.
**Usage Example:**
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[-] Implement core logic
[ ] Write tests
[ ] Update documentation
</todos>
</update_todo_list>
*After completing "Implement core logic" and starting "Write tests":*
<update_todo_list>
<todos>
[x] Analyze requirements
[x] Design architecture
[x] Implement core logic
[-] Write tests
[ ] Update documentation
[ ] Add performance benchmarks
</todos>
</update_todo_list>
**When to Use:**
- The task involves multiple steps or requires ongoing tracking.
- You need to update the status of several todos at once.
- New actionable items are discovered during task execution.
- The user requests a todo list or provides multiple tasks.
- The task is complex and benefits from clear, stepwise progress tracking.
**When NOT to Use:**
- There is only a single, trivial task.
- The task can be completed in one or two simple steps.
- The request is purely conversational or informational.
**Task Management Guidelines:**
- Mark task as completed immediately after all work of the current task is done.
- Start the next task by marking it as in_progress.
- Add new todos as soon as they are identified.
- Use clear, descriptive task names.
`
}

4
src/core/task/Task.ts
View file

@ -20,6 +20,7 @@ import {
type ToolProgressStatus,
type HistoryItem,
TelemetryEventName,
TodoItem,
} from "@roo-code/types"
import { TelemetryService } from "@roo-code/telemetry"
import { CloudService } from "@roo-code/cloud"
@ -85,6 +86,7 @@ import { processUserContentMentions } from "../mentions/processUserContentMentio
import { ApiMessage } from "../task-persistence/apiMessages"
import { getMessagesSinceLastSummary, summarizeConversation } from "../condense"
import { maybeRemoveImageBlocks } from "../../api/transform/image-cleaning"
import { restoreTodoListForTask } from "../tools/updateTodoListTool"
// Constants
const MAX_EXPONENTIAL_BACKOFF_SECONDS = 600 // 10 minutes
@ -122,6 +124,7 @@ export type TaskOptions = {
}
export class Task extends EventEmitter<ClineEvents> {
todoList?: TodoItem[]
readonly taskId: string
readonly instanceId: string
@ -370,6 +373,7 @@ export class Task extends EventEmitter<ClineEvents> {
public async overwriteClineMessages(newMessages: ClineMessage[]) {
this.clineMessages = newMessages
restoreTodoListForTask(this)
await this.saveClineMessages()
}

2
src/core/tools/applyDiffTool.ts
View file

@ -145,7 +145,7 @@ export async function applyDiffToolLegacy(
cline.diffViewProvider.editType = "modify"
await cline.diffViewProvider.open(relPath)
await cline.diffViewProvider.update(diffResult.content, true)
await cline.diffViewProvider.scrollToFirstDiff()
cline.diffViewProvider.scrollToFirstDiff()
// Check if file is write-protected
const isWriteProtected = cline.rooProtectedController?.isWriteProtected(relPath) || false

9
src/core/tools/multiApplyDiffTool.ts
View file

@ -159,7 +159,12 @@ Expected structure:
</args>
Original error: ${errorMessage}`
throw new Error(detailedError)
cline.consecutiveMistakeCount++
cline.recordToolError("apply_diff")
TelemetryService.instance.captureDiffApplicationError(cline.taskId, cline.consecutiveMistakeCount)
await cline.say("diff_error", `Failed to parse apply_diff XML: ${errorMessage}`)
pushToolResult(detailedError)
return
}
} else if (legacyPath && typeof legacyDiffContent === "string") {
// Handle legacy parameters (old way)
@ -505,7 +510,7 @@ ${errorDetails ? `\nTechnical details:\n${errorDetails}\n` : ""}
cline.diffViewProvider.editType = "modify"
await cline.diffViewProvider.open(relPath)
await cline.diffViewProvider.update(originalContent!, true)
await cline.diffViewProvider.scrollToFirstDiff()
cline.diffViewProvider.scrollToFirstDiff()
// For batch operations, we've already gotten approval
const isWriteProtected = cline.rooProtectedController?.isWriteProtected(relPath) || false

2
src/core/tools/newTaskTool.ts
View file

@ -22,7 +22,7 @@ export async function newTaskTool(
const partialMessage = JSON.stringify({
tool: "newTask",
mode: removeClosingTag("mode", mode),
message: removeClosingTag("message", message),
content: removeClosingTag("message", message),
})
await cline.ask("tool", partialMessage, block.partial).catch(() => {})

236
src/core/tools/updateTodoListTool.ts Normal file
View file

@ -0,0 +1,236 @@
import { Task } from "../task/Task"
import { ToolUse, AskApproval, HandleError, PushToolResult, RemoveClosingTag } from "../../shared/tools"
import { formatResponse } from "../prompts/responses"
import cloneDeep from "clone-deep"
import crypto from "crypto"
import { TodoItem, TodoStatus, todoStatusSchema } from "@roo-code/types"
import { getLatestTodo } from "../../shared/todo"
let approvedTodoList: TodoItem[] | undefined = undefined
/**
* Add a todo item to the task's todoList.
*/
export function addTodoToTask(cline: Task, content: string, status: TodoStatus = "pending", id?: string): TodoItem {
const todo: TodoItem = {
id: id ?? crypto.randomUUID(),
content,
status,
}
if (!cline.todoList) cline.todoList = []
cline.todoList.push(todo)
return todo
}
/**
* Update the status of a todo item by id.
*/
export function updateTodoStatusForTask(cline: Task, id: string, nextStatus: TodoStatus): boolean {
if (!cline.todoList) return false
const idx = cline.todoList.findIndex((t) => t.id === id)
if (idx === -1) return false
const current = cline.todoList[idx]
if (
(current.status === "pending" && nextStatus === "in_progress") ||
(current.status === "in_progress" && nextStatus === "completed") ||
current.status === nextStatus
) {
cline.todoList[idx] = { ...current, status: nextStatus }
return true
}
return false
}
/**
* Remove a todo item by id.
*/
export function removeTodoFromTask(cline: Task, id: string): boolean {
if (!cline.todoList) return false
const idx = cline.todoList.findIndex((t) => t.id === id)
if (idx === -1) return false
cline.todoList.splice(idx, 1)
return true
}
/**
* Get a copy of the todoList.
*/
export function getTodoListForTask(cline: Task): TodoItem[] | undefined {
return cline.todoList?.slice()
}
/**
* Set the todoList for the task.
*/
export async function setTodoListForTask(cline?: Task, todos?: TodoItem[]) {
if (cline === undefined) return
cline.todoList = Array.isArray(todos) ? todos : []
}
/**
* Restore the todoList from argument or from clineMessages.
*/
export function restoreTodoListForTask(cline: Task, todoList?: TodoItem[]) {
if (todoList) {
cline.todoList = Array.isArray(todoList) ? todoList : []
return
}
cline.todoList = getLatestTodo(cline.clineMessages)
}
/**
* Convert TodoItem[] to markdown checklist string.
* @param todos TodoItem array
* @returns markdown checklist string
*/
function todoListToMarkdown(todos: TodoItem[]): string {
return todos
.map((t) => {
let box = "[ ]"
if (t.status === "completed") box = "[x]"
else if (t.status === "in_progress") box = "[-]"
return `${box} ${t.content}`
})
.join("\n")
}
function normalizeStatus(status: string | undefined): TodoStatus {
if (status === "completed") return "completed"
if (status === "in_progress") return "in_progress"
return "pending"
}
function parseMarkdownChecklist(md: string): TodoItem[] {
if (typeof md !== "string") return []
const lines = md
.split(/\r?\n/)
.map((l) => l.trim())
.filter(Boolean)
const todos: TodoItem[] = []
for (const line of lines) {
const match = line.match(/^\[\s*([ xX\-~])\s*\]\s+(.+)$/)
if (!match) continue
let status: TodoStatus = "pending"
if (match[1] === "x" || match[1] === "X") status = "completed"
else if (match[1] === "-" || match[1] === "~") status = "in_progress"
const id = crypto
.createHash("md5")
.update(match[2] + status)
.digest("hex")
todos.push({
id,
content: match[2],
status,
})
}
return todos
}
export function setPendingTodoList(todos: TodoItem[]) {
approvedTodoList = todos
}
function validateTodos(todos: any[]): { valid: boolean; error?: string } {
if (!Array.isArray(todos)) return { valid: false, error: "todos must be an array" }
for (const [i, t] of todos.entries()) {
if (!t || typeof t !== "object") return { valid: false, error: `Item ${i + 1} is not an object` }
if (!t.id || typeof t.id !== "string") return { valid: false, error: `Item ${i + 1} is missing id` }
if (!t.content || typeof t.content !== "string")
return { valid: false, error: `Item ${i + 1} is missing content` }
if (t.status && !todoStatusSchema.options.includes(t.status as TodoStatus))
return { valid: false, error: `Item ${i + 1} has invalid status` }
}
return { valid: true }
}
/**
* Update the todo list for a task.
* @param cline Task instance
* @param block ToolUse block
* @param askApproval AskApproval function
* @param handleError HandleError function
* @param pushToolResult PushToolResult function
* @param removeClosingTag RemoveClosingTag function
* @param userEdited If true, only show "User Edit Succeeded" and do nothing else
*/
export async function updateTodoListTool(
cline: Task,
block: ToolUse,
askApproval: AskApproval,
handleError: HandleError,
pushToolResult: PushToolResult,
removeClosingTag: RemoveClosingTag,
userEdited?: boolean,
) {
// If userEdited is true, only show "User Edit Succeeded" and do nothing else
if (userEdited === true) {
pushToolResult("User Edit Succeeded")
return
}
try {
const todosRaw = block.params.todos
let todos: TodoItem[]
try {
todos = parseMarkdownChecklist(todosRaw || "")
} catch {
cline.consecutiveMistakeCount++
cline.recordToolError("update_todo_list")
pushToolResult(formatResponse.toolError("The todos parameter is not valid markdown checklist or JSON"))
return
}
const { valid, error } = validateTodos(todos)
if (!valid && !block.partial) {
cline.consecutiveMistakeCount++
cline.recordToolError("update_todo_list")
pushToolResult(formatResponse.toolError(error || "todos parameter validation failed"))
return
}
let normalizedTodos: TodoItem[] = todos.map((t) => ({
id: t.id,
content: t.content,
status: normalizeStatus(t.status),
}))
const approvalMsg = JSON.stringify({
tool: "updateTodoList",
todos: normalizedTodos,
})
if (block.partial) {
await cline.ask("tool", approvalMsg, block.partial).catch(() => {})
return
}
approvedTodoList = cloneDeep(normalizedTodos)
const didApprove = await askApproval("tool", approvalMsg)
if (!didApprove) {
pushToolResult("User declined to update the todoList.")
return
}
const isTodoListChanged =
approvedTodoList !== undefined && JSON.stringify(normalizedTodos) !== JSON.stringify(approvedTodoList)
if (isTodoListChanged) {
normalizedTodos = approvedTodoList ?? []
cline.say(
"user_edit_todos",
JSON.stringify({
tool: "updateTodoList",
todos: normalizedTodos,
}),
)
}
await setTodoListForTask(cline, normalizedTodos)
// If todo list changed, output new todo list in markdown format
if (isTodoListChanged) {
const md = todoListToMarkdown(normalizedTodos)
pushToolResult(formatResponse.toolResult("User edits todo:\n\n" + md))
} else {
pushToolResult(formatResponse.toolResult("Todo list updated successfully."))
}
} catch (error) {
await handleError("update todo list", error)
}
}

8
src/core/webview/ClineProvider.ts
View file

@ -884,11 +884,6 @@ export class ClineProvider
this.contextProxy.setProviderSettings(providerSettings),
])
// Notify CodeIndexManager about the settings change
if (this.codeIndexManager) {
await this.codeIndexManager.handleExternalSettingsChange()
}
// Change the provider for the current task.
// TODO: We should rename `buildApiHandler` for clarity (e.g. `getProviderClient`).
const task = this.getCurrentCline()
@ -1352,6 +1347,7 @@ export class ClineProvider
alwaysAllowMcp,
alwaysAllowModeSwitch,
alwaysAllowSubtasks,
alwaysAllowUpdateTodoList,
allowedMaxRequests,
autoCondenseContext,
autoCondenseContextPercent,
@ -1438,6 +1434,7 @@ export class ClineProvider
alwaysAllowMcp: alwaysAllowMcp ?? false,
alwaysAllowModeSwitch: alwaysAllowModeSwitch ?? false,
alwaysAllowSubtasks: alwaysAllowSubtasks ?? false,
alwaysAllowUpdateTodoList: alwaysAllowUpdateTodoList ?? false,
allowedMaxRequests,
autoCondenseContext: autoCondenseContext ?? true,
autoCondenseContextPercent: autoCondenseContextPercent ?? 100,
@ -1606,6 +1603,7 @@ export class ClineProvider
alwaysAllowModeSwitch: stateValues.alwaysAllowModeSwitch ?? false,
alwaysAllowSubtasks: stateValues.alwaysAllowSubtasks ?? false,
alwaysAllowFollowupQuestions: stateValues.alwaysAllowFollowupQuestions ?? false,
alwaysAllowUpdateTodoList: stateValues.alwaysAllowUpdateTodoList ?? false,
followupAutoApproveTimeoutMs: stateValues.followupAutoApproveTimeoutMs ?? 60000,
allowedMaxRequests: stateValues.allowedMaxRequests,
autoCondenseContext: stateValues.autoCondenseContext ?? true,

187
src/core/webview/__tests__/webviewMessageHandler.spec.ts
View file

@ -14,8 +14,82 @@ const mockGetModels = getModels as Mock<typeof getModels>
const mockClineProvider = {
getState: vi.fn(),
postMessageToWebview: vi.fn(),
customModesManager: {
getCustomModes: vi.fn(),
deleteCustomMode: vi.fn(),
},
context: {
extensionPath: "/mock/extension/path",
globalStorageUri: { fsPath: "/mock/global/storage" },
},
contextProxy: {
context: {
extensionPath: "/mock/extension/path",
globalStorageUri: { fsPath: "/mock/global/storage" },
},
setValue: vi.fn(),
},
log: vi.fn(),
postStateToWebview: vi.fn(),
} as unknown as ClineProvider
import { t } from "../../../i18n"
vi.mock("vscode", () => ({
window: {
showInformationMessage: vi.fn(),
showErrorMessage: vi.fn(),
},
workspace: {
workspaceFolders: [{ uri: { fsPath: "/mock/workspace" } }],
},
}))
vi.mock("../../../i18n", () => ({
t: vi.fn((key: string, args?: Record<string, any>) => {
// For the delete confirmation with rules, we need to return the interpolated string
if (key === "common:confirmation.delete_custom_mode_with_rules" && args) {
return `Are you sure you want to delete this ${args.scope} mode?\n\nThis will also delete the associated rules folder at:\n${args.rulesFolderPath}`
}
// Return the translated value for "Yes"
if (key === "common:answers.yes") {
return "Yes"
}
// Return the translated value for "Cancel"
if (key === "common:answers.cancel") {
return "Cancel"
}
return key
}),
}))
vi.mock("fs/promises", () => {
const mockRm = vi.fn().mockResolvedValue(undefined)
const mockMkdir = vi.fn().mockResolvedValue(undefined)
return {
default: {
rm: mockRm,
mkdir: mockMkdir,
},
rm: mockRm,
mkdir: mockMkdir,
}
})
import * as vscode from "vscode"
import * as fs from "fs/promises"
import * as os from "os"
import * as path from "path"
import * as fsUtils from "../../../utils/fs"
import { getWorkspacePath } from "../../../utils/path"
import { ensureSettingsDirectoryExists } from "../../../utils/globalContext"
import type { ModeConfig } from "@roo-code/types"
vi.mock("../../../utils/fs")
vi.mock("../../../utils/path")
vi.mock("../../../utils/globalContext")
describe("webviewMessageHandler - requestRouterModels", () => {
beforeEach(() => {
vi.clearAllMocks()
@ -295,3 +369,116 @@ describe("webviewMessageHandler - requestRouterModels", () => {
})
})
})
describe("webviewMessageHandler - deleteCustomMode", () => {
beforeEach(() => {
vi.clearAllMocks()
vi.mocked(getWorkspacePath).mockReturnValue("/mock/workspace")
vi.mocked(vscode.window.showErrorMessage).mockResolvedValue(undefined)
vi.mocked(ensureSettingsDirectoryExists).mockResolvedValue("/mock/global/storage/.roo")
})
it("should delete a project mode and its rules folder", async () => {
const slug = "test-project-mode"
const rulesFolderPath = path.join("/mock/workspace", ".roo", `rules-${slug}`)
vi.mocked(mockClineProvider.customModesManager.getCustomModes).mockResolvedValue([
{
name: "Test Project Mode",
slug,
roleDefinition: "Test Role",
groups: [],
source: "project",
} as ModeConfig,
])
vi.mocked(fsUtils.fileExistsAtPath).mockResolvedValue(true)
vi.mocked(mockClineProvider.customModesManager.deleteCustomMode).mockResolvedValue(undefined)
await webviewMessageHandler(mockClineProvider, { type: "deleteCustomMode", slug })
// The confirmation dialog is now handled in the webview, so we don't expect showInformationMessage to be called
expect(vscode.window.showInformationMessage).not.toHaveBeenCalled()
expect(mockClineProvider.customModesManager.deleteCustomMode).toHaveBeenCalledWith(slug)
expect(fs.rm).toHaveBeenCalledWith(rulesFolderPath, { recursive: true, force: true })
})
it("should delete a global mode and its rules folder", async () => {
const slug = "test-global-mode"
const homeDir = os.homedir()
const rulesFolderPath = path.join(homeDir, ".roo", `rules-${slug}`)
vi.mocked(mockClineProvider.customModesManager.getCustomModes).mockResolvedValue([
{
name: "Test Global Mode",
slug,
roleDefinition: "Test Role",
groups: [],
source: "global",
} as ModeConfig,
])
vi.mocked(fsUtils.fileExistsAtPath).mockResolvedValue(true)
vi.mocked(mockClineProvider.customModesManager.deleteCustomMode).mockResolvedValue(undefined)
await webviewMessageHandler(mockClineProvider, { type: "deleteCustomMode", slug })
// The confirmation dialog is now handled in the webview, so we don't expect showInformationMessage to be called
expect(vscode.window.showInformationMessage).not.toHaveBeenCalled()
expect(mockClineProvider.customModesManager.deleteCustomMode).toHaveBeenCalledWith(slug)
expect(fs.rm).toHaveBeenCalledWith(rulesFolderPath, { recursive: true, force: true })
})
it("should only delete the mode when rules folder does not exist", async () => {
const slug = "test-mode-no-rules"
vi.mocked(mockClineProvider.customModesManager.getCustomModes).mockResolvedValue([
{
name: "Test Mode No Rules",
slug,
roleDefinition: "Test Role",
groups: [],
source: "project",
} as ModeConfig,
])
vi.mocked(fsUtils.fileExistsAtPath).mockResolvedValue(false)
vi.mocked(mockClineProvider.customModesManager.deleteCustomMode).mockResolvedValue(undefined)
await webviewMessageHandler(mockClineProvider, { type: "deleteCustomMode", slug })
// The confirmation dialog is now handled in the webview, so we don't expect showInformationMessage to be called
expect(vscode.window.showInformationMessage).not.toHaveBeenCalled()
expect(mockClineProvider.customModesManager.deleteCustomMode).toHaveBeenCalledWith(slug)
expect(fs.rm).not.toHaveBeenCalled()
})
it("should handle errors when deleting rules folder", async () => {
const slug = "test-mode-error"
const rulesFolderPath = path.join("/mock/workspace", ".roo", `rules-${slug}`)
const error = new Error("Permission denied")
vi.mocked(mockClineProvider.customModesManager.getCustomModes).mockResolvedValue([
{
name: "Test Mode Error",
slug,
roleDefinition: "Test Role",
groups: [],
source: "project",
} as ModeConfig,
])
vi.mocked(fsUtils.fileExistsAtPath).mockResolvedValue(true)
vi.mocked(mockClineProvider.customModesManager.deleteCustomMode).mockResolvedValue(undefined)
vi.mocked(fs.rm).mockRejectedValue(error)
await webviewMessageHandler(mockClineProvider, { type: "deleteCustomMode", slug })
expect(mockClineProvider.customModesManager.deleteCustomMode).toHaveBeenCalledWith(slug)
expect(fs.rm).toHaveBeenCalledWith(rulesFolderPath, { recursive: true, force: true })
// Verify error message is shown to the user
expect(vscode.window.showErrorMessage).toHaveBeenCalledWith(
t("common:errors.delete_rules_folder_failed", {
rulesFolderPath,
error: error.message,
}),
)
// No error response is sent anymore - we just continue with deletion
expect(mockClineProvider.postMessageToWebview).not.toHaveBeenCalled()
})
})

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

@ -1,5 +1,6 @@
import { safeWriteJson } from "../../utils/safeWriteJson"
import * as path from "path"
import * as os from "os"
import * as fs from "fs/promises"
import pWaitFor from "p-wait-for"
import * as vscode from "vscode"
@ -35,6 +36,7 @@ import { getVsCodeLmModels } from "../../api/providers/vscode-lm"
import { openMention } from "../mentions"
import { TelemetrySetting } from "../../shared/TelemetrySetting"
import { getWorkspacePath } from "../../utils/path"
import { ensureSettingsDirectoryExists } from "../../utils/globalContext"
import { Mode, defaultModeSlug } from "../../shared/modes"
import { getModels, flushModels } from "../../api/providers/fetchers/modelCache"
import { GetModelsOptions } from "../../shared/api"
@ -44,6 +46,7 @@ import { getCommand } from "../../utils/commands"
const ALLOWED_VSCODE_SETTINGS = new Set(["terminal.integrated.inheritEnv"])
import { MarketplaceManager, MarketplaceItemType } from "../../services/marketplace"
import { setPendingTodoList } from "../tools/updateTodoListTool"
export const webviewMessageHandler = async (
provider: ClineProvider,
@ -183,6 +186,10 @@ export const webviewMessageHandler = async (
await updateGlobalState("alwaysAllowSubtasks", message.bool)
await provider.postStateToWebview()
break
case "alwaysAllowUpdateTodoList":
await updateGlobalState("alwaysAllowUpdateTodoList", message.bool)
await provider.postStateToWebview()
break
case "askResponse":
provider.getCurrentCline()?.handleWebviewAskResponse(message.askResponse!, message.text, message.images)
break
@ -1111,6 +1118,21 @@ export const webviewMessageHandler = async (
break
case "browserToolEnabled":
await updateGlobalState("browserToolEnabled", message.bool ?? true)
await provider.postStateToWebview()
break
case "codebaseIndexEnabled":
// Update the codebaseIndexConfig with the new enabled state
const currentCodebaseConfig = getGlobalState("codebaseIndexConfig") || {}
await updateGlobalState("codebaseIndexConfig", {
...currentCodebaseConfig,
codebaseIndexEnabled: message.bool ?? false,
})
// Notify the code index manager about the change
if (provider.codeIndexManager) {
await provider.codeIndexManager.handleSettingsChange()
}
await provider.postStateToWebview()
break
case "language":
@ -1300,6 +1322,14 @@ export const webviewMessageHandler = async (
}
break
}
case "updateTodoList": {
const payload = message.payload as { todos?: any[] }
const todos = payload?.todos
if (Array.isArray(todos)) {
await setPendingTodoList(todos)
}
break
}
case "saveApiConfiguration":
if (message.text && message.apiConfiguration) {
try {
@ -1494,17 +1524,66 @@ export const webviewMessageHandler = async (
break
case "deleteCustomMode":
if (message.slug) {
const answer = await vscode.window.showInformationMessage(
t("common:confirmation.delete_custom_mode"),
{ modal: true },
t("common:answers.yes"),
)
// Get the mode details to determine source and rules folder path
const customModes = await provider.customModesManager.getCustomModes()
const modeToDelete = customModes.find((mode) => mode.slug === message.slug)
if (answer !== t("common:answers.yes")) {
if (!modeToDelete) {
break
}
// Determine the scope based on source (project or global)
const scope = modeToDelete.source || "global"
// Determine the rules folder path
let rulesFolderPath: string
if (scope === "project") {
const workspacePath = getWorkspacePath()
if (workspacePath) {
rulesFolderPath = path.join(workspacePath, ".roo", `rules-${message.slug}`)
} else {
rulesFolderPath = path.join(".roo", `rules-${message.slug}`)
}
} else {
// Global scope - use OS home directory
const homeDir = os.homedir()
rulesFolderPath = path.join(homeDir, ".roo", `rules-${message.slug}`)
}
// Check if the rules folder exists
const rulesFolderExists = await fileExistsAtPath(rulesFolderPath)
// If this is a check request, send back the folder info
if (message.checkOnly) {
await provider.postMessageToWebview({
type: "deleteCustomModeCheck",
slug: message.slug,
rulesFolderPath: rulesFolderExists ? rulesFolderPath : undefined,
})
break
}
// Delete the mode
await provider.customModesManager.deleteCustomMode(message.slug)
// Delete the rules folder if it exists
if (rulesFolderExists) {
try {
await fs.rm(rulesFolderPath, { recursive: true, force: true })
provider.log(`Deleted rules folder for mode ${message.slug}: ${rulesFolderPath}`)
} catch (error) {
provider.log(`Failed to delete rules folder for mode ${message.slug}: ${error}`)
// Notify the user about the failure
vscode.window.showErrorMessage(
t("common:errors.delete_rules_folder_failed", {
rulesFolderPath,
error: error instanceof Error ? error.message : String(error),
}),
)
// Continue with mode deletion even if folder deletion fails
}
}
// Switch back to default mode after deletion
await updateGlobalState("mode", defaultModeSlug)
await provider.postStateToWebview()
@ -1755,38 +1834,131 @@ export const webviewMessageHandler = async (
break
}
case "codebaseIndexConfig": {
const codebaseIndexConfig = message.values ?? {
codebaseIndexEnabled: false,
codebaseIndexQdrantUrl: "http://localhost:6333",
codebaseIndexEmbedderProvider: "openai",
codebaseIndexEmbedderBaseUrl: "",
codebaseIndexEmbedderModelId: "",
case "saveCodeIndexSettingsAtomic": {
if (!message.codeIndexSettings) {
break
}
await updateGlobalState("codebaseIndexConfig", codebaseIndexConfig)
const settings = message.codeIndexSettings
try {
if (provider.codeIndexManager) {
await provider.codeIndexManager.handleExternalSettingsChange()
// Check if embedder provider has changed
const currentConfig = getGlobalState("codebaseIndexConfig") || {}
const embedderProviderChanged =
currentConfig.codebaseIndexEmbedderProvider !== settings.codebaseIndexEmbedderProvider
// If now configured and enabled, start indexing automatically
// Save global state settings atomically (without codebaseIndexEnabled which is now in global settings)
const globalStateConfig = {
...currentConfig,
codebaseIndexQdrantUrl: settings.codebaseIndexQdrantUrl,
codebaseIndexEmbedderProvider: settings.codebaseIndexEmbedderProvider,
codebaseIndexEmbedderBaseUrl: settings.codebaseIndexEmbedderBaseUrl,
codebaseIndexEmbedderModelId: settings.codebaseIndexEmbedderModelId,
codebaseIndexOpenAiCompatibleBaseUrl: settings.codebaseIndexOpenAiCompatibleBaseUrl,
codebaseIndexOpenAiCompatibleModelDimension: settings.codebaseIndexOpenAiCompatibleModelDimension,
codebaseIndexSearchMaxResults: settings.codebaseIndexSearchMaxResults,
codebaseIndexSearchMinScore: settings.codebaseIndexSearchMinScore,
}
// Save global state first
await updateGlobalState("codebaseIndexConfig", globalStateConfig)
// Save secrets directly using context proxy
if (settings.codeIndexOpenAiKey !== undefined) {
await provider.contextProxy.storeSecret("codeIndexOpenAiKey", settings.codeIndexOpenAiKey)
}
if (settings.codeIndexQdrantApiKey !== undefined) {
await provider.contextProxy.storeSecret("codeIndexQdrantApiKey", settings.codeIndexQdrantApiKey)
}
if (settings.codebaseIndexOpenAiCompatibleApiKey !== undefined) {
await provider.contextProxy.storeSecret(
"codebaseIndexOpenAiCompatibleApiKey",
settings.codebaseIndexOpenAiCompatibleApiKey,
)
}
if (settings.codebaseIndexGeminiApiKey !== undefined) {
await provider.contextProxy.storeSecret(
"codebaseIndexGeminiApiKey",
settings.codebaseIndexGeminiApiKey,
)
}
// Send success response first - settings are saved regardless of validation
await provider.postMessageToWebview({
type: "codeIndexSettingsSaved",
success: true,
settings: globalStateConfig,
})
// Update webview state
await provider.postStateToWebview()
// Then handle validation and initialization
if (provider.codeIndexManager) {
// If embedder provider changed, perform proactive validation
if (embedderProviderChanged) {
try {
// Force handleSettingsChange which will trigger validation
await provider.codeIndexManager.handleSettingsChange()
} catch (error) {
// Validation failed - the error state is already set by handleSettingsChange
provider.log(
`Embedder validation failed after provider change: ${error instanceof Error ? error.message : String(error)}`,
)
// Send validation error to webview
await provider.postMessageToWebview({
type: "indexingStatusUpdate",
values: provider.codeIndexManager.getCurrentStatus(),
})
// Exit early - don't try to start indexing with invalid configuration
break
}
} else {
// No provider change, just handle settings normally
try {
await provider.codeIndexManager.handleSettingsChange()
} catch (error) {
// Log but don't fail - settings are saved
provider.log(
`Settings change handling error: ${error instanceof Error ? error.message : String(error)}`,
)
}
}
// Wait a bit more to ensure everything is ready
await new Promise((resolve) => setTimeout(resolve, 200))
// Auto-start indexing if now enabled and configured
if (provider.codeIndexManager.isFeatureEnabled && provider.codeIndexManager.isFeatureConfigured) {
if (!provider.codeIndexManager.isInitialized) {
await provider.codeIndexManager.initialize(provider.contextProxy)
try {
await provider.codeIndexManager.initialize(provider.contextProxy)
provider.log(`Code index manager initialized after settings save`)
} catch (error) {
provider.log(
`Code index initialization failed: ${error instanceof Error ? error.message : String(error)}`,
)
// Send error status to webview
await provider.postMessageToWebview({
type: "indexingStatusUpdate",
values: provider.codeIndexManager.getCurrentStatus(),
})
}
}
// Start indexing in background (no await)
provider.codeIndexManager.startIndexing()
}
}
} catch (error) {
provider.log(
`[CodeIndexManager] Error during background CodeIndexManager configuration/indexing: ${error.message || error}`,
)
provider.log(`Error saving code index settings: ${error.message || error}`)
await provider.postMessageToWebview({
type: "codeIndexSettingsSaved",
success: false,
error: error.message || "Failed to save settings",
})
}
await provider.postStateToWebview()
break
}
case "requestIndexingStatus": {
const status = provider.codeIndexManager!.getCurrentStatus()
provider.postMessageToWebview({
@ -1795,6 +1967,26 @@ export const webviewMessageHandler = async (
})
break
}
case "requestCodeIndexSecretStatus": {
// Check if secrets are set using the VSCode context directly for async access
const hasOpenAiKey = !!(await provider.context.secrets.get("codeIndexOpenAiKey"))
const hasQdrantApiKey = !!(await provider.context.secrets.get("codeIndexQdrantApiKey"))
const hasOpenAiCompatibleApiKey = !!(await provider.context.secrets.get(
"codebaseIndexOpenAiCompatibleApiKey",
))
const hasGeminiApiKey = !!(await provider.context.secrets.get("codebaseIndexGeminiApiKey"))
provider.postMessageToWebview({
type: "codeIndexSecretStatus",
values: {
hasOpenAiKey,
hasQdrantApiKey,
hasOpenAiCompatibleApiKey,
hasGeminiApiKey,
},
})
break
}
case "startIndexing": {
try {
const manager = provider.codeIndexManager!

16
src/i18n/locales/ca/common.json
View file

@ -21,7 +21,7 @@
"confirmation": {
"reset_state": "Estàs segur que vols restablir tots els estats i emmagatzematge secret a l'extensió? Això no es pot desfer.",
"delete_config_profile": "Estàs segur que vols eliminar aquest perfil de configuració?",
"delete_custom_mode": "Estàs segur que vols eliminar aquest mode personalitzat?",
"delete_custom_mode_with_rules": "Esteu segur que voleu suprimir aquest mode {scope}?\n\nAixò també suprimirà la carpeta de regles associada a:\n{rulesFolderPath}",
"delete_message": "Què vols eliminar?",
"just_this_message": "Només aquest missatge",
"this_and_subsequent": "Aquest i tots els missatges posteriors"
@ -74,6 +74,7 @@
"share_auth_required": "Es requereix autenticació. Si us plau, inicia sessió per compartir tasques.",
"share_not_enabled": "La compartició de tasques no està habilitada per a aquesta organització.",
"share_task_not_found": "Tasca no trobada o accés denegat.",
"delete_rules_folder_failed": "Error en eliminar la carpeta de regles: {{rulesFolderPath}}. Error: {{error}}",
"claudeCode": {
"processExited": "El procés Claude Code ha sortit amb codi {{exitCode}}.",
"errorOutput": "Sortida d'error: {{output}}",
@ -144,6 +145,10 @@
"resetFailed": "Error en restablir els modes personalitzats: {{error}}",
"modeNotFound": "Error d'escriptura: Mode no trobat",
"noWorkspaceForProject": "No s'ha trobat cap carpeta d'espai de treball per al mode específic del projecte"
},
"scope": {
"project": "projecte",
"global": "global"
}
},
"mdm": {
@ -152,5 +157,14 @@
"organization_mismatch": "Has d'estar autenticat amb el compte de Roo Code Cloud de la teva organització.",
"verification_failed": "No s'ha pogut verificar l'autenticació de l'organització."
}
},
"prompts": {
"deleteMode": {
"title": "Suprimeix el mode personalitzat",
"description": "Esteu segur que voleu suprimir aquest mode {{scope}}? Això també suprimirà la carpeta de regles associada a: {{rulesFolderPath}}",
"descriptionNoRules": "Esteu segur que voleu suprimir aquest mode personalitzat?",
"cancel": "Cancel·la",
"confirm": "Suprimeix"
}
}
}

20
src/i18n/locales/ca/embeddings.json
View file

@ -10,7 +10,12 @@
"couldNotReadErrorBody": "No s'ha pogut llegir el cos de l'error",
"requestFailed": "La sol·licitud de l'API d'Ollama ha fallat amb l'estat {{status}} {{statusText}}: {{errorBody}}",
"invalidResponseStructure": "Estructura de resposta no vàlida de l'API d'Ollama: no s'ha trobat la matriu \"embeddings\" o no és una matriu.",
"embeddingFailed": "La incrustació d'Ollama ha fallat: {{message}}"
"embeddingFailed": "La incrustació d'Ollama ha fallat: {{message}}",
"serviceNotRunning": "El servei d'Ollama no s'està executant a {{baseUrl}}",
"serviceUnavailable": "El servei d'Ollama no està disponible (estat: {{status}})",
"modelNotFound": "No s'ha trobat el model d'Ollama: {{modelId}}",
"modelNotEmbeddingCapable": "El model d'Ollama no és capaç de fer incrustacions: {{modelId}}",
"hostNotFound": "No s'ha trobat l'amfitrió d'Ollama: {{baseUrl}}"
},
"scanner": {
"unknownErrorProcessingFile": "Error desconegut en processar el fitxer {{filePath}}",
@ -19,5 +24,18 @@
},
"vectorStore": {
"qdrantConnectionFailed": "No s'ha pogut connectar a la base de dades vectorial Qdrant. Assegura't que Qdrant estigui funcionant i sigui accessible a {{qdrantUrl}}. Error: {{errorMessage}}"
},
"validation": {
"authenticationFailed": "Ha fallat l'autenticació. Comproveu la vostra clau d'API a la configuració.",
"connectionFailed": "No s'ha pogut connectar al servei d'incrustació. Comproveu la vostra configuració de connexió i assegureu-vos que el servei estigui funcionant.",
"modelNotAvailable": "El model especificat no està disponible. Comproveu la vostra configuració de model.",
"configurationError": "Configuració d'incrustació no vàlida. Reviseu la vostra configuració.",
"serviceUnavailable": "El servei d'incrustació no està disponible. Assegureu-vos que estigui funcionant i sigui accessible.",
"invalidEndpoint": "Punt final d'API no vàlid. Comproveu la vostra configuració d'URL.",
"invalidEmbedderConfig": "Configuració d'incrustació no vàlida. Comproveu la vostra configuració.",
"invalidApiKey": "Clau d'API no vàlida. Comproveu la vostra configuració de clau d'API.",
"invalidBaseUrl": "URL base no vàlida. Comproveu la vostra configuració d'URL.",
"invalidModel": "Model no vàlid. Comproveu la vostra configuració de model.",
"invalidResponse": "Resposta no vàlida del servei d'incrustació. Comproveu la vostra configuració."
}
}

16
src/i18n/locales/de/common.json
View file

@ -17,7 +17,7 @@
"confirmation": {
"reset_state": "Möchtest du wirklich alle Zustände und geheimen Speicher in der Erweiterung zurücksetzen? Dies kann nicht rückgängig gemacht werden.",
"delete_config_profile": "Möchtest du dieses Konfigurationsprofil wirklich löschen?",
"delete_custom_mode": "Möchtest du diesen benutzerdefinierten Modus wirklich löschen?",
"delete_custom_mode_with_rules": "Bist du sicher, dass du diesen {scope}-Modus löschen möchtest?\n\nDadurch wird auch der zugehörige Regelordner unter folgender Adresse gelöscht:\n{rulesFolderPath}",
"delete_message": "Was möchtest du löschen?",
"just_this_message": "Nur diese Nachricht",
"this_and_subsequent": "Diese und alle nachfolgenden Nachrichten"
@ -71,6 +71,7 @@
"share_not_enabled": "Aufgabenfreigabe ist für diese Organisation nicht aktiviert.",
"share_task_not_found": "Aufgabe nicht gefunden oder Zugriff verweigert.",
"mode_import_failed": "Fehler beim Importieren des Modus: {{error}}",
"delete_rules_folder_failed": "Fehler beim Löschen des Regelordners: {{rulesFolderPath}}. Fehler: {{error}}",
"claudeCode": {
"processExited": "Claude Code Prozess wurde mit Code {{exitCode}} beendet.",
"errorOutput": "Fehlerausgabe: {{output}}",
@ -144,6 +145,10 @@
"resetFailed": "Fehler beim Zurücksetzen der benutzerdefinierten Modi: {{error}}",
"modeNotFound": "Schreibfehler: Modus nicht gefunden",
"noWorkspaceForProject": "Kein Arbeitsbereich-Ordner für projektspezifischen Modus gefunden"
},
"scope": {
"project": "projekt",
"global": "global"
}
},
"mdm": {
@ -152,5 +157,14 @@
"organization_mismatch": "Du musst mit dem Roo Code Cloud-Konto deiner Organisation authentifiziert sein.",
"verification_failed": "Die Organisationsauthentifizierung konnte nicht verifiziert werden."
}
},
"prompts": {
"deleteMode": {
"title": "Benutzerdefinierten Modus löschen",
"description": "Bist du sicher, dass du diesen {{scope}}-Modus löschen möchtest? Dadurch wird auch der zugehörige Regelordner unter {{rulesFolderPath}} gelöscht",
"descriptionNoRules": "Bist du sicher, dass du diesen benutzerdefinierten Modus löschen möchtest?",
"cancel": "Abbrechen",
"confirm": "Löschen"
}
}
}

20
src/i18n/locales/de/embeddings.json
View file

@ -10,7 +10,12 @@
"couldNotReadErrorBody": "Fehlerinhalt konnte nicht gelesen werden",
"requestFailed": "Ollama API-Anfrage fehlgeschlagen mit Status {{status}} {{statusText}}: {{errorBody}}",
"invalidResponseStructure": "Ungültige Antwortstruktur von Ollama API: \"embeddings\" Array nicht gefunden oder kein Array.",
"embeddingFailed": "Ollama Einbettung fehlgeschlagen: {{message}}"
"embeddingFailed": "Ollama Einbettung fehlgeschlagen: {{message}}",
"serviceNotRunning": "Ollama-Dienst wird unter {{baseUrl}} nicht ausgeführt",
"serviceUnavailable": "Ollama-Dienst ist nicht verfügbar (Status: {{status}})",
"modelNotFound": "Ollama-Modell nicht gefunden: {{modelId}}",
"modelNotEmbeddingCapable": "Ollama-Modell ist nicht für Einbettungen geeignet: {{modelId}}",
"hostNotFound": "Ollama-Host nicht gefunden: {{baseUrl}}"
},
"scanner": {
"unknownErrorProcessingFile": "Unbekannter Fehler beim Verarbeiten der Datei {{filePath}}",
@ -19,5 +24,18 @@
},
"vectorStore": {
"qdrantConnectionFailed": "Verbindung zur Qdrant-Vektordatenbank fehlgeschlagen. Stelle sicher, dass Qdrant läuft und unter {{qdrantUrl}} erreichbar ist. Fehler: {{errorMessage}}"
},
"validation": {
"authenticationFailed": "Authentifizierung fehlgeschlagen. Bitte überprüfe deinen API-Schlüssel in den Einstellungen.",
"connectionFailed": "Verbindung zum Embedder-Dienst fehlgeschlagen. Bitte überprüfe deine Verbindungseinstellungen und stelle sicher, dass der Dienst läuft.",
"modelNotAvailable": "Das angegebene Modell ist nicht verfügbar. Bitte überprüfe deine Modellkonfiguration.",
"configurationError": "Ungültige Embedder-Konfiguration. Bitte überprüfe deine Einstellungen.",
"serviceUnavailable": "Der Embedder-Dienst ist nicht verfügbar. Bitte stelle sicher, dass er läuft und erreichbar ist.",
"invalidEndpoint": "Ungültiger API-Endpunkt. Bitte überprüfe deine URL-Konfiguration.",
"invalidEmbedderConfig": "Ungültige Embedder-Konfiguration. Bitte überprüfe deine Einstellungen.",
"invalidApiKey": "Ungültiger API-Schlüssel. Bitte überprüfe deine API-Schlüssel-Konfiguration.",
"invalidBaseUrl": "Ungültige Basis-URL. Bitte überprüfe deine URL-Konfiguration.",
"invalidModel": "Ungültiges Modell. Bitte überprüfe deine Modellkonfiguration.",
"invalidResponse": "Ungültige Antwort vom Embedder-Dienst. Bitte überprüfe deine Konfiguration."
}
}

16
src/i18n/locales/en/common.json
View file

@ -17,7 +17,7 @@
"confirmation": {
"reset_state": "Are you sure you want to reset all state and secret storage in the extension? This cannot be undone.",
"delete_config_profile": "Are you sure you want to delete this configuration profile?",
"delete_custom_mode": "Are you sure you want to delete this custom mode?",
"delete_custom_mode_with_rules": "Are you sure you want to delete this {scope} mode?\n\nThis will also delete the associated rules folder at:\n{rulesFolderPath}",
"delete_message": "What would you like to delete?",
"just_this_message": "Just this message",
"this_and_subsequent": "This and all subsequent messages"
@ -71,6 +71,7 @@
"share_not_enabled": "Task sharing is not enabled for this organization.",
"share_task_not_found": "Task not found or access denied.",
"mode_import_failed": "Failed to import mode: {{error}}",
"delete_rules_folder_failed": "Failed to delete rules folder: {{rulesFolderPath}}. Error: {{error}}",
"claudeCode": {
"processExited": "Claude Code process exited with code {{exitCode}}.",
"errorOutput": "Error output: {{output}}",
@ -133,6 +134,10 @@
"resetFailed": "Failed to reset custom modes: {{error}}",
"modeNotFound": "Write error: Mode not found",
"noWorkspaceForProject": "No workspace folder found for project-specific mode"
},
"scope": {
"project": "project",
"global": "global"
}
},
"mdm": {
@ -141,5 +146,14 @@
"organization_mismatch": "You must be authenticated with your organization's Roo Code Cloud account.",
"verification_failed": "Unable to verify organization authentication."
}
},
"prompts": {
"deleteMode": {
"title": "Delete Custom Mode",
"description": "Are you sure you want to delete this {{scope}} mode? This will also delete the associated rules folder at: {{rulesFolderPath}}",
"descriptionNoRules": "Are you sure you want to delete this custom mode?",
"cancel": "Cancel",
"confirm": "Delete"
}
}
}

20
src/i18n/locales/en/embeddings.json
View file

@ -10,7 +10,12 @@
"couldNotReadErrorBody": "Could not read error body",
"requestFailed": "Ollama API request failed with status {{status}} {{statusText}}: {{errorBody}}",
"invalidResponseStructure": "Invalid response structure from Ollama API: \"embeddings\" array not found or not an array.",
"embeddingFailed": "Ollama embedding failed: {{message}}"
"embeddingFailed": "Ollama embedding failed: {{message}}",
"serviceNotRunning": "Ollama service is not running at {{baseUrl}}",
"serviceUnavailable": "Ollama service is unavailable (status: {{status}})",
"modelNotFound": "Ollama model not found: {{modelId}}",
"modelNotEmbeddingCapable": "Ollama model is not embedding capable: {{modelId}}",
"hostNotFound": "Ollama host not found: {{baseUrl}}"
},
"scanner": {
"unknownErrorProcessingFile": "Unknown error processing file {{filePath}}",
@ -19,5 +24,18 @@
},
"vectorStore": {
"qdrantConnectionFailed": "Failed to connect to Qdrant vector database. Please ensure Qdrant is running and accessible at {{qdrantUrl}}. Error: {{errorMessage}}"
},
"validation": {
"authenticationFailed": "Authentication failed. Please check your API key in the settings.",
"connectionFailed": "Failed to connect to the embedder service. Please check your connection settings and ensure the service is running.",
"modelNotAvailable": "The specified model is not available. Please check your model configuration.",
"configurationError": "Invalid embedder configuration. Please review your settings.",
"serviceUnavailable": "The embedder service is not available. Please ensure it is running and accessible.",
"invalidEndpoint": "Invalid API endpoint. Please check your URL configuration.",
"invalidEmbedderConfig": "Invalid embedder configuration. Please check your settings.",
"invalidApiKey": "Invalid API key. Please check your API key configuration.",
"invalidBaseUrl": "Invalid base URL. Please check your URL configuration.",
"invalidModel": "Invalid model. Please check your model configuration.",
"invalidResponse": "Invalid response from embedder service. Please check your configuration."
}
}

16
src/i18n/locales/es/common.json
View file

@ -17,7 +17,7 @@
"confirmation": {
"reset_state": "¿Estás seguro de que deseas restablecer todo el estado y el almacenamiento secreto en la extensión? Esta acción no se puede deshacer.",
"delete_config_profile": "¿Estás seguro de que deseas eliminar este perfil de configuración?",
"delete_custom_mode": "¿Estás seguro de que deseas eliminar este modo personalizado?",
"delete_custom_mode_with_rules": "¿Estás seguro de que quieres eliminar este modo {scope}?\n\nEsto también eliminará la carpeta de reglas asociada en:\n{rulesFolderPath}",
"delete_message": "¿Qué deseas eliminar?",
"just_this_message": "Solo este mensaje",
"this_and_subsequent": "Este y todos los mensajes posteriores"
@ -71,6 +71,7 @@
"share_not_enabled": "La compartición de tareas no está habilitada para esta organización.",
"share_task_not_found": "Tarea no encontrada o acceso denegado.",
"mode_import_failed": "Error al importar el modo: {{error}}",
"delete_rules_folder_failed": "Error al eliminar la carpeta de reglas: {{rulesFolderPath}}. Error: {{error}}",
"claudeCode": {
"processExited": "El proceso de Claude Code terminó con código {{exitCode}}.",
"errorOutput": "Salida de error: {{output}}",
@ -144,6 +145,10 @@
"resetFailed": "Error al restablecer modos personalizados: {{error}}",
"modeNotFound": "Error de escritura: Modo no encontrado",
"noWorkspaceForProject": "No se encontró carpeta de espacio de trabajo para modo específico del proyecto"
},
"scope": {
"project": "proyecto",
"global": "global"
}
},
"mdm": {
@ -152,5 +157,14 @@
"organization_mismatch": "Debes estar autenticado con la cuenta de Roo Code Cloud de tu organización.",
"verification_failed": "No se pudo verificar la autenticación de la organización."
}
},
"prompts": {
"deleteMode": {
"title": "Eliminar modo personalizado",
"description": "¿Estás seguro de que quieres eliminar este modo {{scope}}? Esto también eliminará la carpeta de reglas asociada en: {{rulesFolderPath}}",
"descriptionNoRules": "¿Estás seguro de que quieres eliminar este modo personalizado?",
"cancel": "Cancelar",
"confirm": "Eliminar"
}
}
}

20
src/i18n/locales/es/embeddings.json
View file

@ -10,7 +10,12 @@
"couldNotReadErrorBody": "No se pudo leer el cuerpo del error",
"requestFailed": "La solicitud de la API de Ollama falló con estado {{status}} {{statusText}}: {{errorBody}}",
"invalidResponseStructure": "Estructura de respuesta inválida de la API de Ollama: array \"embeddings\" no encontrado o no es un array.",
"embeddingFailed": "Incrustación de Ollama falló: {{message}}"
"embeddingFailed": "Incrustación de Ollama falló: {{message}}",
"serviceNotRunning": "El servicio Ollama no se está ejecutando en {{baseUrl}}",
"serviceUnavailable": "El servicio Ollama no está disponible (estado: {{status}})",
"modelNotFound": "No se encuentra el modelo Ollama: {{modelId}}",
"modelNotEmbeddingCapable": "El modelo Ollama no es capaz de realizar incrustaciones: {{modelId}}",
"hostNotFound": "No se encuentra el host de Ollama: {{baseUrl}}"
},
"scanner": {
"unknownErrorProcessingFile": "Error desconocido procesando archivo {{filePath}}",
@ -19,5 +24,18 @@
},
"vectorStore": {
"qdrantConnectionFailed": "Error al conectar con la base de datos vectorial Qdrant. Asegúrate de que Qdrant esté funcionando y sea accesible en {{qdrantUrl}}. Error: {{errorMessage}}"
},
"validation": {
"authenticationFailed": "Error de autenticación. Comprueba tu clave de API en los ajustes.",
"connectionFailed": "Error al conectar con el servicio de embedder. Comprueba los ajustes de conexión y asegúrate de que el servicio esté funcionando.",
"modelNotAvailable": "El modelo especificado no está disponible. Comprueba la configuración de tu modelo.",
"configurationError": "Configuración de embedder no válida. Revisa tus ajustes.",
"serviceUnavailable": "El servicio de embedder no está disponible. Asegúrate de que esté funcionando y sea accesible.",
"invalidEndpoint": "Punto de conexión de API no válido. Comprueba la configuración de tu URL.",
"invalidEmbedderConfig": "Configuración de embedder no válida. Comprueba tus ajustes.",
"invalidApiKey": "Clave de API no válida. Comprueba la configuración de tu clave de API.",
"invalidBaseUrl": "URL base no válida. Comprueba la configuración de tu URL.",
"invalidModel": "Modelo no válido. Comprueba la configuración de tu modelo.",
"invalidResponse": "Respuesta no válida del servicio de embedder. Comprueba tu configuración."
}
}

16
src/i18n/locales/fr/common.json
View file

@ -17,7 +17,7 @@
"confirmation": {
"reset_state": "Êtes-vous sûr de vouloir réinitialiser le global state et le stockage de secrets de l'extension ? Cette action est irréversible.",
"delete_config_profile": "Êtes-vous sûr de vouloir supprimer ce profil de configuration ?",
"delete_custom_mode": "Êtes-vous sûr de vouloir supprimer ce mode personnalisé ?",
"delete_custom_mode_with_rules": "Êtes-vous sûr de vouloir supprimer ce mode {scope} ?\n\nCela supprimera également le dossier de règles associé à l'adresse :\n{rulesFolderPath}",
"delete_message": "Que souhaitez-vous supprimer ?",
"just_this_message": "Uniquement ce message",
"this_and_subsequent": "Ce message et tous les messages suivants"
@ -71,6 +71,7 @@
"share_not_enabled": "Le partage de tâches n'est pas activé pour cette organisation.",
"share_task_not_found": "Tâche non trouvée ou accès refusé.",
"mode_import_failed": "Échec de l'importation du mode : {{error}}",
"delete_rules_folder_failed": "Échec de la suppression du dossier de règles : {{rulesFolderPath}}. Erreur : {{error}}",
"claudeCode": {
"processExited": "Le processus Claude Code s'est terminé avec le code {{exitCode}}.",
"errorOutput": "Sortie d'erreur : {{output}}",
@ -144,6 +145,10 @@
"resetFailed": "Échec de la réinitialisation des modes personnalisés : {{error}}",
"modeNotFound": "Erreur d'écriture : Mode non trouvé",
"noWorkspaceForProject": "Aucun dossier d'espace de travail trouvé pour le mode spécifique au projet"
},
"scope": {
"project": "projet",
"global": "global"
}
},
"mdm": {
@ -152,5 +157,14 @@
"organization_mismatch": "Vous devez être authentifié avec le compte Roo Code Cloud de votre organisation.",
"verification_failed": "Impossible de vérifier l'authentification de l'organisation."
}
},
"prompts": {
"deleteMode": {
"title": "Supprimer le mode personnalisé",
"description": "Êtes-vous sûr de vouloir supprimer ce mode {{scope}} ? Cela supprimera également le dossier de règles associé à l'adresse : {{rulesFolderPath}}",
"descriptionNoRules": "Êtes-vous sûr de vouloir supprimer ce mode personnalisé ?",
"cancel": "Annuler",
"confirm": "Supprimer"
}
}
}

20
src/i18n/locales/fr/embeddings.json
View file

@ -10,7 +10,12 @@
"couldNotReadErrorBody": "Impossible de lire le corps de l'erreur",
"requestFailed": "Échec de la requête API Ollama avec le statut {{status}} {{statusText}} : {{errorBody}}",
"invalidResponseStructure": "Structure de réponse invalide de l'API Ollama : tableau \"embeddings\" non trouvé ou n'est pas un tableau.",
"embeddingFailed": "Échec de l'embedding Ollama : {{message}}"
"embeddingFailed": "Échec de l'embedding Ollama : {{message}}",
"serviceNotRunning": "Le service Ollama n'est pas en cours d'exécution sur {{baseUrl}}",
"serviceUnavailable": "Le service Ollama est indisponible (statut : {{status}})",
"modelNotFound": "Modèle Ollama introuvable : {{modelId}}",
"modelNotEmbeddingCapable": "Le modèle Ollama n'est pas capable d'intégrer : {{modelId}}",
"hostNotFound": "Hôte Ollama introuvable : {{baseUrl}}"
},
"scanner": {
"unknownErrorProcessingFile": "Erreur inconnue lors du traitement du fichier {{filePath}}",
@ -19,5 +24,18 @@
},
"vectorStore": {
"qdrantConnectionFailed": "Échec de la connexion à la base de données vectorielle Qdrant. Veuillez vous assurer que Qdrant fonctionne et est accessible à {{qdrantUrl}}. Erreur : {{errorMessage}}"
},
"validation": {
"authenticationFailed": "Échec de l'authentification. Veuillez vérifier votre clé API dans les paramètres.",
"connectionFailed": "Échec de la connexion au service d'embedding. Veuillez vérifier vos paramètres de connexion et vous assurer que le service est en cours d'exécution.",
"modelNotAvailable": "Le modèle spécifié n'est pas disponible. Veuillez vérifier la configuration de votre modèle.",
"configurationError": "Configuration de l'embedder invalide. Veuillez vérifier vos paramètres.",
"serviceUnavailable": "Le service d'embedding n'est pas disponible. Veuillez vous assurer qu'il est en cours d'exécution et accessible.",
"invalidEndpoint": "Point de terminaison d'API invalide. Veuillez vérifier votre configuration d'URL.",
"invalidEmbedderConfig": "Configuration de l'embedder invalide. Veuillez vérifier vos paramètres.",
"invalidApiKey": "Clé API invalide. Veuillez vérifier votre configuration de clé API.",
"invalidBaseUrl": "URL de base invalide. Veuillez vérifier votre configuration d'URL.",
"invalidModel": "Modèle invalide. Veuillez vérifier votre configuration de modèle.",
"invalidResponse": "Réponse invalide du service d'embedder. Veuillez vérifier votre configuration."
}
}

16
src/i18n/locales/hi/common.json
View file

@ -17,7 +17,7 @@
"confirmation": {
"reset_state": "क्या आप वाकई एक्सटेंशन में सभी स्टेट और गुप्त स्टोरेज रीसेट करना चाहते हैं? इसे पूर्ववत नहीं किया जा सकता है।",
"delete_config_profile": "क्या आप वाकई इस कॉन्फ़िगरेशन प्रोफ़ाइल को हटाना चाहते हैं?",
"delete_custom_mode": "क्या आप वाकई इस कस्टम मोड को हटाना चाहते हैं?",
"delete_custom_mode_with_rules": "क्या आप वाकई इस {scope} मोड को हटाना चाहते हैं?\n\nयह संबंधित नियम फ़ोल्डर को भी यहाँ हटा देगा:\n{rulesFolderPath}",
"delete_message": "आप क्या हटाना चाहते हैं?",
"just_this_message": "सिर्फ यह संदेश",
"this_and_subsequent": "यह और सभी बाद के संदेश"
@ -71,6 +71,7 @@
"share_not_enabled": "इस संगठन के लिए कार्य साझाकरण सक्षम नहीं है।",
"share_task_not_found": "कार्य नहीं मिला या पहुंच अस्वीकृत।",
"mode_import_failed": "मोड आयात करने में विफल: {{error}}",
"delete_rules_folder_failed": "नियम फ़ोल्डर हटाने में विफल: {{rulesFolderPath}}। त्रुटि: {{error}}",
"claudeCode": {
"processExited": "Claude Code प्रक्रिया कोड {{exitCode}} के साथ समाप्त हुई।",
"errorOutput": "त्रुटि आउटपुट: {{output}}",
@ -144,6 +145,10 @@
"resetFailed": "कस्टम मोड रीसेट विफल: {{error}}",
"modeNotFound": "लेखन त्रुटि: मोड नहीं मिला",
"noWorkspaceForProject": "प्रोजेक्ट-विशिष्ट मोड के लिए वर्कस्पेस फ़ोल्डर नहीं मिला"
},
"scope": {
"project": "परियोजना",
"global": "वैश्विक"
}
},
"mdm": {
@ -152,5 +157,14 @@
"organization_mismatch": "आपको अपने संगठन के Roo Code Cloud खाते से प्रमाणित होना होगा।",
"verification_failed": "संगठन प्रमाणीकरण सत्यापित करने में असमर्थ।"
}
},
"prompts": {
"deleteMode": {
"title": "कस्टम मोड हटाएं",
"description": "क्या आप वाकई इस {{scope}} मोड को हटाना चाहते हैं? यह संबंधित नियम फ़ोल्डर को भी {{rulesFolderPath}} पर हटा देगा",
"descriptionNoRules": "क्या आप वाकई इस कस्टम मोड को हटाना चाहते हैं?",
"cancel": "रद्द करें",
"confirm": "हटाएं"
}
}
}

20
src/i18n/locales/hi/embeddings.json
View file

@ -10,7 +10,12 @@
"couldNotReadErrorBody": "त्रुटि सामग्री पढ़ नहीं सका",
"requestFailed": "Ollama API अनुरोध स्थिति {{status}} {{statusText}} के साथ विफल: {{errorBody}}",
"invalidResponseStructure": "Ollama API से अमान्य प्रतिक्रिया संरचना: \"embeddings\" सरणी नहीं मिली या सरणी नहीं है।",
"embeddingFailed": "Ollama एम्बेडिंग विफल: {{message}}"
"embeddingFailed": "Ollama एम्बेडिंग विफल: {{message}}",
"serviceNotRunning": "ओलामा सेवा {{baseUrl}} पर नहीं चल रही है",
"serviceUnavailable": "ओलामा सेवा अनुपलब्ध है (स्थिति: {{status}})",
"modelNotFound": "ओलामा मॉडल नहीं मिला: {{modelId}}",
"modelNotEmbeddingCapable": "ओलामा मॉडल एम्बेडिंग में सक्षम नहीं है: {{modelId}}",
"hostNotFound": "ओलामा होस्ट नहीं मिला: {{baseUrl}}"
},
"scanner": {
"unknownErrorProcessingFile": "फ़ाइल {{filePath}} प्रसंस्करण में अज्ञात त्रुटि",
@ -19,5 +24,18 @@
},
"vectorStore": {
"qdrantConnectionFailed": "Qdrant वेक्टर डेटाबेस से कनेक्ट करने में विफल। कृपया सुनिश्चित करें कि Qdrant चल रहा है और {{qdrantUrl}} पर पहुंच योग्य है। त्रुटि: {{errorMessage}}"
},
"validation": {
"authenticationFailed": "प्रमाणीकरण विफल। कृपया सेटिंग्स में अपनी एपीआई कुंजी जांचें।",
"connectionFailed": "एम्बेडर सेवा से कनेक्ट करने में विफल। कृपया अपनी कनेक्शन सेटिंग्स जांचें और सुनिश्चित करें कि सेवा चल रही है।",
"modelNotAvailable": "निर्दिष्ट मॉडल उपलब्ध नहीं है। कृपया अपनी मॉडल कॉन्फ़िगरेशन जांचें।",
"configurationError": "अमान्य एम्बेडर कॉन्फ़िगरेशन। कृपया अपनी सेटिंग्स की समीक्षा करें।",
"serviceUnavailable": "एम्बेडर सेवा उपलब्ध नहीं है। कृपया सुनिश्चित करें कि यह चल रहा है और पहुंच योग्य है।",
"invalidEndpoint": "अमान्य एपीआई एंडपॉइंट। कृपया अपनी यूआरएल कॉन्फ़िगरेशन जांचें।",
"invalidEmbedderConfig": "अमान्य एम्बेडर कॉन्फ़िगरेशन। कृपया अपनी सेटिंग्स जांचें।",
"invalidApiKey": "अमान्य एपीआई कुंजी। कृपया अपनी एपीआई कुंजी कॉन्फ़िगरेशन जांचें।",
"invalidBaseUrl": "अमान्य बेस यूआरएल। कृपया अपनी यूआरएल कॉन्फ़िगरेशन जांचें।",
"invalidModel": "अमान्य मॉडल। कृपया अपनी मॉडल कॉन्फ़िगरेशन जांचें।",
"invalidResponse": "एम्बेडर सेवा से अमान्य प्रतिक्रिया। कृपया अपनी कॉन्फ़िगरेशन जांचें।"
}
}

16
src/i18n/locales/id/common.json
View file

@ -17,7 +17,7 @@
"confirmation": {
"reset_state": "Apakah kamu yakin ingin mereset semua state dan secret storage di ekstensi? Ini tidak dapat dibatalkan.",
"delete_config_profile": "Apakah kamu yakin ingin menghapus profil konfigurasi ini?",
"delete_custom_mode": "Apakah kamu yakin ingin menghapus mode kustom ini?",
"delete_custom_mode_with_rules": "Anda yakin ingin menghapus mode {scope} ini?\n\nIni juga akan menghapus folder aturan terkait di:\n{rulesFolderPath}",
"delete_message": "Apa yang ingin kamu hapus?",
"just_this_message": "Hanya pesan ini",
"this_and_subsequent": "Ini dan semua pesan selanjutnya"
@ -71,6 +71,7 @@
"share_not_enabled": "Berbagi tugas tidak diaktifkan untuk organisasi ini.",
"share_task_not_found": "Tugas tidak ditemukan atau akses ditolak.",
"mode_import_failed": "Gagal mengimpor mode: {{error}}",
"delete_rules_folder_failed": "Gagal menghapus folder aturan: {{rulesFolderPath}}. Error: {{error}}",
"claudeCode": {
"processExited": "Proses Claude Code keluar dengan kode {{exitCode}}.",
"errorOutput": "Output error: {{output}}",
@ -144,6 +145,10 @@
"resetFailed": "Gagal mereset mode kustom: {{error}}",
"modeNotFound": "Kesalahan tulis: Mode tidak ditemukan",
"noWorkspaceForProject": "Tidak ditemukan folder workspace untuk mode khusus proyek"
},
"scope": {
"project": "proyek",
"global": "global"
}
},
"mdm": {
@ -152,5 +157,14 @@
"organization_mismatch": "Kamu harus diautentikasi dengan akun Roo Code Cloud organisasi kamu.",
"verification_failed": "Tidak dapat memverifikasi autentikasi organisasi."
}
},
"prompts": {
"deleteMode": {
"title": "Hapus Mode Kustom",
"description": "Anda yakin ingin menghapus mode {{scope}} ini? Ini juga akan menghapus folder aturan terkait di: {{rulesFolderPath}}",
"descriptionNoRules": "Anda yakin ingin menghapus mode kustom ini?",
"cancel": "Batal",
"confirm": "Hapus"
}
}
}

20
src/i18n/locales/id/embeddings.json
View file

@ -10,7 +10,12 @@
"couldNotReadErrorBody": "Tidak dapat membaca body error",
"requestFailed": "Permintaan API Ollama gagal dengan status {{status}} {{statusText}}: {{errorBody}}",
"invalidResponseStructure": "Struktur respons tidak valid dari API Ollama: array \"embeddings\" tidak ditemukan atau bukan array.",
"embeddingFailed": "Embedding Ollama gagal: {{message}}"
"embeddingFailed": "Embedding Ollama gagal: {{message}}",
"serviceNotRunning": "Layanan Ollama tidak berjalan di {{baseUrl}}",
"serviceUnavailable": "Layanan Ollama tidak tersedia (status: {{status}})",
"modelNotFound": "Model Ollama tidak ditemukan: {{modelId}}",
"modelNotEmbeddingCapable": "Model Ollama tidak mampu melakukan embedding: {{modelId}}",
"hostNotFound": "Host Ollama tidak ditemukan: {{baseUrl}}"
},
"scanner": {
"unknownErrorProcessingFile": "Error tidak dikenal saat memproses file {{filePath}}",
@ -19,5 +24,18 @@
},
"vectorStore": {
"qdrantConnectionFailed": "Gagal terhubung ke database vektor Qdrant. Pastikan Qdrant berjalan dan dapat diakses di {{qdrantUrl}}. Error: {{errorMessage}}"
},
"validation": {
"authenticationFailed": "Autentikasi gagal. Silakan periksa kunci API Anda di pengaturan.",
"connectionFailed": "Gagal terhubung ke layanan embedder. Silakan periksa pengaturan koneksi Anda dan pastikan layanan berjalan.",
"modelNotAvailable": "Model yang ditentukan tidak tersedia. Silakan periksa konfigurasi model Anda.",
"configurationError": "Konfigurasi embedder tidak valid. Harap tinjau pengaturan Anda.",
"serviceUnavailable": "Layanan embedder tidak tersedia. Pastikan layanan tersebut berjalan dan dapat diakses.",
"invalidEndpoint": "Endpoint API tidak valid. Silakan periksa konfigurasi URL Anda.",
"invalidEmbedderConfig": "Konfigurasi embedder tidak valid. Silakan periksa pengaturan Anda.",
"invalidApiKey": "Kunci API tidak valid. Silakan periksa konfigurasi kunci API Anda.",
"invalidBaseUrl": "URL dasar tidak valid. Silakan periksa konfigurasi URL Anda.",
"invalidModel": "Model tidak valid. Silakan periksa konfigurasi model Anda.",
"invalidResponse": "Respons tidak valid dari layanan embedder. Silakan periksa konfigurasi Anda."
}
}

16
src/i18n/locales/it/common.json
View file

@ -17,7 +17,7 @@
"confirmation": {
"reset_state": "Sei sicuro di voler reimpostare tutti gli stati e l'archiviazione segreta nell'estensione? Questa azione non può essere annullata.",
"delete_config_profile": "Sei sicuro di voler eliminare questo profilo di configurazione?",
"delete_custom_mode": "Sei sicuro di voler eliminare questa modalità personalizzata?",
"delete_custom_mode_with_rules": "Sei sicuro di voler eliminare questa modalità {scope}?\n\nQuesto eliminerà anche la cartella delle regole associata in:\n{rulesFolderPath}",
"delete_message": "Cosa desideri eliminare?",
"just_this_message": "Solo questo messaggio",
"this_and_subsequent": "Questo e tutti i messaggi successivi"
@ -71,6 +71,7 @@
"share_not_enabled": "La condivisione delle attività non è abilitata per questa organizzazione.",
"share_task_not_found": "Attività non trovata o accesso negato.",
"mode_import_failed": "Importazione della modalità non riuscita: {{error}}",
"delete_rules_folder_failed": "Impossibile eliminare la cartella delle regole: {{rulesFolderPath}}. Errore: {{error}}",
"claudeCode": {
"processExited": "Il processo Claude Code è terminato con codice {{exitCode}}.",
"errorOutput": "Output di errore: {{output}}",
@ -144,6 +145,10 @@
"resetFailed": "Reset modalità personalizzate fallito: {{error}}",
"modeNotFound": "Errore di scrittura: Modalità non trovata",
"noWorkspaceForProject": "Nessuna cartella workspace trovata per la modalità specifica del progetto"
},
"scope": {
"project": "progetto",
"global": "globale"
}
},
"mdm": {
@ -152,5 +157,14 @@
"organization_mismatch": "Devi essere autenticato con l'account Roo Code Cloud della tua organizzazione.",
"verification_failed": "Impossibile verificare l'autenticazione dell'organizzazione."
}
},
"prompts": {
"deleteMode": {
"title": "Elimina Modalità Personalizzata",
"description": "Sei sicuro di voler eliminare questa modalità {{scope}}? Questo eliminerà anche la cartella delle regole associata a: {{rulesFolderPath}}",
"descriptionNoRules": "Sei sicuro di voler eliminare questa modalità personalizzata?",
"cancel": "Annulla",
"confirm": "Elimina"
}
}
}

20
src/i18n/locales/it/embeddings.json
View file

@ -10,7 +10,12 @@
"couldNotReadErrorBody": "Impossibile leggere il corpo dell'errore",
"requestFailed": "Richiesta API Ollama fallita con stato {{status}} {{statusText}}: {{errorBody}}",
"invalidResponseStructure": "Struttura di risposta non valida dall'API Ollama: array \"embeddings\" non trovato o non è un array.",
"embeddingFailed": "Embedding Ollama fallito: {{message}}"
"embeddingFailed": "Embedding Ollama fallito: {{message}}",
"serviceNotRunning": "Il servizio Ollama non è in esecuzione su {{baseUrl}}",
"serviceUnavailable": "Il servizio Ollama non è disponibile (stato: {{status}})",
"modelNotFound": "Modello Ollama non trovato: {{modelId}}",
"modelNotEmbeddingCapable": "Il modello Ollama non è in grado di eseguire l'embedding: {{modelId}}",
"hostNotFound": "Host Ollama non trovato: {{baseUrl}}"
},
"scanner": {
"unknownErrorProcessingFile": "Errore sconosciuto nell'elaborazione del file {{filePath}}",
@ -19,5 +24,18 @@
},
"vectorStore": {
"qdrantConnectionFailed": "Impossibile connettersi al database vettoriale Qdrant. Assicurati che Qdrant sia in esecuzione e accessibile su {{qdrantUrl}}. Errore: {{errorMessage}}"
},
"validation": {
"authenticationFailed": "Autenticazione fallita. Controlla la tua chiave API nelle impostazioni.",
"connectionFailed": "Connessione al servizio di embedder fallita. Controlla le impostazioni di connessione e assicurati che il servizio sia in esecuzione.",
"modelNotAvailable": "Il modello specificato non è disponibile. Controlla la configurazione del tuo modello.",
"configurationError": "Configurazione dell'embedder non valida. Rivedi le tue impostazioni.",
"serviceUnavailable": "Il servizio di embedder non è disponibile. Assicurati che sia in esecuzione e accessibile.",
"invalidEndpoint": "Endpoint API non valido. Controlla la configurazione del tuo URL.",
"invalidEmbedderConfig": "Configurazione dell'embedder non valida. Controlla le tue impostazioni.",
"invalidApiKey": "Chiave API non valida. Controlla la configurazione della tua chiave API.",
"invalidBaseUrl": "URL di base non valido. Controlla la configurazione del tuo URL.",
"invalidModel": "Modello non valido. Controlla la configurazione del tuo modello.",
"invalidResponse": "Risposta non valida dal servizio embedder. Controlla la tua configurazione."
}
}

18
src/i18n/locales/ja/common.json
View file

@ -17,7 +17,7 @@
"confirmation": {
"reset_state": "拡張機能のすべての状態とシークレットストレージをリセットしてもよろしいですか？この操作は元に戻せません。",
"delete_config_profile": "この設定プロファイルを削除してもよろしいですか？",
"delete_custom_mode": "このカスタムモードを削除してもよろしいですか？",
"delete_custom_mode_with_rules": "この{scope}モードを削除してもよろしいですか？\n\nこれにより、関連するルールフォルダも次の場所で削除されます:\n{rulesFolderPath}",
"delete_message": "何を削除しますか？",
"just_this_message": "このメッセージのみ",
"this_and_subsequent": "これ以降のすべてのメッセージ"
@ -70,7 +70,8 @@
"share_auth_required": "認証が必要です。タスクを共有するにはサインインしてください。",
"share_not_enabled": "この組織ではタスク共有が有効になっていません。",
"share_task_not_found": "タスクが見つからないか、アクセスが拒否されました。",
"mode_import_failed": "モードのインポートに失敗しました: {{error}}",
"mode_import_failed": "モードのインポートに失敗しました：{{error}}",
"delete_rules_folder_failed": "ルールフォルダの削除に失敗しました：{{rulesFolderPath}}。エラー：{{error}}",
"claudeCode": {
"processExited": "Claude Code プロセスがコード {{exitCode}} で終了しました。",
"errorOutput": "エラー出力：{{output}}",
@ -144,6 +145,10 @@
"resetFailed": "カスタムモードのリセットに失敗しました：{{error}}",
"modeNotFound": "書き込みエラー：モードが見つかりません",
"noWorkspaceForProject": "プロジェクト固有モード用のワークスペースフォルダーが見つかりません"
},
"scope": {
"project": "プロジェクト",
"global": "グローバル"
}
},
"mdm": {
@ -152,5 +157,14 @@
"organization_mismatch": "組織の Roo Code Cloud アカウントで認証する必要があります。",
"verification_failed": "組織認証の確認ができませんでした。"
}
},
"prompts": {
"deleteMode": {
"title": "カスタムモードの削除",
"description": "この{{scope}}モードを削除してもよろしいですか？これにより、関連するルールフォルダーも{{rulesFolderPath}}で削除されます",
"descriptionNoRules": "このカスタムモードを削除してもよろしいですか？",
"cancel": "キャンセル",
"confirm": "削除"
}
}
}

20
src/i18n/locales/ja/embeddings.json
View file

@ -10,7 +10,12 @@
"couldNotReadErrorBody": "エラー本文を読み取れませんでした",
"requestFailed": "Ollama APIリクエストが失敗しました。ステータス {{status}} {{statusText}}: {{errorBody}}",
"invalidResponseStructure": "Ollama APIからの無効な応答構造：\"embeddings\"配列が見つからないか、配列ではありません。",
"embeddingFailed": "Ollama埋め込みが失敗しました：{{message}}"
"embeddingFailed": "Ollama埋め込みが失敗しました：{{message}}",
"serviceNotRunning": "Ollamaサービスは{{baseUrl}}で実行されていません",
"serviceUnavailable": "Ollamaサービスは利用できません（ステータス：{{status}}）",
"modelNotFound": "Ollamaモデルが見つかりません：{{modelId}}",
"modelNotEmbeddingCapable": "Ollamaモデルは埋め込みに対応していません：{{modelId}}",
"hostNotFound": "Ollamaホストが見つかりません：{{baseUrl}}"
},
"scanner": {
"unknownErrorProcessingFile": "ファイル{{filePath}}の処理中に不明なエラーが発生しました",
@ -19,5 +24,18 @@
},
"vectorStore": {
"qdrantConnectionFailed": "Qdrantベクターデータベースへの接続に失敗しました。Qdrantが実行中で{{qdrantUrl}}でアクセス可能であることを確認してください。エラー：{{errorMessage}}"
},
"validation": {
"authenticationFailed": "認証に失敗しました。設定でAPIキーを確認してください。",
"connectionFailed": "エンベッダーサービスへの接続に失敗しました。接続設定を確認し、サービスが実行されていることを確認してください。",
"modelNotAvailable": "指定されたモデルは利用できません。モデル構成を確認してください。",
"configurationError": "無効なエンベッダー構成です。設定を確認してください。",
"serviceUnavailable": "エンベッダーサービスは利用できません。実行中でアクセス可能であることを確認してください。",
"invalidEndpoint": "無効なAPIエンドポイントです。URL構成を確認してください。",
"invalidEmbedderConfig": "無効なエンベッダー構成です。設定を確認してください。",
"invalidApiKey": "無効なAPIキーです。APIキー構成を確認してください。",
"invalidBaseUrl": "無効なベースURLです。URL構成を確認してください。",
"invalidModel": "無効なモデルです。モデル構成を確認してください。",
"invalidResponse": "エンベッダーサービスからの無効な応答です。設定を確認してください。"
}
}

16
src/i18n/locales/ko/common.json
View file

@ -17,7 +17,7 @@
"confirmation": {
"reset_state": "확장 프로그램의 모든 상태와 보안 저장소를 재설정하시겠습니까? 이 작업은 취소할 수 없습니다.",
"delete_config_profile": "이 구성 프로필을 삭제하시겠습니까?",
"delete_custom_mode": "이 사용자 지정 모드를 삭제하시겠습니까?",
"delete_custom_mode_with_rules": "이 {scope} 모드를 삭제하시겠습니까?\n\n이렇게 하면 연결된 규칙 폴더도 다음 위치에서 삭제됩니다:\n{rulesFolderPath}",
"delete_message": "무엇을 삭제하시겠습니까?",
"just_this_message": "이 메시지만",
"this_and_subsequent": "이 메시지와 모든 후속 메시지"
@ -71,6 +71,7 @@
"share_not_enabled": "이 조직에서는 작업 공유가 활성화되지 않았습니다.",
"share_task_not_found": "작업을 찾을 수 없거나 액세스가 거부되었습니다.",
"mode_import_failed": "모드 가져오기 실패: {{error}}",
"delete_rules_folder_failed": "규칙 폴더 삭제 실패: {{rulesFolderPath}}. 오류: {{error}}",
"claudeCode": {
"processExited": "Claude Code 프로세스가 코드 {{exitCode}}로 종료되었습니다.",
"errorOutput": "오류 출력: {{output}}",
@ -144,6 +145,10 @@
"resetFailed": "사용자 정의 모드 재설정 실패: {{error}}",
"modeNotFound": "쓰기 오류: 모드를 찾을 수 없습니다",
"noWorkspaceForProject": "프로젝트별 모드용 작업 공간 폴더를 찾을 수 없습니다"
},
"scope": {
"project": "프로젝트",
"global": "글로벌"
}
},
"mdm": {
@ -152,5 +157,14 @@
"organization_mismatch": "조직의 Roo Code Cloud 계정으로 인증해야 합니다.",
"verification_failed": "조직 인증을 확인할 수 없습니다."
}
},
"prompts": {
"deleteMode": {
"title": "사용자 정의 모드 삭제",
"description": "이 {{scope}} 모드를 삭제하시겠습니까? 이렇게 하면 {{rulesFolderPath}}의 관련 규칙 폴더도 삭제됩니다.",
"descriptionNoRules": "이 사용자 정의 모드를 삭제하시겠습니까?",
"cancel": "취소",
"confirm": "삭제"
}
}
}

20
src/i18n/locales/ko/embeddings.json
View file

@ -10,7 +10,12 @@
"couldNotReadErrorBody": "오류 본문을 읽을 수 없습니다",
"requestFailed": "Ollama API 요청이 실패했습니다. 상태 {{status}} {{statusText}}: {{errorBody}}",
"invalidResponseStructure": "Ollama API에서 잘못된 응답 구조: \"embeddings\" 배열을 찾을 수 없거나 배열이 아닙니다.",
"embeddingFailed": "Ollama 임베딩 실패: {{message}}"
"embeddingFailed": "Ollama 임베딩 실패: {{message}}",
"serviceNotRunning": "Ollama 서비스가 {{baseUrl}}에서 실행되고 있지 않습니다",
"serviceUnavailable": "Ollama 서비스를 사용할 수 없습니다 (상태: {{status}})",
"modelNotFound": "Ollama 모델을 찾을 수 없습니다: {{modelId}}",
"modelNotEmbeddingCapable": "Ollama 모델은 임베딩이 불가능합니다: {{modelId}}",
"hostNotFound": "Ollama 호스트를 찾을 수 없습니다: {{baseUrl}}"
},
"scanner": {
"unknownErrorProcessingFile": "파일 {{filePath}} 처리 중 알 수 없는 오류",
@ -19,5 +24,18 @@
},
"vectorStore": {
"qdrantConnectionFailed": "Qdrant 벡터 데이터베이스에 연결하지 못했습니다. Qdrant가 실행 중이고 {{qdrantUrl}}에서 접근 가능한지 확인하세요. 오류: {{errorMessage}}"
},
"validation": {
"authenticationFailed": "인증에 실패했습니다. 설정에서 API 키를 확인하세요.",
"connectionFailed": "임베더 서비스에 연결하지 못했습니다. 연결 설정을 확인하고 서비스가 실행 중인지 확인하세요.",
"modelNotAvailable": "지정된 모델을 사용할 수 없습니다. 모델 구성을 확인하세요.",
"configurationError": "잘못된 임베더 구성입니다. 설정을 검토하세요.",
"serviceUnavailable": "임베더 서비스를 사용할 수 없습니다. 실행 중이고 액세스 가능한지 확인하세요.",
"invalidEndpoint": "잘못된 API 엔드포인트입니다. URL 구성을 확인하세요.",
"invalidEmbedderConfig": "잘못된 임베더 구성입니다. 설정을 확인하세요.",
"invalidApiKey": "잘못된 API 키입니다. API 키 구성을 확인하세요.",
"invalidBaseUrl": "잘못된 기본 URL입니다. URL 구성을 확인하세요.",
"invalidModel": "잘못된 모델입니다. 모델 구성을 확인하세요.",
"invalidResponse": "임베더 서비스에서 잘못된 응답이 왔습니다. 구성을 확인하세요."
}
}

16
src/i18n/locales/nl/common.json
View file

@ -17,7 +17,7 @@
"confirmation": {
"reset_state": "Weet je zeker dat je alle status en geheime opslag in de extensie wilt resetten? Dit kan niet ongedaan worden gemaakt.",
"delete_config_profile": "Weet je zeker dat je dit configuratieprofiel wilt verwijderen?",
"delete_custom_mode": "Weet je zeker dat je deze aangepaste modus wilt verwijderen?",
"delete_custom_mode_with_rules": "Weet je zeker dat je deze {scope}-modus wilt verwijderen?\n\nDit verwijdert ook de bijbehorende regelsmap op:\n{rulesFolderPath}",
"delete_message": "Wat wil je verwijderen?",
"just_this_message": "Alleen dit bericht",
"this_and_subsequent": "Dit en alle volgende berichten"
@ -71,6 +71,7 @@
"share_not_enabled": "Taken delen is niet ingeschakeld voor deze organisatie.",
"share_task_not_found": "Taak niet gevonden of toegang geweigerd.",
"mode_import_failed": "Importeren van modus mislukt: {{error}}",
"delete_rules_folder_failed": "Kan regelmap niet verwijderen: {{rulesFolderPath}}. Fout: {{error}}",
"claudeCode": {
"processExited": "Claude Code proces beëindigd met code {{exitCode}}.",
"errorOutput": "Foutuitvoer: {{output}}",
@ -144,6 +145,10 @@
"resetFailed": "Aangepaste modi resetten mislukt: {{error}}",
"modeNotFound": "Schrijffout: Modus niet gevonden",
"noWorkspaceForProject": "Geen workspace map gevonden voor projectspecifieke modus"
},
"scope": {
"project": "project",
"global": "globaal"
}
},
"mdm": {
@ -152,5 +157,14 @@
"organization_mismatch": "Je moet geauthenticeerd zijn met het Roo Code Cloud-account van je organisatie.",
"verification_failed": "Kan organisatie-authenticatie niet verifiëren."
}
},
"prompts": {
"deleteMode": {
"title": "Aangepaste modus verwijderen",
"description": "Weet je zeker dat je deze {{scope}}-modus wilt verwijderen? Dit zal ook de bijbehorende regelsmap op {{rulesFolderPath}} verwijderen",
"descriptionNoRules": "Weet je zeker dat je deze aangepaste modus wilt verwijderen?",
"cancel": "Annuleren",
"confirm": "Verwijderen"
}
}
}

20
src/i18n/locales/nl/embeddings.json
View file

@ -10,7 +10,12 @@
"couldNotReadErrorBody": "Kon foutinhoud niet lezen",
"requestFailed": "Ollama API-verzoek mislukt met status {{status}} {{statusText}}: {{errorBody}}",
"invalidResponseStructure": "Ongeldige responsstructuur van Ollama API: \"embeddings\" array niet gevonden of is geen array.",
"embeddingFailed": "Ollama insluiting mislukt: {{message}}"
"embeddingFailed": "Ollama insluiting mislukt: {{message}}",
"serviceNotRunning": "Ollama-service draait niet op {{baseUrl}}",
"serviceUnavailable": "Ollama-service is niet beschikbaar (status: {{status}})",
"modelNotFound": "Ollama-model niet gevonden: {{modelId}}",
"modelNotEmbeddingCapable": "Ollama-model is niet in staat tot insluiten: {{modelId}}",
"hostNotFound": "Ollama-host niet gevonden: {{baseUrl}}"
},
"scanner": {
"unknownErrorProcessingFile": "Onbekende fout bij verwerken van bestand {{filePath}}",
@ -19,5 +24,18 @@
},
"vectorStore": {
"qdrantConnectionFailed": "Kan geen verbinding maken met Qdrant vectordatabase. Zorg ervoor dat Qdrant draait en toegankelijk is op {{qdrantUrl}}. Fout: {{errorMessage}}"
},
"validation": {
"authenticationFailed": "Authenticatie mislukt. Controleer je API-sleutel in de instellingen.",
"connectionFailed": "Verbinding met de embedder-service mislukt. Controleer je verbindingsinstellingen en zorg ervoor dat de service draait.",
"modelNotAvailable": "Het opgegeven model is niet beschikbaar. Controleer je modelconfiguratie.",
"configurationError": "Ongeldige embedder-configuratie. Controleer je instellingen.",
"serviceUnavailable": "De embedder-service is niet beschikbaar. Zorg ervoor dat deze draait en toegankelijk is.",
"invalidEndpoint": "Ongeldig API-eindpunt. Controleer je URL-configuratie.",
"invalidEmbedderConfig": "Ongeldige embedder-configuratie. Controleer je instellingen.",
"invalidApiKey": "Ongeldige API-sleutel. Controleer je API-sleutelconfiguratie.",
"invalidBaseUrl": "Ongeldige basis-URL. Controleer je URL-configuratie.",
"invalidModel": "Ongeldig model. Controleer je modelconfiguratie.",
"invalidResponse": "Ongeldige reactie van embedder-service. Controleer je configuratie."
}
}

16
src/i18n/locales/pl/common.json
View file

@ -17,7 +17,7 @@
"confirmation": {
"reset_state": "Czy na pewno chcesz zresetować wszystkie stany i tajne magazyny w rozszerzeniu? Tej operacji nie można cofnąć.",
"delete_config_profile": "Czy na pewno chcesz usunąć ten profil konfiguracyjny?",
"delete_custom_mode": "Czy na pewno chcesz usunąć ten niestandardowy tryb?",
"delete_custom_mode_with_rules": "Czy na pewno chcesz usunąć ten tryb {scope}?\n\nSpowoduje to również usunięcie powiązanego folderu reguł pod adresem:\n{rulesFolderPath}",
"delete_message": "Co chcesz usunąć?",
"just_this_message": "Tylko tę wiadomość",
"this_and_subsequent": "Tę i wszystkie kolejne wiadomości"
@ -71,6 +71,7 @@
"share_not_enabled": "Udostępnianie zadań nie jest włączone dla tej organizacji.",
"share_task_not_found": "Zadanie nie znalezione lub dostęp odmówiony.",
"mode_import_failed": "Import trybu nie powiódł się: {{error}}",
"delete_rules_folder_failed": "Nie udało się usunąć folderu reguł: {{rulesFolderPath}}. Błąd: {{error}}",
"claudeCode": {
"processExited": "Proces Claude Code zakończył się kodem {{exitCode}}.",
"errorOutput": "Wyjście błędu: {{output}}",
@ -144,6 +145,10 @@
"resetFailed": "Resetowanie trybów niestandardowych nie powiodło się: {{error}}",
"modeNotFound": "Błąd zapisu: Tryb nie został znaleziony",
"noWorkspaceForProject": "Nie znaleziono folderu obszaru roboczego dla trybu specyficznego dla projektu"
},
"scope": {
"project": "projekt",
"global": "globalny"
}
},
"mdm": {
@ -152,5 +157,14 @@
"organization_mismatch": "Musisz być uwierzytelniony kontem Roo Code Cloud swojej organizacji.",
"verification_failed": "Nie można zweryfikować uwierzytelnienia organizacji."
}
},
"prompts": {
"deleteMode": {
"title": "Usuń tryb niestandardowy",
"description": "Czy na pewno chcesz usunąć ten tryb {{scope}}? Spowoduje to również usunięcie powiązanego folderu z regułami w {{rulesFolderPath}}",
"descriptionNoRules": "Czy na pewno chcesz usunąć ten tryb niestandardowy?",
"cancel": "Anuluj",
"confirm": "Usuń"
}
}
}

Some files were not shown because too many files have changed in this diff Show more