You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix command auto-approval for multi-line shell constructs that must be treated as a single command.
6
+
7
+
**Quoted multi-line arguments** (`sh -c '...'`, `sh -c $'...'`, `sh -c "..."`): the parser previously split on every newline before handling quotes, so newlines inside a quoted argument were treated as separate commands, defeating allowlist auto-approval. Single-quoted, ANSI-C (`$'...'`), and double-quoted strings are now masked before the newline split so embedded newlines and operators stay within their command.
8
+
9
+
**Heredocs** (`<< EOF`, `<< 'EOF'`, `<< "EOF"`, `<<- EOF`): the entire heredoc -- opener line, body, and terminator -- is now treated as a single quoted region. Body lines are not split into independent sub-commands. All heredoc delimiter quoting styles (unquoted, single-quoted, double-quoted, backslash-escaped) are supported. An unterminated heredoc (missing terminator) is treated as malformed and returned as a single opaque token.
10
+
11
+
**Locale quoting** (`$"..."`): treated as a distinct token analogous to ANSI-C quoting, preserving the `$` prefix and preventing the double-quote handler from stripping it.
12
+
13
+
Quote masking is comment-aware: a quote character inside a `#` comment is not paired with a quote on a later line, so a comment cannot hide a real newline separator and merge two distinct commands. Commands with an unterminated quote are detected with a quote-aware scanner and returned as a single opaque token, preventing a line inside the unclosed quote from surfacing as an independently auto-approvable command. Genuine unquoted newlines still split into separate sub-commands, each of which must be allowlisted for auto-approval.
14
+
15
+
**Pattern selector (UI)**: the command pattern breakdown shown after execution now uses the same heredoc- and quote-aware parser (`parseCommand`) before extracting patterns, so an unterminated or terminated heredoc no longer produces spurious tokens like `EOF`, body-line words, or `<<` fragments in the allow/deny selector.
16
+
17
+
Note: this change only prevents *auto-approval* of fragments from a malformed command; it does not reject malformed commands before execution, which will be addressed in a separate PR to keep the scope focused here.
Copy file name to clipboardExpand all lines: .roo/commands/release.md
+26-36Lines changed: 26 additions & 36 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -36,16 +36,9 @@ mode: code
36
36
- Do not manually edit `src/README.md`; the extension bundle step copies root `README.md` into `src/README.md`.
37
37
- Check for stale upstream Roo Code wording that should now say Zoo Code.
38
38
39
-
6. Create the release notes as a changeset file at `.changeset/v[version].md`, then run `pnpm changeset:version` on the release branch before opening the PR.
40
-
41
-
```md
42
-
---
43
-
"zoo-code": patch|minor|major
44
-
---
45
-
46
-
[list of changes]
47
-
```
39
+
6. Write the release notes directly into `CHANGELOG.md` on the release branch.
48
40
41
+
- Use the heading format `## [version]` (with square brackets) — e.g. `## [3.58.1]`. The publish workflow at `.github/workflows/marketplace-publish.yml` extracts release notes by matching this exact pattern; headings without brackets will be missed and the GitHub release will fall back to a generic message.
49
42
- Always include contributor attribution and the PR number: use `(PR #<prNumber> by @username)`.
50
43
- For PRs that close issues, include both issue and PR authors: `- Fix: Description (#123 by @reporter, PR #456 by @contributor)`.
51
44
- For PRs without linked issues, include the PR number and author: `- Add support for feature (PR #456 by @contributor)`.
@@ -58,21 +51,19 @@ mode: code
58
51
- Ask the user what three areas should be highlighted.
59
52
- Update relevant announcement files and documentation, including `webview-ui/src/components/chat/Announcement.tsx`, `README.md`, and the `latestAnnouncementId`in`src/core/webview/ClineProvider.ts`.
60
53
- Ask the user to confirm the English announcement before proceeding.
61
-
- Arrange translation updates for all supported locales affected by README, announcement, or package localization changes.
54
+
- Arrange translation updates for all supported locales affected by README, announcement, or package localization changes. Use the `/roo-translate` skill to propagate the updated `chat.json` announcement highlight keys and the "What's New" section to all supported locales.
55
+
- All 17 locale READMEs should contain a translated "What's New" section. Check each one and add a translated section where missing.
62
56
63
57
8. Create the release branch:
64
58
65
59
```bash
66
60
git checkout -b release/v[version]
67
61
```
68
62
69
-
9. Generate the final release state on that branch:
70
-
71
-
```bash
72
-
pnpm changeset:version
73
-
```
63
+
9. Bump the version in`src/package.json` to the target release version and ensure `CHANGELOG.md` and `src/CHANGELOG.md` are up to date.
74
64
75
-
- This should update `src/package.json`, `CHANGELOG.md`, and `src/CHANGELOG.md`, then consume the `.changeset` file.
65
+
- Verify the `CHANGELOG.md` heading uses `## [version]` (with brackets).
66
+
- Copy or sync `CHANGELOG.md` to `src/CHANGELOG.md`if the project keeps both.
76
67
- Review the generated version and changelog before opening the PR.
77
68
78
69
10. Open a single release PR with the fully generated release state.
@@ -91,32 +82,31 @@ mode: code
91
82
- If the release includes translated README or package-localization updates, include those files in the same PR.
92
83
- Let the release validation workflow and normal PR checks run before merge.
93
84
94
-
11. After the release PR is merged, stop for a release review on the resulting `main` commit.
95
-
96
-
```bash
97
-
git switch main
98
-
git pull origin main
99
-
REVIEWED_SHA=$(git rev-parse HEAD)
100
-
git rev-parse --short "$REVIEWED_SHA"
101
-
```
85
+
11. Once the release PR is open and passing checks, get it approved by a reviewer before proceeding.
102
86
103
-
- Review the merged release state before any publish step.
104
-
- Confirm that `src/package.json`, `CHANGELOG.md`, `src/CHANGELOG.md`, and the Marketplace-facing `README.md` all reflect the intended release.
105
-
- Check that the release PR checks passed and that the merged commit is the one you want to ship.
106
-
- Share that review summary, including `REVIEWED_SHA`, with the user and waitfor explicit confirmation before creating the tag.
107
-
- Do not create the tag or trigger publishing until the user says to proceed.
87
+
- Do not create the tag until the PR has at least one approval — the publish workflow enforces this automatically and will fail if no approved PR is found for the tagged commit.
108
88
109
-
12. Only after explicit confirmation, create the release tag on that reviewed `main` commit:
89
+
12. After the PR is approved, create the release tag on the release branch tip and push it:
110
90
111
91
```bash
112
-
git tag v[version]"$REVIEWED_SHA"
92
+
git tag v[version]
113
93
git push origin v[version]
114
94
```
115
95
116
-
- If `main` advances after the review pause, keep using the pinned `REVIEWED_SHA`for the tag instead of silently tagging a newer commit.
96
+
- Tag the branch tip as-is. Do not rebase or merge additional commits into the release branch before tagging — doing so changes the commit SHA and may pull in unreviewed changes that weren't part of the approval.
97
+
- The publish workflow validates that the tag version matches `src/package.json`.
98
+
99
+
13. The tag push triggers the stable publish workflow.
117
100
118
-
13. The stable publish workflow runs from the `v[version]` tag.
101
+
- The workflow first checks that the tagged commit belongs to an approved PR. If the PR is not yet approved this step fails — approve the PR first, then retrigger by recreating and pushing the tag: `git tag -d v[version] && git push origin :refs/tags/v[version] && git tag v[version] && git push origin v[version]`.
102
+
- Once the approval check passes, the `marketplace-production` environment gate fires and notifies the configured approvers.
103
+
- A human approver must then approve the deployment before the extension is published to VS Code Marketplace and Open VSX.
119
104
120
-
- Do not create the tag before the release PR is merged.
121
-
- The publish workflow validates that the tag version matches `src/package.json`.
122
-
- Marketplace and Open VSX publishing use the configured CI secrets.
105
+
14. After a successful deployment, add the release PR to the merge queue.
106
+
107
+
```bash
108
+
gh pr merge [pr-number] --auto --squash
109
+
```
110
+
111
+
- Do not merge before the deployment succeeds — merging first and then discovering a publish failure leaves `main` ahead of what was actually shipped.
112
+
- The merge queue runs all required checks against the release branch before merging to `main`.
- Stabilize flaky e2e provider suite ordering and zai requestCapture race (#512 by @edelauna, #514 by @edelauna, PR #45 by @app/roomote)
23
+
- Fix flaky e2e subtasks fixture collision and task identity prompt (#561, PR #563 by @simurg79)
24
+
- Add contributing guidelines: PR expectations and AI-assisted contribution policy (PR #562 by @edelauna)
25
+
- Configure knip and remove dead code (PR #225 by @app/roomote)
26
+
- Pin dependencies (PR #423 by @app/renovate)
27
+
28
+
## [3.58.1]
29
+
30
+
### Patch Changes
31
+
32
+
- Fix: Remove unsupported `--no-absolute-filenames` tar argument (#491 by @kazenshi, PR #492 by @kazenshi)
33
+
34
+
## 3.58.0
35
+
36
+
### Minor Changes
37
+
38
+
- Add Zoo Gateway provider with auth callback and multi-profile token sync (PR #344 by @JamesRobert20, PR #345 by @JamesRobert20, PR #347 by @JamesRobert20)
39
+
- Add Gemini 3.5 Flash support (PR #331 by @jeanbispo)
40
+
- Add Semble as a local on-the-fly embedding provider for code indexing (PR #399 by @navedmerchant)
41
+
- Remove extension-side LLM telemetry; server logs only through gateway (PR #346 by @JamesRobert20)
42
+
- Add VS Code integrated terminal shell override (PR #277 by @proyectoauraorg)
43
+
- Add configurable chat font size (#157 by @duvw, PR #276 by @proyectoauraorg)
44
+
- Render GitHub-style alerts in the webview (#258 by @melck, PR #275 by @proyectoauraorg)
45
+
- Add configurable max output tokens for GLM models (#161 by @app/roomote, PR #274 by @proyectoauraorg)
46
+
- Introduce WorkspacePathResolver for async symlink-aware path canonicalization (#389 by @edelauna, PR #428 by @proyectoauraorg)
47
+
- Better secure release workflows and GitHub Actions (PR #482 by @edelauna)
48
+
- Fix React crash from malformed follow-up suggestion mode (PR #414 by @edelauna)
49
+
- Fix OpenAI temperature omitted when no custom value is set (#242 by @brunocasado, PR #247 by @proyectoauraorg)
50
+
- Handle per-key failures during settings import (PR #401 by @taltas)
51
+
- Add comprehensive test coverage for ReadFileTool (PR #222 by @proyectoauraorg)
52
+
- Unskip VS Code e2e replay for subtasks (PR #94 by @app/roomote)
53
+
- Fix e2e cache: replace paths filter with content-hash cache skip (PR #268 by @app/roomote)
54
+
- Remove deprecated requestRooCreditBalance handler (PR #385 by @JamesRobert20)
55
+
- Update mermaid to v11.15.0 for a security fix (PR #235 by @app/renovate)
56
+
- Update axios to v1.16.0 for a security fix (PR #400 by @app/renovate)
57
+
- Pin dependencies (PR #353 by @app/renovate)
58
+
- Remove unused tmp dependency and other unused packages (PR #341 by @app/renovate)
Pull requests should be reviewable, tested, and maintainable. Before opening a PR, please make sure that:
144
+
145
+
- The change is scoped to a specific issue, bug, or improvement.
146
+
- You can explain what the change does and why it is correct.
147
+
- You have tested the change locally where practical.
148
+
- You are willing to respond to review feedback and make reasonable follow-up changes.
149
+
- The PR does not require maintainers to substantially rewrite, redesign, or take ownership of the implementation before it can be merged.
150
+
151
+
Maintainers may close PRs that are incomplete, too broad, inactive, not aligned with the project direction, or that create disproportionate review or maintenance burden. Closing a PR is not a judgment on the contributor; it is a maintainer decision that the change cannot be accepted in its present form.
152
+
153
+
### AI-Assisted Contributions
154
+
155
+
Use of AI tools is allowed, but contributors remain fully responsible for their submissions.
156
+
157
+
If you use AI tools to help create a PR, you must:
158
+
159
+
- Review and understand every meaningful change.
160
+
- Be able to explain the implementation and tradeoffs in your own words.
161
+
- Test the change yourself. If testing is impractical for your environment, explain why in the PR description and describe how reviewers can verify the change instead.
162
+
- Verify that generated code is correct, necessary, and compatible with the project license.
163
+
- Consider disclosing AI assistance in the PR description when it materially shaped the code, tests, or design — this helps reviewers give better feedback.
164
+
165
+
Please do not submit AI-generated changes that you do not understand or cannot maintain through review. Maintainers may close PRs that appear substantially AI-assisted but lack human verification, clear rationale, or review follow-through.
166
+
139
167
## Legal
140
168
141
169
By contributing, you agree your contributions will be licensed under the Apache 2.0 License, consistent with Zoo Code's licensing.
0 commit comments