fix(scripts): remove never actually supported npm "--parallel" flag

[imrehg]

What this PR does

The --parallel flag was a proposal for npm, but it wasn't merged in the end. With version 12 unknown flags are now errors instead of warnings (release notes, near the bottom of the Breaking Changes), so on that version it blocks running npm run test and similar tasks.

Why it's needed

Without this change, on newer npm versions (>=12) the test trigger won't work at all.

Reviewer Test Plan

How to verify

Update to npm version >=12.0.0,
Run make test for example, and observe it working

Evidence (Before & After)

Before:

$ make test
npm run test
npm notice run @qwen-code/qwen-code@0.21.7 test
npm notice run cross-env NODE_OPTIONS="--max-old-space-size=3072" npm run test --workspaces --if-present --parallel
npm error code EUNKNOWNCONFIG
npm error Unknown cli flag:
npm error   - --parallel
npm error Run `npm help config` for supported options.
npm error A complete log of this run can be found in: /home/greg/.npm/_logs/2026-08-08T05_54_56_271Z-debug-0.log
make: *** [Makefile:34: test] Error 1

After: the test runs just fine

Tested on

OS	Status
🍏 macOS	⚠️
🪟 Windows	⚠️
🐧 Linux	✅

Environment (optional)

npm run test, etc..

Risk & Scope

• Main risk or tradeoff: Not that I can think of
• Not validated / out of scope: N/A
• Breaking changes / migration notes: Nothing I can think of

Linked Issues

Closes #8721

中文说明

[qwen-code-ci-bot]

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

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

[github-actions]

Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration.

中文

请勿对活跃的 PR 执行 rebase 或 force-push，因为这会使已有的评审评论失效。另外，供日后参考：作为集成流程的一部分，机器人始终会自动将所有改动压缩（squash）为单个提交。

[qwen-code-ci-bot]

Reviewed. Suggestions are inline. Not reviewed: reverse audit — stopped before round 2 by the review time budget. Test Plan (not a blocker): @qwen-code/qwen-code@0.21.7 — no such file or directory.

中文说明

已审查。 建议见行内评论。 未审查：反向审计——评审时间预算不足，未能开始第 2 轮。 Test Plan（非阻断）：@qwen-code/qwen-code@0.21.7 — no such file or directory。

— qwen3.8-max via Qwen Code /review (v0.21.7)

[qwen-code-ci-bot]

[Suggestion] Of the three scripts this PR fixes (test, test:ci, test:release), only test:release is pinned by an exact-value assertion; test and test:ci are asserted nowhere (I checked every packageJson.scripts read site). So the exact --parallel regression this PR fixes can silently recur for the two most-used scripts. — Failure scenario: a future change re-adds --parallel (or another unsupported npm flag) to the test or test:ci script in package.json. No test fails, and CI stays green because CI's npm 10.x tolerates unknown flags — exactly why the original flag went unnoticed — while every developer on npm ≥ 12 hits the identical EUNKNOWNCONFIG failure of issue #8721 again at runtime. Probed on both npm versions: 10.9.4 accepts the flag (exit 0), 12.0.2 hard-fails with EUNKNOWNCONFIG, byte-for-byte the issue report. Consider extending the existing pin pattern to cover test and test:ci too, e.g.:

for (const name of ['test', 'test:ci', 'test:release']) {
  expect(packageJson.scripts[name]).not.toContain('--parallel');
}

— qwen3.8-max via Qwen Code /review (v0.21.7)

[imrehg]

I feel like immortalising the original problem (adding a flag to the calls that never actually worked) with a test here is unlikely to be really helpful, and in its suggestged form it wouldn't catch many other potential problems.

There might be better, more general solutions that chip away at this problem (testing with newer npm versions as they come out, testing with a matrix of npm/node versions....) that would catch such regressions or issues better than adding a fragile check.

I have a change like the way it was suggesged above, prepared and happy to push if the above logic doesn't make sense and the test is still preferred.

