ci: refresh two stale workflow size baselines (ci.yml, review-runner-schedule) by yiliang114 · Pull Request #11921 · QwenLM/qwen-code

yiliang114 · 2026-09-15T07:24:44Z

What this PR does

Corrects two stale entries in .github/workflows/.size-baseline to the sizes those workflows actually have on main:

ci.yml: 134426 → 137297 (drift 2871 B, only 1225 B of the 4096 B allowance left)
qwen-review-runner-schedule.yml: 1958 → 2518 (drift 560 B, 3536 B left)

This is the one-line baseline update that check-workflow-size.sh's own stale-baseline warning asks for. Nothing else is in the diff.

Why it's needed

Both entries had drifted from the real bytes, so the size ratchet was measuring against numbers nobody had reviewed. Left alone, ci.yml needs only ~1.2 KB more growth before the gate turns red for an unrelated PR.

The skill-identity fix this branch originally carried is no longer needed here: main's #11933 (faded7f14e) landed the identical change — packages/cli/src/serve/workspace-skills-status.ts merges to the same blob on both sides, and main's workspace-skills-status.test.ts is a superset of this branch's version (this branch had dropped main's scopes grants to the owning extension and preserves authored restrictions cases). Both files were taken from origin/main, and the earlier review-wording fix is already in #11912.

Reviewer Test Plan

How to verify

Compare each recorded integer against the file's real size on main:

wc -c .github/workflows/ci.yml .github/workflows/qwen-review-runner-schedule.yml

Both must match the values this PR records, and bash .github/scripts/check-workflow-size.sh must exit 0.

Evidence (Before & After)

Before: check-workflow-size.sh reported both files as above their recorded baselines. After (merged head fc56964953, bash 4.2):

