[Suggestion] R4-1: The reclaim sequence added in this block is the pool's fourth copy of the same docker reclaim policy, and the four copies now disagree on which commands they run, on whether they are time-bounded, and on --keep-storage. The copy that matters is the peer E2E lane's: .github/scripts/run-e2e-tests.sh:73 runs the identical labelled prune with no timeout at all while holding the very same docker-sandbox-build.lock this script takes at line 77. So the bound added here protects one direction of a two-way contention — a wedged daemon GC on the E2E side still starves this lane's 30-minute wait. Nothing asserts the copies agree either: ci-runner-routing.test.mjs:590-592 pins e2e.yml's step text and ecs-runner/qwen-docker-cleanup.test.mjs:73-77 pins the sweep's --keep-storage 30GB, so a future reclaim change has to be hand-applied to three shell files plus one workflow and drift between them passes CI silently.

The contention premise is not speculative. docs/plans/2026-09-03-test-suite-barrel-cost.md:44 records that the hk4 runners still carry the shared ecs-qwen label, and scripts/tests/lint.test.js:229 records an ecs-qwen-labelled job actually executing on ecs-qwen-hk4-19 two days before this incident.

Witness:

run-e2e-tests.sh:73        docker image prune --all --force --filter 'label=...' --filter 'until=24h'   <- NO timeout, inside flock --wait 1800 7
qwen-docker-cleanup.sh:44  docker image prune --force --filter 'until=24h'                             <- NO timeout
qwen-docker-cleanup.sh:50  timeout 20m docker builder prune --all ... --keep-storage 30GB              <- under flock --nonblock
e2e.yml:421-422            both image prunes                                                            <- NO timeout, under flock --nonblock 9
this diff :83,:87,:96      timeout 20m x3, NO --keep-storage                                            <- the fourth copy

The in-scope minimum is to bound the peer lane's twin — apply the same timeout to run-e2e-tests.sh:73 so both holders of the mutex are bounded. The fuller fix is one shared reclaim helper taking the label filter and an optional reserve, called from all three scripts and the workflow; that is a cross-lane CI-infra refactor and is reasonably a follow-up issue rather than a change here. If neither lands, a comment recording why the release lane is the only one that needs these guards would stop the next reader treating the omission as an oversight.

A shared helper must keep --keep-storage per call site rather than folding the flag sets into one: ecs-runner/qwen-docker-cleanup.sh:50-51 deliberately retains a 30 GB reserve while this line deliberately omits it, because a reserve reclaims nothing on a host holding less cache than the reserve.

If the minimal variant lands, an assertion in scripts/tests/e2e-workflow.test.js — which already reads the E2E script as e2eRunScript at line 13 — that the labelled prune in run-e2e-tests.sh carries a timeout bound is the test to add; nothing pins that today, so it is red before the fix and green after. Please confirm by removing the bound and watching it fail.

run-e2e-tests.sh:73        docker image prune --all --force --filter 'label=...' --filter 'until=24h'   <- 无 timeout，处于 flock --wait 1800 7 之内
qwen-docker-cleanup.sh:44  docker image prune --force --filter 'until=24h'                             <- 无 timeout
qwen-docker-cleanup.sh:50  timeout 20m docker builder prune --all ... --keep-storage 30GB              <- 在 flock --nonblock 之下
e2e.yml:421-422            两个镜像裁剪                                                                 <- 无 timeout，在 flock --nonblock 9 之下
本 diff :83,:87,:96        timeout 20m x3，无 --keep-storage                                            <- 第四份副本

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

Verified before deciding: run-e2e-tests.sh does run the identical labelled prune with no timeout while holding the same docker-sandbox-build.lock this script takes — the one-direction-bound gap is real.

Deferred to the follow-up queue rather than implemented here: bounding the E2E lane means editing the shared CI script every PR's E2E shards run on, which is CI machinery outside this release-lane PR's footprint — the same call your fuller-fix variant makes. The finding, the minimal fix, and the suggested e2e-workflow.test.js pin are recorded in the deferred-findings issue so they survive the merge.

