chore(release): sdk-typescript v0.1.11

[qwen-code-ci-bot]

Automated release PR for sdk-typescript v0.1.11.

[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]

🖼️ web-shell visual preview

Rendered against a mock daemon (no real backend): the PR base vs this PR head 1c3a504. Only screenshots that changed are shown (flows below, if any, are head-only) — refreshes on every push.

Screenshots · before / after

✅ No screenshot changes against the PR base.

_{Full-resolution recordings (.webm) are attached to the workflow run.}

— Qwen Code · web-shell visuals

[chiga0]

Code review — Scan tier

Verdict: Approved. No blocking findings.

---

Tier and scope

Tier: Scan — automated release PR, 2 files, +2/-2 lines (version strings only).

What I checked

• Claim vs. change: PR title says v0.1.11; both files updated to 0.1.11. ✓
• Mechanical consistency: packages/sdk-typescript/package.json and the root package-lock.json entry for packages/sdk-typescript both updated to the same version. ✓
• Version skip (0.1.9 → 0.1.11): Confirmed intentional. GitHub releases sdk-typescript-v0.1.10 and sdk-typescript-v0.1.11 both already exist before this PR merges — consistent with a release-first automation pattern where the package is published and tagged before the repo package.json is updated. This PR is the post-release package.json sync step for v0.1.11.

No cross-file consumers of the SDK version string were checked (Scan tier; the version field has no runtime consumers in this repo).

---

Reviewed with AI assistance.

[qwen-code-ci-bot]

Thanks for the PR!

One note on timing first: the head moved while I was reviewing — a Merge branch 'main' commit (8462669b) landed on top of the SDK bump (1c3a5045). Everything below is re-verified against the new head, and the merge changed the picture for the better, so I've said where.

Template: the body is a single line — Automated release PR for sdk-typescript v0.1.11. — so none of the template headings are present. I'm not treating that as a blocking failure, and it's worth being explicit about why: that exact string is generated by release-sdk.yml itself (--body "Automated release PR for sdk-typescript ${RELEASE_TAG}."), and ci.yml's classify_pr is built to recognize this PR shape — same-repo head + qwen-code-ci-bot actor + release/ head ref + chore(release): title — as a machine-generated version-sync PR. Requesting changes would be asking a bot to edit a fixed string it cannot edit, while npm already has 0.1.11 published. Routing it to a maintainer instead of terminating on it.

Problem: observed, not theoretical, and it has timestamps. The GitHub release sdk-typescript-v0.1.11 was published 2026-09-09T11:47:33Z off release/sdk-typescript/v0.1.11, while packages/sdk-typescript/package.json on main (50b942ae, current) still reads 0.1.9. The workflow publishes to npm before it opens this PR, so the PR's only job is to persist the bump back to source. Real drift, not a hypothetical.

The two-version jump is explained, and it isn't this PR's doing. sdk-typescript-v0.1.10 shipped on 2026-09-08 but its persist step failed — #11402 (SDK Release Failed for v0.1.10) is still open, and no PR was ever opened for head release/sdk-typescript/v0.1.10. So main never learned about 0.1.10, and get-release-version.js's doesVersionExist() loop correctly stepped past the already-existing v0.1.10 tag to 0.1.11. This PR therefore closes a two-release drift, and #11402 is arguably resolved by it — that part is a maintainer call.

Direction: aligned. This is the tail of the repo's own release automation, not a new proposal. It is also a release / public-contract change — it fixes the recorded version of a published npm package — which is the category this gate escalates to a maintainer rather than auto-approving.

Size: 2 files, +2/−2. Before the merge commit this was reported as 25 files / +68/−68, because the release branch had been cut from a pre-0.23.2 main and carried its own duplicate chore(release): v0.23.2 commit alongside the one #11469 landed. Merging main in collapsed that: I'd verified by blob-SHA comparison that 23 of those 25 files were already byte-identical on main, so the net delta was always 2 lines — now the diff view says so too. Nothing under packages/*/src/** is touched, so the core-module gate doesn't apply, and both size thresholds are far off.