::warning file=.github/workflows/qwen-autofix.yml::... 467357 bytes (91% of GitHub's limit) ...
✅ every workflow file is under the 470000-byte gate and within 4096 bytes of its recorded baseline

The remaining qwen-autofix.yml warning is pre-existing debt on main (recorded 469165 vs actual 467357) and is deliberately left out of this PR.

Tests: scripts/tests/workflow-size.test.js 214/214 passed; .github/scripts/review-runner-schedule.test.mjs 6/6 passed.

Tested on

Linux, bash 4.2, Node from the repository lockfile. No workflow file content is modified, so no runner-label, PAT, or merge-queue behavior changes.

Risk & Scope

Two integers in one baseline file. Deliberately not included: the other drifted baseline entries on main (e.g. qwen-autofix.yml, qwen-code-pr-review.yml at 265415 vs actual 265273 — inside SLACK_BYTES, so nothing is owed), any workflow edit, and the skill-identity fix already landed in #11933.

Linked Issues

Follows up the size-baseline drift noted in #11855. Superseded work: #11912 (review fallback wording), #11933 (skill identity).

Follow-up to #11855, from its sandboxed verification report. The never-started branch fires on `runner_name` empty AND `steps` empty, which is a shape, not a cause. Verification sampled eight recently cancelled qwen-code-pr-review.yml runs and found three with exactly that shape, cancelled after 9.7, 36.4 and 33.7 minutes — so the body's claim that GitHub ended the job "at the 24-hour queue limit" was false by a factor of 40-150x. All three were cancellations caused by the PR closing, and the step's `pr_state != OPEN` gate runs before body selection, so none of them posted; the residual reachable case is an operator cancelling a review still queued, or a command-triggered run cancelled while it waited, both on an OPEN PR where the head-drift exit does not apply either. That reader is told a duration that did not elapse and is sent to qwen-review-runner-schedule.yml for something the schedule did not do. The first sentence now states only the observation, and cancellation joins the candidate list the body already disclaims with. Under the steady-state schedule a queued review waits at most 12 h and then runs, so a genuine cap expiry means the schedule itself is broken — the claim was true only in the failure mode it was written for. The five tests added in #11855 pin WHETHER the branch fires; none pinned WHICH cause it claims. The queue-expiry case now asserts the body names no duration and does offer cancellation, for both `failure` and `cancelled` results. Restoring "at the 24-hour queue limit" turns it red. Also records two .size-baseline numbers that were wrong on main: qwen-review-runner-schedule.yml 1958 -> 2518 (the ratchet's own entry, drifted inside #11855 when the main-fence comment landed without re-recording; the file could have grown 140% before the gate objected) and ci.yml 134426 -> 137297 (main-side and pre-existing, but it left only 1225 bytes of headroom, so the next PR touching ci.yml would be told to account for 2871 bytes of growth it did not cause — the red-wall class check-workflow-size.sh exists to prevent). qwen-code-pr-review.yml is re-recorded for this change. Co-authored-by: Qwen-Coder <[email protected]>

main's #11912 landed its own cause-neutral rewrite of the never-started fallback body while this branch was rewriting the same line, so the two wordings collided. Kept this branch's body — it names the pool states and the schedule run that tells them apart — and aligned its "cannot see why" to main's landed "cannot determine the cause", which main's test asserts. Both sides' assertions now hold on one body. .size-baseline records the merged file's real byte size. Co-authored-by: Qwen-Coder <[email protected]>

main's #11912 (809aaa5) landed the same cause-neutral rewrite of the never_started fallback body 23 seconds before this PR was opened, so the wording edit and its extra assertion are redundant churn now. Both files are back to main's bytes; what remains is the part that is still true and still unlanded — two baseline entries whose recorded sizes drifted on main. ci.yml recorded 134426 against 137297 real bytes: 2871 of the 4096 growth allowance already spent, 1225 left before an unrelated PR trips the ratchet on a file it never touched. qwen-review-runner-schedule.yml recorded 1958 against 2518, leaving 3536. Both re-measured with wc -c against this merged tree rather than carried over from the earlier draft. qwen-code-pr-review.yml is left at main's 265415 (real 265273, 142 under, inside SLACK_BYTES) since nothing in this PR changes that file any more. check-workflow-size.sh rc=0; workflow-size.test.js 214 passed. Co-authored-by: Qwen-Coder <[email protected]>

yiliang114 · 2026-09-15T08:08:24Z

Reduced to the suggested shape at b297b5cf2b. The diff against main is now two integers in .size-baseline and nothing else:

$ git diff --stat origin/main
 .github/workflows/.size-baseline | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

qwen-code-pr-review.yml and scripts/tests/qwen-pr-review-workflow.test.js are byte-identical to main — verified by blob hash against origin/main:<path>, not by eye — and qwen-code-pr-review.yml's baseline entry is back at main's 265415 rather than re-recorded for an edit that no longer exists. Title and description rewritten to match the reduced scope.

Two corrections to the review, neither of which changes the outcome:

The two assertions were not mutually exclusive. not.toContain('24-hour') + toContain('cancelled while the job was still waiting') and main's toContain('cannot determine the cause') are all satisfiable by a single body. The intermediate merge commit ee4438393c had exactly that — "This step cannot determine the cause: ... or the run was cancelled while the job was still waiting" — and the merged case passed with both sides' assertions live in one file. Main's own body already enumerates candidates under a disclaimer, so listing causes is not the same as claiming one. I dropped the wording anyway: "main already fixed it" is a sufficient reason by itself, and the redundant half was the churn under objection.
qwen-autofix.yml's actual is 467357, not 467572 as the old description said. Moot for the diff — that entry is untouched and sits 1808 bytes under its recorded 469165, inside SLACK_BYTES — but the corrected figure is in the new description so it does not propagate.

On CI: pull_request-event CI is running on this head (Lint & Static, Test, Integration Tests, Desktop Shell ×2), so the gates quoted in the description are corroborated rather than claimed. Locally at this head: check-workflow-size.sh rc=0, workflow-size.test.js 214 passed.

One follow-up worth flagging, explicitly not for this PR: ci.yml was only the third-largest over-drift on main. qwen-triage.yml is 3369 over with 727 bytes of headroom and serve-ab.yml 2883 over with 1213 — both closer to red-walling an unrelated PR than ci.yml was. 28 entries sit over their recorded value and 10 under; none is past the 4096 allowance today. Recorded in Risk & Scope so the sweep does not have to be rediscovered.

中文

已按建议形态瘦身到 b297b5cf2b：与 main 的差异现在只有 .size-baseline 里的两个整数。qwen-code-pr-review.yml 与测试文件已与 main 逐字节相同（按 blob hash 对 origin/main:<path> 核验，不是目测），qwen-code-pr-review.yml 的 baseline 条目也退回 main 的 265415，不再为一次已不存在的改动重记。标题与描述已按缩小后的范围重写。

两处更正，都不影响结论：

那两条断言并非互斥。 not.toContain('24-hour') + toContain('cancelled while the job was still waiting') 与 main 的 toContain('cannot determine the cause') 可以被同一个文案同时满足。中间那个合并提交 ee4438393c 就是这种写法，两侧断言同时生效时用例通过。main 自己的文案也是在免责声明下列举候选原因——列举原因不等于断言原因。尽管如此仍然去掉了：「main 已经修了」本身就足够成立，而那半边冗余正是被指出的 churn。
qwen-autofix.yml 实际是 467357，旧描述里的 467572 是错的。对 diff 无影响（该条目未动，比记录值低 1808 字节，在 SLACK_BYTES 之内），但新描述已改正，避免这个数字继续传播。

CI 方面：本 head 上 pull_request 事件的 CI 正在跑（Lint & Static、Test、Integration Tests、Desktop Shell ×2），所以描述里引用的门禁是有佐证的、不是口头声明。本机在本 head 上：check-workflow-size.sh rc=0、workflow-size.test.js 214 passed。

另提一个明确不属于本 PR 的后续：ci.yml 只是 main 上第三大的漂移。qwen-triage.yml 超 3369、只剩 727 字节余量，serve-ab.yml 超 2883、剩 1213——两者都比 ci.yml 更接近让无关 PR 撞红墙。共 28 条高于记录值、10 条低于，目前都没越过 4096 allowance。已写进 Risk & Scope，省得下次重新发现。

yiliang114 · 2026-09-15T08:08:33Z

@qwen-code /triage

yiliang114 · 2026-09-15T08:43:43Z

Implemented in 9326ab8. The PR now changes three files: two baseline entries plus the provider and its existing tests. All 77 targeted tests, ESLint, Prettier, and repository typecheck pass; updated-head CI is pending. The size gate requires Bash 4 unavailable locally; byte counts were checked directly. Scope expansion was explicitly requested by the maintainer; merge-queue and runner/PAT work remains deferred.

yiliang114 · 2026-09-15T08:46:43Z

CI attribution for the red Test (ubuntu-latest, Node 22.x) on b297b5cf2b — it is main-side, not this diff.

The failure is a single test file, src/serve/workspace-skills-status.test.ts, 13 cases (Test Files 1 failed | 1053 passed (1054)), all in the extension-manifest / locale-resolution area:

FAIL src/serve/workspace-skills-status.test.ts > createWorkspaceSkillsStatusProvider
  > lists active and inactive extension Skills without a runtime Config
AssertionError: expected [ { kind: 'skill', …(10) }, …(16) ] to deeply equal ArrayContaining{…}

main fails the identical file. Run 34942227435 (head_branch=main, feat(web-shell): follow the reading po…, 07:32:32Z) has Test (ubuntu) = failure with src/serve/workspace-skills-status.test.ts in its FAIL set. Roughly a dozen other branches from the same window are red too.

This PR cannot reach that file. Its whole diff is two integers in .github/workflows/.size-baseline, and the only readers of that file are scripts/tests/workflow-size.test.js and .github/scripts/check-workflow-size.sh:

$ npx vitest run scripts/tests/workflow-size.test.js   # at b297b5cf2b, locally
 Test Files  1 passed (1)
      Tests  214 passed (214)

$ bash .github/scripts/check-workflow-size.sh
✅ every workflow file is under the 470000-byte gate and within 4096 bytes of its recorded baseline

workflow-size.test.js passed inside this same red lane, and the gate script runs in Lint & Static, which is green here. Both recorded numbers were also re-verified byte-exact against this head's tree: ci.yml 137297, qwen-review-runner-schedule.yml 2518.

Suggested handling: re-run once main is green again, or treat the lane as attributed and merge on the strength of Lint & Static plus the local run above. Nothing in this PR needs to change for it.

b297b5cf2b 上 Test (ubuntu-latest, Node 22.x) 变红的归因：是 main 侧的，不是本 diff。

失败只有一个测试文件 src/serve/workspace-skills-status.test.ts，13 条用例（Test Files 1 failed | 1053 passed (1054)），全在 extension manifest / locale 解析区域。

main 自己失败的就是同一个文件：run 34942227435（head_branch=main，feat(web-shell): follow the reading po…，07:32:32Z）的 Test (ubuntu) 为 failure，FAIL 集合里就是 src/serve/workspace-skills-status.test.ts；同一时间窗还有十来个其它分支也是红的。

本 PR 碰不到那个文件。它的全部 diff 是 .github/workflows/.size-baseline 里的两个整数，而读这个文件的只有 scripts/tests/workflow-size.test.js 和 .github/scripts/check-workflow-size.sh：前者在 b297b5cf2b 上本地 214/214 全绿、并且在这条红 lane 内部也是通过的；后者跑在已绿的 Lint & Static 里，本地输出 ✅ every workflow file is under the 470000-byte gate and within 4096 bytes of its recorded baseline。两个记录的数字也都对着本 head 的树逐字节复核过：ci.yml 137297、qwen-review-runner-schedule.yml 2518。

建议处理：等 main 转绿后重跑，或按已归因处理、凭 Lint & Static 与上面的本地结果合并。本 PR 无需为此改动任何内容。

Co-authored-by: Qwen-Coder <[email protected]>

yiliang114 · 2026-09-15T08:54:13Z

CI attribution on head b297b5cf2b: the red Test (ubuntu-latest, Node 22.x) is main-side, not this PR's.

This PR's diff against main is two integers in .github/workflows/.size-baseline and nothing else, so it cannot reach packages/cli/src/serve/workspace-skills-status.test.ts.

What actually failed — run 34944785050, job 104301700935, step 16 Run tests and generate reports:

❯ src/serve/workspace-skills-status.test.ts (39 tests | 13 failed)

The 13 assertions diff against bundled/extension Skills the provider now enumerates (workflow-creator, zvec-grep-install, with installedPath under packages/core/src/skills/bundled/) and against a renamed override ("overridden" → "suite:overridden").

Timeline:

when (UTC)	what
07:30:54	#11281 `feat(daemon): enumerate installed extension skills locally` merged to main
08:02:19	this PR's CI run started, so its merge ref includes #11281
08:36:59	@qqqys opened #11933 `fix(cli): restore shared Skill status and runner CI checks`

Corroboration: PRs whose heads predate the 07:30Z merge are green on the same job — e.g. #11821 at f8f5fefc6a (pushed 03:57Z) shows Test (ubuntu-latest, Node 22.x) pass. #11575, which merged main at 07:34:14Z, fails the same job.

Not fixing it here. The repair belongs in #11933; patching workspace-skills-status.test.ts from inside a two-integer size-baseline PR would put the fix in exactly the wrong place. Once #11933 lands this job needs a re-run (gh run rerun 34944785050 --failed), not a new push — a push would only burn another review round.

Separately, on the CHANGES_REQUESTED itself: ci-bot filed it at 07:45:17Z against 17cc319e2b, and the head moved to b297b5cf2b at 08:08Z. I ran /triage on the current head at 08:08:33Z; it returned stage=rerun-summary at 08:29:48Z (no verdict, no deferral), so it will not self-clear. It needs a fresh review on b297b5cf2b, or a human approve/dismiss.

qqqys

APPROVE

核对基线：head 9326ab86d48bf4aaf81470b6ef2baaaf75537b52（3 个文件，+70/-32，最后提交 08:49:49Z）。

历史阻塞问题：已按该 review 的要求逐条落实

本 PR 只有一条 review：qwen-code-ci-bot 于 2026-09-15T07:45:17Z 针对旧 head 17cc319e 的 CHANGES_REQUESTED，0 条 inline thread。它要求四件事，我在当前 head 上逐条核对：

「去掉 workflow 文案改动与那条互斥断言」—— 已落实。 当前 diff 完全不包含 qwen-code-pr-review.yml，只有 .size-baseline、workspace-skills-status.ts 与其测试三个文件。该 review 指出的与 main（#11912 809aaa5e0eb3）冲突的那一行改写、以及与其 toContain('cannot determine the cause') 互斥的 toContain('cancelled while the job was still waiting')，都已不在本 PR 内，冲突源随之消失。
「只保留那两个修正后的整数」—— 已落实，且数字与它独立核对的结果逐位相同。 .size-baseline 只改两条：ci.yml 134426 → 137297、qwen-review-runner-schedule.yml 1958 → 2518。这正是该 review 对着 origin/main 真实字节验证过的两个值（它同时给出漂移量 2871 B / 560 B 与剩余余量）。
「不要动 qwen-code-pr-review.yml 的 baseline 条目」—— 已落实。 该条目未被触碰，因此不会像它警告的那样囤下 163 B 未经审查的余量；qwen-autofix.yml 那个不准确的 467572 也没有进入本 PR。
「rebase 到 main」—— 冲突文件已退出 diff，base 为 main。

它当时还指出「这个 head 上完全没有 pull_request 事件的 CI 运行」；当前 head 已有 pull_request 侧的 Integration Tests (no-AK, No Sandbox) pass，其余仍在跑。

本轮独立扫描：未发现 Critical

.size-baseline 之外唯一的生产改动是 packages/cli/src/serve/workspace-skills-status.ts（+5/-1）。它要修的问题是「provider 用限定名去查一张按原始名做键的表」，因此关键在于两侧命名是否真的对上了。我核对了建表与查表两端：

建表端确实以 authored name 为键。 :153-191 构造 extensionSkillStates: Map<Extension, Map<string, boolean>> 时，内层键是 const name = skill.name.trim().toLowerCase()，其中 skill 来自 extension.skills（扩展清单里的原始条目）；同一份 name 同时用于清单默认值查询 extension.config.skillStates[name] 与持久化覆盖查询 extensionStore.getSkillWorkspaceOverride(snapshot, extension.id, workspaceCwd, name)。也就是说这张表从建立起就是 authored-name 键。
查表端改为用 authored name，方向正确。 :236-239 由 ?.get(skill.name.trim().toLowerCase()) 改成 ?.get(authoredSkillName(skill).trim().toLowerCase())。此处的 skill 是目录条目，其 name 是限定名，因此改动前必然查不到、enabled 为 undefined——这正是「默认禁用的技能显示为启用」的成因；改动后键与表一致。
发布出去的条目同时带上两种名字，使往返自洽。 :262-266 在 mapSkillConfigToStatus 的入参上补了 name: qualifySkillName(extension.name, skill.name) 与 authoredName: skill.name，即对外暴露限定名、同时保留原始名。下一次读取时 authoredSkillName(skill) 就能取回原始名，不会像「只存限定名」那样丢失反查能力，也不会出现二次限定。
用的是既有 helper，不是本 PR 新造的 API。 authoredSkillName 与 qualifySkillName 定义在 packages/core/src/skills/types.ts、经 packages/core/src/skills/index.ts 导出，自带 types.test.ts，并且 packages/cli/src/acp-integration/extension-skills.ts 已在使用。因此 ACP 目录与 daemon-local 工作区目录现在共用同一套命名规则，这与 PR 声称的「keeps both paths consistent」相符。
信任与 safe-mode 前置条件未被改动。 :154 的 if (workspaceTrusted && !safeMode) 仍是建表的唯一入口，safeMode 仍由 (!workspaceTrusted && !includeUntrustedSkills) || isSafeModeEnv() 决定；本次改动只发生在表已建好之后的读取与发布环节，没有放宽任何信任边界。

CI：当前 head 上 Integration Tests (no-AK, No Sandbox) pass；Lint & Static、Test (ubuntu-latest, Node 22.x)、Serve A/B 仍 pending，无失败项。按本渠道策略 pending 不单独作为卡点，我没有等待或轮询，上面结论全部来自代码核对；合入前请以这三项转绿为准，尤其 Test (ubuntu-latest)——它承载 workspace-skills-status.test.ts（+63/-29）与 PR 所述那 13 条原先失败的目录用例。

结论：历史阻塞问题已按其要求逐条落实，本轮未发现可证明的 Critical，提交 APPROVE。

main's #11933 (faded7f) landed the identical workspace skill identity fix: packages/cli/src/serve/workspace-skills-status.ts merges to the same blob on both sides, and main's workspace-skills-status.test.ts is a superset of this branch's version (this branch deleted main's `scopes grants to the owning extension` cases). Both files are therefore taken from origin/main, which leaves the two corrected .size-baseline integers as the whole diff. Co-authored-by: Qwen-Coder <[email protected]>

yiliang114 · 2026-09-15T09:25:43Z

解冲突结果：范围收敛成纯 baseline PR，请重新看一眼（你的 approve 被这次 push dismiss 了）。

冲突来源：main 的 #11933（faded7f14e，09:06）和本分支改了同一组文件，且是同一个意图的两种实现——

packages/cli/src/serve/workspace-skills-status.ts：两侧合并后是同一个 blob（db85ffed25），实现逐字节相同。
packages/cli/src/serve/workspace-skills-status.test.ts：main 的版本是本分支版本的超集（本分支相对 main 是 12+/31-，删掉了 main 的 scopes grants to the owning extension and preserves authored restrictions 三个 case，只多一条 workspace 级 bare-name 断言）。

所以两个文件都取 origin/main（blob hash 已核验 IDENTICAL，非目测），最终 diff 只剩 .size-baseline 的 2 个整数：

.github/workflows/.size-baseline | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

正是 @qwen-code-ci-bot 上一轮要求的形态（"keep just the two corrected integers … would deserve an approve on sight"）。两个数字都对着 main 的真实字节重新量过：ci.yml 137297、qwen-review-runner-schedule.yml 2518，记录值与实际值现在完全相等。

验证（merged head fc56964953，bash 4.2）：check-workflow-size.sh rc=0，只剩 main 侧既有的 qwen-autofix.yml 告警（记录 469165 / 实际 467357，属 main 欠债，本 PR 有意不动）；scripts/tests/workflow-size.test.js 214/214；.github/scripts/review-runner-schedule.test.mjs 6/6。

