Autofix report for #13479 — Release Failed for v0.25.0-nightly.20261005.69d5db2ff2

Diagnosis

The failing job was Integration Tests (Docker) on self-hosted runner ecs-qwen-hk4-26. The job's GitHub annotation shows the runner worker itself crashed:

System.IO.IOException: No space left on device : '/home/github-runner/actions-runner-26/_diag/Worker_20261005-211802-utc.log'

Timeline reconstructed from the public API: the job-start Disk floor gate (self-hosted) passed at 21:18:52Z (≥ 2 GiB free), the Run Docker Integration Tests step started at 21:22:37Z, and the runner died ~24 minutes into it (job ended 21:46:51Z) — mid-step, with no step conclusion and without even the always() container-cleanup step running. Every other release lane, including Integration Tests (No Sandbox) running the same tests on the same pool, passed.

Root cause: the docker lane's heavy step — the sandbox image build, a full monorepo install + bundle inside a two-stage Dockerfile — runs long after the job-start disk floor gate, on a shared pool whose docker daemon store persists across jobs. The lane's pre-build cleanup only pruned labelled images older than 24h; BuildKit's intermediate install/build layers (the build's largest disk consumer) and dangling images were outside its reach. The daily host sweep (qwen-docker-cleanup.timer, 02:30 UTC) bounds the store, but the release builds at ~21:20 UTC, at the peak of the day's accumulation. This is the same ENOSPC class as #10035 (which added the job-start gates via #10394/#11972/#12769) — tonight's run shows the gate's coverage ends before the docker lane's heaviest step begins.

No product code defect is involved; the previous four nightly releases passed this lane, and the two September release failures were ordinary test failures with completed steps, a different signature.

Fix

One focused change in .github/scripts/run-release-docker-integration.sh, inside the existing image-missing (i.e. about-to-build) branch, after the lock acquisition and the existing labelled-image prune:

1. docker builder prune --all --force --filter 'until=24h' — reclaim BuildKit cache, which image pruning cannot touch, using the same age filter as the daily host sweep. Warn-only on failure, like the existing prune.
2. A pre-build disk floor gate on the Docker data root (docker info --format '{{.DockerRootDir}}'), reusing the existing check-disk-floor.sh with an 8 GiB floor (build-sized: cold builder stage + final image, with margin; overridable via DISK_FLOOR_MIN_FREE_KB). A breached floor now fails the job fast with a legible ::error:: — the established "a re-run lands on an instance with headroom" pattern from fix(release): gate pool-routed validation jobs on a disk floor #11972 — instead of the runner worker crashing mid-build and killing the cleanup steps with it.

Both pieces are scoped to the build branch: when the image already exists (built by a concurrent run at the same revision) nothing changes. Because release workflow scripts are checked out from github.workflow_sha, the fix rides main and applies to the next nightly automatically.

Coverage: four new tests in scripts/tests/release-workflow.test.js — a text/ordering pin, plus three execution tests that drive the real script against stub docker/npm/npx/git/node binaries: (a) build happens only after image prune → cache prune → floor gate, in that order; (b) a tripped gate stops the build and the tests; (c) an already-present image skips reclaim and gate entirely.

Environment note

This runner has no Docker daemon, so the release docker lane itself could not be re-run locally; verification is by the stub-harness execution tests above, shellcheck, and the full scripts suite. The mutation probes below confirm each new guard has a failing test without it.

Verification

• bash -n .github/scripts/run-release-docker-integration.sh — passed.
• node scripts/lint.js --shellcheck — could not run in this sandbox: the lane stages its file list with file --mime-type, and the file binary is not installed here. Ran the lane's pinned ShellCheck 0.11.0 (downloaded from the URL in scripts/lint.js) directly instead: clean on the changed script and on check-disk-floor.sh.
• npx vitest run --config ./scripts/tests/vitest.config.ts release-workflow — 71 passed (67 pre-existing + 4 new).
• npx vitest run --config ./scripts/tests/vitest.config.ts (full scripts suite) — 2800 passed, 12 failed in verify-capture.test.js (terminal rendering) and web-shell-publish-artifacts.test.js (npm pack output format); stashing this change and re-running the base tree fails the identical 12, so they are pre-existing environment issues unrelated to this change.
• Mutation probes (remove guard → expect red → restore → green): (1) gate block deleted → 3 tests failed; (2) gate degraded to warn-only || true → gate-failure test failed; (3) docker builder prune line deleted → 2 tests failed. All restored and re-verified green.
• node --test .github/scripts/check-disk-floor.test.mjs .github/scripts/ecs-runner/qwen-docker-cleanup.test.mjs — 10/10 passed.
• npm run build — passed.
• npm run typecheck — passed.
• npm run lint — passed.
• Not run: the docker integration lane itself (no Docker daemon available in this environment).

System.IO.IOException: No space left on device : '/home/github-runner/actions-runner-26/_diag/Worker_20261005-211802-utc.log'

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.25.0

✅ AutoFix round 6 finished — view run. See this round's report below.

🤖 Addressed the latest review feedback (round 1/10). What changed, and what I pushed back on: · 已处理最新评审反馈（第 1/10 轮）。改动内容与我反驳保留之处如下：

Autofix round — PR #13481 (issue #13479)