What did land here, as your fallback option: this script now records the asymmetry next to the mutex — every daemon call it makes is time-bounded so a wedged GC cannot starve a peer lane's 30-minute wait, and the E2E lane's unbounded copy of the same prune under the same lock is noted as a cross-lane change tracked separately.

[Suggestion] R4-3: Two point samples now cover three heavy phases, and the phase the incident actually died in is the one nothing measures. This gate is taken once, before two back-to-back vitest docker phases, and cleanup_release_containers is on the EXIT trap, so phase-1 containers and their writable layers are still on the data root when phase 2 starts. The companion instrumentation the repo attaches to every other disk-floor gate is absent from this job: ci.yml runs a 10-second df sampler loop next to its gate and uploads the sample file on failure, and integration_docker in release.yml has neither.

A host that clears this sample with just over 8 GiB free can cross zero during the cli phase — container writable layers, transcripts and the runner's own diagnostic log all land on that filesystem — and the worker dies on ENOSPC mid-phase with no step conclusion, so even the always() container-cleanup step never runs and the auto-filed issue again carries no actionable signal. That is the identical shape as run 37374675168. This is not covered by the PR's out-of-scope statement: in-lane instrumentation is neither an end-to-end lane validation nor a host-level capacity control, and #10394 already established it as the companion to every disk-floor gate in ci.yml.

Witness:

DFSAMPLE occurrences:  .github/workflows/ci.yml = 6 (L636, L765, L780, L1158, L1708, L1890)
                       .github/workflows/release.yml = 0
sed -n '530,585p' release.yml | grep -E 'DFSAMPLE|df -|upload-artifact|if: .*failure'  ->  NONE FOUND
only upload-artifact in release.yml is at :340, owned by quality_build
  (job headers: integration_docker = 530, audio_capture_prebuilds = 583)
ci.yml:632-643 is the pattern: sample_disk + ( while sleep 10; do sample_disk; done ) & + trap
  dual sink at :639-640
script:21  trap cleanup_release_containers EXIT     gate at :119, vitest at :122 and :123

Attach the sampler #10394 established to this lane: start a 10-second df loop over "$docker_root" and "${RUNNER_TEMP}" before the first npx vitest, stop it from the existing trap, and add an if: failure() actions/upload-artifact step for the sample file to integration_docker. A third gate sample between the two vitest invocations would also help, but the sampler is what turns a recurrence into a diagnosable one.

Each sample must go to the job log as well as to the file — ci.yml:780 does exactly echo "$sample"; echo "$sample" >> "$DISK_SAMPLES" 2>/dev/null || true — because in the incident the worker itself crashed, the step got no conclusion and even the always() step never ran, so a file plus an if: failure() upload alone would have been lost the same way.

A new case in scripts/tests/release-workflow.test.js in the style of the existing pin at line 349 (gates every pool-routed job on a disk floor before its heavy steps) is the test to add: assert releaseYaml.jobs.integration_docker.steps contains a step whose run starts the sampler loop and an if: failure() upload-artifact step whose path is the sample file. Deleting either must redden it — please confirm by removing one and re-running.

DFSAMPLE 出现次数：  .github/workflows/ci.yml = 6（L636、L765、L780、L1158、L1708、L1890）
                     .github/workflows/release.yml = 0
sed -n '530,585p' release.yml | grep -E 'DFSAMPLE|df -|upload-artifact|if: .*failure'  ->  NONE FOUND
release.yml 中唯一的 upload-artifact 在 :340，属于 quality_build
  （作业起始行：integration_docker = 530，audio_capture_prebuilds = 583）
ci.yml:632-643 即该模式：sample_disk + ( while sleep 10; do sample_disk; done ) & + trap
  双写形式在 :639-640
script:21  trap cleanup_release_containers EXIT     门在 :119，vitest 在 :122 与 :123

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

Verified before deciding: release.yml's integration_docker job has no df sampler and no failure upload — ci.yml carries six DFSAMPLE loops, this workflow has none, and its only upload-artifact step belongs to quality_build. The gap is real and matches the incident shape (worker died mid-phase, no step conclusion, even the always() cleanup never ran).