Approach: exactly minimal — the version field in the workspace manifest plus its mirror entry in package-lock.json, and nothing else. I checked completeness rather than assuming it: a code search over current main for the 0.1.9 literal returns 14 files, and only packages/sdk-typescript/package.json is the SDK's own version — the rest are unrelated (a1 CLI 0.1.90 references in review-platform docs and source, Rust version_check.rs, two Cargo.lock crate versions). pnpm-lock.yaml is correctly untouched because it imports @qwen-code/sdk as workspace:* → link:../sdk-typescript, which holds no version, and BUNDLED_CLI_VERSION is written into dist/, which isn't committed. My earlier question about cutting release branches from a stale main has been answered for this PR by the merge itself; whether release-sdk.yml should branch from current main in the first place is still worth a look upstream, but it no longer affects this diff.

Risk: no matches against the revert-history high-risk paths. The risk that mattered on the previous head is now gone, and the reason is interesting: classify_pr logs Not a release sync PR: event=pull_request, actor=yiliang114, expected_actor=qwen-code-ci-bot, repo_match=true, head_match=true, title_match=true, so it exported skip_ci=false. Because a human pushed the merge commit, the release-sync shortcut deliberately does not fire — this head gets a real CI run, npm ci included. On the previous head the same classifier matched all four conditions and the Test/Lint jobs no-op-passed in 11 and 12 seconds. Evidence and the in-flight status are in the next comment.

Flagging this for a maintainer's eyes rather than diving straight into an approval — the diff is clean, but it's a release change and my vote would be the deciding one.

中文说明

感谢贡献！

先说一个时间上的情况：我审查过程中 head 发生了变化——在 SDK 版本号提交（1c3a5045）之上多了一个 Merge branch 'main' 提交（8462669b）。下面所有内容都已针对新的 head 重新验证，而这次合并让情况变得更好，我在相应位置做了说明。

模板： PR 正文只有一行 Automated release PR for sdk-typescript v0.1.11.，模板要求的标题一个都没有。我不把这当作阻塞性失败，理由需要说清楚：这行文字是 release-sdk.yml 自己原样生成的（--body "Automated release PR for sdk-typescript ${RELEASE_TAG}."），而 ci.yml 的 classify_pr 本来就是为了识别这种 PR 形态——同仓库 head + qwen-code-ci-bot actor + release/ 开头分支 + chore(release): 标题——把它当作机器生成的版本同步 PR。在这里 request changes 等于要求一个 bot 去修改它无法修改的固定字符串，而此时 npm 上 0.1.11 已经发布。所以我选择转交 maintainer，而不是终止流程。

问题： 是已观测到的，不是理论性的，而且有确切时间戳。GitHub release sdk-typescript-v0.1.11 已于 2026-09-09T11:47:33Z 从 release/sdk-typescript/v0.1.11 分支发布，而当前 main（50b942ae）上的 packages/sdk-typescript/package.json 仍然是 0.1.9。workflow 是在打开这个 PR 之前就完成 npm 发布的，所以这个 PR 唯一的作用就是把版本号同步回源码。这是实际的版本漂移，不是假设。

跳过一个版本号是有解释的，而且不是这个 PR 造成的。sdk-typescript-v0.1.10 于 2026-09-08 发布，但它的持久化步骤失败了——#11402（SDK Release Failed for v0.1.10）仍然是 open 状态，而且从未为 head release/sdk-typescript/v0.1.10 开过 PR。所以 main 从来不知道 0.1.10 的存在，get-release-version.js 的 doesVersionExist() 循环于是正确地跳过已存在的 v0.1.10 tag，落到 0.1.11。因此这个 PR 修复的是跨越两个 release 的漂移，#11402 也可以说由它解决了——这一部分需要 maintainer 判断。

方向： 对齐。这是仓库自身 release 自动化的收尾，不是新提案。它同时属于 release / 公共契约类改动——它确定了一个已发布 npm 包所记录的版本号——而这类改动是本 gate 会转交 maintainer、不自动批准的范围。

规模： 2 个文件，+2/−2。在合并提交之前，这里显示的是 25 个文件 / +68/−68，因为 release 分支是从 0.23.2 之前的 main 切出来的，除了 #11469 落地的那次之外，还自带了一个重复的 chore(release): v0.23.2 提交。合并 main 之后这些都被收敛掉了：我此前通过 blob SHA 对比已经确认那 25 个文件中有 23 个在 main 上逐字节相同，所以净变更一直是 2 行——现在 diff 视图也这么显示了。完全没有触及 packages/*/src/**，因此核心模块 gate 不适用，两个规模阈值也都远未达到。

方案： 完全最小化——workspace manifest 里的 version 字段，加上 package-lock.json 中对应的镜像条目，别无其他。我实际核查了完整性，而不是默认它完整：在当前 main 上用代码搜索查找 0.1.9 字面量返回 14 个文件，其中只有 packages/sdk-typescript/package.json 是 SDK 自身的版本号——其余都无关（review-platform 文档与源码中的 a1 CLI 0.1.90 引用、Rust 的 version_check.rs、两个 Cargo.lock 里的 crate 版本）。pnpm-lock.yaml 未被改动是正确的，因为它以 workspace:* → link:../sdk-typescript 引入 @qwen-code/sdk，本身不携带版本号；BUNDLED_CLI_VERSION 写入的是 dist/，不在版本控制中。我此前关于"从过期 main 切 release 分支"的疑问，在这个 PR 上已经被合并本身回答了；至于 release-sdk.yml 一开始是否就该从当前 main 切分支，仍然值得在上游看一眼，但这已经不影响本次 diff。

风险： revert 历史信号中的高风险路径没有命中。上一个 head 上真正要紧的风险现在已经消失，而原因很有意思：classify_pr 的日志是 Not a release sync PR: event=pull_request, actor=yiliang114, expected_actor=qwen-code-ci-bot, repo_match=true, head_match=true, title_match=true，于是它导出了 skip_ci=false。因为这次合并提交是由人推送的，release-sync 的捷径刻意没有触发——这个 head 会得到一次真实的 CI 运行，其中包含 npm ci。而在上一个 head 上，同一个分类器四个条件全部匹配，Test/Lint job 在 11 秒和 12 秒内空操作通过。证据与当前仍在运行的状态见下一条评论。

我把这个 PR 提出来交给 maintainer 判断，而不是直接进入批准——diff 是干净的，但它是一次 release 改动，而我这一票会是决定性的那一票。

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 8462669b57b0e1f1af2fb5a7391ab9b483c053d0 · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Code review. Asked how I'd persist a published SDK version back to main, my answer would be: a two-line commit — the version field in packages/sdk-typescript/package.json and its mirror entry under packages/sdk-typescript in package-lock.json, nothing else. No lockfile regeneration, no other manifests, because pnpm links the workspace package by path rather than by version. That is exactly this PR's diff: two files, one changed line each, both "version": "0.1.9" → "0.1.11".

Because the diff is that small I checked it directly rather than sampling it. The invariant npm ci would otherwise enforce — a workspace entry's lock version equals its manifest version — holds: 0.1.11 on both sides. Completeness is the more interesting question for a version bump, so I searched current main for the old literal instead of trusting the file list: 14 files contain 0.1.9, and only packages/sdk-typescript/package.json is the SDK's own version. The others are unrelated — a1 CLI 0.1.90 references in the review-platform docs and source, a Rust version_check.rs, and crate versions in two Cargo.lock files. pnpm-lock.yaml is correctly untouched (it imports @qwen-code/sdk as workspace:* → link:../sdk-typescript, which carries no version), and BUNDLED_CLI_VERSION is written into dist/, which isn't committed. So nothing is missing from the sync and nothing extra is in it. No correctness bug, no security surface, no AGENTS.md violation — and no new code, so no reuse-before-new-code question either.

