chore(release): v0.21.7

[qwen-code-ci-bot]

Automated release PR for v0.21.7. Syncs package.json versions and CHANGELOG.md on main.

[qwen-code-dev-bot]

Automated approval for the release version bump.

[qwen-code-ci-bot]

✅ Qwen Triage finished — view run. See the stage comments in this thread for the result.

✅ Qwen Triage 已完成 —— 查看运行。结果见本线程中的各阶段评论。

[qwen-code-ci-bot]

Automated release PR — version bumps and CHANGELOG for v0.21.7, syncing the release branch back into main after the tag was cut.

Template: the PR body is a single line rather than the full template, which is expected for bot-created release PRs. The purpose is self-evident from the title and body. ✓

Problem: N/A — this is a routine release chore, not a bug fix or feature. The release workflow generates it to sync version metadata and the changelog back to main; the v0.21.7 tag already points at this branch's first commit (0639ef72), and the GitHub release was published from it on 2026-08-06.

Direction: aligned — release PRs are core project infrastructure, and this follows the same pattern as v0.21.1–v0.21.6.

Size: 118 additions / 60 deletions across 22 files. All changes are package.json version bumps, package-lock.json version sync, and the CHANGELOG entry. No production source code touched, so the core-module gate is not applicable.

Approach: minimal and focused — exactly what a release PR should be. The lockfile diff is a symmetric +30/−30 of pure version-string replacements (no dependency added or removed), and there are no unrelated changes anywhere in the diff.

Risk: no elevated risk signals — none of the changed files match high-risk paths.

Moving on to code review. 🔍

中文说明

自动化发布 PR —— v0.21.7 的版本号同步和 CHANGELOG 更新，在 tag 切出后将发布分支同步回 main。

模板：PR 正文只有一行，这对机器人创建的发布 PR 来说是正常的。标题和正文已经清楚说明了目的。✓

问题：不适用 —— 这是常规发布操作，不是 bug 修复或功能添加。发布工作流生成此 PR 以将版本元数据和变更日志同步回 main；v0.21.7 tag 已指向本分支的第一个提交（0639ef72），GitHub release 已于 2026-08-06 从该提交发布。

方向：对齐 —— 发布 PR 是项目基础设施的核心部分，且与 v0.21.1–v0.21.6 的模式一致。

规模：22 个文件，+118/-60。全部是 package.json 版本号、package-lock.json 版本同步和 CHANGELOG 内容。未触及生产源代码，核心模块门控不适用。

方案：最小且聚焦 —— 正是发布 PR 应有的样子。锁文件 diff 为完全对称的 +30/−30 纯版本号替换（未增删任何依赖），diff 中无任何无关改动。

风险：无升级风险信号 —— 没有变更文件命中高风险路径。

进入代码审查 🔍

— Qwen Code · qwen3.8-max