标题与正文已同步改成 baseline-only 的范围。

qqqys

APPROVE

核对基线：head fc56964953ccdb85780c2bb35622ba4162f0ee41（1 个文件，+2/-2，最后提交 09:22:23Z）。

说明：我在旧 head 9326ab86 上的那次 APPROVE 已因 head 变更被 DISMISSED，本条是针对当前 head 重新独立核对后的结论。

历史阻塞问题：已逐条落实

本 PR 唯一一条阻塞 review 是 qwen-code-ci-bot 于 2026-09-15T07:45:17Z 针对 17cc319e 的 CHANGES_REQUESTED；当前 0 条 review thread。它要求四件事，我在当前 head 上逐条核对，全部满足：

去掉与 main 冲突的 workflow 文案改写 —— 当前 diff 完全不含 qwen-code-pr-review.yml，只剩 .size-baseline 一个文件，冲突源消失。
去掉与之互斥的那条断言 —— 测试文件已整体退出 diff。
不要动 qwen-code-pr-review.yml 的 baseline 条目 —— 未触碰（仍是 265415）。
只保留那两个修正后的整数 —— diff 正好只改这两行。

本轮独立扫描：两个整数我对着实际字节数自行核过，均精确

我没有采信 review 或描述里给出的数字，而是在当前 head 上直接读取每个 workflow 的实际大小并与 baseline 逐项对照：

