Merge branch 'main' into feat/sytem-prompts-disable-option

Author: Alorse

.roo/rules-issue-fixer/1_Workflow.xml

@@ -491,4 +491,62 @@
       ```
     </instructions>
   </step>
+
+  <step number="11">
+    <name>Monitor PR Checks</name>
+    <instructions>
+      After the PR is created, monitor the CI/CD checks to ensure they pass:
+      
+      <execute_command>
+      <command>gh pr checks --watch</command>
+      </execute_command>
+      
+      This command will:
+      1. Display all CI/CD checks configured for the repository
+      2. Show the status of each check in real-time
+      3. Update automatically as checks complete
+      4. Exit when all checks have finished running
+      
+      Monitor the output and note:
+      - Which checks are running (e.g., tests, linting, build)
+      - Any checks that fail and their error messages
+      - The overall status of the PR checks
+      
+      If any checks fail:
+      1. Analyze the failure logs
+      2. Identify what needs to be fixed
+      3. Ask the user if they want you to address the failures
+      
+      <ask_followup_question>
+      <question>The PR checks have completed. Here's the status:
+
+      [Show check results - passing/failing]
+
+      [If all pass]: All checks have passed successfully! The PR is ready for review.
+
+      [If any fail]: Some checks have failed:
+      - [Failed check 1]: [Brief error description]
+      - [Failed check 2]: [Brief error description]
+
+      Would you like me to fix these issues?</question>
+      <follow_up>
+      <suggest>Yes, please fix the failing checks</suggest>
+      <suggest>Show me the detailed error logs</suggest>
+      <suggest>I'll handle the failures manually</suggest>
+      <suggest>The PR is fine as-is, these failures are expected</suggest>
+      </follow_up>
+      </ask_followup_question>
+      
+      If user wants fixes:
+      1. Create a plan to address each failure
+      2. Make necessary code changes
+      3. Commit and push the fixes
+      4. Monitor checks again to ensure they pass
+      
+      Important notes:
+      - The --watch flag will keep the command running until all checks complete
+      - This step helps ensure the PR meets all quality standards before review
+      - Early detection of CI/CD failures saves reviewer time
+    </instructions>
+  </step>
 </workflow>

.roo/rules-pr-fixer/1_workflow.xml

@@ -47,6 +47,13 @@
         <step>Resolve conflicts by rebasing the PR branch and force-pushing.</step>
       </steps>
     </phase>
+
+    <phase name="validation">
+      <description>Verify that the pushed changes resolve the issues.</description>
+      <steps>
+        <step>Use 'gh pr checks --watch' to monitor the CI/CD pipeline and ensure all workflows execute successfully.</step>
+      </steps>
+    </phase>
   </main_workflow>
 
   <completion_criteria>

.roo/rules-pr-fixer/3_common_patterns.xml

@@ -45,4 +45,10 @@
       <command tool="gh">gh pr checkout <pr_number_or_url></command>
     </template>
   </pattern>
+  <pattern name="watching_pr_checks">
+    <usage>After pushing changes, use this command to monitor the CI/CD pipeline in real-time.</usage>
+    <template>
+      <command tool="gh">gh pr checks --watch</command>
+    </template>
+  </pattern>
 </common_patterns>

.roo/rules-pr-fixer/4_tool_usage.xml

@@ -9,8 +9,13 @@
       <tool>gh pr checks</tool>
       <when>After getting comments, to check the technical status.</when>
       <why>Quickly identifies if there are failing automated checks that need investigation.</why>
-    </priority>
-  </tool_priorities>
+   </priority>
+   <priority level="3">
+     <tool>gh pr checks --watch</tool>
+     <when>After pushing a fix, to confirm that the changes have resolved the CI/CD failures.</when>
+     <why>Provides real-time feedback on whether the fix was successful.</why>
+   </priority>
+ </tool_priorities>
 
   <tool_specific_guidance>
     <tool name="use_mcp_tool (github: get_pull_request)">

.roo/rules-pr-fixer/5_examples.xml

@@ -81,6 +81,15 @@
 </ask_followup_question>
         </tool_use>
       </step>
+     <step number="6">
+       <description>After pushing the changes, watch the PR checks to confirm the fix.</description>
+       <tool_use>
+         <execute_command>
+           <command>gh pr checks --watch</command>
+         </execute_command>
+       </tool_use>
+       <analysis>Confirm that all checks are passing after the fix.</analysis>
+     </step>
     </workflow>
 
     <key_takeaways>

.roo/rules-pr-reviewer/1_workflow.xml

@@ -137,8 +137,8 @@
       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 unnecessary praise. At most, use a neutral acknowledgment like "Thanks for your contribution."
-      - Use Markdown **only when necessary for clarity** (e.g., links, code blocks). Avoid excessive formatting.
+      - 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.
@@ -163,12 +163,10 @@
       [Summary of findings organized by priority]
 
       Would you like me to:
-      1. Submit these as individual review comments
-      2. Create a comprehensive review with all comments
-      3. Modify any of the suggestions
-      4. Skip the review submission</question>
+      1. Create a comprehensive review with all comments
+      2. Modify any of the suggestions
+      3. Skip the review submission</question>
       <follow_up>
-      <suggest>Submit as individual review comments</suggest>
       <suggest>Create a comprehensive review</suggest>
       <suggest>Let me modify the suggestions first</suggest>
       <suggest>Skip submission - just wanted the analysis</suggest>
@@ -180,41 +178,38 @@
   <step number="9">
     <name>Submit Review</name>
     <instructions>
-      Based on user preference, submit the review:
+      Based on user preference, submit the review as a comprehensive review:
 
-      For individual comments:
+      1. First create a pending review:
       <use_mcp_tool>
       <server_name>github</server_name>
-      <tool_name>add_pull_request_review_comment_to_pending_review</tool_name>
+      <tool_name>create_pending_pull_request_review</tool_name>
       <arguments>
       {
         "owner": "[owner]",
         "repo": "[repo]",
-        "pullNumber": [number],
-        "path": "[file path]",
-        "line": [line number],
-        "body": "[comment text]",
-        "subjectType": "LINE"
+        "pullNumber": [number]
       }
       </arguments>
       </use_mcp_tool>
 
-      For comprehensive review:
-      1. First create a pending review:
+      2. Add comments to the pending review using:
       <use_mcp_tool>
       <server_name>github</server_name>
-      <tool_name>create_pending_pull_request_review</tool_name>
+      <tool_name>add_pull_request_review_comment_to_pending_review</tool_name>
       <arguments>
       {
         "owner": "[owner]",
         "repo": "[repo]",
-        "pullNumber": [number]
+        "pullNumber": [number],
+        "path": "[file path]",
+        "line": [line number],
+        "body": "[comment text]",
+        "subjectType": "LINE"
       }
       </arguments>
       </use_mcp_tool>
 
-      2. Add comments to the pending review
-      
       3. Submit the review:
       <use_mcp_tool>
       <server_name>github</server_name>

.roo/rules-pr-reviewer/2_best_practices.xml

@@ -6,8 +6,11 @@
   - 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
+  - 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

.roo/rules-pr-reviewer/3_common_mistakes_to_avoid.xml

@@ -3,7 +3,9 @@
   - Making judgmental or harsh comments
   - Providing feedback on code outside the PR's scope
   - Overlooking unrelated changes not tied to the main issue
-  - Using excessive praise or unnecessary formatting
+  - 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 and discussions
   - Forgetting to check for an associated issue for additional context
@@ -13,6 +15,6 @@
   - 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
+  - Making assumptions instead of asking clarifying questions about potential intentions
   - Forgetting to link to specific lines with full GitHub URLs
 </common_mistakes_to_avoid>

CHANGELOG.md

@@ -1,5 +1,20 @@
 # CHANGELOG
 
+## [3.21.5] - 2025-06-23
+
+- Fix Qdrant URL prefix handling for QdrantClient initialization (thanks @CW-B-W!)
+- Improve LM Studio model detection to show all downloaded models (thanks @daniel-lxs!)
+- Resolve Claude Code provider JSON parsing and reasoning block display
+
+## [3.21.4] - 2025-06-23
+
+- Fix start line not working in multiple apply diff (thanks @samhvw8!)
+- Resolve diff editor issues with markdown preview associations (thanks @daniel-lxs!)
+- Resolve URL port handling bug for HTTPS URLs in Qdrant (thanks @benashby!)
+- Mark unused Ollama schema properties as optional (thanks @daniel-lxs!)
+- Close the local browser when used as fallback for remote (thanks @markijbema!)
+- Add Claude Code provider for local CLI integration (thanks @BarreiroT!)
+
 ## [3.21.3] - 2025-06-21
 
 - Add profile-specific context condensing thresholds (thanks @SannidhyaSah!)
@@ -37,6 +52,7 @@
 - Fix markdown for links followed by punctuation (thanks @xyOz-dev!)
 
 ## [3.21.1] - 2025-06-19
+
 - Modified chat component to improve API model name display.
 - Implemented on-demand configuration fetching and caching.
 - Updated UI styling for consistency and enhanced visual design.