Skip to content

refactor(cli): remove unused MemoryUsageDisplay component - #10238

Merged
wenshao merged 1 commit into
QwenLM:mainfrom
qqqys:simplify/memory-usage-display
Aug 29, 2026
Merged

refactor(cli): remove unused MemoryUsageDisplay component#10238
wenshao merged 1 commit into
QwenLM:mainfrom
qqqys:simplify/memory-usage-display

Conversation

@qqqys

@qqqys qqqys commented Aug 27, 2026

Copy link
Copy Markdown
Collaborator

What this PR does

Removes a status-bar memory-usage display component that is no longer referenced anywhere in the codebase. The component polled process RSS on an interval and rendered a formatted reading, but nothing imports or mounts it — its only trace in the repository is its own declaration. Nothing else changes.

Why it's needed

The component arrived together with a debug flag that showed live memory usage in the footer. The flag's snake_case alias was deliberately removed by a follow-up cleanup, and the footer's rendering binding was removed with the welcome-screen redesign of January 2026; the flag itself and the matching setting were retired entirely afterwards. The display file was simply left behind. Today no flag, setting, or mount point exists, and a full-corpus search resolves the symbol to its own declaration. Dead surface is a cost: every contributor who reads it has to work out what wires it up, and the answer here is "nothing".

Reviewer Test Plan

How to verify