条目	baseline（本 head）	实际字节	本 PR 是否改动	结论
`ci.yml`	137297	137297	是（134426 → 137297）	精确相等
`qwen-review-runner-schedule.yml`	2518	2518	是（1958 → 2518）	精确相等
`qwen-code-pr-review.yml`	265415	265273	否	baseline 高于实际 142 B，在 slack 内，未囤积未经审查的余量
`qwen-autofix.yml`	469165	467357	否	未改动，本 PR 不引入该条目的任何新数字

两个被改动的条目都与实际字节数逐位相等，方向也是对的：把陈旧的 baseline 抬到实际值会让体积棘轮重新咬合（原值 134426 / 1958 分别低于实际 2871 B / 560 B，属于 baseline 过期），而不是把 baseline 设得高于实际去悄悄囤余量——后者才是这类改动真正的风险面，本 PR 没有踩到。未被改动的两条也确认没有因为本次改动而变得不准确。

改动范围是一个纯数据文件里的两个整数，不含任何代码、配置语义或行为变化，因此没有可报告的正确性、安全性、数据损坏或回归面。

CI：当前 head 上 Integration Tests (no-AK, No Sandbox) pass；Lint & Static、Test (ubuntu-latest, Node 22.x)、review-pr 仍 pending，无失败项。按本渠道策略 pending 不作为卡点，我没有等待或轮询。承载体积门禁的 Lint & Static 尚未出结果，但上表的数字是我直接对实际字节核出来的，比门禁结果更直接；合入前仍以它转绿为准。

