[finding] .github/workflows/test.yml — 3 findings #773

Origin: 2c6db44177351a84156c12e838aceecd76f8713b
Agent: premerge.review.code_review
File: .github/workflows/test.yml:101
Severity: suggestion (Phase premerge)
Disposition: DEFERRED (premerge-repair-budget-exhausted)
Tier: SUGGESTION
Related: PR #768

Findings (3)

1. .github/workflows/test.yml:101 — suggestion / SUGGESTION / DEFERRED (premerge-repair-budget-exhausted) — The new 'Dump shard plan bytes' step re-runs ci-job-fixtures.sh plus the full packer for every shard of every sharded jo

Lenses: premerge.review.code_review

ci_diag_dump section [A] calls bash ci-shard-env.sh "$job" "$shards" "$shard", which re-extracts the job block with awk over the whole workflow and re-runs ci-shard-plan.py; this happens on 6 shape-checks shards + 2 macos shards + 6 windows shards. The producer's output was written to $GITHUB_ENV one step earlier and is in [B] already. [A] also discards the producer's stderr and on failure prints 'the producer refused; its diagnostic is on stderr in the planning step', which is only true when the second run fails for the same reason as the first.

2. .github/workflows/test.yml:101 — suggestion / SUGGESTION / DEFERRED (premerge-repair-budget-exhausted) — The Dump shard plan bytes step is wired after the planning step, so on the CR-refusal path - the one case the byte evide

Lenses: premerge.review.code_review

tests/ci-shard-env.sh exits 2 when the packed plan carries a CR. That refusal happens in the Plan shard N of 6 step, which fails the job; the Dump shard plan bytes step immediately below never runs, because a step with no if: only runs on success. The refusal message tells the operator to run the dump by hand, but the step wired to do it automatically is precisely the one skipped.

3. .github/workflows/test.yml:169 — suggestion / SUGGESTION / DEFERRED (premerge-repair-budget-exhausted) — shard_routed is incremented in all three harnesses and only ever echoed (no gate reads it), and run_one_routed is a shel

Lenses: premerge.review.code_review

The SHARD-COVERAGE tail compares only shard_ran against shard_plan_len; shard_routed appears exclusively in the informational echo at 373/555/1017. run_one_routed=0 at the top of run_one is the only thing preventing leakage between calls, and unlike fail/failed it is per-call state: a future edit that adds an early return above that line leaves the previous call's value in scope and mis-counts shard_ran. Declaring it local run_one_routed=0 removes the dependency.

To resolve: address the findings above in code and close this issue. Closing resolves exactly the findings listed in this body and the findings added by a later comment on it — one index records both, and closing resolves that recorded set and nothing else. A finding in this file that this issue never recorded is filed as a NEW issue rather than suppressed, so closing never mutes the file. Before closing, apply finding:true-positive if it was a real defect or finding:false-positive if it was not — that label is the eval ground truth (RFC 0018).