Commit 6aebce3d85 — fix(release): harden the docker disk reclaim and data-root floor gate (#13479). All 8 round-1 findings (every one a Suggestion from the automated reviewer) were verified against the code and implemented; nothing was declined, deferred, or escalated. Changes stayed inside the PR's footprint: .github/scripts/run-release-docker-integration.sh and scripts/tests/release-workflow.test.js.

Dispositions

• R1-7 (rc:4190525808) — dangling images unreclaimed → implemented. Added the sweep-shaped docker image prune --force --filter 'until=24h' (warn-only, same shape as ecs-runner/qwen-docker-cleanup.sh:44) between the labelled prune and the builder prune, with a comment on why the labelled prune cannot reach that class. --no-prune on the build call was left alone, as the finding required.
• R1-2 (rc:4190525817) — unbounded prune inside the host build mutex → implemented. The builder prune is now timeout 20m docker builder prune --all --force --filter 'until=24h', keeping the || echo "::warning::…" tail. The comment now states the deliberate omission of --keep-storage (a reserve, not a quota — it would reclaim nothing on exactly the below-30 GB hosts this line exists for) and why the bound matters (the E2E lane waits only 30 minutes on the same mutex; run 33637097713).
• R1-13 (rc:4190525834) — only unscoped check-disk-floor.sh invocation repo-wide → implemented (scoped). The gate now runs self-hosted only, matching all 16 other call sites and the helper's own header, with the divergence stated in the function comment (an ephemeral hosted runner starts with an order of magnitude more free disk than the 8 GiB floor — the finding's own measurement was ~82 GiB on ubuntu-latest). Judgment call: the finding offered scope-or-document; I chose scoping because it matches the repo convention and the helper's documented purpose, and the failure mode this gate exists for (a saturated persistent pool host) does not exist on an ephemeral hosted VM. The hosted lane's behavior is now pinned by a test asserting no gate, no docker info, and no flock calls.
• R1-3 (rc:4190525842) — three silent gate-skip paths → implemented. The gate logic moved into check_docker_data_root_floor(), which warns (exit 0, build proceeds) when the helper is absent at the released ref and when the docker data root cannot be resolved or is not a readable directory. The pre-existing [ -f ] relative-to-step-cwd convention was kept, as the finding instructed.
• R1-5 (rc:4190525845) — gate samples only before the build → implemented (re-gate). The same gate runs a second time after npm run build:sandbox and before the two vitest phases, with a comment recording that run 37374675168 died in the vitest phase ~15 minutes after the build. Narrow variant: the image-present path keeps its no-gate contract, which the finding presented as the default.
• R1-8 (rc:4190525852) — stub answered any info invocation → implemented. The docker stub now answers only the exact info --format '{{.DockerRootDir}}' contract (anything else prints nothing and exits 1), and the self-hosted execution test pins expect(calls).toContain('docker info --format {{.DockerRootDir}}'). A template typo now drops the gate lines and reds the suite (probe P8 below). DISK_FLOOR_MIN_FREE_KB was not renamed.
• R1-9 (rc:4190525857) — prune failure path unpinned → implemented. New pruneFails harness option makes the stub fail builder prune only; the case asserts exit 0, the ::warning::docker build cache cleanup failed line, and that the build and both vitest runs still happen.
• R1-10 (rc:4190525862) — self-hosted lock path never executed under test → implemented. New runnerEnvironment option (default github-hosted) plus flock and timeout stubs (both absent on stock macOS, which runs this suite on merge_group). The self-hosted case asserts the full recorded order — daemon lock → coordinator lock → build mutex → labelled prune → dangling prune → cache prune → docker info → pre-build gate → build → unlock 7 → post-build gate → unlock 8 → vitest — and the gate-trip case now asserts a non-zero exit with no unlock lines past the trip (the mutant-C3 shape the finding measured as uncovered). Fd 9 is correctly never asserted unlocked.

Verification