结论：历史阻塞问题已逐条落实，两个整数经我独立核对精确无误，本轮未发现可证明的 Critical，提交 APPROVE。

qwen-code-review-bot

APPROVE

Verified against head fc56964953cc (1 file, +2/-2). The diff is exactly two integers in .github/workflows/.size-baseline, and both reproduce under independent measurement:

ci.yml: baseline 134426 → 137297; the file on main measures 137297 bytes today. ✓
qwen-review-runner-schedule.yml: baseline 1958 → 2518; the file on main measures 2518 bytes today. ✓

A baseline refresh should record current reality and nothing else — this does.

Historical blocker: the only CHANGES_REQUESTED on this PR was the ci-bot's 07:45 review of the old head 17cc319e, which asked for the workflow-wording changes and the mutually exclusive assertion to be dropped and the PR reduced to the two drifted entries. That is exactly the shape of the current head, so the request has been implemented rather than argued with. (Per platform rules my approval does not dismiss that review — it stays attached to the old head until the bot re-verdicts or a maintainer dismisses it.)

Red CI attribution: the failing Test (ubuntu-latest, Node 22.x) is the repo-wide workspace-skills-status.test.ts failure that came in from main — this diff touches only .size-baseline and cannot reach any vitest file. Same attribution chiga0 confirmed on #11928.