Deferred to the follow-up queue rather than implemented here: attaching the #10394 sampler means adding steps to a workflow this PR never touches — CI machinery outside this PR's footprint. The full design you specified (10-second loop over the docker root and RUNNER_TEMP, dual job-log/file sink per ci.yml:780, if: failure() upload-artifact step, plus the new pin in the style of the line-349 test) is recorded in the deferred-findings issue so it survives the merge.

The secondary ask — a third gate sample between the two vitest invocations — was considered and not added: a point sample there does not diagnose the incident shape (only the streamed sampler survives a worker crash), and each added gate is flake surface on the lane. It rides along in the same deferral record.

[Suggestion] R4-3: Still stands. Two point samples now cover three heavy phases, and the phase the incident actually died in is the one nothing measures. This gate is taken once, before two back-to-back vitest docker phases, and cleanup_release_containers is on the EXIT trap, so phase-1 containers and their writable layers are still on the data root when phase 2 starts. The companion instrumentation the repo attaches to every other disk-floor gate is still absent from this job: ci.yml runs a 10-second df sampler loop next to its gate and uploads the sample file on failure, and integration_docker in release.yml has neither.

A host that clears this sample with just over 2 GiB free can cross zero during the cli phase — container writable layers, transcripts and the runner's own diagnostic log all land on that filesystem — and the worker dies on ENOSPC mid-phase with no step conclusion, so even the always() container-cleanup step never runs and the auto-filed issue again carries no actionable signal. That is the identical shape as run 37374675168, which is what this PR exists to make diagnosable. A point sample cannot survive a worker crash; only a streamed sampler can.

Witness (measured in the review worktree at head 46c54cfbe2):

grep -c DFSAMPLE .github/workflows/ci.yml        -> 6
grep -c DFSAMPLE .github/workflows/release.yml   -> 0
grep -c 'while sleep 10' .github/workflows/release.yml -> 0
upload-artifact steps inside integration_docker  -> 0
   (release.yml's single upload-artifact belongs to quality_build)

You verified this gap in comment 4211178534 and deferred it to the follow-up queue because the remedy adds steps to a workflow this PR never touches, which is a reasonable scoping call and is recorded in the deferred-findings issue. Nothing landed this round, so the entry carries forward rather than closing — the deferral record is now the only thing carrying it. The design you specified there is the fix: a 10-second df loop over "$docker_root" and "${RUNNER_TEMP}" started before the first npx vitest, stopped from the existing trap, plus an if: failure() actions/upload-artifact step for the sample file on integration_docker.

Each sample must go to the job log as well as to the file, which is what ci.yml:780 does — echo "$sample"; echo "$sample" >> "$DISK_SAMPLES" 2>/dev/null || true — because in the incident the worker itself crashed, the step got no conclusion and even the always() step never ran, so a file plus an if: failure() upload alone would have been lost the same way. A new case in the style of the existing pin at release-workflow.test.js:349 (gates every pool-routed job on a disk floor before its heavy steps) is the test to add: assert releaseYaml.jobs.integration_docker.steps contains a step whose run starts the sampler loop and an if: failure() upload-artifact step whose path is the sample file, then delete each in turn and confirm it reds.

grep -c DFSAMPLE .github/workflows/ci.yml        -> 6
grep -c DFSAMPLE .github/workflows/release.yml   -> 0
grep -c 'while sleep 10' .github/workflows/release.yml -> 0
integration_docker 内的 upload-artifact 步骤  -> 0
   （release.yml 唯一的 upload-artifact 属于 quality_build）

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

Verified and still deferred to the follow-up queue: the remedy (a 10-second df sampler over the docker data root and RUNNER_TEMP started before the first npx vitest, stopped from the existing EXIT trap, each sample echoed to the job log as well as the file — the ci.yml:780 pattern, because the incident's worker crash loses a file-only artifact — plus an if: failure() upload-artifact step) adds steps to .github/workflows/release.yml, which this PR never touches. Expanding into a new workflow file mid-review is exactly the scope drift the footprint boundary exists to prevent. The deferral is recorded in the deferred-findings issue so it survives the merge; the design above is the fix to schedule from there.