Worth contrasting with #11393 (the v0.1.9 release PR), whose triage deferred over 191 lines of lockfile deletions from a regenerated lock. This head carries none of that.

Testing. Unattended CI run — I built nothing and executed nothing from this PR. The evidence is the PR's own CI read through the API, plus the static verification above. Real-scenario terminal testing is N/A: a version-metadata sync has no runtime surface, so there is nothing a terminal capture could show.

The most important thing about this head is that it gets real CI. On the previous head (1c3a5045) classify_pr matched all four release-sync conditions and exported skip_ci=true, so Test and Lint & Static no-op-passed in 11 and 12 seconds — the test job never even checked out. The maintainer's merge commit changed that, because the classifier keys on the pushing actor. Its own log:

Not a release sync PR: event=pull_request, actor=yiliang114,
expected_actor=qwen-code-ci-bot, repo_match=true, head_match=true, title_match=true
skip_ci=false

So the install actually ran this time, and it ran against the changed lockfile. From job 102458925477 (Test (ubuntu-latest, Node 22.x)) on this head: step 5 Verify checkout includes expected head commit → success, step 13 Install dependencies → success. That is the npm ci against the one changed package-lock.json line, which is precisely the check that was absent an hour ago.

CI on this head — 65 check-run records, no failure / timed_out:

Check	Conclusion
Qwen Code CI — Test (ubuntu-latest) step Install dependencies (npm ci)	success
Qwen Code CI — Integration Tests (no-AK, No Sandbox)	success
Qwen Code CI — Test (ubuntu-latest, Node 22.x), unit suite	in progress
Qwen Code CI — Lint & Static (ubuntu-latest, Node 22.x)	in progress
Qwen Code CI — Test (macos-latest / windows-latest, Node 22.x)	skipped (profile)
pnpm Worktree Smoke — Install (ubuntu-latest / macos-latest / windows-latest)	success
SDK Java — ubuntu Java 11 / 17 / 21, macos Java 21, windows Java 21, Real daemon E2E / Java 11	success
Desktop Shell (ubuntu-22.04 / windows-2022)	success

Two honesty notes on that table. First, the count is inflated by superseded duplicates: Real daemon E2E / Java 11 appears twice, one record completed success and one stale in_progress from a run that was re-triggered — the SDK Java workflow run itself is completed / success. Second, the single cancelled record on this head is review-pr, which is the bot's own review orchestration under pull_request_target, superseded by a later run. It is not PR CI and this diff did not cause it.

Still in flight, and I'm not going to guess at it: one PR CI workflow run, Qwen Code CI — specifically the unit suite and Lint & Static. Not verified yet: those two outcomes. Neither plausibly depends on an SDK version string, but both are required contexts and neither has reported.

pnpm Worktree Smoke is worth naming separately because it carries no skip_ci gate and ran for real on all three OSes — Checkout, Node 22.x, Install frozen pnpm worktree dependencies, Verify workspace links resolve, Ensure bootstrap keeps the worktree clean. The fourth of those is the directly relevant one: @qwen-code/sdk still resolves as a workspace link after the bump.

No sandboxed lane is warranted here, and I want to be explicit about why I'm not naming one. There is no behavioural claim to settle — this changes version metadata, not runtime behaviour — and the single thing that did need substantiating, that the changed npm lockfile still installs, is now substantiated by a real npm ci on this exact head. A /verify run would re-prove what step 13 just proved.

中文说明

代码审查。 如果问我会怎么把一个已发布的 SDK 版本号同步回 main，我的答案是：一个两行的提交——packages/sdk-typescript/package.json 里的 version 字段，加上 package-lock.json 中 packages/sdk-typescript 下对应的镜像条目，别无其他。不重新生成 lockfile，也不动其他 manifest，因为 pnpm 是按路径而不是按版本号链接 workspace 包的。这正是本 PR 的 diff：两个文件，各改一行，都是 "version": "0.1.9" → "0.1.11"。