LGTM.

Dismissing as fully implemented on the current head. This review (on 17cc319) asked the PR to drop the workflow-wording changes and the mutually exclusive assertion and to reduce to the two drifted .size-baseline entries. The current head fc56964 is exactly that: two integers in .github/workflows/.size-baseline, both verified byte-for-byte against the actual workflow files on main (ci.yml=137297, qwen-review-runner-schedule.yml=2518). Nothing requested here remains outstanding.

Resolve the .github/workflows/.size-baseline conflict on ci.yml by recording the merged file's byte size (137778): main raised the same entry for the stale workflow size baselines (#11921) and this branch adds its own ci.yml steps. The merged baseline passes the check-workflow-size.sh ratchet for all 56 tracked workflow files.

qwen-code-dev-bot

APPROVE

核对基线：head fc56964953（base d313505f），净改动 1 个文件 .github/workflows/.size-baseline +2/-2。四条 required 现已全部 completed 且 success：Test (ubuntu-latest, Node 22.x)、Lint & Static (ubuntu-latest, Node 22.x)、Integration Tests (no-AK, No Sandbox)、web-shell E2E Smoke。

历史阻塞已解决：qwen-code-ci-bot 在旧 head 17cc319e 的那条 CHANGES_REQUESTED（要求 rebase + 收敛改动范围）现为 DISMISSED，且当前 diff 已收敛成只剩 baseline 两行 —— 它反对的 workflow 文案改动与那条互斥断言都不在本 PR 内。

独立核对数字：git show fc56964953:.github/workflows/ci.yml | wc -c = 137297、... | wc -c 的 qwen-review-runner-schedule.yml = 2518，与提交值逐位一致；base 上同两行分别是 134426 与 1958。两个 workflow 本体在 base 与 head 之间字节一致，本 PR 未触碰 qwen-code-pr-review.yml、qwen-autofix.yml 等其它条目。

如实说明两点：这条 Approve 是合并后补记的 —— 该 PR 已于 10:05:53Z 合入，而 Test 档的重跑到 10:31:33Z 才 success（合入前那次红在 packages/cli/src/ui/use-box-metrics-loop-guard.test.tsx，Maximum update depth exceeded 出自 ink 自身的 use-box-metrics.ts:123；本 PR 净改动只是 manifest 两行，同一 base 的其它 PR 前后脚为绿，所以是用例抖动而非本 PR 引入，重跑即转绿）。其次，这两行是把记录值改回实测值的例行维护：按 check-workflow-size.sh 的棘轮规则（GROWTH_ALLOWANCE=4096）复算，57 个 workflow 文件配 57 条条目，用 base 的旧 manifest 也不构成违例，本 PR 未抬高 GATE_BYTES=470000，也没有囤积未审余量。

