Merge branch 'main' into cte/benchmarks

Author: cte

.changeset/shiny-mugs-care.md

@@ -0,0 +1,5 @@
+---
+"roo-cline": patch
+---
+
+Remove item number from history preview cards

.changeset/tame-carpets-bake.md

@@ -0,0 +1,5 @@
+---
+"roo-cline": patch
+---
+
+Add credentials auth for Google vertex

.changeset/wise-bats-perform.md

@@ -0,0 +1,5 @@
+---
+"roo-cline": patch
+---
+
+Handle outputless commands

.changeset/wise-pears-join.md

@@ -0,0 +1,5 @@
+---
+"roo-cline": patch
+---
+
+Improved observability of openai compatible APIs, by sending x-title and http-referer headers, as per Open Router standard.

.clinerules

@@ -10,6 +10,18 @@
    - Prefer fixing the underlying issue over disabling the lint rule
    - Document any approved lint rule disabling with a comment explaining the reason
 
+3. Logging Guidelines:
+   - Always instrument code changes using the logger exported from `src\utils\logging\index.ts`.
+     - This will facilitate efficient debugging without impacting production (as the logger no-ops outside of a test environment.)
+   - Logs can be found in `logs\app.log`
+     - Logfile is overwritten on each run to keep it to a manageable volume.
+
+4. Styling Guidelines:
+   - Use Tailwind CSS classes instead of inline style objects for new markup
+   - VSCode CSS variables must be added to webview-ui/src/index.css before using them in Tailwind classes
+   - Example: `<div className="text-md text-vscode-descriptionForeground mb-2" />` instead of style objects
+
+
 # Adding a New Setting
 
-To add a new setting that persists its state, follow the steps in cline_docs/settings.md
+To add a new setting that persists its state, follow the steps in cline_docs/settings.md

.eslintrc.json

@@ -17,8 +17,7 @@
 		"@typescript-eslint/semi": "off",
 		"eqeqeq": "warn",
 		"no-throw-literal": "warn",
-		"semi": "off",
-		"react-hooks/exhaustive-deps": "off"
+		"semi": "off"
 	},
 	"ignorePatterns": ["out", "dist", "**/*.d.ts"]
 }

.github/CODEOWNERS

@@ -1,2 +1,2 @@
 # These owners will be the default owners for everything in the repo
-* @stea9499 @ColemanRoo @mrubens @cte
+* @mrubens @cte

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -33,7 +33,7 @@ body:
       id: model
       attributes:
           label: Which Model are you using?
-          description: Please specify the model you're using (e.g. Claude 3.5 Sonnet)
+          description: Please specify the model you're using (e.g. Claude 3.7 Sonnet)
       validations:
           required: true
     - type: textarea

.github/pull_request_template.md

@@ -1,37 +1,35 @@
-<!-- **Note:** Consider creating PRs as a DRAFT. For early feedback and self-review. -->
+## Context
 
-## Description
+<!-- Brief description of WHAT you’re doing and WHY. -->
 
-## Type of change
+## Implementation
 
-<!-- Please ignore options that are not relevant -->
+<!--
 
-- [ ] Bug fix (non-breaking change which fixes an issue)
-- [ ] New feature
-- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
-- [ ] This change requires a documentation update
+Some description of HOW you achieved it. Perhaps give a high level description of the program flow. Did you need to refactor something? What tradeoffs did you take? Are there things in here which you’d particularly like people to pay close attention to?
 
-## How Has This Been Tested?
+-->
 
-<!-- Please describe the tests that you ran to verify your changes -->
+## Screenshots
 
-## Checklist:
+| before | after |
+| ------ | ----- |
+|        |       |
 
-<!-- Go over all the following points, and put an `x` in all the boxes that apply -->
+## How to Test
 
-- [ ] My code follows the patterns of this project
-- [ ] I have performed a self-review of my own code
-- [ ] I have commented my code, particularly in hard-to-understand areas
-- [ ] I have made corresponding changes to the documentation
+<!--
 
-## Additional context
+A straightforward scenario of how to test your changes will help reviewers that are not familiar with the part of the code that you are changing but want to see it in action. This section can include a description or step-by-step instructions of how to get to the state of v2 that your change affects.
 
-<!-- Add any other context or screenshots about the pull request here -->
+A "How To Test" section can look something like this:
 
-## Related Issues
+- Sign in with a user with tracks
+- Activate `show_awesome_cat_gifs` feature (add `?feature.show_awesome_cat_gifs=1` to your URL)
+- You should see a GIF with cats dancing
 
-<!-- List any related issues here. Use the GitHub issue linking syntax: #issue-number -->
+-->
 
-## Reviewers
+## Get in Touch
 
-<!-- @mention specific team members or individuals who should review this PR -->
+<!-- We'd love to have a way to chat with you about your changes if necessary. If you're in the [Roo Code Discord](https://discord.gg/roocode), please share your handle here. -->

.github/workflows/changeset-release.yml

@@ -37,7 +37,7 @@ jobs:
           cache: 'npm'
 
       - name: Install Dependencies
-        run: npm run install:all
+        run: npm run install:ci
 
       # Check if there are any new changesets to process
       - name: Check for changesets