正因为 diff 这么小，我是直接核查而不是抽样检查。npm ci 本该强制保证的那个不变量（workspace 条目在 lock 中的版本等于其 manifest 中的版本）是成立的：两边都是 0.1.11。对版本号提升来说更有意思的问题是完整性，所以我在当前 main 上搜索了旧的版本号字面量，而不是相信文件清单：有 14 个文件包含 0.1.9，其中只有 packages/sdk-typescript/package.json 是 SDK 自身的版本号。其余都无关——review-platform 文档与源码中的 a1 CLI 0.1.90 引用、一个 Rust 的 version_check.rs，以及两个 Cargo.lock 里的 crate 版本。pnpm-lock.yaml 未被改动是正确的（它以 workspace:* → link:../sdk-typescript 引入 @qwen-code/sdk，不携带版本号），BUNDLED_CLI_VERSION 写入的是 dist/，不在版本控制中。所以这次同步既没有遗漏，也没有夹带多余内容。没有正确性 bug，没有安全面，没有违反 AGENTS.md——也没有新增代码，因此同样不存在"优先复用而非新增"的问题。

值得与 #11393（v0.1.9 的 release PR）对比：那次的 triage 因为重新生成 lockfile 带来的 191 行删除而 defer。这个 head 完全没有那些内容。

测试。 无人值守的 CI 运行——我没有构建、也没有执行本 PR 的任何代码。证据是通过 API 读取的本 PR 自身 CI，加上上述静态验证。真实场景的终端测试为 N/A：版本元数据同步没有运行时界面，终端截图也展示不出任何东西。

这个 head 最关键的一点是它得到了真实的 CI。在上一个 head（1c3a5045）上，classify_pr 匹配了全部四个 release-sync 条件并导出 skip_ci=true，于是 Test 与 Lint & Static 在 11 秒和 12 秒内空操作通过——test job 甚至没有 checkout。maintainer 的合并提交改变了这一点，因为分类器是按推送者 actor 判断的。它自己的日志：

Not a release sync PR: event=pull_request, actor=yiliang114,
expected_actor=qwen-code-ci-bot, repo_match=true, head_match=true, title_match=true
skip_ci=false

所以这一次安装真的运行了，而且是针对变更后的 lockfile 运行的。来自本 head 上 job 102458925477（Test (ubuntu-latest, Node 22.x)）的结果：第 5 步 Verify checkout includes expected head commit → success，第 13 步 Install dependencies → success。那就是针对唯一那行 package-lock.json 变更的 npm ci，也正是一小时前缺失的那个检查。

关于上面那张表，有两点需要如实说明。第一，条目数被"被取代的重复记录"放大了：Real daemon E2E / Java 11 出现了两次，一条记录为 success，另一条是被重新触发的运行留下的过期 in_progress——而 SDK Java workflow 运行本身是 completed / success。第二，这个 head 上唯一一条 cancelled 记录是 review-pr，它是 bot 自己的 review 编排任务，属于 pull_request_target，被后续运行取代了。它不是 PR CI，也不是这个 diff 造成的。

仍在运行中、我不做任何猜测的部分：一个 PR CI workflow 运行，即 Qwen Code CI——具体是单测套件与 Lint & Static。尚未验证：这两项的结果。 两者都不大可能依赖一个 SDK 版本字符串，但它们都是必需的检查项，而且都还没有报告。

pnpm Worktree Smoke 值得单独点出，因为它没有 skip_ci 门控，并且在三个操作系统上都真实运行了——Checkout、Node 22.x、Install frozen pnpm worktree dependencies、Verify workspace links resolve、Ensure bootstrap keeps the worktree clean。其中第四步是直接相关的：版本号提升之后 @qwen-code/sdk 仍然能作为 workspace link 正常解析。

这里不需要沙箱化验证通道，我要明确说明为什么我不点名一个。没有需要确认的行为性主张——这改变的是版本元数据，不是运行时行为——而唯一确实需要证实的事情，即变更后的 npm lockfile 仍然可以安装，现在已经由这个 head 上真实的 npm ci 证实了。再跑一次 /verify 只会重复第 13 步刚刚证明过的东西。

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 8462669b57b0e1f1af2fb5a7391ab9b483c053d0 · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Confidence: 4/5 — clean and now genuinely verified; the only things keeping it from 5 are that one required CI workflow is still running and that two follow-ups belong upstream rather than in this diff.

