chore(ci): remove retired WebUI dependency guard

[yiliang114]

What this PR does

Removes the repository-wide WebUI retirement guard from CI and preflight, together with its dedicated script and tests. The retirement document now records the dependency scan as a one-time pre-merge check.

The previous release timeout changes are fully reverted; this PR does not extend or weaken any quality-check budget.

Why it is needed

@qwen-code/webui and the packages/webui workspace have already been removed. A one-time repository audit confirms there are no remaining active package, import, or workspace-path references, so carrying a custom scanner in every full CI run adds maintenance and runtime cost without protecting a live compatibility boundary.

Reviewer Test Plan

How to verify

Run:

npx vitest run scripts/tests/ci-platform-lanes.test.js scripts/tests/release-workflow.test.js scripts/tests/package-scripts.test.js
npx prettier --check .github/workflows/ci.yml .github/workflows/release.yml package.json scripts/tests/ci-platform-lanes.test.js scripts/tests/release-workflow.test.js docs/design/web-shell/chat-transcript-contract-prevalidation.md

Expected: 105 tests pass, one existing test is skipped, and formatting passes. A direct repository scan should find no active @qwen-code/webui package/import or packages/webui path references.

Evidence (Before & After)

N/A — removal of a CI-only retirement guard.

Tested on

OS	Status
🍏 macOS	✅
🪟 Windows	CI
🐧 Linux	CI

Environment (optional)

Node.js 22.

Risk & Scope

• Main risk or tradeoff: Reintroducing the retired package is no longer rejected by a custom repository-wide scanner; normal dependency review and existing consumer-specific boundaries remain.
• Not validated / out of scope: Changes to release timeouts or fixes for transient runner-load failures in release run #33957952281.
• Breaking changes / migration notes: None.

Linked Issues

Related to the post-retirement preview release validation after #9812 and release run https://github.com/QwenLM/qwen-code/actions/runs/33957952281

中文说明

本 PR 做了什么

删除全仓 WebUI 退役 CI 守卫、preflight 挂钩及其专用脚本和测试；设计文档改为记录“合并前一次性扫描”。

之前增加的 release timeout 已全部撤回，本 PR 不提高也不弱化任何质量检查预算。

为什么需要

@qwen-code/webui 与 packages/webui workspace 已经删除。一次性全仓审计确认活动代码、依赖清单和 workspace 路径均无剩余引用，因此没有必要让每次 full CI 长期运行一套仅用于退役确认的自定义扫描器。

Reviewer Test Plan

运行上述三个测试文件，预期 105 个测试通过、1 个既有测试跳过，格式检查通过；一次性仓库扫描应找不到活动的 WebUI package/import/path 引用。

风险与范围

• 取舍：不再由自定义全仓扫描器阻止旧包重新引入；正常依赖评审和已有 consumer-specific boundary 仍保留。
• 范围外：release timeout 调整，以及 release run #33957952281 中仅在高负载下出现的其他失败。
• 破坏性变更：无。

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

Thanks for the PR!

Template looks good ✓ — every required section is filled in, including a real Risk & Scope and the Chinese translation.

Problem: observed, and I confirmed the evidence independently rather than taking the description's word for it. Pulling the job timings off release run #33957952281:

• Quality Checks (Scripts) → failure (the lane contract).
• Quality Checks (Static) → cancelled at 30m25s (09:32:01Z → 10:02:26Z). Step detail backs the description exactly: Format Project ran 09:34:01Z → 09:53:03Z = 19m02s, then Run Lint was cancelled at 10:02:14Z. That is the 30-minute ceiling firing, not a lint error.
• Quality Checks (Build) → success in 44m22s (09:32:02Z → 10:16:24Z) against a 45-minute ceiling.

So both blockers are real and both numbers in the description check out. This is not theoretical hardening.

Direction: the lane-contract half is a plain follow-up to #9812 — the guard was added to CI without updating the pinned payload list, and the fix is to add the name. Clearly aligned. The second half raises two release job ceilings, which puts this PR in the release pipeline, and that is a call I'd rather a maintainer own than have a gate rubber-stamp — see the escalation at the bottom.