_{Reviewed at 6bae6987e4dbab042ac87a93b8dea4bbc5cc3ef4 · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Code review: the diff is entirely mechanical — 20 package.json files bumped 0.21.6 → 0.21.7 (including the root and CLI sandboxImageUri tags and the channel packages' pinned @qwen-code/channel-base dependency), the lockfile updated to match, and a CHANGELOG section prepended for the release. No logic, no new code paths, nothing to second-guess.

Two verification points, both clean:

• The lockfile diff is a symmetric +30/−30 consisting solely of version-string replacements — no dependency added, removed, or re-resolved. The esbuild version the failing CI job trips over (see below) is unchanged by this PR.
• The new CHANGELOG section follows the established structure (Highlights / Breaking Changes / Complete Change List with Features, Bug Fixes, Performance, Documentation, Internal Changes / New Contributors), is dated 2026-08-06 matching the published release, and anchors the compare link at v0.21.6...v0.21.7. Entries spot-check correctly against the merged work they reference (fix(core): remove fixed Goal continuation limit #8421, feat(cli): render inline terminal images #8305, fix(autofix): ship core dist in the review CLI bundle #8612, feat(voice): support trusted private ASR base URLs #8350 all verified merged on 2026-08-06). The branch is exactly two commits: the release commit that the v0.21.7 tag and GitHub release already point at, plus the changelog-sync commit on top — merging brings main back in line with the shipped tag.

Testing evidence (CI checks on the reviewed commit, fetched via API — PR code is never executed in this environment):

Final CI results for 6bae698 (auto-updated by the triage finalize job after CI completed):

Check	Conclusion
Capture web-shell visuals (ubuntu-latest, Node 22.x)	❌ failure
Classify PR	✅ success
macos-latest / Java 21	✅ success
Real daemon E2E / Java 11	✅ success
Test (ubuntu-latest, Node 22.x)	✅ success
ubuntu-latest / Java 11	✅ success
ubuntu-latest / Java 17	✅ success
ubuntu-latest / Java 21	✅ success
windows-latest / Java 21	✅ success

_{One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。}

The one red check, Capture web-shell visuals, failed during npm ci — esbuild's postinstall verification could not exec the freshly extracted binary: spawnSync .../packages/web-shell/node_modules/esbuild/bin/esbuild ETXTBSY (errno -26, "text file busy"). That is a kernel-level race on the runner (the binary was still held open for writing, e.g. by a scanner) at the dependency-install step, before any repository code runs. This PR cannot have caused it: the diff touches only version strings and changelog text, and the lockfile change neither adds nor re-resolves any dependency. Classified as a transient runner flake; re-running the failed job should clear it. The main Qwen Code CI run completed green; the SDK Java run is still in flight (Real daemon E2E running, macOS job queued), and the in-progress triage check is this triage run itself. Skipped checks are expected for a metadata-only release PR. Not verified: the pending runs' outcomes — no polling; the finalize workflow updates this table when CI settles. No behavioral claims to settle — this PR changes version numbers and changelog text only, so no sandboxed /verify or /tmux lane is warranted.

中文说明

代码审查： diff 完全是机械性的 —— 20 个 package.json 从 0.21.6 升到 0.21.7（包括根目录和 CLI 的 sandboxImageUri 标签，以及 channel 包固定引用的 @qwen-code/channel-base 依赖），锁文件同步更新，CHANGELOG 顶部添加了新版本段落。没有逻辑变更，没有新代码路径。

两点核验，均无异常：锁文件 diff 为完全对称的 +30/−30，全部是版本号字符串替换 —— 没有增删或重新解析任何依赖（下方失败的 CI 任务所涉及的 esbuild 版本也未被本 PR 改动）；新 CHANGELOG 段落结构与既有格式一致，日期 2026-08-06 与已发布的 release 相符，对比链接锚定 v0.21.6...v0.21.7，条目与其引用的已合并工作抽查一致（#8421、#8305、#8612、#8350 均确认已于 2026-08-06 合并）。分支恰好两个提交：v0.21.7 tag 和 GitHub release 已指向的发布提交，加上其上的 changelog 同步提交 —— 合并后 main 将与已发布的 tag 保持一致。

测试证据： 通过 API 读取该提交的 CI 检查（本环境从不执行 PR 代码）。唯一变红的 Capture web-shell visuals 失败于 npm ci 阶段 —— esbuild 安装后校验无法执行刚解压的二进制：spawnSync .../esbuild/bin/esbuild ETXTBSY（errno -26，text file busy）。这是 runner 上的内核级竞态（二进制仍被写入方占用，例如扫描器），发生在依赖安装步骤、任何仓库代码运行之前。本 PR 不可能导致它：diff 只改版本号字符串和变更日志文本，锁文件也未增删或重新解析任何依赖。判定为 runner 瞬时抖动，重跑失败任务即可恢复。主 Qwen Code CI 运行已绿；SDK Java 运行仍在进行（Real daemon E2E 运行中、macOS 任务排队），另一个进行中的 triage 检查即本次 triage 运行本身。跳过的检查对纯元数据发布 PR 属预期。未验证：进行中运行的最终结果 —— 不轮询，finalize 工作流会在 CI 结束后更新上表。本 PR 只改版本号和变更日志文本，无行为性声明，无需 /verify 或 /tmux 沙箱验证。

— Qwen Code · qwen3.8-max

_{Reviewed at 6bae6987e4dbab042ac87a93b8dea4bbc5cc3ef4 · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Confidence: 5/5 — routine release PR, mechanical version bumps, nothing to hesitate about; the single red check is a runner install flake, not this diff.

This is exactly what a release PR should look like: version numbers synced across all 20 workspace packages, lockfile regenerated as pure version-string replacements, CHANGELOG entry added with the right structure, date, and compare anchor. No source code touched, no behavioral changes, no review concerns. v0.21.7 was already cut and published from this branch's first commit, so this merge just brings main back in line with the shipped tag.

On CI: Qwen Code CI is green; the SDK Java run is still in flight. The Web-shell Visuals failure is an ETXTBSY race while npm ci installs esbuild — it happens before any repository code runs, and a version-strings-only diff cannot influence it, so I'm treating it as runner noise rather than a finding against the PR. The failed job needs a re-run to clear it.

Approval is deferred until CI lands green on 6bae6987e4dbab042ac87a93b8dea4bbc5cc3ef4.

中文说明

置信度：5/5 —— 常规发布 PR，机械性版本号同步，无需犹豫；唯一变红的检查是 runner 安装时的瞬时抖动，与本 diff 无关。

这正是发布 PR 应有的样子：所有 20 个工作区包的版本号同步，锁文件以纯版本号替换重新生成，CHANGELOG 条目结构、日期与对比锚点均正确。未触及源代码，无行为变更，无审查顾虑。v0.21.7 已从本分支的第一个提交切出并发布，此合并只是让 main 与已发布的 tag 保持一致。

CI 方面：Qwen Code CI 已绿；SDK Java 运行仍在进行。Web-shell Visuals 的失败是 npm ci 安装 esbuild 时的 ETXTBSY 竞态 —— 发生在任何仓库代码运行之前，纯版本号 diff 不可能影响它，因此判定为 runner 噪声而非 PR 问题，需要重跑该失败任务以恢复。

批准将推迟到 CI 在该提交上全绿之后。

— Qwen Code · qwen3.8-max

_{Reviewed at 6bae6987e4dbab042ac87a93b8dea4bbc5cc3ef4 · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Released in v0.21.8.