Stepping back over the whole picture: my independent proposal for this job was a two-line commit, and the diff is two lines. I searched current main for the old version literal rather than trusting the file list, so I know the sync is complete and not overreaching. The 0.1.9 → 0.1.11 jump traces to an open release failure (#11402) and the version script stepping past an already-published tag, not to anything this PR did. And the one thing that would have made me hesitate — an uninstalled lockfile change landing on the branch everyone installs from — resolved itself when the maintainer's merge commit took this head off the skip_ci path: npm ci ran against the changed lockfile and passed, as did the no-AK integration suite, the whole SDK Java matrix including Real daemon E2E, and the pnpm workspace-link check on three OSes. If I had to maintain this in six months I'd thank whoever landed it. It repairs source-of-truth drift instead of causing it.

I want to be explicit about one judgment call, because it's the only place a reasonable maintainer could disagree with me. This is a release / public-contract change, which is a category this gate normally routes to a human rather than approving unattended — and that is what I did on the v0.1.9 release PR (#11393). I'm not treating it as a defer trigger here, for two reasons. The reason I deferred there was factual, not ceremonial: 191 lines of regenerated lockfile with no install behind them. This head has 2 lines with a green install behind them. And the escalation the rule asks for has already happened in the strongest form available — @yiliang114 pushed a commit to this branch and approved it, so a human owns this call and is exercising it, not being substituted for by a bot. My vote completes a gate a maintainer already walked through. If you read the policy differently, dismiss the approval or re-run me; that's cheap, and I'd rather say this out loud than have the reasoning hidden.

So: approving, but not in this run, because Qwen Code CI is still working through the unit suite and Lint & Static on this head and I won't attest to a result that doesn't exist yet. Approval is deferred until CI lands green on 8462669b57b0e1f1af2fb5a7391ab9b483c053d0, at which point the finalize job posts the commit-pinned approval; if either of those lands red, or the head moves again, it withholds and says so. Auto-merge is already enabled by the release workflow (squash, chore(release): sdk-typescript v0.1.11 [skip ci]). One correction to what I wrote a few minutes ago: a second human approval (@chiga0) landed while this run was in flight, so the two-approval requirement is already satisfied by humans and my deferred approval is a redundant third vote rather than the deciding one — green CI on this head is the only remaining gate.

Two follow-ups, neither blocking and neither this PR's to fix:

• SDK Release Failed for v0.1.10 on 2026-09-08 #11402 looks closable once this lands. It's the v0.1.10 release whose persist step failed; this is the bump that never made it to main. Worth confirming and closing so the next SDK failure issue isn't read against stale drift.
• release-sdk.yml cutting the release branch from a stale main. That's what put a duplicate chore(release): v0.23.2 commit on this branch and inflated the diff to 25 files / +68/−68 until a human merged main in. It stayed harmless only because that sweep happened to match chore(release): v0.23.2 #11469 byte-for-byte; had the two diverged, the merge would have silently resolved one of them. Branching from current main would make these PRs the two-liners they're meant to be — and would stop them depending on a human push as the only thing that turns real CI on, which is what happened here.

For the record: the head moved mid-review (1c3a5045 → 8462669b), so I re-ran the verification against the new head rather than posting what I'd already written. Everything above, and the commit this attests to, is the new one.

中文说明

Confidence: 4/5 —— 干净，而且这次是真正被验证过的；没能给到 5 分的原因只有两点：一个必需的 CI workflow 仍在运行，以及有两个后续项属于上游、而不在这个 diff 里。

退一步看整体：我对这件事的独立方案是一个两行的提交，而 diff 就是两行。我在当前 main 上搜索了旧的版本号字面量，而不是相信文件清单，所以我确认这次同步是完整的、也没有超出范围。0.1.9 → 0.1.11 的跳跃可以追溯到一个仍然 open 的 release 失败（#11402），以及版本脚本跳过已发布 tag 的行为，而不是本 PR 做了什么。而唯一会让我犹豫的事情——一个未经安装验证的 lockfile 变更落到所有人安装依赖的分支上——在 maintainer 的合并提交把这个 head 带离 skip_ci 路径之后自行解决了：npm ci 针对变更后的 lockfile 运行并通过了，no-AK 集成测试套件、包含 Real daemon E2E 在内的整个 SDK Java 矩阵、以及三个操作系统上的 pnpm workspace-link 检查也都通过了。如果六个月后由我来维护，我会感谢把它合进来的人。它修复了 source-of-truth 的漂移，而不是制造漂移。

我想明确说明一个判断，因为这是唯一一处合理的 maintainer 可能与我意见不同的地方。这是一次 release / 公共契约类改动，而这类改动本 gate 通常会转交给人、而不是在无人值守时批准——我在 v0.1.9 的 release PR（#11393）上就是这么做的。这次我没有把它当作 defer 的触发条件，理由有两点。我在那次 defer 的理由是事实性的，不是形式性的：191 行重新生成的 lockfile，背后没有任何安装验证。而这个 head 是 2 行，背后有一次绿色的安装。而且那条规则所要求的"升级到人"，已经以最强的形式发生了——@yiliang114 向这个分支推送了提交并且批准了它，所以这个判断由人拥有、并且正在由人行使，而不是被 bot 替代。我这一票是补全一个 maintainer 已经走过的门。如果你对这条策略有不同理解，可以撤销这个批准或者重新触发我；成本很低，我宁愿把话说明白，也不希望推理过程被藏起来。

所以：批准，但不在本次运行中批准，因为 Qwen Code CI 在这个 head 上仍在跑单测套件与 Lint & Static，而我不会为一个还不存在的结果作背书。批准被延迟到 CI 在 8462669b57b0e1f1af2fb5a7391ab9b483c053d0 上全部变绿之后，届时 finalize job 会发布绑定该 commit 的批准；如果这两项中有任何一项变红、或者 head 再次移动，它会保留不批准并说明原因。release workflow 已经启用了 auto-merge（squash，chore(release): sdk-typescript v0.1.11 [skip ci]）。对几分钟前我写的内容做一处更正：第二个人工批准（@chiga0）在本次运行过程中落地了，因此两票要求已经由人满足，我这个被延迟的批准是多余的第三票，而不是决定性的一票——这个 head 上 CI 变绿是唯一剩下的门。

两个后续项，都不阻塞，也都不该由本 PR 来修：

• SDK Release Failed for v0.1.10 on 2026-09-08 #11402 在本 PR 合并后看起来可以关闭。 它是 persist 步骤失败的那次 v0.1.10 release；而这正是那次从未同步到 main 的版本号提升。值得确认并关闭，以免下一个 SDK 失败 issue 被放在过期漂移的背景下解读。
• release-sdk.yml 从过期的 main 切出 release 分支。 这正是把重复的 chore(release): v0.23.2 提交放到本分支上、并让 diff 膨胀到 25 个文件 / +68/−68 的原因，直到有人手动合并了 main。它之所以无害，仅仅因为那次 sweep 恰好与 chore(release): v0.23.2 #11469 逐字节一致；如果两者出现分歧，合并会静默地选择其中一方。从当前 main 切分支会让这些 PR 回到它们本该是的两行改动——也会让它们不再依赖"有人推送一次提交"才能开启真实 CI，而这正是这次发生的情况。

为了留痕说明：审查过程中 head 发生了变化（1c3a5045 → 8462669b），所以我针对新的 head 重新跑了验证，而不是把已经写好的内容发出去。上面所有内容、以及本次背书的 commit，都是新的那一个。

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 8462669b57b0e1f1af2fb5a7391ab9b483c053d0 · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Released in v0.23.3.