[wenshao]

Verification report — built a real environment and ran this end to end

I reviewed this as a maintainer and wanted more than a code read, so I built a real verification environment: three real npm binaries (10.9.7, 11.19.1, 12.0.2) installed side by side and put on PATH via shims so that the nested npm inside a script body is also the version under test, plus separate checkouts of this repo at the PR base, at the PR head, and with PR 8725 merged into today's main.

Verdict: correct, behaviour-preserving, and merge-ready. I'd merge it. Details and evidence below.

1. The reported failure reproduces exactly, and the fix clears it

make test in a real checkout with npm 12.0.2 first on PATH:

arm	exit	wall	outcome
main without the PR	1	189 ms	EUNKNOWNCONFIG — dies before a single test runs
main + PR 8725	—	60 s+	npm parses it, vitest runs the workspaces (I killed it at 60 s)

The output is byte-identical to the Test Plan in the description, down to make: *** [Makefile:34: test] Error 1. I ran the same pair for all three scripts (test, test:ci, test:release) — without the PR all three die at parse time in ~185 ms; with it all three proceed into vitest.

2. --parallel was never a real npm flag, and never did anything

npm config get parallel returns undefined on 10.9.7, 11.19.1 and 12.0.2 — it was never a defined config on any version this repo can run. npm 11 already prints npm warn Unknown cli config "--parallel". This will stop working in the next major version of npm., which is exactly the break that landed in 12.

To make sure removing it changes nothing, I ran a three-workspace fixture whose test script busy-waits 1500 ms and prints its own start/end timestamps, under each npm, with and without the flag:

• wall time is identical (~4.73 s ≈ 3 × 1.5 s) in every accepting combination;
• the probe timestamps show zero overlap — ws-b starts ~20 ms after ws-a ends, every time. Workspaces were always serial, flag or no flag;
• the only observable effect the flag ever had was setting npm_config_parallel=true in the child env. Nothing reads it: zero hits in this repo, and zero hits across the entire installed dependency tree (I checked the positive control npm_config_user_agent to confirm the scan actually works).

3. Argument forwarding across -- is intact

This was the one non-obvious risk: in test:release the flag sat immediately before the -- separator. It forwards correctly after removal — in the real repo under npm 12 the merged tree runs npm notice run vitest run --coverage.enabled=false, and in the fixture every workspace receives args=["--coverage.enabled=false"] identically with and without the flag.

4. Backward compatible, and it explains why CI never caught this

npm 10.9.7 and 11.19.1 both run the merged tree fine. CI can't have caught the original problem: the release/CD workflows pin npm@11.19.0 and everything else uses the npm bundled with Node 22.x (10.x) — versions that accept the flag. So this is a developer-machine break today, and a CI break the day those pins move to 12.

5. Do the two test edits actually bind?

I mutated each guard back to the regression it is supposed to catch, ran the suite, and restored the tree:

probe	mutation	result
M1	re-add --parallel to test:release	✅ caught — the exact-value pin binds
M2	re-add --parallel to test and test:ci	❌ blind — see below
M3	inline-expand npm run test:ci in windows-runner-smoke.yml	✅ caught on this PR, ❌ blind on main

M3 is worth calling out: narrowing the forbidden substring from npm run test:ci --workspaces --if-present --parallel to npm run test:ci --workspaces --if-present makes that assertion strictly stronger, since the shorter string matches more. The smoke-workflow regression it now catches is one main is blind to today. That edit is a small improvement, not just a mechanical follow-on.

6. Merge readiness against today's main

The PR branched on 8 Aug and both test files it touches have moved substantially on main since, so I merged it and tested the result rather than trusting the mergeable flag:

• git merge is clean — 3 files, +5 −5, no conflicts;
• the two touched test files pass on the merged tree: 31/31;
• residual scan finds no --parallel anywhere except the coreutils sort flag table in packages/core/src/permissions/shell-semantics.ts, which is unrelated;
• full npm run test:scripts on the merged tree: 4 failed | 1934 passed | 30 skipped. None of the four are caused by this PR. Three of them reproduce on main without the PR in a separate checkout (they assert on unwritable directories, which a root user cannot produce); the fourth, install-script.test.js, passes in a built checkout and only fails here because my verification worktrees were never built, so packages/audio-capture/dist is absent.

On the open thread about pinning test and test:ci

One measured data point rather than an opinion first: with --parallel put back on test and test:ci, the full scripts suite on today's main comes back byte-identical — 4 failed | 1934 passed | 30 skipped, 1968 tests, nothing red. Only test:release is pinned, so the exact regression this PR fixes can silently return to the two most-used scripts.

That said, I agree with @imrehg's reasoning and I don't think it should hold up this PR. A string assertion pins one flag name and would not have caught this particular flag before npm 12 shipped; the thing that actually catches this class is running the suite on a newer npm. If someone wants the belt-and-braces version later, a not.toContain('--parallel') loop over the three scripts is two lines — but it's a separate, optional change, and I'd rather see the npm/node matrix idea pursued instead.

Scope of what I checked

I verified that all three scripts parse and enter vitest under npm 12, not that the entire workspace suite passes there — that's a long run and orthogonal to this change, which only touches argument parsing. Everything else above was executed, not inferred.

中文说明

验证报告 —— 搭建真实环境端到端跑过一遍

我作为维护者审这个 PR，觉得只读代码不够，于是搭了一套真实的验证环境：并排安装三个真实 npm 版本（10.9.7、11.19.1、12.0.2），并用 shim 放进 PATH，保证脚本体里嵌套调用的 npm 也是被测版本；再分别准备了本仓库在 PR base、PR head，以及 PR 8725 合并进今天 main 之后这三种状态的 checkout。

结论：改动正确、行为无变化、可以合并。我支持合入。 证据如下。

1. 报告的失败可以精确复现，改完即消失

在真实 checkout 里、npm 12.0.2 排在 PATH 最前时执行 make test：

分支	退出码	耗时	结果
不带此 PR 的 main	1	189 ms	EUNKNOWNCONFIG —— 一个测试都没跑就挂
main + PR 8725	—	60 s+	npm 正常解析，vitest 开始跑各 workspace（我在 60 s 时手动终止）

输出与描述里的 Test Plan 逐字节一致，连 make: *** [Makefile:34: test] Error 1 都一样。三个脚本（test、test:ci、test:release）我都跑了同样的对照：不带此 PR 时三个都在约 185 ms 的参数解析阶段挂掉，带上之后三个都进入 vitest。

2. --parallel 从来就不是真实存在的 npm 参数，也从没起过作用

npm config get parallel 在 10.9.7、11.19.1 和 12.0.2 上都返回 undefined —— 在本仓库能跑的任何 npm 版本上它都不是已定义配置。npm 11 早就打印 npm warn Unknown cli config "--parallel". This will stop working in the next major version of npm.，正是 12 里落地的那次破坏性变更。

为确认删掉它不改变任何行为，我用一个三 workspace 的 fixture 做了对照：每个 workspace 的 test 脚本忙等 1500 ms 并打印自己的起止时间戳，在每个 npm 版本上分别带/不带该 flag 运行：

• 所有能接受该 flag 的组合里，墙钟时间完全一致（约 4.73 s ≈ 3 × 1.5 s）；
• 时间戳显示零重叠 —— 每次都是 ws-b 在 ws-a 结束后约 20 ms 才开始。workspace 一直是串行的，带不带 flag 都一样；
• 该 flag 唯一可观测的副作用是在子进程环境里设置 npm_config_parallel=true。没有任何东西读它：本仓库零命中，整个已安装依赖树也零命中（我用正对照 npm_config_user_agent 确认过扫描本身是有效的）。