• bash -n .github/scripts/run-release-docker-integration.sh — passed.
• npx prettier --check scripts/tests/release-workflow.test.js — passed (the .sh has no prettier parser, as before).
• npm run build — passed (exit 0).
• npm run typecheck — passed (exit 0).
• npm run lint — passed (exit 0).
• shellcheck v0.11.0 (pinned version, run directly on the script; the repo's node scripts/lint.js --shellcheck lane cannot run in this sandbox because file(1) is absent) — clean.
• npx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/release-workflow.test.js — 76 passed (baseline pre-round: 71 passed; the 3 pre-existing execution tests keep their names, 5 cases added). Re-run after the commit (which includes the pre-commit hook's prettier/eslint pass): still 76 passed, working tree clean.
• Mutation probes (each: mutate the script, re-run the suite, confirm red, restore; suite green again after restore):
  • P1 dangling image prune removed → 3 failed (caught).
  • P2 timeout 20m bound removed → 1 failed (caught).
  • P3 self-hosted scoping removed → 1 failed (caught).
  • P4 helper-absent warning removed → 1 failed (caught).
  • P5 unreadable-root warning removed → 2 failed (caught).
  • P6 post-build re-gate removed → 2 failed (caught).
  • P7 prune || echo "::warning::…" tail removed → 1 failed (caught).
  • P8 {{.DockerRootDir}} → {{.DockerRoot}} typo → 2 failed (caught).
  • P9 early exit before flock --unlock 7 (the finding's mutant C3) → 4 failed (caught).
• Pre-round check (this round's tests against the pre-round script): 6 of the changed/new tests fail pre-round — they pin the new behavior; the 3 that stay green (fails before…, skips the reclaim…, continues with a warning when the BuildKit cache prune fails) pin pre-existing behavior this round did not alter.
• Not run: integration tests after npm run bundle — the touched behavior (a release-workflow shell script and its harness) is not exercised through the bundled CLI. No settings source changed, so npm run generate:settings-schema was not needed.

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

🧵 Resolved all 8 selected review thread(s). · 已关闭全部选中的 8 条评审线程。

Re-review when you have a moment. After round 10 this bot stops and leaves the PR for a human. · 有空请复审；第 10 轮后本 bot 停止并将 PR 交给人工。

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.25.0

🤖 Addressed the latest review feedback (round 2/10). What changed, and what I pushed back on: · 已处理最新评审反馈（第 2/10 轮）。改动内容与我反驳保留之处如下：

Round summary

Both inline findings from @yiliang114's round-2 review (CHANGES_REQUESTED) are implemented in 32e8b5a. No base-branch conflict (--conflict false; no merge performed). Diff this round: 2 files, +87/−22 — inside the window's growth budget.

rc:4191354944 — unbounded daemon round-trips under the host build mutex (P3) — implemented

The two docker image prune calls and the docker info inside check_docker_data_root_floor ran while fd 7 (the exclusive host build mutex) was held, carrying no time bound; on a wedged daemon either could hold the mutex past the E2E lane's 30-minute flock --wait 1800. Applied the suggested bounds:

• timeout 20m docker image prune --all --force … (labelled prune — the reviewer noted this pre-existing call has the same exposure, so both prunes are bounded for consistency)
• timeout 20m docker image prune --force … (dangling prune)
• timeout 60 docker info --format '{{.DockerRootDir}}' inside the gate

A timeout degrades exactly like any other failure of that call: the prunes fall into their existing || echo "::warning::…" continuation, and a docker info timeout yields an empty root, which the gate already handles as warn-and-skip. The builder-prune comment's rationale sentence was generalized to cover every daemon call in the branch instead of only that prune.

Witness: the static pin test now requires the timeout 20m / timeout 60 prefixes on all three lines. Mutation probe: stripping the three prefixes fails that test; restored → green.

rc:4191354951 — gates skipped on the cached-image re-run path (P3) — implemented

Both gate calls lived inside the image-missing branch, so a re-run landing on the same still-saturated host — where the image is now cached — went straight to the vitest phase, the actual #13479 death site, ungated. The post-build gate is hoisted out of the branch to directly before the two vitest runs, so every path (cold build, cached re-run) passes the data-root gate before vitest writes container layers to that filesystem. The pre-build gate stays inside the branch: with no build there is nothing to pre-gate. The reviewer is right that this widens coverage past the PR body's original scoping, but the move is two lines, closes the re-run edge of the very incident this PR fixes, and keeps the gate count at two on the cold path.

Witness: two new stubbed-execution tests on the cached + self-hosted path — one asserts the gate runs exactly once before the first vitest invocation while the reclaim and build are skipped; one asserts a gate trip blocks vitest entirely. Mutation probe: deleting the hoisted gate call fails both new tests plus the static gate-placement pin and the cold-path ordering test; restored → green.

Verification

• bash -n .github/scripts/run-release-docker-integration.sh — passed
• npx prettier --check scripts/tests/release-workflow.test.js .github/scripts/run-release-docker-integration.sh — passed
• COREPACK_HOME=/tmp/corepack-home npx vitest run --config ./scripts/tests/vitest.config.ts release-workflow.test — 84 passed (78 in release-workflow.test.js, including the 2 new cached-path tests; 6 in cua-driver-release-workflow.test.js). COREPACK_HOME is pointed at a writable tmp dir because this sandbox denies writes to the default corepack cache; the suite itself is the repo's standard test:scripts config.
• Mutation probe A (strip the three new timeout prefixes from the script) — the static pin test failed as designed; restored, suite green
• Mutation probe B (delete the hoisted gate call) — 4 tests failed as designed (static pin, cold-path ordering, both new cached-path tests); restored, suite green
• npm run build — passed
• npm run typecheck — passed
• npm run lint — passed

Not run: ShellCheck (no binary on this runner; syntax is covered by bash -n and the stubbed execution tests — CI runs ShellCheck). The real self-hosted docker lane cannot run off the pool by definition; CI remains the final gate.

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

🧵 Resolved all 2 selected review thread(s). · 已关闭全部选中的 2 条评审线程。

Re-review when you have a moment. After round 10 this bot stops and leaves the PR for a human. · 有空请复审；第 10 轮后本 bot 停止并将 PR 交给人工。

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.25.0

🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下：

🤖 No action this round (round 3/10) — the round was dispatched by two failed checks in the review automation itself, not by anything in this PR. · 本轮无改动(第 3/10 轮)—— 触发本轮的是评审自动化自身的两个失败检查,而非本 PR 的内容。

Round summary

No new review feedback exists since the last evaluation (2026-10-06T03:50:48Z): no reviews, no inline comments, no issue-level comments. Both round-2 inline findings (rc:4191354944, rc:4191354951) were implemented in 32e8b5a and their threads were resolved last round. The only listed items are two failed checks, both in the 🧐 Qwen Pull Request Review workflow (the review automation pipeline, run 37428041959):

• review-pr — FAILURE after 28 seconds (07:18:12Z → 07:18:40Z)
• fallback-comment — FAILURE after 34 seconds (07:18:43Z → 07:19:17Z)

Why these failures are not actionable from this PR

The failing jobs never execute anything this PR changes. The PR touches exactly two files:

• .github/scripts/run-release-docker-integration.sh — invoked only by release.yml (lines 572/578); the review workflow never runs it.
• scripts/tests/release-workflow.test.js — run by the CI Test job, which is green on this head (see below).

The timing rules out a review of the diff. review-pr failed 28 seconds after start — long before checkout, dependency install, CLI build, or the review step itself could run. Its first steps are self-hosted runner health probes (directory-writability checks, workspace-ownership restore, stale-state cleanup) on the same shared self-hosted pool whose disk saturation is the subject of issue #13479. A fast failure there is an infrastructure event, not a verdict on this diff. The same workflow reviewed this PR successfully twice before on larger diffs.

fallback-comment runs on GitHub-hosted ubuntu-latest and exists only to post a comment when review-pr fails. Its only failure paths are GitHub API calls (the dedup lookup fails closed after three retries rather than risking a duplicate comment). A 34-second failure there is an API/auth transient in the automation, again unrelated to this PR's content.

Every check that does execute this PR's content is green on 32e8b5a: Lint & Static ✅, Test (ubuntu-latest, Node 22.x) ✅, Integration Tests (no-AK, No Sandbox) ✅, Desktop Shell (ubuntu-22.04) ✅, Desktop Shell (windows-2022) ✅, web-shell E2E Smoke ✅.

The boundary applies. The review-automation workflow (.github/workflows/qwen-code-pr-review.yml) is CI/verification machinery this PR is not about; autofix is not permitted to modify it, and no change to the release script or its tests could affect these two jobs anyway.

What resolves this

A maintainer re-run of the failed jobs on run 37428041959 (Actions → 🧐 Qwen Pull Request Review → Re-run failed jobs). That needs no code change; if the failures persist across re-runs, they belong to the review-automation infrastructure (runner pool health / API credentials), tracked outside this PR.

Verification

No code changed this round, so no build/test re-run was triggered; the working tree is clean and byte-identical to head 32e8b5a, the exact commit the green checks above ran against. Evidence gathered this round:

• git status --porcelain=v1 --untracked-files=all — clean; HEAD = 32e8b5a
• git diff origin/main...HEAD — re-verified both round-2 findings are implemented in the head commit (timeout bounds on the two docker image prune calls and the gate's docker info; post-build data-root gate hoisted ahead of the vitest runs so the cached-image re-run path is gated)
• Check-run metadata for run 37428041959 — per-job start/completion timestamps quoted above
• grep over .github/workflows/ — confirmed the touched script is referenced only by release.yml, never by the review workflow

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.25.0

🔀 Base updated: red check(s) [review-pr] pass on current main — merged current main via update-branch; CI will re-run.

Qwen Code review did not complete successfully. The review pipeline failed before a review could be posted. A transient error is retried automatically; if you are seeing this, retry with @qwen-code /review. See workflow logs.

🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下：

Autofix review round — no action

No code changes this round. The feedback window contained no actionable findings on the PR's code:

• Inline comments: none.
• Reviews: none.
• Issue-level comments: one — [ic:6023889269], the automated reviewer's fallback notice that the review-pr pipeline itself failed before a review could be posted (<!\-\- qwen-review-fallback -->). This is infrastructure state, not a finding on the diff: the notice says a transient error is retried automatically, and re-triggering the review (@qwen-code /review) is a GitHub-side action this round has no credentials to perform. The next evaluation cycle re-runs the review; any findings it produces will be addressed then.
• Failed checks: review-pr: FAILURE — the same review-pipeline failure above, not a build, lint, typecheck, or test failure on this branch.
• Diff growth this window: source 0 / test 0 — nothing added.

Verification

Since no files changed, the full build/typecheck/lint battery was not re-run. The PR's own focused test suite was executed against the current branch head to confirm the branch is healthy:

• npx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/release-workflow.test.js — 78/78 passed (run with COREPACK_HOME=/tmp/corepack-cache because this sandbox cannot write the default corepack cache under /home/github-runner/.cache; the warmup is environment setup, not a test result).

The branch remains exactly as the last evaluation left it, ready for the review pipeline's retry.

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.25.0

🔀 Base updated: red check(s) [review-pr] pass on current main — merged current main via update-branch; CI will re-run.

Verdict: merge-ready — 69/69 scripted assertions passed, 0 unexpected failures. Verified head 2560f56274fe27523abadf0a523d8ba6c74c9fbd.

Evidence: 01-ab-suite-head-vs-base.png · 02-mutation-matrix.png · 03-real-helper-harness.png (appended below)

Central claim and A/B

Claim under test: on the self-hosted release Docker lane, an image-missing run now prunes dangling images and BuildKit cache (both until=24h, timeout 20m-bounded) and gates the Docker data root at 8 GiB before npm run build:sandbox; a tripped gate fails fast before the build; a second gate guards the vitest phase (the actual #13479 death site) on every self-hosted run, including cached-image re-runs.

The PR's own suite stubs check-disk-floor.sh; the harness above composes the real script with the real helper (only docker/git/node/npm/npx/timeout/flock stubbed), so the env-var name, argv shape, exit-code propagation through set -euo pipefail, and the ::error:: annotation are pinned by execution. 58/58 assertions pass (41 head A–G + 13 head H–I + 4 base E).

Mutation matrix (vacuity proof, head)

Script restored and sha256-verified after every row. Zero survivors, so no adjudication needed; M4 proves the runner collects tests that pin this file.

Corrections

• PR body, "Risk & Scope"/overview: "Both behaviors are scoped to the branch that actually builds the image; when a concurrent run already built the image for the same revision, nothing changes" — and the Reviewer Test Plan's "an already-present image skips both". The pre-vitest check_docker_data_root_floor call deliberately sits outside the image-missing branch (the code comment says so, and the tests gates the cached-image re-run path… / blocks the vitest phase… pin it). On the cached-image path something does change: one data-root gate before vitest. Verified live in cells H/I with the real helper. The code and tests are correct and intentional — this is a description nit only; a one-line body edit would fix it.

Findings

None blocking. Observations, ordered:

1. Degrade paths are warn-and-skip by design (missing helper on old release refs, failed/timeout 60 docker info, non-directory root) — cell G and the PR's three warn-path tests pass. On a host with a wedged daemon the gate never fires, but that host's build fails anyway; consistent with check-disk-floor.sh's existing "letting the job proceed" philosophy. No action.
2. The gate is two-legged: the helper's inode floor (default 100000) also applies to the docker root; only the KB floor is overridden to 8 GiB. Cell D proved the inode leg trips the gate. Coherent bonus coverage — noted so reviewers know the gate is not space-only.
3. Consistency claims verified: the new prunes match the daily sweep qwen-docker-cleanup.sh (until=24h; the sweep additionally carries --keep-storage 30GB, and the PR's comment correctly explains omitting it — a reserve reclaims nothing on the saturated hosts this line exists for); the dangling-image prune already existed in e2e.yml:422 (the E2E lane keeps it; unchanged, as the PR states); the lock-protocol cross-reference to e2e.yml:419 is accurate; the nightly E2E docker legs are untouched (2-file diff).

Not covered

• Real dockerized build end-to-end (no image build executed here). Corroborated the two daemon-touching facts directly against this host's real daemon instead: docker info --format '{{.DockerRootDir}}' → /var/lib/docker, and the real helper against it → DISKFLOOR … dir[/var/lib/docker] fs[/] avail_kb[1376919168] floor_kb[8388608] free_inodes[485500488], exit 0. The "8 GiB covers a cold builder stage" sizing is accepted as the author's judgment (env-overridable via DISK_FLOOR_MIN_FREE_KB).
• Pinned ShellCheck 0.11.0: scripts/lint.js has no linux/aarch64 entry, so the pinned binary cannot run on this host. Corroboration with distro ShellCheck 0.9.0: default check set clean on both arms; with the CI's exact flags (--enable=all …) both arms fail identically on pre-existing style notes (SC2292/SC2250 across the file's [ ] idiom, SC2154 ×2) — an A/A-proven 0.9.0-vs-pinned behavior difference, not attributable to the PR (head adds notes of the same classes only, no new warning class).
• Full scripts vitest suite — the diff's blast radius is release-workflow.test.js; the targeted suite (2 files, 84 tests) is what was run, on both trees.
• Step-level logs of run 37374675168 (annotations API 404s with this token scope). Job-level facts corroborated: Integration Tests (Docker) failure, 2026-10-05 21:18→21:46 UTC, schedule run — matching the incident description.
• The daily sweep's 02:30 UTC schedule and the runner-pool capacity claims (ci: prevent transient ENOSPC on high-concurrency self-hosted runners #10035) are external to this repo.

Methodology

Local maintainer-driven round on Linux aarch64 (Orange Pi), Node 24.14, pnpm per-tree installs via scripts/setup-worktree.js. Head 2560f56274fe27523abadf0a523d8ba6c74c9fbd, base = merge-base f338578520eb765f8605d57dc07af94897345e1d (API baseRefOid was fresh; main has not touched either file since, and git merge-tree --write-tree origin/main <head> merges clean). Base replay copied the head test file onto the base tree verbatim. Mutations applied by exact-string replacement (count-asserted), restored by cp from a sha256-verified pristine backup. The wire harness drove bash --noprofile --norc <real script> in a fixture cwd with stub binaries logging every call, composing the real check-disk-floor.sh; both sides of the wire asserted (stub call log + script output + exit code). Raw logs and all harnesses are in the artifact directory tmp/pr13481-verify-20261007-a/. No prior verification round exists on this PR (comment history checked); this is round 1.

Evidence

01-ab-suite-head-vs-base.png

02-mutation-matrix.png

03-real-helper-harness.png

🕐 Review received — an automatic review of the current head is still running, so this round is held until it lands (a push now would cancel it and discard its work, #8888). Your feedback stays queued for the next eligible round.

🤖 Addressed the latest review feedback (round 3/10). What changed, and what I pushed back on: · 已处理最新评审反馈（第 3/10 轮）。改动内容与我反驳保留之处如下：

Autofix round — PR #13481 (issue #13479)

Commit: b6fae431f8 — fix(release): decouple the docker data-root floor knob and pin the prune guards (#13479)

Both inline findings from the automated reviewer were verified against the code, reproduced, and implemented. No conflicts with main (--conflict false; no merge performed).

Feedback disposition

rc:4202942045 — R1-1: 8 GiB docker build floor shared the workspace gate's env knob — implemented

Verified before changing anything: the pre-fix gate line forwarded the ambient
DISK_FLOOR_MIN_FREE_KB into the docker data-root gate
(DISK_FLOOR_MIN_FREE_KB="${DISK_FLOOR_MIN_FREE_KB:-8388608}"), and this is the
only one of the ten check-disk-floor.sh call sites that sets a floor, so the
documented workspace-floor override silently moved the docker build floor too.
Reproduced with the reviewer's own witness shape: the new harness case passing
DISK_FLOOR_MIN_FREE_KB: '1' in the spawn env was red pre-fix
(floor=1 at both gates).

Change (.github/scripts/run-release-docker-integration.sh): the gate now reads
a dedicated DISK_FLOOR_DOCKER_MIN_FREE_KB knob, still defaulting to 8388608 and
still forwarded to the helper as DISK_FLOOR_MIN_FREE_KB — the helper and its
2 GiB default for the nine other call sites are untouched. A two-line comment
records why the knob must stay separate. This keeps the advertised escape hatch
(the PR's disclosed "8 GiB can in principle fail a build that would have fit"
tradeoff) while decoupling it from the workspace floor.

Change (scripts/tests/release-workflow.test.js):

• the text pin now asserts DISK_FLOOR_DOCKER_MIN_FREE_KB:-8388608;
• the harness strips both floor knobs from the ambient ...process.env spread
  (the suite's verdict no longer depends on the runner's environment) and only
  forwards them when a test pins them explicitly;
• new test keeps the 8 GiB docker floor when the workspace floor knob is set
  passes DISK_FLOOR_MIN_FREE_KB: '1' and asserts floor=8388608 at both gates
  (red pre-fix, green after);
• new test honors the dedicated docker floor knob pins
  DISK_FLOOR_DOCKER_MIN_FREE_KB=4194304 and asserts it reaches both gates.

rc:4202942062 — R1-2: load-bearing || echo "::warning::…" prune guards unobservable in tests — implemented

Verified: the docker stub's only failure branch was gated on
builder prune + PRUNE_FAILS, so every docker image prune exited 0 in all
tests and the guards on the labelled prune and the new dangling prune had no
witness.

Change (scripts/tests/release-workflow.test.js): the docker stub gained a
separate IMAGE_PRUNE_FAILS branch that fails both docker image prune
invocations (it does not overload PRUNE_FAILS, so the BuildKit cache-prune
test's outcome is unchanged), plus one witness test per guard:
continues with a warning when the dangling image prune fails and
continues with a warning when the labelled image prune fails. Both assert
status 0, the specific ::warning:: text, and that the build still ran.

Notes for the maintainer (PR body only — no code action taken)

• The PR body advertises the floor override as DISK_FLOOR_MIN_FREE_KB; the
  docker gate's override knob is now DISK_FLOOR_DOCKER_MIN_FREE_KB. A
  one-line body edit would keep the description accurate.
• @wenshao's verification comment (ic:6029348643, observation ①) already
  flagged a separate body wording nit: the cached-image path does gain one
  pre-vitest gate. Also body-only.

Mutation probes (each performed, then restored; script sha-verified against the pre-round backup)

1. Reverted the gate line to forwarding DISK_FLOOR_MIN_FREE_KB → red:
   keeps the 8 GiB docker floor…, honors the dedicated docker floor knob,
   and the text-pin test prunes BuildKit cache and gates the docker data root… (3 tests killed). Restored → green.
2. Removed || echo "::warning::dangling image cleanup failed…" → red:
   continues with a warning when the dangling image prune fails
   (non-zero status, no warning). Restored → green.
3. Removed || echo "::warning::old CI sandbox image cleanup failed…" → red:
   continues with a warning when the labelled image prune fails
   (non-zero status, no warning). Restored → green.

Verification

• npx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/release-workflow.test.js — 82 passed (82) on the committed state
• Reviewer's witness scenario DISK_FLOOR_MIN_FREE_KB=1 npx vitest run … -t 'builds the image only after the cache prune' — passed (was red pre-fix)
• npm run build — passed (exit 0)
• npm run typecheck — passed (exit 0)
• npm run lint — passed (exit 0)
• npx prettier --check scripts/tests/release-workflow.test.js — passed
• bash -n .github/scripts/run-release-docker-integration.sh — passed
• Pre-fix red proof: the two new floor-knob tests failed on the unmodified script with exactly the defect shape (floor=1 under an ambient workspace knob)
• Not run: the pinned ShellCheck 0.11.0 lane (node scripts/lint.js downloads the binary; outside the trusted command set and not installed on this runner). The change reuses the file's pre-existing ${VAR:-default} env-forward idiom with a renamed variable — no new shell construct. @wenshao's A/A shellcheck corroboration on the pre-round head covers the file's baseline posture.
• Not run: integration tests (npm run bundle + harness) — the changed behavior (CI shell script + its vitest harness) is not exercised through the bundled CLI.

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

🧵 Resolved all 2 selected review thread(s). · 已关闭全部选中的 2 条评审线程。

Re-review when you have a moment. After round 10 this bot stops and leaves the PR for a human. · 有空请复审；第 10 轮后本 bot 停止并将 PR 交给人工。

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.25.0

🕐 Review received — an automatic review of the current head is still running, so this round is held until it lands (a push now would cancel it and discard its work, #8888). Your feedback stays queued for the next eligible round.

🤖 Addressed the latest review feedback (round 4/10). What changed, and what I pushed back on: · 已处理最新评审反馈（第 4/10 轮）。改动内容与我反驳保留之处如下：

Round summary — PR #13481 (issue #13479)

Commit: 175d41d6a5 fix(release): decouple the docker inode floor knob and drop duplicated text pins (#13479)

Both round-2 Suggestions were reproduced, implemented, and mutation-verified. No feedback was declined, deferred, or escalated; no base-conflict resolution was needed (--conflict false, no merge performed).

rc:4204967052 — R2-1: inode floor still coupled to the job-start gate knob — RESOLVED

Reproduced before fixing. Added the harness's inode-knob plumbing and two new execution tests first; against the unfixed script they failed exactly as the finding's witness predicts: with DISK_FLOOR_MIN_FREE_INODES=999999999 set ambiently, both docker data-root gate invocations logged inodes=999999999 instead of the unscaled default, and setting a dedicated docker inode knob had no effect (inodes=100000 instead of 200000). All 88 other tests stayed green.

Fix (option B — decouple, not just reword the comment). check_docker_data_root_floor now passes DISK_FLOOR_MIN_FREE_INODES="${DISK_FLOOR_DOCKER_MIN_FREE_INODES:-100000}" alongside the existing KB override, and the comment now names both knobs. The docker default stays at the helper's own default of 100000, so behavior is byte-identical when no knob is set, and the helper check-disk-floor.sh is untouched (its default still serves the other call sites). One deliberate deviation from the finding's option-B sketch: the sketch's inner ${DISK_FLOOR_MIN_FREE_INODES:-...} fallback would have kept the ambient pass-through the finding asks to eliminate and contradicts its own acceptance test, so the KB-consistent form (dedicated knob, else fixed default) was used instead.

Tests. The stub check-disk-floor.sh now also records the inode floor (mirroring the real helper's :-100000 default), and the harness gained ambientDiskFloorInodes / dockerFloorInodes parameters with hermetic env deletes. Two new tests pin both arms: keeps the default docker inode floor when the workspace inode knob is set (ambient knob must not leak into either docker gate) and honors the dedicated docker inode knob. The five pre-existing exact-match gate assertions were extended to the new log format.

Mutation probe. Negating the new branch (script hardcodes DISK_FLOOR_MIN_FREE_INODES="100000", ignoring the docker knob) reddened exactly honors the dedicated docker inode knob (1 failed / 89 passed); the pre-fix pass-through state reddened exactly the two new tests. Each arm of the new branch has its own witness.

rc:4204967056 — R2-2: duplicated text-position pins in the prune/gate text test — RESOLVED

Removed the eight duplicated assertions from prunes BuildKit cache and gates the docker data root before the build and the vitest phase — the gate count, the four gate-ordering assertions, the two indentation assertions, and the DISK_FLOOR_DOCKER_MIN_FREE_KB:-8388608 literal — along with the scriptLines/gateCallLines/cachePruneLine/buildLine/firstVitestLine computations that existed only to feed them. Kept everything through the timeout 60 docker info pin (the finding's lines 2151-2174): the full prune spellings, the prune ordering, and the timeout 20m builder-prune / timeout 60 docker-info / --filter 'until=24h' pins the execution harness cannot see. The surviving coverage is behavioral: gate count and order are pinned by builds the image only after the cache prune and the pre-build disk gate pass and gates the cached-image re-run path before the vitest phase, and the knob spelling by honors the dedicated docker floor knob and keeps the 8 GiB docker floor when the workspace floor knob is set. The deletion is recorded in test-weakening.json with this evidence.

Acceptance probe (M1). Reindenting the pre-build gate call one level (2→4 spaces, a bash no-op) left the whole suite green (90 passed); the probe was then reverted and the suite re-run green.

Note on the review-body deferred items. The two entries under the review's own qwen-review-deferred marker (the ~61-minute bound sum vs the 1800 s lock wait, and the single gate-skip cause string) were deferred by the reviewer itself under the convergence posture and were not requested this round; they are unchanged and remain tracked there.

Verification

All run on this checkout with COREPACK_HOME=/tmp/corepack-home (the runner's default corepack cache path is not writable in this sandbox; the suite's globalSetup honors COREPACK_HOME):

• npx vitest run --config ./scripts/tests/vitest.config.ts release-workflow.test — 90 passed (2 files), run on the final committed tree.
• Reproduction run before the fix (test edits only): exactly the 2 new inode tests failed (inodes=999999999 and inodes=100000 received vs expected inodes=100000 / inodes=200000), 88 passed.
• Mutation probe A (docker inode knob ignored by the script): exactly honors the dedicated docker inode knob failed (89 passed); then restored and re-run green.
• Mutation probe M1 (pre-build gate reindented 2→4 spaces): 90 passed; then reverted and re-run green.
• bash -n .github/scripts/run-release-docker-integration.sh — passed.
• npx prettier --experimental-cli --check scripts/tests/release-workflow.test.js — clean; the commit's pre-commit hook (prettier + eslint on staged files) also passed.
• npm run build — passed.
• npm run typecheck — passed.
• npm run lint — passed.
• npm run test:scripts (full scripts suite) — 2826 passed, 17 failed in 4 files this round did not touch (verify-capture, web-shell-publish-artifacts, install-script, qwen-triage-workflow; tmux-proxy/packaging/ANSI-rendering cases). Reproduced identically on the unmodified HEAD (same 4 files, same 17 failures: 1+11+1+4), so they are environment-specific to this runner and pre-existing relative to this change; the touched release-workflow suite is fully green in both runs.

🧪 Gate advisory — this round weakened or removed pre-existing tests (machine-measured, not agent-authored):

• scripts/tests/release-workflow.test.js — net 2 assertion(s) removed

The round recorded evidence for each (below, agent-authored). Weakening is sound only when the pinned behaviour itself was wrong or the coverage demonstrably survives elsewhere — read each reason against the diff. · 本轮弱化或删除了既有测试（门自动测量，非 agent 文本）。下列理由由 agent 撰写：仅当被钉住的行为本身有误、或覆盖确有替代时才成立，请对照 diff 逐条审阅。

• scripts/tests/release-workflow.test.js: Removed 8 duplicated text-position assertions (gate count, four gate-ordering, two indentation, one floor literal) from the 'prunes BuildKit cache' text test; the pinned behavior survives in named execution tests: gate count/order/position in 'builds the i

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

🧵 Resolved all 2 selected review thread(s). · 已关闭全部选中的 2 条评审线程。

Re-review when you have a moment. After round 10 this bot stops and leaves the PR for a human. · 有空请复审；第 10 轮后本 bot 停止并将 PR 交给人工。

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.25.0

🕐 Review received — an automatic review of the current head is still running, so this round is held until it lands (a push now would cancel it and discard its work, #8888). Your feedback stays queued for the next eligible round.

🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下：

Autofix review round — no action

No code changes this round. The feedback window contained exactly one actionable finding, and its requested fix is a pull-request-description edit, which this lane cannot perform.

• Inline comments: 1 — rc:4206990470 (R3-1, Suggestion).
• Reviews: 1 — rv:5442416748 (COMMENTED, automated reviewer; disclosed coverage gaps only, no requested change).
• Reviewer-deferred items: 3 entries under the review's own qwen-review-deferred marker (the builder-prune until=24h window, the two prune-warning tests sharing one stub switch, and the github-hosted not.toContain('disk-floor') assertion). The reviewer deferred them under the convergence posture and explicitly did not request them this round; left untouched.
• Failed checks: none. Base conflict: none (--conflict false; no merge performed).

rc:4206990470 — R3-1: PR description still names the old override knob and claims the cached-image path is unaffected — VERIFIED, escalated to the maintainer

Verified every claim against the current head (175d41d6a5) before deciding:

• .github/scripts/run-release-docker-integration.sh:51-53 reads DISK_FLOOR_DOCKER_MIN_FREE_KB / DISK_FLOOR_DOCKER_MIN_FREE_INODES — the DISK_FLOOR_MIN_FREE_KB knob the description names has no effect on the docker data-root gate.
• The post-build/pre-vitest gate (.github/scripts/run-release-docker-integration.sh:113-120) sits after the fi closing the image-missing branch, so a cached-image re-run is gated and can fail without building — pinned by the PR's own tests gates the cached-image re-run path before the vitest phase and blocks the vitest phase when the cached-image host fails the gate (scripts/tests/release-workflow.test.js:2535,2566).
• .github/scripts/check-disk-floor.sh:22-23 reads the generic knobs at the 2 GiB / 100000 defaults serving the nine job-start call sites (release.yml:213, ci.yml:627/1149/1528/2101/2323, e2e.yml:297, tui-parity.yml:43/97 — all confirmed by grep) — so the finding's negative constraint (do not rename the helper's knobs back) is correct, and no code-side variant of this fix exists.

Disposition: escalated, thread left open, with a ready-to-apply correction. The finding asks to update the "How to verify" and "Risk & Scope" sections of the PR description (EN and ZH). This address-review lane has no PR-body write channel: the workflow sets the body once at PR creation and never edits it afterwards (confirmed against qwen-autofix.yml and autofix-push-and-report.sh, which only push commits and post comments), and the agent side carries no GitHub credentials. Round 3 already surfaced this as a maintainer note; it now arrives as an inline finding. I replied on the thread with the verified evidence and the exact replacement statements for both languages, and asked the maintainer to apply the edit. This was not declined — the finding is real and worth fixing — and not deferred to the post-merge queue, because a stale description matters most before merge.

Verification

• Code inspection of .github/scripts/run-release-docker-integration.sh (gate function, both call sites, branch structure) — finding's claims confirmed.
• grep of the nine job-start check-disk-floor.sh call sites across .github/workflows/ — confirmed all invoke the helper with no env prefix.
• Test-name pins confirmed at scripts/tests/release-workflow.test.js:2535,2566.
• No build/typecheck/lint/vitest runs needed: the working tree is unchanged this round (no commit produced).

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.25.0

🕐 Review received — an automatic review of the current head is still running, so this round is held until it lands (a push now would cancel it and discard its work, #8888). Your feedback stays queued for the next eligible round.

🤖 Addressed the latest review feedback (round 5/10). What changed, and what I pushed back on: · 已处理最新评审反馈（第 5/10 轮）。改动内容与我反驳保留之处如下：

Round summary

All six findings from the round-4 review were triaged source-blind: three were reproduced with the suite's own stub harness and fixed in code (R4-2, R4-4, R4-5), two were verified as real and deferred to the follow-up queue because their fixes live on CI machinery outside this PR's footprint (R4-1, R4-3), and one needs a maintainer to edit the PR body (R3-1). Commit: fix(release): reclaim on the cached path and size the pre-vitest floor separately (#13479).

Fixed in code

• R4-4 (cached-image re-run reached the pre-vitest gate with no reclaim) — reproduced on the pre-fix script: the cached path logged zero prune lines before the gate, and the two not.toContain assertions in the cached-path tests pinned that gap as intended behavior. Fix: the dangling-image and BuildKit-cache prunes moved out of the image-missing branch so they run on every path before any gate samples the data root; the labelled --all prune stays inside the build mutex (the pre-existing pin expect(imagePrune).toBeGreaterThan(buildLock) still holds). The moved prunes run under the shared daemon lock but outside the build mutex — the daily host sweep runs both with no lock at all — and keep their timeout 20m bounds.
• R4-5 (the pre-vitest gate re-charged the build budget) — check_docker_data_root_floor now takes the free-space floor as an argument: the pre-build call keeps the build-sized 8 GiB (DISK_FLOOR_DOCKER_MIN_FREE_KB); the pre-vitest call charges the repo's calibrated job floor of 2 GiB (check-disk-floor.sh's own default) via the new DISK_FLOOR_DOCKER_POST_MIN_FREE_KB, so an operator can tune the two checkpoints independently; the inode floor stays shared. A host admitted by the first gate with less than 8 GiB plus the build's own consumption now builds, passes the second gate, and runs both vitest phases instead of dying after the build it already paid for.
• R4-2 (the dangling-prune comment's justification was measurably false) — rewritten to the verified facts: this lane passes --no-prune to the build, and until on images is creation age, so the line takes dangling images older than a day and a same-day dangler waits for the daily 02:30 UTC sweep. Comment-only; no test pins comment text and the suite held its green baseline.

Deferred to the follow-up queue (verified real, fix outside this PR's footprint)

• R4-1 (the E2E lane runs the same labelled prune unbounded under the same build mutex) — verified against run-e2e-tests.sh. Bounding it means editing the shared CI script every PR's E2E shards run on; recorded in the deferred-findings issue together with the suggested e2e-workflow.test.js pin. As the finding's own fallback, this script now carries a comment recording the asymmetry so the omission is not mistaken for an oversight. Thread replied, left open.
• R4-3 (no disk sampler on release.yml's integration_docker) — verified: ci.yml carries six DFSAMPLE loops, release.yml none. Attaching the ci: gate heavy jobs on a disk floor and persist pressure samples #10394 sampler adds steps to a workflow this PR never touches; recorded in the deferred-findings issue with the full design. The secondary mid-phase gate sample was not added: a point sample does not survive the incident's worker crash the way the streamed sampler does, and each added gate is flake surface. Thread replied, left open.

Needs a maintainer

• R3-1 (PR description still names DISK_FLOOR_MIN_FREE_KB and claims cached-image runs are unaffected) — still stale at this head, and this round widened the gap (new post-floor knob). The bot cannot edit the PR body — the workflow writes it only at creation — so the thread reply carries the exact replacement sentences in both languages for a maintainer to paste. Thread replied, left open.

Effect on earlier deferrals

The round-2 deferral (aggregate prune-bound budget inside the fd-7 build mutex) shrinks: only the labelled prune and the gate's bounded docker info remain inside the mutex. The round-3 deferral (shared prune-failure stub switch in the new tests) is untouched.

Verification

• bash -n .github/scripts/run-release-docker-integration.sh — passed
• npx vitest run scripts/tests/release-workflow.test.js — 85 passed at baseline; 87 passed after the fix (two new tests: the post-floor knob, and the host-admitted-between-the-floors case)
• Mutation probes (each applied, run against the focused suite, then restored and re-run to green):
  • dangling prune gated on image-absence → the 2 cached-path tests failed (R4-4 witness)
  • builder prune gated on image-absence → the same 2 tests failed (R4-4 witness)
  • pre-vitest floor restored to the shared 8 GiB default → 7 floor tests failed (R4-5 witness)
  • pre-vitest floor hardcoded (env knob dropped) → the new post-knob test failed (knob witness)
• npm run build — passed
• npm run typecheck — passed
• npm run lint — passed (the pre-commit hook's prettier/eslint pass also ran clean on both files)
• npx prettier --check .github/scripts/run-release-docker-integration.sh scripts/tests/release-workflow.test.js — passed
• Integration tests not run: the change is release-lane shell scripting exercised by the stub-harness suite; the bundled CLI never touches it
• npm run generate:settings-schema not run: no settings source changed

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

🧵 Resolved all 3 selected review thread(s). · 已关闭全部选中的 3 条评审线程。

Re-review when you have a moment. After round 10 this bot stops and leaves the PR for a human. · 有空请复审；第 10 轮后本 bot 停止并将 PR 交给人工。

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.25.0

🕐 Review received — an automatic review of the current head is still running, so this round is held until it lands (a push now would cancel it and discard its work, #8888). Your feedback stays queued for the next eligible round.

🤖 Addressed the latest review feedback (round 6/10). What changed, and what I pushed back on: · 已处理最新评审反馈（第 6/10 轮）。改动内容与我反驳保留之处如下：

Autofix round summary — PR #13481 (issue #13479)

Commit: fae808c24f fix(release): derive the docker floor from the helper and bound the image inspects (#13479)

All six findings this round trace to the same integration seam in run-release-docker-integration.sh — the two floor-gate checkpoints and the daemon calls made while the shared host locks are held — so they were fixed as one coherent batch instead of six point patches.

Feedback dispositions

rc:4213016563 (R4-1) — resolved in code

The "every daemon call is time-bounded" comment overclaimed: both docker image inspect calls ran unbounded while fds 8/9 were held. Rather than narrowing the wording, the invariant was made true:

• The image-id read is now timeout 60 docker image inspect --format '{{.Id}}' ..., which fails closed under set -e (no || true, so an empty id can never reach QWEN_SANDBOX_IMAGE).
• The presence probe is now bounded too, with the asymmetry the finding called out respected: a 124 (timeout) is discriminated from "image absent" and fails the lane fast, because rebuilding against a wedged daemon would hang with the locks held until the job timeout. Any other non-zero still takes the rebuild branch, unchanged.

Witnesses: text pins for the bound and the 124 discrimination in the existing prune/gate text test, plus a new execution case (inspectTimesOut) that simulates the bound via the stubbed pass-through timeout.

rc:4213016572 (R4-5) — resolved in code

The pre-vitest floor and the inode floor no longer copy check-disk-floor.sh's calibrated defaults as literals. Both are forwarded empty (${DISK_FLOOR_DOCKER_POST_MIN_FREE_KB:-} / ${DISK_FLOOR_DOCKER_MIN_FREE_INODES:-}); the helper's :- fallback resolves its own defaults, so a repo-wide retune now reaches these gates by construction and the existing "charges the calibrated job floor" comments are true. The explicit env-prefix assignment stays, so an ambient DISK_FLOOR_MIN_FREE_KB/DISK_FLOOR_MIN_FREE_INODES still cannot move the docker floors (the ambient-isolation cases pass unchanged). check-disk-floor.sh itself was not touched, and the build-sized 8 GiB pre-build budget remains a lane-local literal because it is not the helper's default.

Witness: the stub helper echoes the floors as received, so the affected assertions now pin floor=unset/inodes=unset; re-hardcoding a literal at either call site turns them red (probe 1 and 2 below).

rc:4213016593 (R5-1) — resolved in code

The stub helper now counts its invocations and honors a POST_GATE_EXIT override for calls after the first, driven by a new postGateExit harness option. gateExit: '1' still fails the first checkpoint (the two existing trip cases are untouched and pass). The duplicated between-floors case was converted into the scenario its name claimed — postGateExit: '1' asserting the build ran, the build lock was released, and npx vitest never ran — which is the build-path post-gate trip coverage the mutation battery showed nothing else executed. Its previous assertions survive verbatim in the ordering test under byte-identical input; recorded in test-weakening.json with that evidence.

rc:4213016603 (R5-2) — resolved in code

• The lane validates all three DISK_FLOOR_DOCKER_* knobs at the top of the gate function (so the pre-build call already validates the pre-vitest knob): a malformed value now fails fast, before the image build, with ::error::<docker knob> must be a non-negative integer of at most 18 digits naming the knob the operator actually set. Empty stays valid (helper default applies). The helper's own validation is untouched.
• Any helper failure is additionally re-labelled by the lane with the gate's own knobs and the docker data root, so a genuine floor breach no longer reads as the job-start gate's variables.

Witnesses: a new case (dockerPostFloorKb: '3G') asserts non-zero exit, the docker knob named in the output, and no build started; the existing pre-build trip case now also pins the re-labelled failure message.

rc:4213016800 (R3-1) — escalated (maintainer action), thread left open

The remaining gap is the PR body text, which only a maintainer can edit (the workflow writes it at creation). The corrected wording was already drafted in comment 4211178811; a reply on the thread restates that and leaves the thread unresolved as the standing reminder. No code change exists for this finding.

rc:4213016977 (R4-3) — deferred to the follow-up queue, thread left open

The df-sampler instrumentation for integration_docker is verified real, but the remedy adds steps to .github/workflows/release.yml, a file this PR never touches — outside the PR footprint boundary. Recorded in deferred-findings.json with the full design (10-second df loop over the data root and RUNNER_TEMP started before the first vitest, stopped from the existing EXIT trap, samples echoed to the job log as well as the file per the ci.yml:780 pattern, plus an if: failure() upload-artifact step, pinned by a new suite case) so it survives the merge; a thread reply says the same.

Conflict notes

None — --conflict false; no merge with the base was needed.

Verification

• bash -n .github/scripts/run-release-docker-integration.sh — passed
• npx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/release-workflow.test.js — 89 passed (87 pre-round + 2 new; the duplicated case was converted, not added)
• Mutation probes (each: mutate the script, run the suite, confirm red, restore, re-run green 89/89):
  • re-hardcode :-2097152 at the post-gate call site → red (floor=unset assertions fail)
  • re-hardcode :-100000 in the inode forward → red (inodes=unset assertions fail)
  • drop timeout 60 from the image-id read → red (text pin)
  • drop the 124 discrimination from the presence probe → red (timeout case + text pin)
  • remove the knob-validation loop → red (malformed-knob case)
  • revert the failure re-labelling wrapper → red (pre-build trip case's new assertions)
  • make the post-build gate non-fatal (|| true) → red (converted post-gate trip case)
• node --test .github/scripts/check-disk-floor.test.mjs — 0 failures
• npm run build — passed
• npm run typecheck — passed
• npm run lint — passed
• npx prettier --check scripts/tests/release-workflow.test.js — passed (and the pre-commit hook's prettier/eslint pass made no changes)

Environment note: this sandbox makes $HOME/.cache read-only, so corepack-backed commands were run with COREPACK_HOME=/tmp/autofix-review-13481/corepack-home. The first unredirected npm run build failed with EACCES: mkdir /home/github-runner/.cache/node/corepack/v1 — an environment constraint, not the change; the redirected rerun passed. No settings source changed; the build's schema regeneration produced no diff.

Deferred non-Critical feedback

Critical-only mode is active: 5 change-producing rounds are complete. The workflow excluded the non-Critical feedback below from this round's actionable sections; the items remain open for human follow-up. Maintainer feedback is deferred only after its author has used 2 regular feedback batches in this window's Critical-only tail; authors at that budget, if any, are named below. (@qwen-code /retry starts a fresh counting window.)

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

🧵 Resolved all 4 selected review thread(s). · 已关闭全部选中的 4 条评审线程。

Re-review when you have a moment. After round 10 this bot stops and leaves the PR for a human. · 有空请复审；第 10 轮后本 bot 停止并将 PR 交给人工。

🧠 Handled by Qwen Code · model/模型 kimi-k3 · CLI 0.25.0

🕐 Review received — an automatic review of the current head is still running, so this round is held until it lands (a push now would cancel it and discard its work, #8888). Your feedback stays queued for the next eligible round.

🔀 Base updated: red check(s) [Test (ubuntu-latest, Node 22.x)] pass on current main — merged current main via update-branch; CI will re-run.