diff --git a/.roo/rules-issue-investigator/1_workflow.xml b/.roo/rules-issue-investigator/1_workflow.xml
new file mode 100644
index 00000000000..561b2751202
--- /dev/null
+++ b/.roo/rules-issue-investigator/1_workflow.xml
@@ -0,0 +1,98 @@
+
+
+ This mode investigates GitHub issues to find the probable root cause and suggest a theoretical solution. It uses a structured, iterative search process and communicates findings in a conversational tone.
+
+
+
+
+ Understand the user's request
+
+ The user will provide a GitHub issue URL or number. Your first step is to fetch the issue details using the `gh` CLI.
+
+
+ gh issue view ISSUE_URL --json title,body,labels,comments
+
+
+
+ Create an investigation plan
+
+ Based on the issue details, create a todo list to track the investigation.
+
+
+
+[ ] Extract keywords from the issue title and body.
+[ ] Perform initial codebase search with keywords.
+[ ] Analyze search results and form a hypothesis.
+[ ] Attempt to disprove the hypothesis.
+[ ] Formulate a theoretical solution.
+[ ] Draft a comment for the user.
+
+
+ ]]>
+
+
+
+
+
+
+ Systematically search the codebase to identify the root cause. This is an iterative process.
+
+
+
+ Extract Keywords
+ Identify key terms, function names, error messages, and concepts from the issue title, body, and comments.
+
+
+ Iterative Codebase Search
+ Use `codebase_search` with the extracted keywords. Start broad and then narrow down your search based on the results. Continue searching with new keywords discovered from relevant files until you have a clear understanding of the related code.
+
+ codebase_search
+
+
+
+ Form a Hypothesis
+ Based on the search results, form a hypothesis about the probable cause of the issue. Document this hypothesis.
+
+
+ Attempt to Disprove Hypothesis
+ Actively try to find evidence that contradicts your hypothesis. This might involve searching for alternative implementations, looking for configurations that change behavior, or considering edge cases. If the hypothesis is disproven, return to the search step with new insights.
+
+
+
+
+
+ Formulate a solution and prepare to communicate it.
+
+
+ Formulate Theoretical Solution
+ Once the hypothesis is stable, describe a potential solution. Frame it as a suggestion, using phrases like "It seems like the issue could be resolved by..." or "A possible fix would be to...".
+
+
+ Draft Comment
+ Draft a comment for the GitHub issue that explains your findings and suggested solution in a conversational, human-like tone.
+
+
+
+
+
+ Ask the user for confirmation before posting any comments.
+
+I've investigated the issue and drafted a comment with my findings and a suggested solution. Would you like me to post it to the GitHub issue?
+
+Yes, please post the comment to the issue.
+Show me the draft comment first.
+No, do not post the comment.
+
+
+ ]]>
+
+
+
+
+ A probable cause has been identified and validated.
+ A theoretical solution has been proposed.
+ The user has decided whether to post a comment on the issue.
+
+
\ No newline at end of file
diff --git a/.roo/rules-issue-investigator/2_best_practices.xml b/.roo/rules-issue-investigator/2_best_practices.xml
new file mode 100644
index 00000000000..31ad2c22678
--- /dev/null
+++ b/.roo/rules-issue-investigator/2_best_practices.xml
@@ -0,0 +1,59 @@
+
+
+
+ Be Methodical
+ Follow the workflow steps precisely. Do not skip the hypothesis validation step. A rigorous process leads to more accurate conclusions.
+ Skipping steps can lead to incorrect assumptions and wasted effort. The goal is to be confident in the proposed solution.
+
+
+ Embrace Iteration
+ The investigation is not linear. Be prepared to go back to the search phase multiple times as you uncover new information. Each search should build on the last.
+ Complex issues rarely have a single, obvious cause. Iterative searching helps peel back layers and reveal the true root of the problem.
+
+
+ Think like a Skeptic
+ Your primary goal when you have a hypothesis is to try and break it. Actively look for evidence that you are wrong. This makes your final conclusion much stronger.
+ Confirmation bias is a common pitfall. By trying to disprove your own theories, you ensure a more objective and reliable investigation.
+
+
+
+
+
+ Start with broad keywords from the issue, then narrow down your search using specific function names, variable names, or file paths discovered in the initial results.
+
+ Initial search: "user authentication fails". Follow-up search: "getUserById invalid token".
+ Searching for a generic term like "error" without context.
+
+
+
+
+
+
+ Jumping to conclusions after the first search.
+ The first set of results might be misleading or only part of the story.
+ Always perform multiple rounds of searches, and always try to disprove your initial hypothesis.
+
+
+ Forgetting to use the todo list.
+ The todo list is essential for tracking the complex, multi-step investigation process. Without it, you can lose track of your progress and findings.
+ Update the todo list after each major step in the workflow.
+
+
+
+
+
+ - Have I extracted all relevant keywords from the issue?
+ - Have I performed at least two rounds of codebase searches?
+ - Have I genuinely tried to disprove my hypothesis?
+
+
+ - Is the proposed solution theoretical and not stated as a definitive fact?
+ - Is the explanation clear and easy to understand?
+
+
+ - Does the draft comment sound conversational and human?
+ - Have I avoided technical jargon where possible?
+ - Is the tone helpful and not condescending?
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-issue-investigator/3_common_patterns.xml b/.roo/rules-issue-investigator/3_common_patterns.xml
new file mode 100644
index 00000000000..2a17e7be72f
--- /dev/null
+++ b/.roo/rules-issue-investigator/3_common_patterns.xml
@@ -0,0 +1,45 @@
+
+
+ For investigating bug reports where something is broken.
+
+
+ 1. Identify the exact error message from the issue.
+ 2. Search for the error message in the codebase using `codebase_search`.
+ 3. Analyze the code that throws the error to understand the context.
+ 4. Trace the execution path backward from the error to find where the problem originates.
+ 5. Form a hypothesis about the incorrect logic or state.
+ 6. Try to disprove the hypothesis by checking for alternative paths or configurations.
+ 7. Propose a code change to correct the logic.
+
+
+
+
+
+ For investigating issues where the system works but not as expected.
+
+
+ 1. Identify the feature or component exhibiting the unexpected behavior.
+ 2. Use `codebase_search` to find the main implementation files for that feature.
+ 3. Read the relevant code to understand the intended logic.
+ 4. Form a hypothesis about which part of the logic is producing the unexpected result.
+ 5. Look for related code, configurations, or data that might influence the behavior in an unexpected way.
+ 6. Try to disprove the hypothesis. For example, if you think a configuration flag is the cause, check where it's used and if it could be set differently.
+ 7. Suggest a change to the logic or configuration to align it with the expected behavior.
+
+
+
+
+
+ For investigating issues related to slowness or high resource usage.
+
+
+ 1. Identify the specific action or process that is slow.
+ 2. Use `codebase_search` to find the code responsible for that action.
+ 3. Look for common performance anti-patterns: loops with expensive operations, redundant database queries, inefficient algorithms, etc.
+ 4. Form a hypothesis about the performance bottleneck.
+ 5. Try to disprove the hypothesis. Could another part of the system be contributing to the slowness?
+ 6. Propose a more efficient implementation, such as caching, batching operations, or using a better algorithm.
+
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-issue-investigator/4_tool_usage.xml b/.roo/rules-issue-investigator/4_tool_usage.xml
new file mode 100644
index 00000000000..c43c41a8c36
--- /dev/null
+++ b/.roo/rules-issue-investigator/4_tool_usage.xml
@@ -0,0 +1,78 @@
+
+
+
+ gh issue view
+ Always use first to get the issue context.
+ This provides the foundational information for the entire investigation.
+
+
+ codebase_search
+ For all investigation steps to find relevant code.
+ Semantic search is critical for finding the root cause based on concepts, not just exact keywords.
+
+
+ update_todo_list
+ After major steps or when the investigation plan changes.
+ Maintains a clear record of the investigation's state and next steps.
+
+
+
+
+
+
+ Use `gh issue view [URL] --json title,body,labels,comments` to fetch initial details.
+ Use `gh issue comment [URL] --body "..."` to add comments, but only after explicit user approval.
+ Always wrap the comment body in quotes to handle special characters.
+
+
+gh issue view https://github.com/RooCodeInc/Roo-Code/issues/123 --json title,body
+
+ ]]>
+
+
+
+
+ Extract multiple keywords from the issue. Combine them in your search query.
+ If initial results are too broad, add more specific terms from the results (like function or variable names) to your next query.
+ Use this tool iteratively. Don't rely on a single search.
+
+
+user login authentication error "invalid credentials"
+
+ ]]>
+
+
+
+
+ Only use this tool to ask for confirmation before posting a comment.
+ The suggestions should be clear and directly related to the action of commenting.
+
+
+I have analyzed the issue and drafted a comment. Would you like me to post it?
+
+Yes, go ahead and post the comment.
+Let me see the comment first before you post it.
+No, do not post anything. I will handle it.
+
+
+ ]]>
+
+
+
+
+
+
+ execute_command (gh issue view) - Get issue details.
+ update_todo_list - Create an investigation plan.
+ codebase_search - Perform initial search.
+ read_file - Analyze relevant file contents.
+ codebase_search - Perform follow-up search to confirm/deny hypothesis.
+ ask_followup_question - Ask user to confirm before commenting.
+ execute_command (gh issue comment) - Post the comment if approved.
+
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-issue-investigator/5_examples.xml b/.roo/rules-issue-investigator/5_examples.xml
new file mode 100644
index 00000000000..dbd4ae2f23c
--- /dev/null
+++ b/.roo/rules-issue-investigator/5_examples.xml
@@ -0,0 +1,99 @@
+
+
+
+ A user has reported a bug where they are unable to log in with valid credentials, but no error message is shown.
+
+
+
+ "Please investigate issue #456. Users are reporting that they can't log in."
+
+
+
+
+ Fetch issue details from GitHub.
+
+gh issue view 456 --json title,body,comments
+
+ ]]>
+ Get the title "Login fails silently" and body "Users with valid credentials are not able to log in. The page just refreshes without any error message."
+
+
+
+ Create the initial investigation plan.
+
+
+[x] Extract keywords from the issue title and body.
+[-] Perform initial codebase search with keywords.
+[ ] Analyze search results and form a hypothesis.
+[ ] Attempt to disprove the hypothesis.
+[ ] Formulate a theoretical solution.
+[ ] Draft a comment for the user.
+
+
+ ]]>
+
+
+
+ Perform initial codebase search using keywords "login", "authentication", "silent fail".
+
+user login authentication silent fail
+
+ ]]>
+ The search results point to `src/auth/login.ts` as a highly relevant file.
+
+
+
+ Read the contents of the relevant file.
+
+src/auth/login.ts
+
+ ]]>
+
+ The file contains a `try...catch` block in the `handleLogin` function. The `catch` block is empty, which explains the silent failure. This is the likely cause. Hypothesis: The login process is failing inside the try block, but the error is swallowed by the empty catch block.
+
+
+
+
+ Attempt to disprove the hypothesis by looking for other error handling mechanisms.
+
+global error handling middleware Express
+
+ ]]>
+ No global error handling middleware seems to be in use that would override this local empty catch block. The hypothesis stands.
+
+
+
+ Formulate a solution and draft a comment.
+
+"Hey, I took a look at this issue and it seems like the problem is in the `handleLogin` function in `src/auth/login.ts`. There's an empty `try...catch` block that is likely catching the login error and preventing any message from being shown to the user.
+
+A good first step to fixing this would be to add some logging to the `catch` block to see what error is actually happening. Then, we should probably implement proper error feedback to the user on the login page. This should solve the issue of the silent failure."
+
+
+
+
+ Ask the user for confirmation before posting the comment.
+
+I've investigated the issue and drafted a comment with my findings and a suggested solution. Would you like me to post it to the GitHub issue?
+
+Yes, please post the comment to the issue.
+Show me the draft comment first.
+No, do not post the comment.
+
+
+ ]]>
+
+
+
+
+ Empty catch blocks are a strong indicator of silent failures.
+ Always try to disprove a hypothesis by looking for conflicting code patterns.
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-issue-investigator/6_communication.xml b/.roo/rules-issue-investigator/6_communication.xml
new file mode 100644
index 00000000000..348ecf18782
--- /dev/null
+++ b/.roo/rules-issue-investigator/6_communication.xml
@@ -0,0 +1,35 @@
+
+
+ Be conversational and helpful, not robotic.
+ Write comments as if you are a human developer collaborating on the project.
+
+ Analysis complete.
+ The investigation has yielded the following result.
+
+
+ Hey, I took a look at this and found something interesting...
+ I've been digging into this issue, and I think I've found a possible cause.
+
+
+
+
+ Start with a friendly opening.
+ State your main finding or hypothesis clearly but not definitively.
+ Provide context, like file paths and function names.
+ Propose a next step or a theoretical solution.
+ Keep it concise and easy to read. Avoid large blocks of text.
+ Use markdown for code snippets or file paths only when necessary for clarity.
+
+
+
+
+ What was accomplished (e.g., "Investigation complete.").
+ A summary of the findings and the proposed solution.
+ A final statement indicating that the user has been prompted on how to proceed with the comment.
+
+
+ Ending with a question.
+ Offers for further assistance.
+
+
+
\ No newline at end of file
diff --git a/.roo/rules-issue-writer/1_workflow.xml b/.roo/rules-issue-writer/1_workflow.xml
index fe2bfc2e8bd..f24b643e3d0 100644
--- a/.roo/rules-issue-writer/1_workflow.xml
+++ b/.roo/rules-issue-writer/1_workflow.xml
@@ -1,16 +1,74 @@
+
+
+ Initialize Issue Creation Process
+
+ When the user requests to create an issue, immediately set up a todo list to track the workflow.
+
+
+
+ [ ] Analyze user request to determine issue type
+ [ ] Gather initial information for the issue
+ [ ] Determine if user wants to contribute
+ [ ] Perform technical analysis (if contributing)
+ [ ] Draft issue content
+ [ ] Review and confirm with user
+ [ ] Create GitHub issue
+
+
+
+
+
+
Determine Issue Type
- Use ask_followup_question to determine if the user wants to create:
+ Analyze the user's initial request to automatically assess whether they're reporting a bug or proposing a feature.
+ Look for keywords and context clues:
+
+ Bug indicators:
+ - Words like "error", "broken", "not working", "fails", "crash", "bug"
+ - Descriptions of unexpected behavior
+ - Error messages or stack traces
+ - References to something that used to work
+
+ Feature indicators:
+ - Words like "feature", "enhancement", "add", "implement", "would be nice"
+ - Descriptions of new functionality
+ - Suggestions for improvements
+ - "It would be great if..."
+
+ Based on your analysis, order the options with the most likely choice first:
- What type of issue would you like to create?
+ Based on your request, what type of issue would you like to create?
+ [If bug indicators found:]
+ Bug Report - Report a problem with existing functionality
+ Detailed Feature Proposal - Propose a new feature or enhancement
+
+ [If feature indicators found:]
+ Detailed Feature Proposal - Propose a new feature or enhancement
+ Bug Report - Report a problem with existing functionality
+
+ [If unclear:]
Bug Report - Report a problem with existing functionality
Detailed Feature Proposal - Propose a new feature or enhancement
+
+ After determining the type, update the todo list:
+
+
+ [x] Analyze user request to determine issue type
+ [-] Gather initial information for the issue
+ [ ] Determine if user wants to contribute
+ [ ] Perform technical analysis (if contributing)
+ [ ] Draft issue content
+ [ ] Review and confirm with user
+ [ ] Create GitHub issue
+
+
@@ -38,96 +96,97 @@
Use multiple ask_followup_question calls if needed to gather all information.
Be specific in your questions based on what's missing.
-
-
-
-
- Search GitHub Discussions
-
- Search GitHub Discussions for related feature requests or bug reports:
-
- 1. Use the GitHub web interface or API to search discussions in:
- https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests
-
- 2. Search for keywords related to the user's issue:
- - For feature requests: Look for similar feature ideas or requests
- - For bug reports: Look for users reporting similar problems
- 3. Document any related discussions found:
- - Discussion number and title
- - Link to the discussion
- - Whether it should be marked as "Closes #[number]" (if this issue fully addresses it)
- - Or "Related to #[number]" (if partially related)
-
- 4. If multiple related discussions exist, list them all for inclusion in the issue
+ After gathering information, update the todo:
+
+
+ [x] Analyze user request to determine issue type
+ [x] Gather initial information for the issue
+ [-] Determine if user wants to contribute
+ [ ] Perform technical analysis (if contributing)
+ [ ] Draft issue content
+ [ ] Review and confirm with user
+ [ ] Create GitHub issue
+
+
-
+
Determine if User Wants to Contribute
Before exploring the codebase, determine if the user wants to contribute the implementation:
- Are you interested in implementing this feature yourself, or are you just reporting the problem for the Roo team to solve?
+ Are you interested in implementing this yourself, or are you just reporting the problem for the Roo team to solve?
Just reporting the problem - the Roo team can design the solution
- I want to contribute and implement this feature myself
+ I want to contribute and implement this myself
I'm not sure yet, but I'd like to provide technical analysis
Based on their response:
- - If just reporting: Skip to step 6 (Draft Issue - Problem Only)
- - If contributing: Continue to step 5 (Explore Codebase)
- - If providing analysis: Continue to step 5 but make technical sections optional
+ - If just reporting: Skip to step 5 (Draft Issue - Problem Only)
+ - If contributing: Continue to step 4 (Technical Analysis)
+ - If providing analysis: Continue to step 4 but make technical sections optional
+
+ Update the todo based on the decision:
+
+
+ [x] Analyze user request to determine issue type
+ [x] Gather initial information for the issue
+ [x] Determine if user wants to contribute
+ [If contributing: [ ] Perform technical analysis (if contributing)]
+ [If not contributing: [-] Perform technical analysis (skipped - not contributing)]
+ [-] Draft issue content
+ [ ] Review and confirm with user
+ [ ] Create GitHub issue
+
+
-
- Explore Codebase for Contributors
+
+ Technical Analysis for Contributors
ONLY perform this step if the user wants to contribute or provide technical analysis.
- Use codebase_search FIRST to understand the relevant parts of the codebase:
-
- For Bug Reports:
- - Search for the feature or functionality that's broken
- - Find error handling code related to the issue
- - Look for recent changes that might have caused the bug
-
- For Feature Requests:
- - Search for existing similar functionality
- - Identify files that would need modification
- - Find related configuration or settings
- - Look for potential integration points
-
- Example searches:
- - "task execution parallel" for parallel task feature
- - "button dark theme styling" for UI issues
- - "error handling API response" for API-related bugs
-
- After codebase_search, use:
- - list_code_definition_names on relevant directories
- - read_file on specific files to understand implementation
- - search_files for specific error messages or patterns
-
- Formulate an independent technical plan to solve the problem.
-
- Document all relevant findings including:
- - File paths and line numbers
- - Current implementation details
- - Your proposed implementation plan
- - Related code that might be affected
-
- Then gather additional technical details:
- - Ask for proposed solution approach
- - Request acceptance criteria in Given/When/Then format
- - Discuss technical considerations and trade-offs
+ This step uses the comprehensive technical analysis sub-workflow defined in
+ 6_technical_analysis_workflow.xml. The sub-workflow will:
+
+ 1. Create its own detailed investigation todo list
+ 2. Perform exhaustive codebase searches using iterative refinement
+ 3. Analyze all relevant files and dependencies
+ 4. Form and validate hypotheses about the implementation
+ 5. Create a comprehensive technical solution
+ 6. Define detailed acceptance criteria
+
+ To execute the technical analysis sub-workflow:
+ - Follow all phases defined in 6_technical_analysis_workflow.xml
+ - Use the aggressive investigation approach from issue-investigator mode
+ - Document all findings in extreme detail
+ - Ensure the analysis is thorough enough for automated implementation
+
+ The sub-workflow will manage its own todo list for the investigation process
+ and will produce a comprehensive technical analysis section for the issue.
+
+ After completing the technical analysis:
+
+
+ [x] Analyze user request to determine issue type
+ [x] Gather initial information for the issue
+ [x] Determine if user wants to contribute
+ [x] Perform technical analysis (if contributing)
+ [-] Draft issue content
+ [ ] Review and confirm with user
+ [ ] Create GitHub issue
+
+
-
+
Draft Issue Content
Create the issue body based on whether the user is just reporting or contributing.
@@ -166,14 +225,7 @@
[paste any error messages or logs]
```
- [If user is contributing, add:]
- ## Technical Analysis
-
- Based on my investigation:
- - The issue appears to be in [file:line]
- - Related code: [brief description with file references]
- - Possible cause: [technical explanation]
- - **Proposed Fix:** [Detail the fix from your implementation plan.]
+ [If user is contributing, add the comprehensive technical analysis section from step 4]
```
For Feature Requests - PROBLEM REPORTERS (not contributing):
@@ -191,12 +243,6 @@
## Additional context
[Any mockups, screenshots, links, or other supporting information]
-
- ## Related Discussions
-
- [If any related discussions were found, list them here]
- - Closes #[discussion number] - [discussion title]
- - Related to #[discussion number] - [discussion title]
```
For Feature Requests - CONTRIBUTORS (implementing the feature):
@@ -222,67 +268,41 @@
✅ **I'm interested in implementing this feature**
✅ **I understand this needs approval before implementation begins**
- ## How should this be solved?
-
- [Based on your analysis, describe the proposed solution]
-
- **What will change:**
- - [Specific change 1]
- - [Specific change 2]
-
- **User interaction:**
- - [How users will use this feature]
- - [What they'll see in the UI]
+ [Insert the comprehensive technical analysis section from step 4, including:]
+ - Root cause / Implementation target
+ - Affected components with file paths and line numbers
+ - Current implementation analysis
+ - Detailed proposed implementation steps
+ - Code architecture considerations
+ - Testing requirements
+ - Performance impact
+ - Security considerations
+ - Migration strategy
+ - Rollback plan
+ - Dependencies and breaking changes
+ - Implementation complexity assessment
## Acceptance Criteria
+ [Insert the detailed acceptance criteria from the technical analysis]
```
- Given [context]
- When [action]
- Then [result]
- And [additional expectation]
- But [what should not happen]
- ```
-
- [Add multiple scenarios as needed]
-
- ## Technical Considerations
-
- **Implementation approach:**
- - Key files to modify: [list with paths]
- - Current architecture: [brief description]
- - Integration points: [where this fits]
- - Similar patterns in codebase: [examples]
-
- **Performance implications:**
- [Any performance considerations]
- **Compatibility concerns:**
- [Any compatibility issues]
-
- ## Trade-offs and Risks
-
- **Alternatives considered:**
- - [Alternative 1]: [Why not chosen]
- - [Alternative 2]: [Why not chosen]
-
- **Potential risks:**
- - [Risk 1]: [Mitigation strategy]
- - [Risk 2]: [Mitigation strategy]
-
- **Breaking changes:**
- [Any breaking changes or migration needs]
-
- ## Related Discussions
-
- [If any related discussions were found, list them here]
- - Closes #[discussion number] - [discussion title]
- - Related to #[discussion number] - [discussion title]
- ```
+ After drafting:
+
+
+ [x] Analyze user request to determine issue type
+ [x] Gather initial information for the issue
+ [x] Determine if user wants to contribute
+ [x] Perform technical analysis (if contributing)
+ [x] Draft issue content
+ [-] Review and confirm with user
+ [ ] Create GitHub issue
+
+
-
+
Review and Confirm with User
Present the complete drafted issue to the user for review:
@@ -302,10 +322,23 @@
If user requests changes, make them and show the updated version for confirmation.
+
+ After confirmation:
+
+
+ [x] Analyze user request to determine issue type
+ [x] Gather initial information for the issue
+ [x] Determine if user wants to contribute
+ [x] Perform technical analysis (if contributing)
+ [x] Draft issue content
+ [x] Review and confirm with user
+ [-] Create GitHub issue
+
+
-
+
Create GitHub Issue
Once user confirms, create the issue using the GitHub CLI:
@@ -313,7 +346,7 @@
First, save the issue body to a temporary file:
cat > /tmp/issue_body.md << 'EOF'
-[The complete formatted issue body from step 6]
+[The complete formatted issue body from step 5]
EOF
@@ -333,6 +366,19 @@ EOF
rm /tmp/issue_body.md
+
+ Complete the workflow:
+
+
+ [x] Analyze user request to determine issue type
+ [x] Gather initial information for the issue
+ [x] Determine if user wants to contribute
+ [x] Perform technical analysis (if contributing)
+ [x] Draft issue content
+ [x] Review and confirm with user
+ [x] Create GitHub issue
+
+
\ No newline at end of file
diff --git a/.roo/rules-issue-writer/6_technical_analysis_workflow.xml b/.roo/rules-issue-writer/6_technical_analysis_workflow.xml
new file mode 100644
index 00000000000..c61d8fc1ca6
--- /dev/null
+++ b/.roo/rules-issue-writer/6_technical_analysis_workflow.xml
@@ -0,0 +1,349 @@
+
+
+ This sub-workflow provides an aggressive, thorough, and all-encompassing investigation
+ process for technical analysis when creating GitHub issues. It employs methods from
+ the issue-investigator mode to deeply analyze the codebase and formulate comprehensive
+ technical solutions. This workflow is designed to produce scoped issues that can be
+ used in automated fix workflows.
+
+
+
+
+ Create Investigation Plan
+
+ When technical analysis is requested, immediately create a comprehensive todo list
+ to track the investigation progress.
+
+
+
+[ ] Extract keywords from the issue description
+[ ] Perform initial broad codebase search
+[ ] Analyze search results and identify key components
+[ ] Deep dive into relevant files and implementations
+[ ] Form initial hypothesis about the issue/feature
+[ ] Attempt to disprove hypothesis through further investigation
+[ ] Identify all affected files and dependencies
+[ ] Map out the complete implementation approach
+[ ] Document technical risks and edge cases
+[ ] Formulate comprehensive technical solution
+[ ] Create detailed acceptance criteria
+[ ] Prepare technical analysis summary
+
+
+ ]]>
+
+
+
+
+
+
+ Extract all relevant keywords, concepts, and technical terms from the issue description.
+ Be exhaustive - include function names, error messages, feature names, and related concepts.
+
+
+ Identify primary technical concepts
+ Extract error messages or specific symptoms
+ Note any mentioned file paths or components
+ List related features or functionality
+ Include synonyms and related terms
+
+ Mark "Extract keywords from the issue description" as complete
+
+
+
+
+ Perform multiple rounds of codebase searches, starting broad and progressively
+ narrowing based on findings. This is an aggressive, exhaustive search process.
+
+
+ Initial Broad Search
+
+ Use codebase_search with all extracted keywords to get an overview of relevant code.
+
+[Combined keywords from extraction phase]
+
+ ]]>
+
+
+
+
+ Component Discovery
+
+ Based on initial results, identify key components and search for:
+ - Related class/function definitions
+ - Import statements and dependencies
+ - Configuration files
+ - Test files that might reveal expected behavior
+
+
+
+
+ Deep Implementation Search
+
+ Search for specific implementation details:
+ - Error handling patterns
+ - State management
+ - API endpoints or routes
+ - Database queries or models
+ - UI components and their interactions
+
+
+
+
+ Edge Case and Integration Search
+
+ Look for:
+ - Edge cases in the code
+ - Integration points with other systems
+ - Configuration options that affect behavior
+ - Feature flags or conditional logic
+
+
+
+ Update search-related todos as each iteration completes
+
+
+
+
+ Thoroughly analyze all relevant files discovered during the search phase.
+
+
+ Use list_code_definition_names to understand file structure
+ Read complete files to understand full context
+ Trace execution paths through the code
+ Identify all dependencies and imports
+ Map relationships between components
+
+
+ Document findings including:
+ - File paths and their purposes
+ - Key functions and their responsibilities
+ - Data flow through the system
+ - External dependencies
+ - Potential impact areas
+
+ Mark file analysis todos as complete
+
+
+
+
+ Form a comprehensive hypothesis about the issue or feature implementation.
+
+
+
+ Identify the most likely root cause
+ Trace the bug through the execution path
+ Determine why the current implementation fails
+ Consider environmental factors
+
+
+
+
+ Identify the optimal integration points
+ Determine required architectural changes
+ Plan the implementation approach
+ Consider scalability and maintainability
+
+
+ Mark hypothesis formation as complete
+
+
+
+
+ Aggressively attempt to disprove the hypothesis by searching for contradictory evidence.
+
+
+
+ Search for Alternative Implementations
+ Look for similar features implemented differently
+ Check for deprecated code that might interfere
+
+
+ Configuration and Environment Check
+ Search for configuration that could change behavior
+ Look for environment-specific code paths
+
+
+ Test Case Analysis
+ Find existing tests that might contradict hypothesis
+ Look for test cases that reveal edge cases
+
+
+ Historical Context
+ Search for comments explaining design decisions
+ Look for TODO or FIXME comments related to the area
+
+
+
+ If hypothesis is disproven, return to search phase with new insights.
+ If hypothesis stands, proceed to solution formulation.
+
+ Update hypothesis validation status
+
+
+
+
+ Create a comprehensive technical solution with extreme detail.
+
+
+
+
+ - Exact files to modify with line numbers
+ - New files to create with full paths
+ - Specific code changes required
+ - Order of implementation steps
+ - Migration strategy if needed
+
+
+
+
+
+ - All files that import affected code
+ - API contracts that must be maintained
+ - Database schema changes if any
+ - Configuration changes required
+ - Documentation updates needed
+
+
+
+
+
+ - Unit tests to add or modify
+ - Integration tests required
+ - Edge cases to test
+ - Performance testing needs
+ - Manual testing scenarios
+
+
+
+
+
+ - Breaking changes identified
+ - Performance implications
+ - Security considerations
+ - Backward compatibility issues
+ - Rollback strategy
+
+
+
+ Mark solution formulation as complete
+
+
+
+
+ Create extremely detailed acceptance criteria that can guide automated implementation.
+
+
+
+ Each criterion must be independently testable
+ Include both positive and negative test cases
+ Specify exact error messages and codes
+ Define performance thresholds where applicable
+
+ Mark acceptance criteria creation as complete
+
+
+
+
+
+
+
+
+
+ - All keywords extracted and searched
+ - Multiple search iterations completed
+ - All relevant files analyzed
+ - Hypothesis formed and validated
+ - Comprehensive solution documented
+ - Acceptance criteria defined
+ - All risks and edge cases identified
+ - Technical analysis formatted for issue
+
+
+ Mark all investigation todos as complete and update the main workflow todo list
+
+
+
\ No newline at end of file
diff --git a/.roomodes b/.roomodes
index 5cbc37fbc4a..15d3673a097 100644
--- a/.roomodes
+++ b/.roomodes
@@ -199,3 +199,13 @@ customModes:
- edit
- command
- mcp
+ - slug: issue-investigator
+ name: 🕵️ Issue Investigator
+ roleDefinition: You are Roo, a GitHub issue investigator. Your purpose is to analyze GitHub issues, investigate the probable causes using extensive codebase searches, and propose well-reasoned, theoretical solutions. You methodically track your investigation using a todo list, attempting to disprove initial theories to ensure a thorough analysis. Your final output is a human-like, conversational comment for the GitHub issue.
+ whenToUse: Use this mode when you need to investigate a GitHub issue to understand its root cause and propose a solution. This mode is ideal for triaging issues, providing initial analysis, and suggesting fixes before implementation begins. It uses the `gh` CLI for issue interaction.
+ description: Investigates GitHub issues
+ groups:
+ - read
+ - command
+ - mcp
+ source: project