3. -- 之后的参数透传没有受影响

这是唯一一处不那么显然的风险：在 test:release 里该 flag 正好紧挨着 -- 分隔符。删除后透传依然正确 —— 真实仓库在 npm 12 下，合并后的树会打印 npm notice run vitest run --coverage.enabled=false；fixture 里带与不带该 flag，每个 workspace 收到的都是完全相同的 args=["--coverage.enabled=false"]。

4. 向后兼容，也解释了 CI 为什么没发现这个问题

npm 10.9.7 与 11.19.1 跑合并后的树都正常。CI 不可能发现原来的问题：release/CD workflow 固定用 npm@11.19.0，其余地方用 Node 22.x 自带的 npm（10.x）—— 都是接受该 flag 的版本。所以这在今天是开发机上的故障，等那些 pin 升到 12 的那天就会变成 CI 故障。

5. 两处测试改动到底有没有约束力？

我把每个守卫都变异回它本应拦住的那个回归，跑一遍套件，再恢复现场：

探针	变异	结果
M1	给 test:release 加回 --parallel	✅ 拦住 —— 全等值断言有效
M2	给 test 和 test:ci 加回 --parallel	❌ 拦不住 —— 见下
M3	在 windows-runner-smoke.yml 里把 npm run test:ci 就地展开	✅ 本 PR 拦住，❌ main 拦不住

M3 值得单独说：把禁止子串从 npm run test:ci --workspaces --if-present --parallel 缩短为 npm run test:ci --workspaces --if-present，使这条断言严格变强了，因为更短的串能匹配到更多情况。它现在能拦住的那类 smoke workflow 回归，正是今天 main 拦不住的。这处改动是一个小改进，不只是机械的连带修改。

6. 对今天 main 的可合并性

这个 PR 是 8 月 8 日拉出去的，它改动的两个测试文件此后在 main 上变动很大，所以我没有只信 mergeable 标记，而是实际合并后做了测试：

• git merge 干净 —— 3 个文件，+5 −5，无冲突；
• 合并后的树上，被改的两个测试文件全绿：31/31；
• 残留扫描在 --parallel 上只剩 packages/core/src/permissions/shell-semantics.ts 里 coreutils sort 的参数表，与本 PR 无关；
• 合并后的树完整跑 npm run test:scripts：4 failed | 1934 passed | 30 skipped。这 4 个都不是本 PR 造成的。其中 3 个在另一个不带此 PR 的 main checkout 上同样复现（它们断言目录不可写，而 root 用户造不出这种目录）；第 4 个 install-script.test.js 在已构建的 checkout 上是通过的，这里失败只是因为我的验证 worktree 从未构建过，缺少 packages/audio-capture/dist。

关于是否给 test 和 test:ci 加断言这条讨论

先给一个实测数据，而不是先给观点：把 --parallel 加回 test 和 test:ci 后，今天 main 上的完整 scripts 套件结果逐字节一致 —— 4 failed | 1934 passed | 30 skipped，共 1968 个测试，没有一处变红。只有 test:release 被钉住了，所以这个 PR 修的那个回归可以悄无声息地回到两个最常用的脚本上。

话虽如此，我认同 @imrehg 的判断，也不认为这该拦住本 PR。字符串断言只钉住一个 flag 名字，而且在 npm 12 发布之前它根本抓不到这个 flag；真正能覆盖这一类问题的，是在更新的 npm 上跑套件。如果之后有人想要双保险，对三个脚本做一次 not.toContain('--parallel') 循环也就两行 —— 但那是一个独立且可选的改动，我更希望看到 npm/node 版本矩阵那个思路被推进。

我这次验证的边界

我验证的是三个脚本在 npm 12 下都能通过参数解析并进入 vitest，而不是整个 workspace 套件在那上面全绿 —— 那是一次很长的运行，且与本改动无关，本改动只影响参数解析。除此之外，上面的每一条都是实际跑出来的，不是推断的。

