Shard `Test (coverage)` 4 ways and stop the Codecov upload being skipped by its implicit `success()`

[os-support-ai]

Blocked-by: #5402

Ruled by the maintainer on 2026-08-20 (#5393, verbatim 「接受你的所有建议，现在开始处理。」). Item 2 of 5. Both halves live in the same test-coverage job in ci.yml, so they are one card and one PR.

Half 1 — shard it

Measured on the same commit by #5395:

	measured
unsharded (today)	39 min 05 s
4-way sharded + blob merge	12 min 04 s (3.24×)
extra runner minutes	+9.2%
the blob-report merge ci.yml declines on cost grounds	13 seconds

ci.yml's comment declines sharding because it would need a blob-report merge and "nothing blocks on this job". That trade was priced when the job was shorter; the merge costs 13 seconds and buys back 27 minutes.

Equivalence is the acceptance test, and it has a measured baseline: 1287 files both ways, 55432 vs 55395 of 84590 statements, onlyUnsharded=0, onlyMerged=0, delta −0.0437 pp — against a noise floor of 3 statements between two identical sharded runs. Reproduce that, do not assume it.

⚠️ The job also has timeout-minutes: 40, which has already fired 4 times ("The job has exceeded the maximum execution time of 40m0s"). At ~12 minutes the cap stops being load-bearing. ⛔ Do not raise it as part of this card — if sharding works the margin is no longer tight, and raising a cap is a separate decision.

Half 2 — the upload cannot stay silent

Upload coverage to Codecov has no if:, so it carries the implicit success() and is skipped whenever the test step fails — 311 of 373 coverage jobs, and 120 of the 121 most recent. "Codecov received nothing" and "Codecov received an unchanged report" are indistinguishable from outside, which is how four dark days went unnoticed.

Make the failure visible. ⛔ Do not make the upload unconditional in a way that publishes a partial or empty report as if it were complete — a wrong coverage number is worse than a missing one. The requirement is that a skipped upload is loud, not that it always uploads.

⚠️ #5402 also found that on a failing suite the live unsharded recipe leaves no coverage/ directory at all (reproduced 2 of 2), while the blob-report path produced a complete 1287-file report every time. If sharding changes that, say so — it may resolve this half on its own, and that is a finding worth recording either way.

⛔ Constraints

• ⛔ No test deleted, skipped, quarantined, or given a raised timeout. This card changes how the suite is run, never what it asserts.
• Blocked on ci.yml Test (coverage) has failed 100% of the time since 2026-08-16 — one test times out under v8 coverage, and Codecov has received nothing since #5402: while the suite fails under coverage, a sharded coverage run fails too (measured — prototype run 32364577842, sharded + coverage, still timed out). Equivalence cannot be verified against a red suite.
• Run vitest from the repo root; 17 packages carry their own vitest.config.ts that does not re-export the root config.
• Report elapsed from the jobs' own started_at/completed_at.

Evidence and method: #5395. Ruling: #5393.

[os-support-ai]

Inherited from #5402: one config decision routed here, plus the mechanism behind this card's second half

#5402's dev found the mechanism for "a failing suite leaves no coverage/ directory at all", and it is not a second defect — it is downstream of the red suite:

vitest/dist/chunks/coverage.DM_a_rWm.js:791
 if (!this.options.reportOnFailure) await this.cleanAfterRun();

vitest/dist/chunks/defaults.9aQKnqFk.js:22
 reportOnFailure: false

vitest.config.mts does not override it, so the v8 provider deletes the reports directory whenever the run is red. The blob-report path escapes this because merge-reports is a separate, green vitest invocation. Demonstrated on both ablation legs of PR #5411 with the same command and tree: red run → no coverage/; green run → coverage/ with coverage-final.json.

⚠️ This is why sharding may resolve half 2 of this card on its own — the card already flagged that possibility; it is now explained rather than suspected. If this card moves the lane onto the blob-report path, the directory stops being deleted as a side effect.

The decision routed here, deliberately undecided by #5402

Should vitest.config.mts set coverage.reportOnFailure: true, so a red run still emits a partial report?

• A — leave the default (false). Coverage only ever reflects a fully green suite; nothing partial can be mistaken for a real number.
• B — set it true. A red run leaves an artifact, making a future instance of this class diagnosable from the artifact rather than only from check-run annotations — but the file is partial and ⛔ must never be uploaded as if complete.

#5402's dev recommended routing it here (rather than deciding it in that PR) because this card owns ci.yml and the upload step, and deciding the config half separately would split one decision across two PRs. Their default preference was A, on the grounds that a partial report's value is diagnostic only and this particular failure was already fully diagnosable from the annotations.

⚠️ Note the interaction with half 2 of this card: with the upload step gated by its implicit success(), setting reportOnFailure: true alone would still upload nothing on a red run. The config and the upload gating are one decision, which is exactly why it belongs here. State which you chose and why — either is acceptable, silently doing neither is not.

⛔ Still pm:blocked on #5402 (PR #5411 open, gates running). Do not start until that lands and the push lane genuinely passes.

---

Generated by Claude Code

[os-support-ai]

Unblocked — and one correction to this card's own body before anyone acts on it

#5402 is fixed and merged (PR #5411, 2026-08-20T15:16:13Z). The Blocked-by: #5402 line in the body above is discharged; label swapped pm:blocked → pm:dispatched, read back and confirmed.

⚠️ Correction: "17 packages" in the Constraints section is wrong — it is 11

The body says "17 packages carry their own vitest.config.ts that does not re-export the root config." That is false, it is mine, and I have been repeating it in dispatch orders all session. Measured independently on origin/main:

	count
vitest config files, total	20
the root vitest.config.mts	1
configs that import the root config (covered — importing executes its module scope)	8 — core, react, types, components, fields, plugin-dashboard, apps/console, examples/schema-catalog
standalone configs (the real hole)	11 — plugin-calendar, -charts, -detail, -form, -gantt, -grid, -kanban, -list, -map, -timeline, -view

packages/core/vitest.config.ts is two lines re-exporting the root config; it was never uncovered. 17 was the count of all packages/* configs, which I garbled into "uncovered". #5313 had this right on 2026-08-19.

⚠️ The practical instruction is unchanged and still binding: run vitest from the repo root. Only the number was wrong, not the rule. And once PR #5412 (#5406) lands, all 11 are guarded, so a package-cwd run is refused everywhere — but ⛔ do not rely on that until it merges.

Re-verify the premise on the merged ref, do not inherit it

The unlock is exactly when a card's stated facts are least trustworthy. #5402 changed the thing this card measures: the coverage job was failing 100% of the time, and the 39 min 05 s / 12 min 04 s figures were taken while that was true.

Re-measure both arms on current main before concluding anything. In particular, #5402 removed a duplicated full-repo parse (that one test went 41,268 ms → 1 ms under coverage), so the unsharded baseline is now faster than 39 minutes and the 3.24× ratio in the body is stale. If the gap has narrowed enough to change the conclusion, ⛔ say so rather than shipping the sharding because the card said to — that is a fork for the maintainer, not a detail to smooth over.

The equivalence baseline (1287 files, onlyUnsharded=0, onlyMerged=0, −0.0437 pp against a 3-statement noise floor) is still the acceptance test either way.

---

Generated by Claude Code