Size: not applicable. No core paths (packages/core/src/**, auth/providers/models/config/tools/services) are touched. 9 changed lines across 3 files: 2+2 in the release workflow, 1+0 and 2+2 in the two test files. Nothing close to any threshold.

Approach: minimal on both counts — no drive-by edits, no reformatting, nothing unrelated. Two honest questions, neither a blocker:

1. The two halves are logically independent (a stale test expectation vs. a job-budget policy change). Bundling them is defensible when both block the same release run and each is a handful of lines, but if the timeout half needs discussion, it would be a shame for it to hold up the one-line contract fix.
2. On the ceiling itself: the evidence proves 30 was too small for Static, but it doesn't establish that 90 is the right number — Static's true duration is unmeasured, because Run Lint was cut off about 9 minutes in. 90 looks like headroom rather than a measurement. If host contention on the shared ECS pool is the actual cause, a larger ceiling absorbs the symptom and the degradation stays invisible. Is the contention itself worth a look, or is 90 simply the pragmatic bound?

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

⏸️ Escalating rather than approving. This touches .github/workflows/release.yml, and release-pipeline policy is exactly the area the gate defers to a human on. The code review found no blockers; the reason this isn't an approval is the subject matter, not a defect. Note also that I could not resolve an owner deterministically — the PR carries no area label and has no human reviewer yet — so nobody is @mentioned here rather than guessing a login. A maintainer needs to pick this up.

Flagging these for discussion before this lands.

中文说明

感谢贡献！

模板完整 ✓ —— 所有必填小节都写了，包括 Risk & Scope 和中文说明。

问题：已观测到，并且我独立核实了证据，没有直接采信 PR 描述。 从 release run #33957952281 拉取 job 时间：

• Quality Checks (Scripts) → failure（lane 契约测试）。
• Quality Checks (Static) → 在 30 分 25 秒时被 cancelled（09:32:01Z → 10:02:26Z）。step 明细与描述完全一致：Format Project 跑了 09:34:01Z → 09:53:03Z，即 19 分 02 秒，随后 Run Lint 在 10:02:14Z 被取消。这是 30 分钟上限触发，不是 lint 报错。
• Quality Checks (Build) → success，耗时 44 分 22 秒（09:32:02Z → 10:16:24Z），而上限是 45 分钟。

所以两个阻塞都是真实存在的，描述里的两个数字都核对无误。这不是理论性加固。

方向： lane 契约这一半是 #9812 的直接跟进——CI 里加了守卫，但没有同步更新被 pin 住的 payload 列表，修复方式就是补上这个名字。方向明确对齐。另一半提高了两个 release job 的上限，这把 PR 带进了发布流水线，这类判断我更希望由 maintainer 来定，而不是让 gate 直接盖章——见文末的转交说明。

规模： 不适用。没有触及核心路径（packages/core/src/**、auth/providers/models/config/tools/services）。3 个文件共 9 行改动：release workflow 2+2，两个测试文件 1+0 和 2+2。远未触及任何阈值。

方案： 两部分都很克制——没有顺手改动，没有重排版，没有无关内容。两个真诚的问题，都不是阻塞项：

1. 这两半在逻辑上是独立的（一个是过期的测试预期，一个是 job 时间预算的策略调整）。当两者都阻塞同一次 release run、且各自只有几行时，放在一起是可以理解的；但如果超时这一半需要讨论，让那一行契约修复被它拖住就可惜了。
2. 关于上限本身：证据能证明 Static 的 30 分钟太小，但并不能证明 90 是正确的数字——Static 的真实耗时无法测量，因为 Run Lint 只跑了约 9 分钟就被切断了。90 看起来是留余量，而不是实测结果。如果真正的原因是共享 ECS pool 上的资源争用，那么提高上限只是吸收了症状，性能退化会一直不可见。是否值得看一下争用本身，还是说 90 就是一个务实的上限？

风险： 无升级风险信号——三个文件都不匹配与 revert 相关的高风险路径。

⏸️ 转交 maintainer，而不是批准。 本 PR 改动了 .github/workflows/release.yml，而发布流水线的策略正是 gate 应当交给人类判断的领域。代码审查没有发现阻塞项；这里不给批准的原因是改动所属的领域，而不是发现了缺陷。另外，我无法确定性地解析出负责人——PR 没有 area label，也还没有人类 reviewer——因此这里不 @ 任何人，而不是猜一个账号。需要 maintainer 接手。

先提出来讨论，再决定合并。

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

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

[qwen-code-ci-bot]

Code review

I formed my own plan from the title and the "why" before opening the diff: for the lane contract, add the missing step name to the pinned payload list in scripts/tests/ci-platform-lanes.test.js at the slot matching the workflow's own step order; for the ceilings, change the two timeout-minutes values in release.yml and update the exact-value pin in scripts/tests/release-workflow.test.js. That is what the PR does, so there is no simpler path I found that it missed.

Then I checked each half against the tree rather than assuming it:

• The name is real and spelled exactly right. Check retired WebUI dependency appears once in .github/workflows/ci.yml (line 1125) and runs npm run check:no-webui, which package.json maps to node scripts/check-no-webui-dependency.js. So the list gains a step that genuinely exists, not a phantom string.
• The position is correct, and position matters here. The assertion is toEqual(FULL_PAYLOAD) over the workflow's own step names in order, so an entry in the wrong slot fails. ci.yml runs Audit critical runtime dependencies → Check lockfile → Check retired WebUI dependency → Check desktop workspace isolation → Check TUI dependency direction → Install linters, and the PR inserts it in exactly that slot.
• The gate matches the filter. FULL_PAYLOAD collects steps whose if contains ci_profile == 'full'. The new step carries that same gate, so it belongs in the list. The second assertion — that no payload member leaked back into the test job — also holds, since the name occurs only once in the whole workflow.
• The timeout change and its pin are updated together, and nothing else pins those values. quality_static 30 → 90 and quality_build 45 → 90 in release.yml match the two edits inside it('bounds shared-pool jobs and skips redundant remote npm caches'), which compares an exact object. I went looking for a second place that would now be stale: scripts/tests/package-scripts.test.js pins timeout-minutes: 110, but that is the test job's unit-test step in ci.yml, unrelated to these two release jobs. The change set is complete.
• 90 is not an invented number in this file. release.yml already uses 90 for another job and 120 for the integration jobs, so the new ceiling sits inside existing precedent rather than above it.

No correctness blockers, and no AGENTS.md violations — nothing over-abstracted, nothing duplicated, no unrelated churn.

Two things I'd put to a maintainer, both non-blocking:

The test being relaxed is a guardrail, not bookkeeping. bounds shared-pool jobs exists to cap how long a job may occupy the contended self-hosted ECS pool. Tripling Static and doubling Build deliberately loosens that cap, and the PR's own Risk & Scope says so plainly ("a genuinely stuck Static or Build job can now occupy a runner for up to 90 minutes") — which is the right way to raise it. My reservation is only about the value: the evidence proves 30 was too small, but Static's real duration is unmeasured because Run Lint was cancelled roughly 9 minutes in, so 90 is headroom chosen by judgement. If the cause is contention on the shared host, a bigger ceiling hides the trend instead of showing it.

There is an in-repo pattern for a retunable ceiling. workspace_tests uses fromJSON(vars.QWEN_RELEASE_WORKSPACE_TIMEOUT_MINUTES || '45'), and the neighbouring comment calls it "the one bound an operator can retune without a PR". If contention is expected to keep moving these numbers, the same treatment would avoid a PR per adjustment. I am raising it as a question about whether that "only one" decision should be revisited, not as a defect — the PR correctly follows the convention as it currently stands.

Test evidence

This is an unattended CI run, so I did not build or execute anything from this PR. The evidence below is the PR's own CI, read through the API for the reviewed commit.

At review time CI had not finished: Lint & Static (ubuntu-latest, Node 22.x), Test (ubuntu-latest, Node 22.x) and Integration Tests (no-AK, No Sandbox) were still in progress. Nothing was red — no check had failed, so there is no failing-job log to quote. I fetched once and did not poll.

That pending state is exactly where the central claim sits. The claim is "these two scripts suites pass with the updated expectations", and the direct oracle is npm run test:scripts, which the in-flight Test (ubuntu-latest, Node 22.x) job runs. So the claim is not verified yet — it is verified when that job lands green, and the finalize workflow rewrites the table below in place once CI settles.

I am deliberately not naming a sandboxed lane here. @qwen-code /verify produces A/B load-bearing proof against the base build and @qwen-code /tmux drives the TUI; neither can say anything about a timeout-minutes constant or a pinned list of step names, because there is no runtime behaviour in this diff to exercise. The gap above is closed by CI completing, not by a lane.

The release-run evidence I cited in Stage 1 is separate and already settled — those job and step timings come from run #33957952281, which has finished.

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

Check	Conclusion
Integration Tests (no-AK, No Sandbox)	🚫 cancelled
Lint & Static (ubuntu-latest, Node 22.x)	🚫 cancelled
Test (ubuntu-latest, Node 22.x)	🚫 cancelled
web-shell E2E Smoke (ubuntu-latest, Node 22.x)	🚫 cancelled
Classify PR	✅ success
Desktop Shell (ubuntu-22.04)	✅ success
Desktop Shell (windows-2022)	✅ success

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

中文说明

代码审查

在看 diff 之前，我先根据标题和"为什么需要"写出了自己的方案：lane 契约部分，在 scripts/tests/ci-platform-lanes.test.js 被 pin 住的 payload 列表里，按 workflow 自身的 step 顺序补上缺失的名字；上限部分，改 release.yml 里的两个 timeout-minutes，并同步更新 scripts/tests/release-workflow.test.js 里的精确值断言。PR 做的正是这件事，我没有找到它遗漏的更简路径。

之后我逐项对照代码树核实，而不是想当然：

• 名字真实存在且拼写完全一致。 Check retired WebUI dependency 在 .github/workflows/ci.yml 中只出现一次（第 1125 行），执行 npm run check:no-webui，而 package.json 把它映射到 node scripts/check-no-webui-dependency.js。所以列表里加的是一个确实存在的 step，不是一个凭空捏造的字符串。
• 插入位置正确，而位置在这里是有意义的。 断言是对 workflow 自身 step 名按顺序做 toEqual(FULL_PAYLOAD)，放错位置就会失败。ci.yml 的顺序是 Audit critical runtime dependencies → Check lockfile → Check retired WebUI dependency → Check desktop workspace isolation → Check TUI dependency direction → Install linters，PR 正是插在这个位置。
• gate 与过滤条件一致。 FULL_PAYLOAD 收集的是 if 中包含 ci_profile == 'full' 的 step，新 step 带的正是同样的 gate，所以它属于这个列表。第二个断言——payload 成员没有回流到 test job——同样成立，因为该名字在整个 workflow 中只出现一次。
• 超时改动与其断言同步更新，且没有别处 pin 这两个值。 release.yml 里 quality_static 30 → 90、quality_build 45 → 90，与 it('bounds shared-pool jobs and skips redundant remote npm caches') 中的两处修改一致，该测试用精确对象比较。我特意找了是否还有第二处会因此过期：scripts/tests/package-scripts.test.js 里 pin 了 timeout-minutes: 110，但那是 ci.yml 中 test job 的单元测试 step，与这两个 release job 无关。改动集合是完整的。
• 90 在这个文件里不是凭空造出来的数字。 release.yml 中已有另一个 job 用 90，integration job 用 120，所以新上限落在既有先例之内，而不是超出它。

没有正确性阻塞项，也没有违反 AGENTS.md 的地方——没有过度抽象、没有重复代码、没有无关改动。

有两点想交给 maintainer 判断，都不是阻塞项：

被放宽的这个测试是一道护栏，不是记账。 bounds shared-pool jobs 的存在是为了限制单个 job 占用有争用的自托管 ECS pool 的时长。把 Static 提到三倍、Build 提到两倍，是在有意放松这道限制，而 PR 自己的 Risk & Scope 也直白地写明了（"真正卡死的 Static 或 Build job 最长会占用 runner 90 分钟"）——这是正确的提出方式。我的保留意见只针对数值：证据能证明 30 太小，但 Static 的真实耗时无法测量，因为 Run Lint 大约跑到第 9 分钟就被取消了，所以 90 是靠判断留出的余量。如果根因是共享 host 上的争用，那么提高上限会把趋势掩盖起来，而不是暴露出来。

仓库里已有"可调节上限"的写法。 workspace_tests 用的是 fromJSON(vars.QWEN_RELEASE_WORKSPACE_TIMEOUT_MINUTES || '45')，旁边的注释称它是"唯一一个 operator 不需要发 PR 就能调整的上限"。如果争用预计会持续改变这些数字，同样的处理可以避免每次调整都要发一个 PR。我提出这一点，是在问"只有这一个"的决定是否值得重新考虑，而不是指出缺陷——PR 正确地遵循了当前的约定。

测试证据

这是一次无人值守的 CI 运行，所以我没有构建或执行本 PR 的任何代码。下面的证据是 PR 自身的 CI，通过 API 针对被审查的 commit 读取。

审查时 CI 尚未跑完：Lint & Static (ubuntu-latest, Node 22.x)、Test (ubuntu-latest, Node 22.x) 和 Integration Tests (no-AK, No Sandbox) 仍在进行中。没有任何一项是红的——没有 check 失败，因此也没有失败 job 的日志可引用。我只拉取了一次，没有轮询等待。

这个未完成状态正好落在核心论断上。论断是"这两个 scripts 测试套件在更新预期后能通过"，而直接的验证来源是 npm run test:scripts，它由正在运行的 Test (ubuntu-latest, Node 22.x) job 执行。所以该论断尚未被验证——它在那个 job 变绿时才被验证，CI 落定后 finalize workflow 会就地改写下面的表格。

我有意没有在这里指名沙箱验证通道。@qwen-code /verify 产出的是相对 base 构建的 A/B 承重证明，@qwen-code /tmux 驱动的是 TUI；两者都无法就一个 timeout-minutes 常量或一份被 pin 住的 step 名列表说明任何事情，因为这个 diff 里没有可供执行的运行时行为。上面的缺口要靠 CI 跑完来闭合，而不是靠某个通道。

我在 Stage 1 引用的 release run 证据是另一回事，且已经落定——那些 job 与 step 时间来自已经结束的 run #33957952281。

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

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

[qwen-code-ci-bot]

Confidence: 3/5 — the review itself is clean and I could not find a defect in either half; the cap is because this PR changes the release pipeline, which is a maintainer's call, not because I doubt the code.

Stepping back: this is a small, honest PR that fixes two things it says it fixes. I verified the motivation from the failed run's own timings rather than accepting the description — Static really was cancelled at its 30-minute ceiling after Format Project ate 19m02s, and Build really did finish in 44m22s against a 45-minute ceiling. Those are not soft claims dressed up as evidence; they are the run's numbers, and they match.

The implementation matches what I would have written independently, and the details that are easy to get wrong are right: the step name is spelled exactly as the workflow spells it, it sits in the slot the order-sensitive toEqual requires, its gate matches the filter that builds the list, and the two timeout edits are mirrored in the only test that pins them. I looked for a second stale pin and there isn't one. Nothing in the diff is unnecessary. In six months nobody will curse this change.

Where I land short of approving is the subject matter, and I want to be precise about that so it doesn't read as doubt I don't have. Raising quality_static from 30 to 90 and quality_build from 45 to 90 loosens a bound that a test named bounds shared-pool jobs exists to hold on a contended self-hosted pool. Whether 90 is the right ceiling — versus, say, 60, versus making it operator-retunable the way workspace_tests already is, versus chasing down why formatting takes 19 minutes — is an ops judgement about the release runners that I have no standing to make. The PR author does have admin on this repo and may well be the right person to make it; that is precisely why a human should sign off rather than a gate.

Two smaller notes, neither blocking and neither a reason to hold this up: the two halves are logically independent, so if the ceiling needs discussion it would be a shame for it to detain the one-line contract fix; and the suites-passing claim is still unconfirmed because CI was in flight at review time, so read the table in my Stage 2 comment once it settles.

⏸️ Deferring — no approval and no request for changes. I could not resolve an owner deterministically: the PR carries no area label, so the owner map matched nothing, and there is no human reviewer yet to fall back on. Rather than guess a login, I am leaving this unassigned. A maintainer needs to pick this up and make the ceiling call. If you would rather the gate had a standing owner for release-workflow changes, adding an area label here would let the resolver name someone next time.

中文说明

Confidence: 3/5 —— 审查本身是干净的，两部分我都找不出缺陷；扣分的原因是本 PR 改动了发布流水线，这属于 maintainer 的判断范围，而不是我对代码有疑虑。

退一步看整体：这是一个小而诚实的 PR，它修的两件事确实就是它说的两件事。我没有采信描述，而是从失败 run 自身的时间数据核对了动机——Static 确实是在 30 分钟上限处被取消的，此前 Format Project 吃掉了 19 分 02 秒；Build 确实用了 44 分 22 秒完成，而上限是 45 分钟。这些不是把软性说法包装成证据，而是那次 run 的真实数字，并且完全吻合。

实现与我独立写出的方案一致，而且那些容易出错的细节都是对的：step 名与 workflow 中的写法逐字一致，位置正好落在顺序敏感的 toEqual 所要求的那一格，它的 gate 与构造该列表的过滤条件相匹配，两处超时修改也在唯一 pin 住它们的测试里同步更新了。我找过是否还有第二处过期断言，没有。diff 里没有多余的东西。六个月后不会有人因为这个改动而骂人。

我没有给批准，原因在于改动的所属领域，我想把这点说清楚，以免被误读成我其实并不存在的怀疑。把 quality_static 从 30 提到 90、quality_build 从 45 提到 90，是在放松一个由名为 bounds shared-pool jobs 的测试专门守住的上限，而这个上限针对的是有争用的自托管 pool。90 是否是正确的上限——相比于 60，相比于像 workspace_tests 那样做成 operator 可调节，相比于去查清楚为什么格式化要花 19 分钟——这是一个关于发布 runner 的运维判断，我没有立场替它做决定。PR 作者在这个仓库确实有 admin 权限，很可能正是做这个决定的合适人选；而这恰恰说明应该由人类签字，而不是由 gate 签字。

另外两点较小的提醒，都不阻塞，也不构成拖住它的理由：这两半在逻辑上是独立的，所以如果上限需要讨论，让它拖住那一行契约修复就可惜了；另外"测试套件通过"这一论断仍未确认，因为审查时 CI 还在跑，所以请在它落定后再看我 Stage 2 评论里的表格。

⏸️ 转交处理——不批准，也不要求修改。 我无法确定性地解析出负责人：PR 没有 area label，所以 owner map 没有匹配到任何区域；也还没有人类 reviewer 可供回退。与其猜一个账号，我就不做指派了。需要 maintainer 接手并对上限做出判断。 如果你希望 gate 对 release-workflow 类改动有一个固定负责人，在这里加一个 area label 就能让解析器下次点出名来。

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

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

[yiliang114]

Direction updated at 8127dc60e34f after maintainer review:

• Removed the recurring repository-wide WebUI retirement guard, its preflight hook, script, and tests.
• Reverted the release timeout changes completely; Static remains 30 minutes and Build remains 45 minutes.
• Ran a one-time repository audit: packages/webui is absent and no active package/import/workspace-path reference remains.
• Local verification: 105 tests passed, one existing test skipped; Prettier and git diff --check passed.

The earlier triage comments reviewed ac4f0a820539 and describe the superseded direction.

中文说明

根据 maintainer 意见，8127dc60e34f 已调整方向：删除长期运行的全仓 WebUI 退役守卫及其 preflight 挂钩、脚本和测试；此前的 release timeout 修改已全部撤回（Static 仍为 30 分钟，Build 仍为 45 分钟）。

一次性全仓审计确认 packages/webui 不存在，活动代码、依赖清单和 workspace 路径均无剩余引用。相关本地验证为 105 个测试通过、1 个既有测试跳过，Prettier 与 git diff --check 均通过。

前面的 triage 评论审查的是旧提交 ac4f0a820539，其描述的方案已经失效。

[qwen-code-dev-bot]

Approved at head 8127dc60.

Why this is safe to remove. I checked for anything left pointing at the deleted pieces, on this head: git grep "check:no-webui\|check-no-webui-dependency" returns nothing, git grep "Check retired" returns nothing, so no workflow step, npm script, contributor doc, or test contract still names the guard. preflight loses exactly one chained step and stays coherent, package.json drops only the script definition, and the two files go together — the script and the test that ran the repository-wide scan.

Verified by running it. In a detached checkout of this head:

npx vitest run --config ./scripts/tests/vitest.config.ts \
  scripts/tests/ci-platform-lanes.test.js scripts/tests/release-workflow.test.js scripts/tests/package-scripts.test.js
→ 3 files passed — 105 passed | 1 skipped (106)
npx prettier --check <the six files named in the PR>
→ All matched files use Prettier code style!

so the lane-contract tests do not enumerate the removed step and the removal needs no test update, as the description claims. I also confirmed the net diff touches no workflow other than ci.yml: the branch's intermediate fix(release): extend quality check timeouts commit is fully reverted here, so this PR really is guard-removal only and does not move any quality-check budget.

Boundaries that survive the guard, which is the part worth being explicit about: the eslint no-restricted-imports rule that keeps @qwen-code/webui out of the VS Code companion bundle, scripts/tests/vscode-companion-no-webui-config.test.js, and the artifact assertion in packages/web-shell/client/build-artifact.test.ts all still run, and a fresh repository scan at this head finds no active package/import/workspace-path reference outside the deliberate mentions in those files and the historical docs/design/, docs/plans/, .qwen/e2e-tests/ records. One consequence to keep in mind rather than act on: because the package remains published on npm, a re-add would not fail installation — reintroduction is now caught by those consumer-specific boundaries and by review rather than by a whole-tree scan. If a cheap ratchet is ever wanted again, banning the specifier in check:lockfile over package.json/lockfile only would cost a fraction of scanning every tracked file on every full run.

History. No review threads exist on this PR and no prior Critical or necessary Suggestion is outstanding; the only existing review is chiga0's approval on this same head. No new Critical found. I checked the remaining webui mentions across the tree before calling any of them stale: eslint.config.js carries only the live companion-bundle rule quoted above, and eslint.legacy-filenames.mjs has none, so nothing is left dangling by the deletion.

One nit, non-blocking: docs/design/web-shell/chat-transcript-contract-prevalidation.md item 4 replaces "CI adds check:no-webui" with the one-time-audit wording, so the record no longer says a guard ever existed. A half-line noting it was added in #9812 and dropped here would keep the design history readable for whoever wonders why the scan is not in CI.

CI facts. At submit time Lint & Static, Test (ubuntu-latest), Real daemon E2E and review-pr were still queued on this head; the no-AK integration lane, Desktop Shell lanes and Classify PR were green, and nothing was red. The decision above is based on the code and the local runs.

[qwen-code-ci-bot]

Released in v0.23.1.