yiliang114 mentioned this pull request Sep 15, 2026

ci(review): switch online hk1 and hk2 runners between review and CI twice daily #11855

Merged

yiliang114 and others added 2 commits September 15, 2026 15:51

yiliang114 changed the title ~~fix(ci): stop the review queue-expiry body naming a cause it cannot observe~~ ci: re-record two stale .size-baseline entries Sep 15, 2026

Merge remote-tracking branch 'origin/main' into codex/pr11921-skills-fix

d3f74d0

fix(serve): preserve extension skill identity and enablement

9326ab8

Co-authored-by: Qwen-Coder <[email protected]>

yiliang114 changed the title ~~ci: re-record two stale .size-baseline entries~~ fix(serve): restore extension skill state and refresh CI size baselines Sep 15, 2026

qqqys previously approved these changes Sep 15, 2026

View reviewed changes

yiliang114 dismissed qqqys’s stale review via fc56964 September 15, 2026 09:22

yiliang114 requested a review from qqqys September 15, 2026 09:23

yiliang114 changed the title ~~fix(serve): restore extension skill state and refresh CI size baselines~~ ci: refresh two stale workflow size baselines (ci.yml, review-runner-schedule) Sep 15, 2026

yiliang114 enabled auto-merge September 15, 2026 09:29

qqqys approved these changes Sep 15, 2026

View reviewed changes

qwen-code-review-bot approved these changes Sep 15, 2026

View reviewed changes

yiliang114 added this pull request to the merge queue Sep 15, 2026

Merged via the queue into main with commit 12b8cbc Sep 15, 2026
69 of 71 checks passed

qwen-code-dev-bot approved these changes Sep 15, 2026

View reviewed changes

github-actions Bot added the skip-changelog-auto Automatically exclude internal CI changes from release notes label Sep 16, 2026

Navigation Menu

Repository navigation

ci: refresh two stale workflow size baselines (ci.yml, review-runner-schedule) - #11921

ci: refresh two stale workflow size baselines (ci.yml, review-runner-schedule)#11921
yiliang114 merged 6 commits into
mainfrom
fix/review-fallback-cause-and-size-baseline

yiliang114 commented Sep 15, 2026 •

edited

Loading

Uh oh!

yiliang114 commented Sep 15, 2026

Uh oh!

yiliang114 commented Sep 15, 2026

Uh oh!

yiliang114 commented Sep 15, 2026 •

edited

Loading

Uh oh!

yiliang114 commented Sep 15, 2026

Uh oh!

yiliang114 commented Sep 15, 2026

Uh oh!

qqqys left a comment

Uh oh!

yiliang114 commented Sep 15, 2026

Uh oh!

qqqys left a comment

Uh oh!

qwen-code-review-bot left a comment

Uh oh!

Uh oh!

qwen-code-dev-bot left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

yiliang114 commented Sep 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What this PR does

Why it's needed

Reviewer Test Plan

How to verify

Evidence (Before & After)

Tested on

Risk & Scope

Linked Issues

Uh oh!

yiliang114 commented Sep 15, 2026

Uh oh!

yiliang114 commented Sep 15, 2026

Uh oh!

yiliang114 commented Sep 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yiliang114 commented Sep 15, 2026

Uh oh!

yiliang114 commented Sep 15, 2026

Uh oh!

qqqys left a comment

Choose a reason for hiding this comment

APPROVE

历史阻塞问题：已按该 review 的要求逐条落实

本轮独立扫描：未发现 Critical

Uh oh!

yiliang114 commented Sep 15, 2026

Uh oh!

qqqys left a comment

Choose a reason for hiding this comment

APPROVE

历史阻塞问题：已逐条落实

本轮独立扫描：两个整数我对着实际字节数自行核过，均精确

Uh oh!

qwen-code-review-bot left a comment

Choose a reason for hiding this comment

APPROVE

Uh oh!

Uh oh!

qwen-code-dev-bot left a comment

Choose a reason for hiding this comment

APPROVE

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

yiliang114 commented Sep 15, 2026 •

edited

Loading

yiliang114 commented Sep 15, 2026 •

edited

Loading