This is a pure deletion of code nothing references. Verify the absence of consumers rather than behavior:

  1. rg -n '\bMemoryUsageDisplay\b' packages integrations integration-tests scripts .github docs-site — expect zero hits after this PR (the only hit before it is the component's own declaration).
  2. npm run build && npm run bundle && npm run typecheck — all green locally with this change (a type-only break from a removed export would surface here; typecheck does not run in CI).
  3. npm run lint:ci — green locally with this change.

No user-visible behavior changes: nothing mounted the component, so no before/after TUI evidence applies.

Evidence (Before & After)

N/A — non-UI change (dead-code deletion; nothing rendered this component).

Tested on

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

Environment (optional)

Local npm run build && npm run bundle && npm run typecheck and npm run lint:ci in a clean worktree off upstream main.

Risk & Scope

  • Main risk or tradeoff: essentially none — the component has zero production consumers, verified by full-corpus search including string keys, dynamic-import shapes, the build graph, and the test corpus; if a consumer were ever found, reverting the single commit restores everything.
  • Not validated / out of scope: macOS/Windows builds (no platform-specific code involved); no integration test run (no CLI behavior is touched by removing code nothing mounts); the formatMemoryUsage helper the component used stays — it has many live consumers.
  • Breaking changes / migration notes: none; the component was internal to the CLI package and never exported through any package surface.

Linked Issues

Part of the dead-surface cleanup tracked in #10000.

Machine details (find-simplifications)
  • id / class: memory-usage-display — class 1/5, orphan file whose feature left.
  • Surface removed: packages/cli/src/ui/components/MemoryUsageDisplay.tsx (41 lines) — 41 deletions, 0 added (git diff --numstat).
  • Every consumer found and its kind: full-corpus grep (production, tests, snapshots, docs, docs-site, .github, .husky, .vscode, patches, root build/lint manifests, tracked .qwen files) resolves to exactly one path — the component's own declaration. Zero production consumers; checklist rows run: string-keys (no show_memory_usage / showMemoryUsage / show-memory-usage remains anywhere in the tree), build-graph, vi-mock, dyn-import, cli-flags (the owning flag was already removed upstream, so nothing is turned into an "Unknown argument" failure); rows not applicable: generated, mirrors, assets. Second pass over integration-tests and the component's own directory without test exclusions: only its own file. formatMemoryUsage (its one import) is consumed by ~10 live call sites and stays.
  • Proof steps run (survey protocol §3): ledger check (no tombstone), recency (introduced 2025-05-30 by 01768d7759 (An assistant message with │ │ "tool_calls" must be followed by tool messages responding to each "tool_call_id" #606), last touched 2025-10-23 by the Gemini-CLI v0.8.2 sync eb95c131be — dated via the GitHub commits API path-limited against QwenLM/qwen-code; local clone is shallow), published-surface escape (territory is packages/cli/src — landable, not a published package), full-corpus grep, own-file check, hidden-consumer checklist, test-only check (the surface had no test), unwire history (deliberate: 8075300e34 (chore: fix typos in code comments and a Java SDK example #7059, 2025-08-26) removed the snake_case flag alias from config.ts; b804b1f48a (2026-01-16 welcome-screen redesign) removed the import and the {showMemoryUsage && <MemoryUsageDisplay />} rendering from Footer.tsx; the kebab-case flag and the ui.showMemoryUsage setting are now absent from the tree entirely), design-doc ownership (none in docs/design / docs/plans).
  • Re-verified at land time against fresh upstream main (2bd0ff923e): same single hit; no drift from the survey.
  • Verification: npm run build && npm run bundle && npm run typecheck green; npm run lint:ci green; test-corpus re-grep on the landing checkout returned zero surviving references; no applicable targeted unit test (the surface had none). Self-audit: two clean passes.
  • No collateral: no eslint.legacy-filenames.mjs entry (.tsx is outside the kebab-case rule's **/${name}.ts globs — verified by grep), no i18n locale keys (the component renders formatted numbers and never calls t()), no docs rows.
中文说明

本 PR 做了什么

删除一个状态栏内存占用显示组件,它在代码库中已无任何引用。该组件曾定时轮询进程 RSS 并渲染格式化后的读数,但现在没有任何代码导入或挂载它——它在本仓库中的唯一痕迹就是它自己的声明。除此之外没有任何其他改动。

为什么需要

该组件随一个在页脚显示实时内存占用的调试 flag 一起引入。该 flag 的下划线别名已被一次后续清理有意移除,页脚中的渲染接线也在 2026 年 1 月的欢迎界面改版中被移除;此后该 flag 本身与对应的设置项也被完全废弃。只有这个显示组件文件被遗留了下来。如今既无 flag、无设置项、也无挂载点,全语料库搜索中该符号仅解析到它自己的声明。死代码是一种成本:每个读到它的人都得弄清是什么在用它,而这里的答案是"没有任何东西"。

评审者测试计划

如何验证

这是一次对无任何引用代码的纯删除。请验证消费者的缺失,而不是行为:

  1. rg -n '\bMemoryUsageDisplay\b' packages integrations integration-tests scripts .github docs-site —— 本 PR 之后应无任何命中(之前唯一的命中是组件自身的声明)。
  2. npm run build && npm run bundle && npm run typecheck —— 本地在包含本改动的情况下全部通过(删除导出可能引发的纯类型问题会在这里暴露;typecheck 不在 CI 中运行)。
  3. npm run lint:ci —— 本地在包含本改动的情况下通过。

没有用户可见的行为变化(没有任何东西挂载该组件),因此无需前后对比的 TUI 证据。

证据(改动前后)

N/A —— 非 UI 改动(死代码删除;没有任何东西渲染该组件)。

测试环境

OS 状态
🍏 macOS ⚠️ 未测试
🪟 Windows ⚠️ 未测试
🐧 Linux ✅ 已测试

环境(可选)

在基于上游 main 的干净 worktree 中本地运行 npm run build && npm run bundle && npm run typechecknpm run lint:ci

风险与范围

  • 主要风险或权衡:基本没有——该组件零生产消费者,已经过全语料库搜索核实(包括字符串键、动态导入形态、构建图与测试语料库);若未来发现任何消费者,回退这一个提交即可完整恢复。
  • 未验证 / 超出范围:macOS/Windows 构建(不涉及平台相关代码);未运行集成测试(删除未被挂载的代码不影响任何 CLI 行为);该组件使用的 formatMemoryUsage 辅助函数保留——它有许多在用调用方。
  • 破坏性变更 / 迁移说明:无;该组件是 CLI 包内部实现,从未通过任何包的对外接口导出。

关联 Issue

属于 #10000 跟踪的死代码表面清理工作。

(机器细节见上方英文 "Machine details" 折叠块:id memory-usage-display,第 1/5 类——功能移除后遗留的孤立文件。删除表面:packages/cli/src/ui/components/MemoryUsageDisplay.tsx(41 行),删除 41 行、新增 0 行。全语料库搜索恰好一处命中——组件自身声明。隐藏消费者核查:string-keysshow_memory_usage/showMemoryUsage/show-memory-usage 在全树中已无残留)、build-graphvi-mockdyn-importcli-flags(所属 flag 已被上游移除,不会造成 "Unknown argument" 失败);generatedmirrorsassets 不适用。证明步骤:台账无墓碑;新近性——2025-05-30 由 01768d7759#606)引入,最近一次改动为 2025-10-23 的 Gemini-CLI v0.8.2 同步 eb95c131be(本地为浅克隆,经 GitHub commits API 按路径查询完整历史定年);非发布包表面;解线历史为有意行为——8075300e34#7059,2025-08-26)自 config.ts 移除下划线 flag 别名,b804b1f48a(2026-01-16 欢迎界面改版)自 Footer.tsx 移除导入与 {showMemoryUsage && <MemoryUsageDisplay />} 渲染;kebab 形式 flag 与 ui.showMemoryUsage 设置项如今在全树中均不存在;无设计文档认领。落地时已按最新上游 main2bd0ff923e)复核:仍为唯一命中,与调查时一致。验证:build + bundle + typecheck 通过,lint:ci 通过,测试语料复扫零残留;无定向单元测试可跑(该表面本无测试)。无连带删除:无 eslint.legacy-filenames.mjs 条目(.tsx 在该规则的 **/${name}.ts 展开之外,已用 grep 核实)、无 i18n 键(组件只渲染格式化数字,从不调用 t())、无文档条目。)

Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
@qwen-code-ci-bot

qwen-code-ci-bot commented Aug 27, 2026

Copy link
Copy Markdown
Collaborator

Qwen Triage finishedview run. See the stage comments in this thread for the result.

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

@qwen-code-ci-bot

qwen-code-ci-bot commented Aug 27, 2026

Copy link
Copy Markdown
Collaborator

Thanks for the PR!

Template looks good ✓

Problem: verified, not theoretical. I re-ran the corpus search independently against current main on this re-run: MemoryUsageDisplay resolves to exactly one hit — its own declaration — and no showMemoryUsage / show_memory_usage flag or setting survives anywhere in the tree. The component is genuinely orphaned.

Direction: aligned. Removing code nothing references is exactly the dead-surface cleanup tracked in #10000; nothing here touches behavior, public surface, or sensitive areas.

Size: not applicable — the only changed file is packages/cli/src/ui/components/MemoryUsageDisplay.tsx (0 additions / 41 deletions), which is not a core path.

Approach: the minimal possible change — a pure single-file deletion. The one judgment call is keeping the formatMemoryUsage helper, and it's the right one: the helper has many live consumers (doctorCommand, systemInfo, AnsiOutput, env-snapshot, core memoryDiagnostics, …), so it stays. No unrelated edits in the diff.

Risk: no elevated risk signals — the changed file matches none of the revert-correlated paths.

Moving on to code review. 🔍

中文说明

感谢贡献!

模板完整 ✓

问题:已核实,并非理论性问题。本次复查中我在当前 main 上再次独立重跑了全语料库搜索:MemoryUsageDisplay 恰好命中一处——即它自己的声明;树中任何位置都不再存在 showMemoryUsage / show_memory_usage 相关的 flag 或设置项。该组件确实是孤立的。

方向:对齐。删除无任何引用的代码正是 #10000 跟踪的死代码表面清理;此处不涉及行为、对外接口或敏感领域。

规模:不适用——唯一改动的文件是 packages/cli/src/ui/components/MemoryUsageDisplay.tsx(0 新增 / 41 删除),不属于核心路径。

方案:最小改动——纯单文件删除。唯一的取舍是保留 formatMemoryUsage 辅助函数,这是正确的:它有许多在用调用方(doctorCommandsystemInfoAnsiOutputenv-snapshot、core 的 memoryDiagnostics 等),应予保留。diff 中无无关改动。

风险:无升级风险信号——改动文件不匹配任何与 revert 相关的高风险路径。

进入代码审查 🔍

Qwen Code · qwen3.8-max

Reviewed at 160bb87a5114c30140d548078580467417b929a5 · re-run with @qwen-code /triage

@qwen-code-ci-bot

qwen-code-ci-bot commented Aug 27, 2026

Copy link
Copy Markdown
Collaborator

Code review

The diff is a pure 41-line deletion of packages/cli/src/ui/components/MemoryUsageDisplay.tsx, byte-identical to the file currently on main. My independent plan for "remove an unused component" was exactly this: confirm zero consumers (done in Stage 1 — the symbol resolves only to its own declaration, and the flag/setting it once hung off are long gone), keep formatMemoryUsage, which still has many live consumers, and delete nothing else. The PR does precisely that and nothing more. No findings.

Testing evidence

This section carries the PR's own CI signal for commit 160bb87 (check names and conclusions via the GitHub API — per policy I did not run any PR code myself).

Final CI results for 160bb87 (fetched via the check-runs API; all checks completed):

Check Conclusion
Classify PR ✅ success
Dependency CVE audit ✅ success
Desktop Shell (ubuntu-22.04) ✅ success
Desktop Shell (windows-2022) ✅ success
Secret scan (TruffleHog) ✅ success
Test (ubuntu-latest, Node 22.x) ✅ success
web-shell E2E Smoke (ubuntu-latest, Node 22.x) ✅ success

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

CI has settled since the previous pass: every check on 160bb87 is completed, with no failures. The deciding one for a deletion PR — Test (ubuntu-latest, Node 22.x) — passed, which is where any surviving reference to the removed export would have surfaced as a compile error. The macOS/Windows unit jobs and the integration suite are skipped by CI configuration (as GitHub reports them), so the ubuntu suite is the deciding signal.

This is a pure deletion of code nothing references, so there is no behavioural claim to substantiate — no before/after evidence applies, and a sandboxed /verify or /tmux run would not add signal here.

中文说明

代码审查

diff 是对 packages/cli/src/ui/components/MemoryUsageDisplay.tsx 的纯删除(41 行),与当前 main 上的文件逐字节一致。我对"移除未使用组件"的独立方案正是如此:确认零消费者(Stage 1 已核实——该符号仅解析到它自己的声明,其原本依附的 flag/设置项早已移除)、保留仍有大量在用调用方的 formatMemoryUsage、其余一概不删。本 PR 恰好做到这一步,不多不少。无发现。

测试证据

本节的证据来自该 PR 针对提交 160bb87 的 CI(检查名与结论经 GitHub API 获取——按策略我未自行运行任何 PR 代码)。上一轮审查后 CI 已全部收敛:160bb87 上的所有检查均已完成且无失败。对删除类 PR 起决定作用的 Test (ubuntu-latest, Node 22.x) 已通过——若仍有代码引用被删除的导出,会以编译错误在那里暴露。macOS/Windows 单测与集成测试按 CI 配置被跳过(以 GitHub 报告为准),故 ubuntu 套件是决定性信号。这是纯删除无引用代码,没有需要证实的行为主张——不存在前后对比证据的适用场景,沙箱 /verify/tmux 运行也不会带来额外信号。

Qwen Code · qwen3.8-max

Reviewed at 160bb87a5114c30140d548078580467417b929a5 · re-run with @qwen-code /triage

@qwen-code-ci-bot

qwen-code-ci-bot commented Aug 27, 2026

Copy link
Copy Markdown
Collaborator

Confidence: 3/5 — clean review at every stage and CI fully green on the reviewed commit; the 3/5 is the fork-refactor policy cap, not doubt about the change.

Honestly, there isn't much left to second-guess — and that's the point. The diff is the smallest this change could be: one unreferenced file deleted in its entirety, nothing else touched. I re-verified the central claim independently against current main on this re-run rather than taking the PR's word for it — MemoryUsageDisplay resolves only to its own declaration, the flag/setting that once mounted it no longer exist anywhere in the tree, and the helper the component imported (formatMemoryUsage) stays, with many live consumers. My independent proposal for this task was byte-identical to what the PR does.

What changed since the last pass: CI settled all green on 160bb87 — including the deciding unit suite — and @wenshao has approved the reviewed commit. The human sign-off the previous run asked for has arrived.

What has not changed is the policy, so I'll state it plainly: this gate never approves cross-repository refactor PRs. A maintainer approval on the thread is a different vote, not a substitute trigger — the check is deterministic (fork + refactor title), and the finalize job re-asserts the same guardrail. So the last step stays human: main requires two approving reviews, and this PR currently has one. A second maintainer approval (e.g. @pomelo-nwu) — or a maintainer merge — lands it.

Context worth keeping: this is one of several dead-code deletions the author has open (#10139 is the sibling). Judged on its own merits, this one stands — the evidence is mechanical and reproducible, and the only realistic risk of deleting a zero-reference symbol is a compile error, which CI has already caught and cleared.

⏸️ Deferring to @pomelo-nwu @wenshao — policy, not doubt: everything this gate can check is green at 160bb87; what remains is the second human sign-off the fork-refactor guardrail exists to require.

中文说明

置信度:3/5 —— 各阶段审查均干净,且被审查提交上的 CI 已全部通过;3/5 反映的是 fork-refactor 策略上限,而非对改动本身的疑虑。

说实话,这里没有多少需要反复掂量的地方——这正是重点所在。diff 已经是这类改动所能达到的最小形态:一个无任何引用的文件被整体删除,此外没有任何改动。本次复查我没有轻信 PR 的自述,而是在当前 main 上再次独立核实了核心主张:MemoryUsageDisplay 仅解析到它自己的声明,曾经挂载它的 flag/设置项在全树中已不存在,组件所导入的辅助函数 formatMemoryUsage 被保留且仍有大量在用调用方。我独立提出的方案与 PR 的做法完全一致。

自上一轮以来的变化:CI 在 160bb87 上已全部转绿——包括起决定作用的单元测试——且 @wenshao批准被审查的提交。上一轮所请求的人类签核已经给出。

没有变化的是策略,在此直说:本门禁从不批准跨仓库(fork)的 refactor PR。讨论串中维护者的批准是另一票,而不是替代触发器——该检查是机械判定的(fork + refactor 标题),finalize 任务也会重新断言同一护栏。因此最后一步仍是人类操作:main 要求两个批准审查,本 PR 目前有一个。第二位维护者批准(例如 @pomelo-nwu)——或由维护者直接合并——即可落地。

值得保留的背景:这是该作者当前在开的数个死代码删除 PR 之一(#10139 是姊妹篇)。就其本身的是非而言,这个 PR 站得住:证据是机械化、可复现的,而删除零引用符号唯一现实的风险是编译错误,CI 已经兜住并排除。

⏸️ 转交 @pomelo-nwu @wenshao —— 是策略使然,并非存疑:160bb87 上本门禁能核查的一切均为绿色;剩下的是 fork-refactor 护栏之所以存在而要求的人类二次签核。

Qwen Code · qwen3.8-max

Reviewed at 160bb87a5114c30140d548078580467417b929a5 · re-run with @qwen-code /triage

@qwen-code-ci-bot qwen-code-ci-bot left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Downgraded from Approve to Comment: CI still running. Reviewed.

中文说明

⚠️ 已从批准降级为评论:CI still running。 已审查。

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

@wenshao

wenshao commented Aug 28, 2026

Copy link
Copy Markdown
Collaborator

@qwen-code /triage

@wenshao
wenshao enabled auto-merge August 28, 2026 17:31
@qwen-code-ci-bot

qwen-code-ci-bot commented Aug 28, 2026

Copy link
Copy Markdown
Collaborator

Sandboxed verification: ✅ passed — merge-ready (agent verdict) - workflow run

Ran the PR in an isolated, token-free container: A/B against the base build, mock-free harness assertions, targeted gates. Advisory evidence for human reviewers — not a review, an approval, or a CI check.

Scripted assertions: 38 passed · 0 failed · 38 total

Flakiness gate: not applicable — no runnable changed test files (0 out-of-scope file(s) noted in the log)

中文 — 判定:✅ 通过 · 可合入(agent 判定)

沙箱验证在隔离、无凭证的容器中执行了该 PR 的代码(与 base 构建 A/B 对照、无 mock harness 断言、定向门禁)。仅作为评审证据,不构成评审、批准或 CI 检查

脚本断言:38 通过 · 0 失败 · 38 总计

抖动门:不适用 — no runnable changed test files (0 out-of-scope file(s) noted in the log)

Verification report

PR #10238 Deep Verification — refactor(cli): remove unused MemoryUsageDisplay component

Verdict: merge-ready — 38/38 scripted assertions passed (0 failures), no findings attributable to the PR.
Verified head: 160bb87a5114c30140d548078580467417b929a5 (HEAD^2, single commit, matches the metadata snapshot exactly).
Base tip: 4a9fe44f5a8f32dc312fcf8cc3c776c6cebc61c2 (HEAD^1); merge commit verified: ff9b5d5356194074261b2f5460e2822a61368a9b.

中文摘要

结论:merge-ready(38/38 脚本化断言通过,0 失败;未发现任何归因于本 PR 的问题)。

  • A/B 结论:对全量被跟踪语料库做符号普查 —— base(HEAD^1)上 MemoryUsageDisplay 恰好 1 处命中,即组件自身声明(MemoryUsageDisplay.tsx:14);head 上 0 处命中。大小写不敏感、kebab 拼写、动态导入路径形态、三个已废弃 flag 键(showMemoryUsage / show_memory_usage / show-memory-usage)全部复核为 0;三个 flag 键在本 PR 之前就已不存在(与描述的解线历史一致)。memoryusage 家族文件集合差(base 61 → head 60)恰好等于被删文件本身。删除是行为中性的:没有任何东西导入或挂载该组件(base 侧亦然),且组件无模块级副作用。
  • 门禁:全工作区 typecheck 通过、lint:ci 通过、bundle 通过(463 个产物文件中 0 处组件痕迹,formatMemoryUsage 仍在 6 个 chunk 中存活);packages/cli 单测 25,523 通过 / 15 失败 / 90 跳过 —— 15 个失败全部被脚本化证明为环境/既有问题(见下表),与本 PR 无关。
  • Findings:无(无归因于本 PR 的问题)。
  • 未覆盖:无前后 TUI 对比(构造上 N/A:两侧都无任何东西挂载该组件);未跑集成测试与全仓 npm test(CI 覆盖,且本改动不触及任何被导入代码);未做 base 侧全套测试(单文件 diff + 普查已在构造上排除差异,仅对唯一失败三例做了 base 侧 A/A)。

Central claim and A/B proof

Central claim: MemoryUsageDisplay has zero consumers, so deleting it is behaviorally neutral. For a dead-code deletion the load-bearing proof inverts: base must show exactly one reference (the declaration itself) and head zero, across every consumer shape. The deleted file (read from base) has a single named export and no module-level side effects — the RSS polling lives entirely inside the component's useEffect — so an import/mount is the only possible behavior path, which is exactly what the census measures.

Census A/B over all tracked files (git grep against each tree — strictly wider than the PR's own directory list), harness census-ab.mjs (19 assertions):

cell tree MemoryUsageDisplay hits case-insens. kebab / dyn-import shape flag keys (×3)
base HEAD^1 (4a9fe44f) 1MemoryUsageDisplay.tsx:14 self-declaration only 1 0 0 (already retired)
head HEAD (= PR 160bb87a merged) 0 0 0 0

Witness: evidence/01-census-ab-base-vs-head.png. Supporting cells: diff shape is exactly one file, +0/−41; file exists at base / absent at head; git rev-list HEAD^1..HEAD^2 yields the single commit matching the metadata snapshot.

The author's specific claims were each re-checked by a second harness (claims.mjs, 6 assertions, witness evidence/02-pr-claim-checks.png):

claim check result
"full-corpus search resolves to its own declaration" base census = 1 hit (self)
"no show_memory_usage/showMemoryUsage/show-memory-usage remains anywhere" 0 hits at base and head ✅ (retired before this PR, as described)
"formatMemoryUsage stays — many live consumers" 8 production + 2 test consumer files at head; present in 6 bundle chunks ✅ not orphaned
"typecheck does not run in CI" ci.yml runs only typecheck:integration, no full-workspace typecheck step ✅ accurate
nothing mounted it / no barrel export no index.ts barrel; census covers export * re-export shapes
memoryusage-family set diff (base\head) exactly the deleted file (61 → 60 files)

Reviewer Test Plan, per step: (1) the literal search across packages integrations integration-tests scripts .github docs-site — zero hits, verified (and subsumed by the full-corpus census); (2) build && bundle && typecheck — build pre-run by the environment (dist output verified), bundle RC=0, full typecheck RC=0; (3) npm run lint:ci — RC=0. All three steps reproduce as promised.

Corrections

None — first round; no earlier review or bot claims to correct.

Findings

None attributable to this PR. The deletion is safe by construction: no importer, no mount point, no side effects, no barrel, no flag, no docs/locale/build-graph reference at either arm.

Transparency notes (verifier-side, not PR issues):

  1. The first lint:ci run exited 1 with 9 errors — all in this verifier's own harness file (tmp/pr10238-verify-*/census-ab.mjs), because tmp/** is outside the repo's node-globals ESLint blocks. Zero findings in the PR tree. After making the harness lint-clean, lint:ci exits 0. This incident doubles as the lint gate's liveness proof (it caught real violations and exited nonzero).
  2. The raw packages/cli suite shows 15 failures — every one proven environmental/pre-existing by scripted checks (witness evidence/03-gates-and-attribution.png, harness attribution.mjs, 13 assertions):
failure group n proven cause evidence
settings.test.ts HOME/.env scenarios 12 this sandbox's own QWEN_HOME=/__w/_temp/verify-agent-home/.qwen leaks into the test process; user-settings resolution then reads $QWEN_HOME/settings.json, outside the tests' mocked paths re-run with QWEN_HOME unset: 173/173 pass (live, scripted)
local-anchor.integration.test.ts sparse-checkout trio 3 container git 2.39.5 lacks the git sparse-checkout check-rules subcommand (present only in newer upstream git); invisibleTrackedPaths() fail-closes there by design, and the tests assert the exemption behavior base-arm A/A reproduces the same 3 failures with byte-identical test names (git worktree add tmp/base-tree HEAD^1; junit name comparison: identical); unknown subcommand: check-rules reproduced directly. CI runs newer git on ubuntu-latest, where these pass.

Not covered

  • Before/after TUI evidence — not applicable by construction and verified as such: at base the sole reference is the declaration itself (nothing rendered the component either), so there is no visual delta to capture.
  • Integration tests / repo-wide npm test — skipped by scope choice: the diff is one un-imported file (assertions D1–D3 + census), which cannot move any integration behavior; CI covers both lanes.
  • Base-arm full-suite run — proven unnecessary (every file except the deleted one is byte-identical across arms, asserted by diff shape; the census proves nothing imports it, so no test outcome can move). Only the failing sparse-checkout trio was re-run at base, where it fails identically. Note the base worktree resolved @qwen-code/qwen-code-core through the head tree's symlink (asserted via readlink -f); benign here because the PR touches no other package, and the nested node_modules gap (git-ignored, e.g. ajv@8.20.0 under packages/core) was bridged with symlinks of PR-invariant dependency content before the base run could collect.
  • macOS/Windows — no platform-specific code involved; not exercised.
  • Per-commit attribution was reachable (exactly 1 commit) and is fully covered above.
  • The sparse-checkout trio's root-cause behavior (fail-closed on old git) was verified only in this container's git 2.39.5; the pass path on a git new enough to have check-rules is covered by CI, not re-measured here.

Methodology

Environment: CI merge-ref checkout (HEAD = merge commit, HEAD^1 = base tip, HEAD^2 = PR head, depth 2) in the verify container (Node 22.23.2, git 2.39.5); npm ci + npm run build were pre-run at HEAD. Three harnesses drove everything, all preserved in this directory as .mjs for re-running: census-ab.mjs (19 assertions: diff shape, file existence, symbol/case/kebab/flag-key census on both trees, formatMemoryUsage non-orphaning, commit attribution), claims.mjs (6 assertions: family set diff, consumer counts, ci.yml typecheck claim, dist output state), attribution.mjs (13 assertions: recorded typecheck/bundle RCs, junit failure-name parity head vs base, full-suite counts, container-git limitation, gate liveness proofs, live clean-env settings re-run, live lint:ci, clean-tree check). Gates ran at head: npm run typecheck (RC=0), npm run lint:ci (RC=0 after harness hygiene), npm run bundle (RC=0; dist/cli.js + 461 chunks grepped), cd packages/cli && npx vitest run (25,523 pass / 15 fail / 90 skip). Gate liveness was proven, not assumed: lint caught 9 real violations (exit 1) and later the clean tree (exit 0); a planted TS2322 scratch file made typecheck fail (exit 2) and was removed; vitest caught the 15 environmental failures rather than passing silently. Base-arm A/A used git worktree add tmp/base-tree HEAD^1 with QWEN_VITEST_GUARD_ROOT pointed at the head root and nested node_modules symlinked (dep tree is PR-invariant); the worktree was removed after evidence capture. Raw logs live in logs/ (chain RCs in logs/chain.log, both arms' junit in logs/head-junit-cleanenv.xml / logs/base-junit.xml). Working tree verified clean at the end (git status --porcelain empty).

Flakiness gate log


verdict: n/a
summary: no runnable changed test files (0 out-of-scope file(s) noted in the log)

Evidence images

01-census-ab-base-vs-head

02-pr-claim-checks

03-gates-and-attribution

Harness scripts and raw logs are in the workflow run artifacts (7-day retention).

Qwen Code · sandboxed verification

@qwen-code-ci-bot

Copy link
Copy Markdown
Collaborator

Triage re-run completed without a new review.

⚠️ The bot's only review on 160bb87a5114c30140d548078580467417b929a5 is a COMMENTED one, which carries no vote — so it has no verdict of its own on this commit, and main needs two approving reviews: an approval left by another account is a separate vote and does not count as the bot's own. Two different things look like this, and the stage-3 comment above says which: the triage skill deferring on purpose at 3/5 — a fork refactor hitting the approval guardrail, or a core change escalated for maintainer awareness, both normal outcomes — or an earlier approval that a push dismissed, leaving only the comment behind, which needs a fresh review.

⚠️ 机器人在 160bb87a5114c30140d548078580467417b929a5 上唯一的评审是 COMMENTED不带票 —— 因此它在该 commit 上没有自己的裁决,而 main 需要两个批准(其他账号的批准是另一张票)。有两种情况长这样,上方的 stage-3 评论会说明是哪一种:triage skill 在 3/5 时有意 defer(fork refactor 命中审批护栏,或核心改动被升级交由维护者把关,两者都是正常结果);或者更早的批准被一次推送作废、只剩下这条评论,此时需要重新评审。

The stage comments above were updated with the latest result. View workflow run.

上方各阶段评论已更新为最新结果。查看工作流运行

@wenshao
wenshao added this pull request to the merge queue Aug 29, 2026
Merged via the queue into QwenLM:main with commit 8a3fa75 Aug 29, 2026
81 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants