ci: refresh two stale workflow size baselines (ci.yml, review-runner-schedule) - #11921
Conversation
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 <qwen-coder@alibabacloud.com>
|
|
|
Second pass at Template looks good ✓ — all nine headings plus the Chinese mirror. Problem: observed and measurable, not argued. This checkout sits exactly on
Both equal the values this PR writes, to the byte. Your wider survey holds too — I recomputed all 57 entries and get your 28 over / 10 under, and your top five over-drifts are right exactly ( The honest version of "does this problem exist", since it is the question worth pushing on here: nothing is red today. No entry on main is past Direction: aligned, and narrowly so. This is the gate asking for its own data to be corrected, so there is no product surface to weigh and no mission question to ask. CHANGELOG: no direct reference, and none expected for a CI data manifest. Size: not applicable. The only changed path is Approach: minimal, and the reduction from the last round is the right call. Dropping the wording half that #11912 landed independently, and leaving One genuine scope question, non-blocking: the two entries you picked are not the two with the least headroom. Risk: no elevated risk signals — the changed path matches none of the revert-correlated high-risk patterns. Moving on to code review. 🔍 中文说明第二轮审查，head 为 模板完整 ✓ —— 九个必需标题加中文镜像都在。 问题： 已观测且可度量，不是靠论证。本地检出正好停在
两者都与本 PR 写入的数值逐字节相符。你更大范围的统计也成立——我重算了全部 57 条，得到你说的 28 条偏高 / 10 条偏低，超出最多的五条也完全准确（ 关于「问题是否真的存在」，说句实在话，这也是这里最该追问的一点：今天没有任何东西是红的。 main 上没有一条超过 方向： 对齐，而且范围很窄。这是门禁在要求修正它自己的数据，因此没有产品面可权衡，也没有使命问题可问。CHANGELOG：无直接引用，对一个 CI 数据清单也不该有。 规模： 不适用。唯一改动的路径是 方案： 最小化，而上一轮之后的收敛正是对的。去掉已被 #11912 独立落地的文案那一半、并把 一个真实的范围问题，非阻塞：你挑的这两条并不是余量最少的两条。 风险： 无升级风险信号——改动路径不匹配任何与 revert 相关的高风险模式。 进入代码审查 🔍 — Qwen Code · qwen3.8-max-2026-09-02 Reviewed at |
Code reviewIndependent proposal first, written from the title and "Why it's needed" before I opened the diff: given "two What I checked beyond the arithmetic: Neither consumer hardcodes a number, so nothing goes stale outside the file. The vitest mirror parses the baseline at runtime and this change can only relax it. It builds its map from the file, then asserts The diff is exactly two integers. Alphabetical position preserved ( Re-recording cannot launder growth. That is the real worry with raising a baseline — that it banks unreviewed slack. It does not here: both new values equal the files' actual current bytes to the byte, so the ratchet restarts at zero drift rather than absorbing extra room, and from this point any No critical findings and no AGENTS.md violations. The single thing I would change is prose in the description, not code — the Test evidenceThis is an unattended CI run, so per the gate's rules I built nothing, ran nothing, and executed nothing from this PR's tree — no Two checks on this head were still in flight when I fetched, so they are listed as pending rather than guessed at — the unit suite runs long here and the gate does not poll. The Final CI results for
One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。 Nothing is red, so there is no failing-job log to excerpt. Of the six workflow runs on this head, one is Not verified, and why:
Real-scenario testing: N/A. No user-visible surface and no runtime behaviour — two integers in a CI data manifest, consumed by a bash gate and its vitest mirror, neither platform-specific. No sandboxed lane applies either: there is no runtime behaviour to A/B and no TUI to drive, and the claim under review is two byte counts, which are checkable exactly rather than probabilistically. 中文说明代码审查先写独立方案，只看标题和「原因」一节、不看 diff：既然「main 上有两条 算术之外我核对的内容： 两个消费方都没有硬编码数值，因此除该文件本身外没有任何东西会变陈旧。 vitest 镜像在运行时解析 baseline，而本改动只会让它更宽松。 它从文件构建映射，然后逐 workflow 断言 diff 就是两个整数。 字母序位置保持（ 重记不会为增长「洗白」。 这是抬高 baseline 真正值得担心的地方——怕它囤下未经审查的余量。这里不会：两个新值都与文件当前真实字节数逐字节相等，所以棘轮是从零漂移重新起算，而不是吸收额外空间；此后 无 Critical，也无违反 AGENTS.md 之处。我唯一想改的是描述里的文字而非代码——即 Stage 1 提出的 测试证据这是无人值守的 CI 运行，因此按门禁规则我没有构建、没有运行、也没有执行本 PR 树里的任何东西——没跑 我取数时该 head 上有两个检查仍在运行，所以它们被列为 pending 而不是被猜测结果——本仓单测跑得久，而门禁不做轮询。CI 落定后 表格区域之外补充说明：没有任何检查是红的，因此没有失败 job 日志可摘。该 head 上六个 workflow run 中，一个是 未验证项及原因：
真实场景测试：N/A。没有用户可见界面，也没有运行时行为——一个 CI 数据清单里的两个整数，消费方是一个 bash 门禁和它的 vitest 镜像，两者都与平台无关。沙箱通道同样不适用：没有可做 A/B 的运行时行为，也没有可驱动的 TUI，而本次审查的主张是两个字节数，它们可以被精确核对，而不是概率性地核对。 — Qwen Code · qwen3.8-max-2026-09-02 Reviewed at |
|
Confidence: 4/5 — every number in this PR reproduced exactly under independent measurement and the diff is two integers; the one reservation is prose, not code. Back to my Stage 2 independent proposal: it matched this PR, including the decision to leave the gate script alone. Normally that is the strongest signal I get that a change is right, and unlike the last round — where matching my proposal was evidence against the PR, because The questions I ask myself before approving: Did I verify the problem actually exists? Yes, and it is where I pushed hardest, because on the surface this PR fixes nothing that is currently failing — Is every change in the diff necessary? Yes. Two integers, both re-recorded onto values I independently confirmed equal the files' real sizes. The restraint is the good part: leaving Would I curse this in six months? No, I'd thank it. It converts untracked drift into a reviewed line, which is the file's entire stated purpose, and it launders nothing — the ratchet restarts at zero drift instead of banking slack. Am I approving because I ran out of reasons to say no? No. My one reservation is genuinely non-blocking and I have named it, and the re-run rule is explicit that a scope-rationale question is not grounds to defer. Verdict: approve. Two procedural notes so the interim state is not confusing:
中文说明Confidence: 4/5 —— 本 PR 里每一个数字在独立测量下都精确复现，diff 就是两个整数；唯一的保留意见是文字层面的，不是代码层面的。 回到我 Stage 2 的独立方案：它与本 PR 一致，包括「不动门禁脚本」这个决定。通常这是我能拿到的、说明一个改动正确的最强信号；而与上一轮不同的是——上一轮「与我的方案一致」恰恰是反对本 PR 的证据，因为 我在 approve 之前问自己的问题： 我是否验证了问题真的存在？ 是，而且这是我推得最狠的一点，因为表面上本 PR 修的并不是任何当前正在失败的东西——今天 diff 里每一处改动都必要吗？ 必要。两个整数，重记到的数值我都独立确认过等于文件真实大小。克制才是这个 PR 好的地方：不动 六个月后我会骂这个改动吗？ 不会，我会感谢它。它把无人跟踪的漂移变成一行经过审查的记录，而这正是该文件声明的全部目的；它也没有洗白任何东西——棘轮是从零漂移重新起算，而不是囤下余量。 我是不是因为说不出反对理由才 approve？ 不是。我唯一的保留意见确实是非阻塞的，而且我已经点名了；re-run 规则也明确写着，范围理由类的问题不构成 defer 的依据。 结论：approve。 两点程序性说明，以免中间状态造成困惑：
— Qwen Code · qwen3.8-max-2026-09-02 Reviewed at |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Needs a rebase and a reduction — the detail is in my review notes above. 🙏
The wording fix this PR exists to make is already on main: #11912 (809aaa5e0eb3) rewrote the identical never_started body line at 07:24:21Z, 23 seconds before this PR was opened, and added its own assertions on the same axis (not.toContain('24-hour queue limit'), toContain('cannot determine the cause'), not.toContain('queue expired')). origin/main's copy of the workflow now has zero occurrences of 24-hour. Both sides rewrote line 3301 from a common base, so the branch is diverged and the merge conflicts rather than resolving.
The new toContain('cancelled while the job was still waiting') is also mutually exclusive with main's toContain('cannot determine the cause'), not redundant with it — no single body satisfies both.
The .size-baseline half is real and I verified it against origin/main's actual bytes rather than the description: ci.yml 137297 (recorded 134426, drift 2871 B, 1225 B of headroom left) and qwen-review-runner-schedule.yml 2518 (recorded 1958, drift 560 B, 3536 B left). Both derived figures check out exactly. Two other numbers did not survive #11912: qwen-code-pr-review.yml at 265436 prices in the wording edit and would bank 163 B of unreviewed slack once it drops out (main is 265273 against a recorded 265415 — 142 B under, inside SLACK_BYTES, so nothing is owed), and qwen-autofix.yml's actual is 467357, not 467572.
Suggested shape: rebase onto main, drop the body edit and that one assertion, leave the qwen-code-pr-review.yml baseline entry alone, and keep just the two corrected integers. That is the one-line baseline PR check-workflow-size.sh's own stale-baseline warning asks for, and it would deserve an approve on sight.
Also worth knowing: no pull_request-event CI ran on this head at all — the only runs are pull_request_target bot orchestration — so the quoted vitest / prettier / eslint output is your claim, not something the gate could corroborate. It did not affect this verdict; the findings above come from reading main's bytes and #11912's patch.
中文说明
需要 rebase 并瘦身——细节在上面的审查记录里。🙏
本 PR 赖以存在的文案修复已经在 main 上了：#11912（809aaa5e0eb3）在 07:24:21Z 改写了完全相同的那一行 never_started 文案，比本 PR 的创建时间早 23 秒，并在同一维度上补了自己的断言（not.toContain('24-hour queue limit')、toContain('cannot determine the cause')、not.toContain('queue expired')）。origin/main 上该 workflow 现在完全不含 24-hour。双方都从同一 base 改写了 3301 行，因此分支状态为 diverged，合并会冲突而不是自动解决。
新增的 toContain('cancelled while the job was still waiting') 与 main 的 toContain('cannot determine the cause') 也是互斥而非冗余——没有任何一个文案能同时满足两者。
.size-baseline 那一半是真的，我是对着 origin/main 的真实字节数核对的，而不是采信描述：ci.yml 137297（记录 134426，漂移 2871 B，仅剩 1225 B 余量）、qwen-review-runner-schedule.yml 2518（记录 1958，漂移 560 B，剩 3536 B）。两个推导数字都完全准确。另外两个数字没能活过 #11912：qwen-code-pr-review.yml 的 265436 计价了那次文案改动，改动退出后它会囤下 163 B 未经审查的余量（main 为 265273 对记录 265415，即低了 142 B，在 SLACK_BYTES 之内，不欠任何回收）；qwen-autofix.yml 的实际大小是 467357 而非 467572。
建议形态： rebase 到 main，去掉文案改动和那一条断言，不要动 qwen-code-pr-review.yml 的 baseline 条目，只保留那两个修正后的整数。那正是 check-workflow-size.sh 自己的 stale-baseline 告警所要求的单行 baseline PR，看到就可以直接 approve。
另外值得知道：这个 head 上完全没有 pull_request 事件的 CI 运行——只有 pull_request_target 的机器人编排——所以引用的 vitest / prettier / eslint 输出是你的说法，门禁无法佐证。这没有影响本次结论；上面的发现来自阅读 main 的字节和 #11912 的 patch。
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 <qwen-coder@alibabacloud.com>
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 <qwen-coder@alibabacloud.com>
yiliang114
changed the title
|
Reduced to the suggested shape at
Two corrections to the review, neither of which changes the outcome:
On CI: One follow-up worth flagging, explicitly not for this PR: 中文已按建议形态瘦身到 两处更正，都不影响结论：
CI 方面：本 head 上 另提一个明确不属于本 PR 的后续： |
|
@qwen-code /triage |
|
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: 64 passed · 0 failed · 64 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 检查。 脚本断言：64 通过 · 0 失败 · 64 总计 抖动门：不适用 — no runnable changed test files (0 out-of-scope file(s) noted in the log) Verification reportVerification report — PR #11921
|
| cell | tree | oracle (real code, no stubs) | result |
|---|---|---|---|
| A1 base, today | tmp/base-tree @ 3a093ae3 |
.github/scripts/check-workflow-size.sh exit + full stdout, WORKFLOW_SIZE_BASE_SHA=HEAD |
exit 0, ✅ … within 4096 bytes of its recorded baseline |
| A1 head, today | tmp/head-tree @ b297b5cf |
same | exit 0, stdout byte-identical to base (assertion A1-identical) |
| A2 base +N | base + N bytes appended to ci.yml |
gate exit | passes N≤1225, hard-fails from N=1226 (grew to 138523 bytes, 4097 over its recorded 134426) |
| A2 head +N | head + same N | gate exit | passes N≤4096, hard-fails from N=4097 (… 4097 over its recorded 137297) |
| A2 flip | both | count of probed N in {0,500,1225,1226,2000,2871,4096,4097,5000} where base=exit 1 and head=exit 0 | 4/9 flip |
| A3 base/head +N | both, on qwen-review-runner-schedule.yml |
gate exit | base fails from 3537, head from 4097; 2/5 flip |
| A4 | both, restored | gate stdout | no new ::warning, no new SLACK_BYTES reclamation, warning count 1==1 (the pre-existing qwen-autofix.yml proximity warning) |
Bisected through the real script, not computed from the constants: base threshold 1226, head threshold 4097, window 2871 = exactly the re-recorded drift (A2-window). The second entry's window is 3537→4097 = 560, its drift.
The vitest mirror, which is the only ratchet enforcer on the merge-queue lanes, flips identically (02-mirror-mutation-matrix-non-discriminating.png):
| arm | mutation | mirror exit | Tests |
|---|---|---|---|
| M1 | base untouched | 0 | 214 passed (214) |
| M2 | head untouched | 0 | 214 passed (214) |
| M3 | head with the 2 integers reverted | 0 | 214 passed (214) |
| M4 | base + ci.yml grown 2000 B (positive control) |
1 | 1 failed | 213 passed — … > .github/workflows/ci.yml is within its baseline allowance, AssertionError: … is 4871 bytes over its recorded 134426 …: expected false to be true |
| M5 | head + same 2000 B | 0 | 214 passed (214) |
M4 proves the harness can redden the mirror in the mutated file's own test, so M3's green is a measured absence of coverage, not a dead harness.
Census (03-census-every-body-number-re-measured.png, claims.mjs, 24/24): every quantitative claim in the body re-measured exact — base 28 over / 10 under / 0 past the 4096 allowance; top-5 over-drifts qwen-triage.yml:3369/727, serve-ab.yml:2883/1213, ci.yml:2871/1225, live-host-release.yml:2794/1302, security-checks.yml:2322/1774 match name/overage/headroom; head 26 over / 21 exact / 10 under; the two deliberately-untouched entries qwen-code-pr-review.yml 265273/265415 (−142) and qwen-autofix.yml 467357/469165 (−1808) both inside SLACK_BYTES=20000; all 57 entries well-formed, no missing file, none above the 470000 gate, on both arms.
Corrections to the description
These are statements of fact with their evidence, not requests to change the code.
- "Recording a larger number tightens the ratchet" / "Main risk or tradeoff: none functional" understates the tradeoff. Measured in A2: ci.yml's absolute hard-fail threshold rises from 138,522 to 141,393 bytes (+2,871) and
qwen-review-runner-schedule.yml's from 6,054 to 6,614 (+560). In absolute terms the ratchet allows more unremarked growth, not less — 2,871 bytes of main-side growth that no PR ever accounted for are hereby baked into the baseline. That is the mechanism's designed and documented remedy (.size-baselineheader: "if the growth is real, bump the number and say why in the PR"; the gate's stale message prescribes exactly this one-line PR), so it is an accepted tradeoff — but it is a tradeoff, and the sentence reads as if the gate got stricter. - The 214-test vitest gate the body cites cannot fail for this diff. M3: with both integers reverted the suite still reports
214 passed (214). The gate is real and healthy, but it is not evidence for this change; the discriminating oracles are the census above and the headroom A/B. The body's own first verification block (theactual=/recorded=loop) is the correct oracle and it checks out exactly. - "The script already downgrades both to a warning when the file is byte-identical to the PR's base" never fired for these two entries. The warning arm requires
size > recorded + 4096; these were 2871/560 over. Measured: base emits no stale-baseline warning at all (A1-no-stale-warn), and gate stdout is byte-identical across arms. The real motivation — headroom for the next PR — is valid and measured; the "it warns and says what it wants" framing describes a state that did not exist for these entries.
Findings and observations (none blocking)
- Low / scope observation — the tightest ratchet entry on
mainis still live, and it is not one of these two.qwen-triage.ymlis 3,369 bytes over with 727 bytes of headroom — tighter than the 1,225ci.ymlhad, on the most-edited workflow in the repo. The next PR that touches it and grows it past 727 bytes hard-fails and is told to account for 3,369 bytes of drift it did not cause: exactly the red-wall class this PR exists to remove. The body declares this out of scope explicitly and the reasoning (38 integers would bury the two) is sound; flagging it as the obvious next one-line PR. - Low / pre-existing —
qwen-autofix.ymlis 2,643 bytes under the 470,000 gate (467,357 actual). It is the sole::warningin every gate run on both arms ("approaching the gate"), and it is the file that already killed the autofix loop once on 2026-08-19. Unrelated to this PR; noting it because the census surfaced it and the margin is the smallest in the repo. - Low / pre-existing, untouched file — the root-guard is applied inconsistently in
scripts/tests/qwen-pr-review-workflow.test.js. The two health-probe cases the body discloses (repairs a single unwritable directory…line 3906,fails fast when repair is impossibleline 3917) build their fixture withchmod 0o555and carry no root guard, so as uid 0 they fail; their siblings on the same chmod hazard (lines 3445/3475) carryskipIf(process.getuid?.() === 0)and skip. The body's disclosure is accurate and its mechanism is confirmed (F5–F7, including the file's ownCAP_DAC_OVERRIDEcomment); the inconsistency is pre-existing and this PR touches neither file.
Not covered
- Per-commit attribution. The metadata snapshot lists 3 commits (
17cc319e,ee443839,b297b5cf); the checkout is shallow (depth 2, grafted) andgit rev-list HEAD^1..HEAD^2returns onlyb297b5cf— the shallow-boundary trap where--countyields a plausible1instead of erroring. The aggregateHEAD^1..HEADdiff is what was verified; it is one file. The dropped half is confirmed dropped:qwen-code-pr-review.ymlandscripts/tests/qwen-pr-review-workflow.test.jsare byte-identical to base, and the merge commit's.size-baselineis byte-identical to the PR head's. #11855's actual diff (the claimed origin of the 560-byte drift): no network in this container. Corroborated only indirectly — the "main-fence" comment block plus itsif:line in the current file is 617 bytes, the same order as the 560-byte drift and slightly over it, so ~57 bytes elsewhere shrank in the same change. The attribution is plausible, not proven.- CI's real runners. This container runs as uid 1000 (non-root), which is why the body's disclosed
2 failed | 48 passed | 215 skippeddid not reproduce here; both arms give50 passed | 215 skipped (265), identical (F2/F3), so the difference is environmental and proven by an A/A control rather than assumed. - Staleness at merge time. The values are exact as of base
3a093ae3. Ifmaingrowsci.ymlfurther before this merges, the entry goes stale again but degrades gracefully (drift within the allowance → no failure); only a >20,000-byte shrink would trip a new warning. - Not run: repo-wide test suites,
npm run build/typecheck(the diff is two integers in a non-compiled manifest; nothing imports it), yamllint/eslint (no.yml/.ts/.jsfile differs from base — confirmed bygit diff --name-status HEAD^1..HEAD), and theterminal-capturebrowser pipeline (no TUI surface; the flat-output capture helper was used instead).
Methodology
Environment: the CI verify container (node:22-bookworm, uid 1000), merge-ref checkout with HEAD^1=base tip and HEAD^2=PR head; npm ci and npm run build had already completed at HEAD. Two scratch worktrees under tmp/ (base-tree @ 3a093ae3, head-tree @ b297b5cf, recreated with git worktree add --detach tmp/base-tree HEAD^1 && git worktree add --detach tmp/head-tree HEAD^2 and removed after the cells were captured) served as the A/B arms; each gate run used cwd=<arm> with WORKFLOW_SIZE_BASE_SHA=HEAD so a mutated file counts as "changed by the PR", taking the gate's strict arm exactly as CI would. No internal-workspace symlink confound exists here (the gate reads relative paths from its own cwd), and readlink -f confirmed each arm resolves its own .size-baseline. Growth probes appended # xxx… comment lines — byte-faithful for a gate whose only observation is wc -c, and inert to the mirror's regexes — and every arm was restored with git checkout -- afterwards (verified git status --porcelain empty on all three trees). Harnesses: ab-headroom.mjs (24 assertions: diff shape, A/A on today's tree, threshold bisect through the real script on both files, regression checks), mirror-ab.mjs (8: the 5-cell vitest matrix plus the reverse-mutation and positive control), claims.mjs (24: every body number against both trees), fallback-aa.mjs (8: the disclosed pre-existing failure as an A/A with its mechanism pinned statically). Raw logs in logs/, images in evidence/ produced by scripts/verify-capture.mjs. Total 64 scripted assertions, 0 unexpected failures; the base-arm reds in A2/A3/M4 are expected control outcomes and are counted as passes by construction.
Flakiness gate log
verdict: n/a
summary: no runnable changed test files (0 out-of-scope file(s) noted in the log)
Evidence images
Harness scripts and raw logs are in the workflow run artifacts (7-day retention).
— Qwen Code · sandboxed verification
|
Triage re-run completed without a new review.
The stage comments above were updated with the latest result. View workflow run. 上方各阶段评论已更新为最新结果。查看工作流运行。 |
|
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. |
|
CI attribution for the red The failure is a single test file,
This PR cannot reach that file. Its whole diff is two integers in
Suggested handling: re-run once
失败只有一个测试文件
本 PR 碰不到那个文件。它的全部 diff 是 建议处理：等 |
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
yiliang114
changed the title
|
CI attribution on head This PR's diff against main is two integers in What actually failed — run 34944785050, job The 13 assertions diff against bundled/extension Skills the provider now enumerates ( Timeline:
Corroboration: PRs whose heads predate the 07:30Z merge are green on the same job — e.g. #11821 at Not fixing it here. The repair belongs in #11933; patching Separately, on the |
qqqys
left a comment
qqqys
left a comment
There was a problem hiding this comment.
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（#11912809aaa5e0eb3）冲突的那一行改写、以及与其toContain('cannot determine the cause')互斥的toContain('cancelled while the job was still waiting')，都已不在本 PR 内，冲突源随之消失。 - 「只保留那两个修正后的整数」—— 已落实，且数字与它独立核对的结果逐位相同。
.size-baseline只改两条：ci.yml134426 → 137297、qwen-review-runner-schedule.yml1958 → 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。
🩺 serve daemon A/BBuilt the PR base vs this PR head ✅ No response changes against the PR base across 12 scenario(s). — Qwen Code · serve A/B |
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 <qwen-coder@alibabacloud.com>
yiliang114
changed the title
|
解冲突结果：范围收敛成纯 baseline PR，请重新看一眼（你的 approve 被这次 push dismiss 了）。 冲突来源：main 的 #11933（
所以两个文件都取 正是 @qwen-code-ci-bot 上一轮要求的形态（"keep just the two corrected integers … would deserve an approve on sight"）。两个数字都对着 main 的真实字节重新量过： 验证（merged head 标题与正文已同步改成 baseline-only 的范围。 |
qqqys
left a comment
qqqys
left a comment
There was a problem hiding this comment.
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
left a comment
qwen-code-review-bot
left a comment
There was a problem hiding this comment.
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: baseline134426→137297; the file onmainmeasures 137297 bytes today. ✓qwen-review-runner-schedule.yml: baseline1958→2518; the file onmainmeasures 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
left a comment
qwen-code-dev-bot
left a comment
There was a problem hiding this comment.
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，也没有囤积未审余量。
5 participants
What this PR does
Corrects two stale entries in
.github/workflows/.size-baselineto the sizes those workflows actually have onmain: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.ymlneeds 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.tsmerges to the same blob on both sides, andmain'sworkspace-skills-status.test.tsis a superset of this branch's version (this branch had droppedmain'sscopes grants to the owning extension and preserves authored restrictionscases). Both files were taken fromorigin/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:Both must match the values this PR records, and
bash .github/scripts/check-workflow-size.shmust exit 0.Evidence (Before & After)
Before:
check-workflow-size.shreported both files as above their recorded baselines. After (merged headfc56964953, bash 4.2):The remaining
qwen-autofix.ymlwarning is pre-existing debt onmain(recorded 469165 vs actual 467357) and is deliberately left out of this PR.Tests:
scripts/tests/workflow-size.test.js214/214 passed;.github/scripts/review-runner-schedule.test.mjs6/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.ymlat 265415 vs actual 265273 — insideSLACK_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).