-
Notifications
You must be signed in to change notification settings - Fork 181
docs: add v3.46.0 release notes #520
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,134 @@ | ||
| <audit_workflow> | ||
| <overview> | ||
| Workflow for auditing existing documentation against defined rules. | ||
| Triggered by: "cleanup", "review", "audit", "rewrite", or "improve" requests. | ||
| </overview> | ||
|
|
||
| <trigger_phrases> | ||
| <phrase>cleanup this section</phrase> | ||
| <phrase>review this page</phrase> | ||
| <phrase>audit this doc</phrase> | ||
| <phrase>rewrite this</phrase> | ||
| <phrase>improve this section</phrase> | ||
| <phrase>what's wrong with this</phrase> | ||
| </trigger_phrases> | ||
|
|
||
| <audit_process> | ||
| <step number="1"> | ||
| <title>Read the target content</title> | ||
| <action>Read the entire section, page, or content specified by the user.</action> | ||
| </step> | ||
|
|
||
| <step number="2"> | ||
| <title>Run checklist against rules</title> | ||
| <action>Evaluate the content against each category in the audit_checklist below.</action> | ||
| <action>Mark each item as PASS, FAIL, or N/A.</action> | ||
| </step> | ||
|
|
||
| <step number="3"> | ||
| <title>Generate findings report</title> | ||
| <action>Output a structured report with specific issues and suggestions.</action> | ||
| <action>Include line references or quotes where possible.</action> | ||
| </step> | ||
|
|
||
| <step number="4"> | ||
| <title>Propose changes</title> | ||
| <action>Ask user if they want to proceed with suggested improvements.</action> | ||
| <action>If yes, apply changes following the validation workflow in 3_validation_enforcement.xml.</action> | ||
| </step> | ||
| </audit_process> | ||
|
|
||
| <audit_checklist> | ||
| <category name="decision_driven_structure"> | ||
| <check id="DD1">Does the first section show what the feature does (not explain why it exists)?</check> | ||
| <check id="DD2">Does the page answer: capability, usage, choices, failures, deeper links (only if applicable)?</check> | ||
| <check id="DD3">Are empty or obvious sections deleted?</check> | ||
| <check id="DD4">Can a reader scanning for 10 seconds find what they need?</check> | ||
| <check id="DD5">Does it avoid feeling like a form with mandatory boxes?</check> | ||
| </category> | ||
|
|
||
| <category name="headings"> | ||
| <check id="H1">Do headings name capabilities (not explanations like "why_it_matters")?</check> | ||
| <check id="H2">Do headings match UI labels, commands, or mental models?</check> | ||
| <check id="H3">Are headings scannable in isolation?</check> | ||
| <check id="H4">Is H3 count ≤ 4 (typical ≤ 2)?</check> | ||
| <check id="H5">Are minor subtopics H4 instead of H3?</check> | ||
| <check id="H6">No H5/H6 used?</check> | ||
| <check id="H7">No orphan headings (each followed by ≥2 sentences or a list)?</check> | ||
| </category> | ||
|
|
||
| <category name="progressive_disclosure"> | ||
| <check id="PD1">Does it start with the default path?</check> | ||
| <check id="PD2">Are modes/levels/configuration after baseline usage?</check> | ||
| <check id="PD3">Is troubleshooting optional and last (if present)?</check> | ||
| </category> | ||
|
|
||
| <category name="tone_and_language"> | ||
| <check id="TL1">Neutral, direct, predictable tone?</check> | ||
| <check id="TL2">No hype, jokes, or clever phrasing?</check> | ||
| <check id="TL3">Short sentences, one idea each?</check> | ||
| <check id="TL4">Active voice, concrete verbs?</check> | ||
| <check id="TL5">No banned words (seamlessly, comprehensive, powerful, etc.)?</check> | ||
| <check id="TL6">No vague verbs (handle, manage, process)?</check> | ||
| <check id="TL7">No softening language (might try to, could potentially)?</check> | ||
| </category> | ||
|
|
||
| <category name="tradeoffs_and_errors"> | ||
| <check id="TE1">Are risks, costs, and irreversible actions explicit?</check> | ||
| <check id="TE2">No apologizing for tradeoffs?</check> | ||
| <check id="TE3">Errors state: what failed, why, one next step?</check> | ||
| </category> | ||
|
|
||
| <category name="screenshots"> | ||
| <check id="SC1">Screenshots only for complex states or decision points?</check> | ||
| <check id="SC2">Screenshot count ≤1 per section, ≤3 per page?</check> | ||
| <check id="SC3">Alt text describes action/outcome (not UI chrome)?</check> | ||
| <check id="SC4">Each screenshot has a "why this matters" caption?</check> | ||
| <check id="SC5">Width is 600 (unless smaller improves readability)?</check> | ||
| </category> | ||
|
|
||
| <category name="content_value"> | ||
| <check id="CV1">Does the page explain why this exists (if non-obvious)?</check> | ||
| <check id="CV2">Does it show how to use it?</check> | ||
| <check id="CV3">Does it document decisions the user must make?</check> | ||
| <check id="CV4">Does it cover known failure modes (if any exist)?</check> | ||
| <check id="CV5">No UI narration that lacks decisions/implications?</check> | ||
| </category> | ||
| </audit_checklist> | ||
|
|
||
| <findings_report_format> | ||
| <template> | ||
| ## Audit Findings: [Page/Section Name] | ||
|
|
||
| ### Summary | ||
| - **Checks passed:** X/Y | ||
| - **Issues found:** Z | ||
| - **Priority:** High/Medium/Low | ||
|
|
||
| ### Issues | ||
|
|
||
| #### [Category Name] | ||
| | ID | Check | Status | Issue | Suggestion | | ||
| |----|-------|--------|-------|------------| | ||
| | H1 | Headings name capabilities | FAIL | "Understanding the feature" is abstract | Rename to specific capability, e.g., "Auto-save behavior" | | ||
|
|
||
| ### Recommended Changes | ||
| 1. [Specific change with before/after] | ||
| 2. [Specific change with before/after] | ||
|
|
||
| ### Questions for User | ||
| - [Any clarifications needed before proceeding] | ||
| </template> | ||
| </findings_report_format> | ||
|
|
||
| <quick_audit> | ||
| <description>For fast "cleanup this" requests, run abbreviated checks:</description> | ||
| <checks> | ||
| <check>First section shows behavior (not concept)?</check> | ||
| <check>Headings name capabilities?</check> | ||
| <check>10-second scan test passes?</check> | ||
| <check>No banned words or UI narration?</check> | ||
| <check>ToC noise under control (H3 ≤ 4)?</check> | ||
| </checks> | ||
| </quick_audit> | ||
| </audit_workflow> |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,43 @@ | ||
| --- | ||
| description: This release adds parallel tool calling, overhauls file reading and terminal output handling, begins a shift toward the AI SDK, and adds a Settings UI for managing Skills. | ||
| keywords: | ||
| - roo code 3.46.0 | ||
| - new features | ||
| - bug fixes | ||
| image: /img/v3.46.0/v3.46.0.png | ||
| --- | ||
|
|
||
| # Roo Code 3.46.0 Release Notes (2026-01-30) | ||
|
|
||
| This is a BIG UPDATE! This release adds parallel tool calling, overhauls how Roo reads files and handles terminal output, and begins a major refactor to use the AI SDK at Roo's core for much better reliability. Together, these changes shift how Roo manages context and executes multi-step workflows in a serious way! Oh, and we also added a UI to manage your skills!! | ||
|
|
||
| <img src="/img/v3.46.0/v3.46.0.png" alt="Roo Code v3.46.0 Release" width="600" /> | ||
|
|
||
| ## Parallel tool calling | ||
|
|
||
| Roo can now run multiple tools in one response when the workflow benefits from it. This gives the model more freedom to batch independent steps (reads, searches, edits, etc.) instead of making a separate API call for each tool. This reduces back-and-forth turns on multi-step tasks where Roo needs several independent tool calls before it can propose or apply a change. ([#11031](https://github.com/RooCodeInc/Roo-Code/pull/11031), [#11046](https://github.com/RooCodeInc/Roo-Code/pull/11046)) | ||
|
|
||
| ## Total read_file tool overhaul | ||
|
|
||
| Roo now caps file reads by default (2000 lines) to avoid context overflows, and it can page through larger files as needed. When Roo needs context around a specific line (for example, a stack trace points at line 42), it can also request the *entire* containing function or class instead of an arbitrary “lines 40–60” slice. Under the hood, `read_file` now has two explicit modes: **slice** (`offset`/`limit`) for chunked reads, and **indentation** (anchored on a target line) for semantic extraction. (thanks pwilkin!) ([#10981](https://github.com/RooCodeInc/Roo-Code/pull/10981)) | ||
|
|
||
| ## Terminal handling overhaul | ||
|
|
||
| When a command produces a lot of output, Roo now caps how much of that output it includes in the model’s context. The omitted portion is saved as an artifact. Roo can then page through the full output or search it on demand, so large builds and test runs stay debuggable without stuffing the entire log into every request. ([#10944](https://github.com/RooCodeInc/Roo-Code/pull/10944), [#11056](https://github.com/RooCodeInc/Roo-Code/pull/11056)) | ||
|
|
||
| ## Skills management in Settings | ||
|
|
||
| You can now create, edit, and delete Skills from the Settings panel, with inline validation and delete confirmation. Editing a skill opens the `SKILL.md` file in VS Code. Skills are still stored as files on disk, but this makes routine maintenance faster—especially when you keep both **Global** skills and **Project** skills. (thanks SannidhyaSah!) ([#10844](https://github.com/RooCodeInc/Roo-Code/pull/10844)) | ||
|
|
||
| ## Provider migration to AI SDK | ||
|
|
||
| We’ve started migrating providers toward a shared Vercel AI SDK foundation, so streaming, tool calling, and structured outputs behave more consistently across providers. In this release, that migration includes shared AI SDK utilities plus provider moves for Moonshot/OpenAI-compatible, DeepSeek, Cerebras, Groq, and Fireworks, and it also improves how provider errors (like rate limits) surface. ([#11047](https://github.com/RooCodeInc/Roo-Code/pull/11047), [#11063](https://github.com/RooCodeInc/Roo-Code/pull/11063), [#11079](https://github.com/RooCodeInc/Roo-Code/pull/11079), [#11086](https://github.com/RooCodeInc/Roo-Code/pull/11086), [#11088](https://github.com/RooCodeInc/Roo-Code/pull/11088), [#11118](https://github.com/RooCodeInc/Roo-Code/pull/11118)) | ||
|
|
||
| ## Boring stuff | ||
|
|
||
| * The collapsed task header’s context percentage now reflects actual input usage (accounting for reserved output tokens), so it’s a more reliable indicator of how close you are to the context limit. ([#11034](https://github.com/RooCodeInc/Roo-Code/pull/11034), [#11054](https://github.com/RooCodeInc/Roo-Code/pull/11054)) | ||
| * Improves webview UI responsiveness by enabling React Compiler optimizations, reducing unnecessary re-renders without requiring manual memoization. (thanks In-line!) ([#9565](https://github.com/RooCodeInc/Roo-Code/pull/9565)) | ||
| * Adds `pnpm serve` / `pnpm serve:rebuild` commands to build and run the Roo Code extension in a web-based VS Code environment (via code-server), making it easier for maintainers and contributors to reproduce and validate web-specific behavior and ship fixes more reliably. ([#10964](https://github.com/RooCodeInc/Roo-Code/pull/10964)) | ||
| * Keeps the Roo Code web apps up to date with the latest Next.js release and related dependency/config updates, which helps reduce build and lint friction and improves compatibility/performance for the website and eval tooling. ([#11108](https://github.com/RooCodeInc/Roo-Code/pull/11108)) | ||
| * Improves the Roo Code website header navigation dropdowns by switching to the shadcn/Radix Navigation Menu component, giving smoother open/close animations, more reliable keyboard navigation, and more stable dropdown sizing during transitions. ([#11117](https://github.com/RooCodeInc/Roo-Code/pull/11117)) | ||
| * Replaces the legacy instruction-loading flow with a unified `skill` tool system, making it easier for Roo to load specialized instructions (like creating MCP servers or custom modes) on demand; also removes the old MCP “Enable MCP Server Creation” toggle. ([#11084](https://github.com/RooCodeInc/Roo-Code/pull/11084)) | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -167,16 +167,21 @@ const sidebars: SidebarsConfig = { | |
| })), | ||
| ], | ||
| }, | ||
| { | ||
| type: "category", | ||
| label: "Extension Release Notes", | ||
| items: [ | ||
| "update-notes/index", | ||
| { | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The Extension Release Notes section in sidebars.ts appears to have broken indentation/brace structure compared to adjacent entries (it is nested deeper than siblings after "Model Providers", and the 3.44 category starts without closing the 3.45 object and the items array). This may be a real syntax error or an accidental nesting change that will break the sidebar build. Fix it with Roo Code or mention @roomote and request a fix. |
||
| type: "category", | ||
| label: "3.45", | ||
| items: [{ type: "doc", id: "update-notes/v3.45.0", label: "3.45.0" }], | ||
| }, | ||
| label: "Extension Release Notes", | ||
| items: [ | ||
| "update-notes/index", | ||
| { | ||
| type: "category", | ||
| label: "3.46", | ||
| items: [{ type: "doc", id: "update-notes/v3.46.0", label: "3.46.0" }], | ||
| }, | ||
| { | ||
| type: "category", | ||
| label: "3.45", | ||
| items: [{ type: "doc", id: "update-notes/v3.45.0", label: "3.45.0" }], | ||
| }, | ||
| { | ||
| type: "category", | ||
| label: "3.44", | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The v3.46.0 release notes intro uses hypey language ("BIG UPDATE!", "serious way!", double "!!") and "better reliability" claims that read like marketing. This conflicts with the new Documentation Writer style rules that emphasize neutral, direct tone and no hype. Consider rewriting the opener to a factual 1–3 sentence summary of what changed and why it matters.
Fix it with Roo Code or mention @roomote and request a fix.