chore(release): v0.21.11

[qwen-code-ci-bot]

Automated release PR for v0.21.11. 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.11, 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.11 tag already points at this branch's release commit (7a48b927), and the GitHub release was published from it on 2026-08-13.

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

Size: 148 additions / 61 deletions across 23 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 changed-file set is byte-identical to the previous release PR (#8942), and the lockfile diff is a symmetric +30/−30 of pure version-string replacements (no dependency added or removed). The integrations/external-context manifest-vs-lockfile drift that was noted on the v0.21.8 release PR no longer applies — its manifest has bumped in lockstep since v0.21.10.

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

Moving on to code review. 🔍

中文说明

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

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

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

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

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

方案：最小且聚焦 —— 正是发布 PR 应有的样子。变更文件集与上一个发布 PR（#8942）完全一致，锁文件 diff 为完全对称的 +30/−30 纯版本号替换（未增删任何依赖）。v0.21.8 发布 PR 中曾记录的 integrations/external-context manifest 与锁文件不同步的问题已不存在 —— 其 manifest 自 v0.21.10 起已随发布同步升级。

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

进入代码审查 🔍

— Qwen Code · qwen3.8-max

_{Reviewed at 66b01b074fcc7076d3dfbf70dbd8cb1b234573ad · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Code review: the diff is entirely mechanical — 21 package.json files bumped 0.21.10 → 0.21.11 (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. My independent baseline for "sync v0.21.11 back to main" was exactly this set of edits and nothing more, and the PR matches it — the changed-file set is identical to the previous release PR (#8942). No logic, no new code paths, nothing to second-guess.

Verification points, all clean:

• The v0.21.11 tag points at this branch's release commit (7a48b927) and the GitHub release was published from it on 2026-08-13; the branch is exactly two commits (release commit + changelog sync), so merging brings main back in line with the shipped tag.
• The CHANGELOG section reconciles 1:1 with the work shipped: its 49 entries are exactly the PRs between v0.21.10 and v0.21.11, minus the previous release chore (chore(release): v0.21.10 #8942) — nothing missing, nothing extra. The section content matches the published GitHub Release body line for line (the release notes are its source).
• Author attributions spot-check correctly against the merged PRs (feat(extensions): support Agent Plugins v1 #8834 @callmeYe, feat(cli): add native multi-agent coordination #8804 @yiliang114, fix(core): resolve Qwen 3.8 reasoning budget conflicts #8525 @DragonnZhang, fix(core): align mock workspace path containment #8759 @rbalachandar, feat(serve): bound daemon ACP NDJSON buffers #8911 @doudouOUC), and the one named new contributor (@rbalachandar) appears in no earlier changelog section.
• The lockfile diff is a symmetric +30/−30 consisting solely of version-string replacements and the pinned channel-base specifiers — no dependency added, removed, or re-resolved. integrations/external-context now bumps in lockstep (manifest and lockfile together), unlike the drift noted on the v0.21.8 release PR. Independently versioned packages (SDK family, desktop, cua-driver, mobile-mcp, zed-extension) are untouched, consistent with their separate release pipelines.

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

CI results for 66b01b0 — this table auto-updates as CI workflows complete:

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

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

The main unit suite (Test (ubuntu-latest, Node 22.x)) and the Qwen Code CI workflow are green. One red check, ubuntu-latest / Java 21, is pre-existing infrastructure noise, not caused by this PR: it fails 17 seconds in, inside the setup-java action's toolchain XML generation (The operation would yield an incorrect node tree…), before any build step runs; the identical failure appears on the branch's first commit; this diff changes no Java sources or pom files; and every other leg of the same matrix (macOS/Windows Java 21, Java 11, Java 17) is green. Still in flight at fetch time: the SDK Java and Web-shell Visuals workflow runs — the remaining checks above belong to them. The triage check is this bot's own orchestration run, not PR CI. Skipped checks (macOS/Windows Node tests, E2E smoke) are expected for a metadata-only release PR. Not verified: live runtime behavior — by design nothing is executed here, and there is no behavioral claim to settle; this PR changes version numbers and changelog text only, so no sandboxed /verify or /tmux lane is warranted.

中文说明

代码审查： diff 完全是机械性的 —— 21 个 package.json 从 0.21.10 升到 0.21.11（包括根目录和 CLI 的 sandboxImageUri 标签，以及 channel 包固定引用的 @qwen-code/channel-base 依赖），锁文件同步更新，CHANGELOG 顶部添加了新版本段落。我对"将 v0.21.11 同步回 main"的独立方案正是这组改动、不多不少，PR 与之完全一致 —— 变更文件集与上一个发布 PR（#8942）相同。没有逻辑变更，没有新代码路径。

核验点均无异常：v0.21.11 tag 指向本分支的发布提交（7a48b927），GitHub release 已于 2026-08-13 从该提交发布；分支恰好两个提交（发布提交 + changelog 同步），合并后 main 将与已发布的 tag 保持一致。CHANGELOG 段落与已发布内容一一对应：49 条条目恰好是 v0.21.10 到 v0.21.11 之间合并的 PR（扣除上一个发布操作 PR #8942），无遗漏、无多余；段落内容与已发布的 GitHub Release 正文逐行一致（release notes 即其来源）。作者署名抽查（#8834 @callmeYe、#8804 @yiliang114、#8525 @DragonnZhang、#8759 @rbalachandar、#8911 @doudouOUC）均与已合并 PR 相符；唯一列名的新贡献者（@rbalachandar）在此前的 changelog 段落中未出现过。锁文件 diff 为完全对称的 +30/−30，全部是版本号字符串替换和 channel-base 固定版本说明符 —— 没有增删或重新解析任何依赖。integrations/external-context 本次 manifest 与锁文件同步升级，不同于 v0.21.8 发布 PR 中记录的不同步现象。独立版本管理的包（SDK 系列、desktop、cua-driver、mobile-mcp、zed-extension）未被触及，与其各自独立的发布流水线一致。

测试证据： 通过 API 读取该提交的 CI 检查（本环境从不执行 PR 代码）。主单测 Test (ubuntu-latest, Node 22.x) 与 Qwen Code CI 工作流通过。唯一的红色检查 ubuntu-latest / Java 21 属于既有基础设施问题，与本 PR 无关：任务开始 17 秒即在 setup-java action 生成 toolchain XML 时失败（尚未执行任何构建步骤），分支第一个提交上出现完全相同的失败，本 diff 未改动任何 Java 源码或 pom 文件，且同一矩阵的其余 leg（macOS/Windows Java 21、Java 11、Java 17）全部通过。读取时 SDK Java 与 Web-shell Visuals 两个工作流仍在运行，表中其余进行中检查属于它们；triage 检查是本机器人自身的编排任务，不属于 PR CI。跳过的检查（macOS/Windows Node 测试、E2E smoke）对纯元数据发布 PR 属预期。未验证：真实运行时行为 —— 按设计本环境不执行任何代码，且本 PR 只改版本号和变更日志文本，无行为性声明，无需 /verify 或 /tmux 沙箱验证。

— Qwen Code · qwen3.8-max

_{Reviewed at 66b01b074fcc7076d3dfbf70dbd8cb1b234573ad · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Confidence: 5/5 — routine release PR; every cross-check (tag, release, changelog reconciliation, lockfile symmetry, CI) came back clean, nothing for a human to second-guess.

This is the release workflow closing its loop: v0.21.11 was tagged and published on 2026-08-13, and this PR syncs the version metadata and changelog back to main. It matches my independent proposal exactly — the same shape as the ten release PRs before it, nothing extra in the diff. The changelog reconciles 1:1 with the 49 PRs shipped between v0.21.10 and v0.21.11, attributions and the new-contributor entry verified. The one red check (ubuntu-latest / Java 21) is pre-existing infrastructure noise in the setup-java action — identical failure on the branch's first commit, no Java content in this diff, sibling matrix legs green — not something this PR caused or can fix.

Verdict: approve. Two mechanical notes: CI is still settling (the SDK Java and Web-shell Visuals runs were in flight at review time), and this run posts as the PR author (the release bot), so it cannot itself approve — GitHub refuses approval of one's own PR, and an approve-on-green marker here would only queue a deferred approval under the same identity that the API will reject. The approvals already standing on this exact commit are @qwen-code-dev-bot's (release pipeline) and @yiliang114's (maintainer) — the two branch protection requires. Nothing blocks merge once the two in-flight CI runs land; the finalize job will update the Stage 2 CI table when they do, and will flag anything that lands red.

— Qwen Code · qwen3.8-max

_{Reviewed at 66b01b074fcc7076d3dfbf70dbd8cb1b234573ad · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Released in v0.21.12.