---

🤖 Generated with Claude Code — Claude Opus 5 (1M context)

[wenshao]

@qwen-code /triage

[qwen-code-ci-bot]

Sandboxed verification: ⚠️ not run — skipped - workflow run

Skipped because the pre-execution risk screen refused this sponsored run: the diff adds or modifies an npm lifecycle script. A maintainer who has reviewed the diff can run the verification manually in a disposable environment.

中文 — 判定：⚠️ 未运行 · 已跳过

跳过原因：the pre-execution risk screen refused this sponsored run: the diff adds or modifies an npm lifecycle script. A maintainer who has reviewed the diff can run the verification manually in a disposable environment。

— Qwen Code · sandboxed verification

[qwen-code-ci-bot]

Thanks for the PR!

Template looks good ✓ — every required section is present and filled in (tiny aside: the 中文说明 block is left empty; not blocking).

Problem: observed, not theoretical. #8721 ships a full reproduction — make test dying at parse time with EUNKNOWNCONFIG: Unknown cli flag: --parallel on npm 12.0.2, with the debug log — and the PR body carries the same before/after. npm 12 turned unknown-flag warnings into hard errors, and --parallel was only ever an npm proposal that never shipped.

Direction: aligned. This is a developer-machine break today and a CI break the day the npm pins move to 12 — CI currently runs npm 10.x/11.x, which still tolerate the flag, so nothing in-repo catches it. Keeping make test working for contributors is squarely in scope. No CHANGELOG signal applies to a build fix like this.

Size: not applicable — no core paths. 3 files, +5/−5: three root package.json script lines and the two test guards that pin them.

Approach: this is the minimal fix — delete the never-supported flag and update the assertions that pin the exact script strings; there is nothing left to cut. One detail worth naming: the forbidden-substring guard in the no-AK integration CI test becomes strictly stronger after the edit, since the shorter string matches more. The only non-obvious risk was test:release, where the flag sat right before the -- separator — argument forwarding across -- survives the removal.

Risk: no high-risk paths touched, no elevated risk signals.

Moving on to code review. 🔍

中文说明

感谢贡献！

模板完整 ✓——所有必填小节都在且已填写（小提示：中文说明部分是空的，不阻塞）。

问题：已观测到的 bug，不是理论问题。#8721 提供了完整复现——在 npm 12.0.2 下 make test 在参数解析阶段就报 EUNKNOWNCONFIG: Unknown cli flag: --parallel 失败，并附调试日志——PR 正文也给出了同样的 before/after。npm 12 把未知 flag 从警告升级为硬错误，而 --parallel 只是 npm 的一个提案，从未真正实现。

方向：对齐。这在今天是开发者本机的问题，等 npm 依赖升到 12 就会变成 CI 问题——目前 CI 用的 npm 10.x/11.x 还能容忍这个 flag，所以仓库里没有任何机制能发现它。保证 make test 对贡献者可用完全在项目范围内。CHANGELOG 对这类构建修复无参考信号。

规模：不适用——未触及核心路径。3 个文件，+5/−5：根 package.json 的三行脚本，以及固定这些脚本字符串的两个测试断言。

方案：这就是最小修复——删掉从未受支持的 flag，并更新固定脚本字符串的断言；没有可再砍的内容。值得一提的细节：no-AK 集成 CI 测试里的"禁止子串"断言在修改后变得更严格，因为更短的子串能匹配到更多内容。唯一不那么明显的风险在 test:release：该 flag 紧挨着 -- 分隔符——删除后 -- 之后的参数转发依然正常。

风险：未触及高风险路径，无升级风险信号。

进入代码审查 🔍

— Qwen Code · qwen3.8-max

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

[qwen-code-ci-bot]

Code review

Before reading the diff, my independent plan from the title + motivation was: remove --parallel from every root script that carries it, then sweep the repo for any other occurrence (Makefile, workflows, docs) and update the tests that pin those exact strings. The PR does exactly that and nothing else.

Checking the base tree confirms the sweep is complete: --parallel appears in exactly six places — three script bodies in package.json (removed here), the two test guards that pin those scripts (updated here), and one entry in packages/core/src/permissions/shell-semantics.ts that is coreutils' sort --parallel in a shell-flag allow-table — unrelated, and correctly left alone.

Both test edits are mandatory, not drive-bys: package-scripts.test.js pins the test:release string exactly, and the no-AK integration CI test forbids the workspaces form of npm run test:ci inside the smoke workflow. The latter edit is strictly stronger — the shorter forbidden substring matches more. The one non-obvious risk was test:release, where the flag sat immediately before the -- separator; forwarding of --coverage.enabled=false across -- is intact after the removal.

No blockers, no convention issues.

Test evidence

Check	Conclusion
Classify PR	✅ success
Test (ubuntu-latest, Node 22.x)	✅ success
Desktop Shell (ubuntu-22.04)	✅ success
Desktop Shell (windows-2022)	✅ success
web-shell E2E Smoke (ubuntu-latest, Node 22.x)	✅ success
Real daemon E2E / Java 11	✅ success
precheck-pr / precheck	✅ success
Test (macos-latest, Node 22.x)	⏭️ skipped
Test (windows-latest, Node 22.x)	⏭️ skipped
SDK Java (workflow run)	✅ success

All 76 check-runs on the reviewed commit completed with zero failures. The macOS/Windows test lanes are skipped by design, not by this PR: ci.yml gates them to merge_group/nightly only, with the pull-request trigger off since 2026-07-02 while standing Windows failures get fixed.

Two honest caveats about what that green proves. First, CI runners bundle npm 10.x (Node 22) and the release pins sit at npm 11 — versions that accepted the flag — so the suite passes with or without this diff; CI cannot pin the change. Second, the sponsored @qwen-code /verify run was refused by its pre-execution risk screen because the diff modifies npm lifecycle scripts in package.json, so there is no A/B proof from that lane either.

What does settle the behavioral claim is the maintainer verification upthread (wenshao's own, not the author's claim): real npm 10.9.7 / 11.19.1 / 12.0.2 binaries shimmed onto PATH so the nested npm is the version under test; the make test failure reproduced byte-identically on unpatched main and cleared by this PR on all three scripts; a version × flag matrix showing the flag was always a no-op (workspaces ran serially with or without it); argument forwarding across -- verified; mutation probes showing both updated guards actually bind; and a clean merge into today's main with 31/31 passing on the two touched test files.

中文说明

代码审查：在读 diff 之前，我根据标题和动机给出的独立方案是：从所有带 --parallel 的根脚本里删掉它，然后全仓库排查其他出现位置（Makefile、workflow、文档），并更新固定这些字符串的测试。PR 的做法与此完全一致，没有任何多余改动。

在 base 分支上核实：--parallel 恰好出现六处——package.json 的三处脚本正文（本 PR 删除）、固定这些脚本的两个测试断言（本 PR 更新）、以及 packages/core/src/permissions/shell-semantics.ts 里 coreutils sort --parallel 的一处（属于 shell flag 允许列表，与本问题无关，正确地未动）。

两处测试改动都是必须的，不是顺手改：package-scripts.test.js 对 test:release 做精确字符串固定；no-AK 集成 CI 测试禁止 smoke workflow 中出现 workspaces 形式的 npm run test:ci，且改后的禁止子串更短、匹配更严。唯一不那么明显的风险是 test:release 中该 flag 紧贴 -- 分隔符；删除后 --coverage.enabled=false 的转发不受影响。

无阻塞问题，无规范问题。

测试证据：被审提交上全部 76 个 check 已完成，零失败（详见上表）。macOS/Windows 测试通道为设计内跳过，与本 PR 无关：ci.yml 将其限定为 merge_group/夜间任务，自 2026-07-02 起 PR 触发关闭（等待修复既有的 Windows 失败）。

两点如实说明：其一，CI 运行环境是 npm 10.x（Node 22）/npm 11，都能容忍该 flag，所以这套测试在本 diff 前后都会通过，CI 本身无法钉住这个改动；其二，受赞助的 @qwen-code /verify 运行被预执行风险扫描拒绝（diff 修改了 package.json 中的 npm lifecycle script），因此也没有来自该通道的 A/B 证明。

真正坐实行为结论的是上文的维护者验证（wenshao 本人操作，而非作者自述）：用真实的 npm 10.9.7 / 11.19.1 / 12.0.2 三个二进制并通过 shim 让脚本内嵌套调用的 npm 也是被测版本；在未打补丁的 main 上逐字节复现 make test 失败、三个脚本在本 PR 下全部恢复；版本 × flag 矩阵证明该 flag 从来就是空操作（工作区始终串行执行）；验证了 -- 后的参数转发；变异探针确认两个更新的测试断言确实有效；合并进当天 main 无冲突，两个相关测试文件 31/31 通过。

— Qwen Code · qwen3.8-max

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

[qwen-code-ci-bot]

Confidence: 5/5 — a real observed break, the minimal correct fix, green CI, and a maintainer has already proven it end-to-end against real npm 10/11/12, including a merge into today's main.

Stepping back: my independent proposal from the review stage was identical to what this PR does — remove the never-supported flag, update the two guards that pin the script strings, touch nothing else. That is exactly the shape of the diff, +5/−5 across 3 files, with no drive-by changes. The problem is unambiguous (npm 12 turned unknown-flag warnings into errors; --parallel was never a real npm flag), and the linked issue carries the reproduction. The one subtle risk — argument forwarding across -- in test:release — was explicitly checked and is intact.

The CI suite cannot pin this change (runners ship npm < 12) and the sponsored /verify run was refused by its risk screen, which would normally leave a behavioral gap. Here it doesn't: wenshao's verification upthread is exactly the experiment I'd want — real npm binaries on both sides of the break, before/after on all three scripts, proof the flag was always a no-op, mutation probes showing the updated tests bind, and a merge into current main that stays green. The only remaining nit is cosmetic: the 中文说明 block in the PR body is empty. Not worth a round-trip.

CI is fully settled on the reviewed commit — no pending runs. LGTM, approving. ✅

中文说明

置信度：5/5 —— 真实观测到的问题、最小且正确的修复、CI 全绿，且维护者已在真实 npm 10/11/12 环境端到端验证（含合并进当天 main）。

整体回顾：我在审查阶段的独立方案与本 PR 完全一致——删掉从未受支持的 flag、更新固定脚本字符串的两个断言、不动其他任何地方。diff 正是这个形状：3 个文件 +5/−5，无顺手改动。问题明确（npm 12 将未知 flag 警告升级为错误；--parallel 从来不是真实的 npm flag），关联 issue 提供了复现。唯一微妙的风险——test:release 中 -- 之后的参数转发——已被明确验证，不受影响。

CI 无法钉住这个改动（运行环境 npm < 12），受赞助的 /verify 也被风险扫描拒绝，通常会留下行为验证缺口；但这里没有：上文 wenshao 的验证正是想要的实验——断裂点两侧的真实 npm 二进制、三个脚本的 before/after、证明该 flag 从来是空操作、变异探针确认更新后的测试确实有效、合并进当前 main 后依然全绿。唯一遗留的小瑕疵是外观性的：PR 正文的中文说明部分是空的，不值得为此打回。

被审提交上的 CI 已全部结束，无 pending 任务。LGTM，予以批准。✅

— Qwen Code · qwen3.8-max

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

[qwen-code-ci-bot]

LGTM, looks ready to ship. ✅

[qwen-code-ci-bot]

Released in v0.23.0.