`changeset-release.yml`: drop the duplicate `pnpm test`, and stop concurrency discarding release runs (95 of 200 never executed)

[os-support-ai]

Blocked-by: #5403

Ruled by the maintainer on 2026-08-20 (#5393, verbatim 「接受你的所有建议，现在开始处理。」). Item 3 of 5, and last on purpose — see the ordering note below. Both halves are in changeset-release.yml, so one card, one PR.

Half 1 — the duplicate test run

Run tests (pnpm test, unsharded) is 34 minutes of a ~35-minute job; everything else combined is ~90 seconds (install 7 s, build 35 s, publish 12 s). It re-tests a commit that is already on main — failing it cannot keep anything out, it only blocks publishing after the fact.

Half 2 — runs are being discarded, not queued

concurrency: ${{ github.workflow }}-${{ github.ref }} with cancel-in-progress unset. I originally described this as serialising with a ~35-minute wait. #5395 refuted the magnitude and found something worse: GitHub holds only one pending run per group and discards the rest — 95 of 200 release runs never executed at all. Median wait for those that did run is 5 min 08 s (22% of wall clock), not ~35 min.

So the defect is not latency. Release runs are being thrown away, on a workflow whose last step publishes to npm.

⛔ Do not fix this with cancel-in-progress: true. The final step is changeset publish; cancelling mid-publish is worse than any wait. The requirement is that no merge loses its release run — find the shape that achieves that (a queue that actually queues, or a design where a dropped run is provably harmless because the next run subsumes it). If the second is true, prove it rather than asserting it: show that a discarded run's changesets are still consumed by the following run.

⚠️ Half 1 makes half 2 much cheaper — a ~2-minute job contends far less than a 35-minute one — but ⛔ it does not make half 2 unnecessary. A dropped run is a dropped publish at any duration.

⚠️ Why this card is last, and what must be true before it lands

I originally proposed removing the release-side tests first, arguing the CI push lane still ran the whole suite as a backstop. That argument was false: #5402 shows Test (coverage) has failed 100% of the time since 2026-08-16.

So this card may only land once both are true, and the implementer must verify both on origin/main before opening the PR, not take this card's word for it:

1. 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 is fixed — the push lane's suite actually passes.
2. Shard Test (coverage) 4 ways and stop the Codecov upload being skipped by its implicit success() #5403 has landed — the push lane is sharded and its upload no longer fails silently.

If either is not true when you pick this up, stop and report rather than proceeding — removing this test run while the push lane is dark would leave main with no working post-merge validation at all.

⚠️ Related context the implementer should read but not act on: the merge queue currently runs no CI (#4986 — a repository-settings matter, ⛔ no PR can fix it), and the release PR itself runs no CI (#5397). Neither blocks this card; both mean there is less validation upstream than the workflow's design assumes.

⛔ Constraints

• ⛔ changeset:publish behaviour is not in scope and must not change. ⛔ No AI-executed release.
• ⛔ Do not touch changeset:version — fix(release): carry QUICK_REFERENCE's Current Release block in changeset:version #5396 just wired the QUICK_REFERENCE sync into it, and a pin in sync-quick-reference-release.test.ts asserts this workflow's version: input. If your change trips that pin, that is the pin working; do not weaken it.
• Report elapsed from the jobs' own started_at/completed_at.

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

[os-support-ai]

Unblocked — and my stated precondition for this card was wrong

Both gating conditions in the body are now met, and the second one needs a correction rather than a tick.

1. Shard Test (coverage) 4 ways and stop the Codecov upload being skipped by its implicit success() #5403 landed — PR ci: shard the coverage lane 4 ways and make a skipped Codecov upload loud #5423, merged 17:03:13Z. The push lane is sharded (39 min → ~12 min) and a skipped upload is now loud.
2. 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's fix did what it claimed. I amended this card to say its precondition was "now The suite is still red under v8 coverage on main after #5402 — shard 3/4 fails deterministically and the unsharded run leaves no coverage/ at all #5421, not merely Shard Test (coverage) 4 ways and stop the Codecov upload being skipped by its implicit success() #5403", on the strength of The suite is still red under v8 coverage on main after #5402 — shard 3/4 fails deterministically and the unsharded run leaves no coverage/ at all #5421's report that the suite was still red under v8 coverage. The suite is still red under v8 coverage on main after #5402 — shard 3/4 fails deterministically and the unsharded run leaves no coverage/ at all #5421 has been refuted and closed not planned — its shard-3 failure was ci-cd-pipeline-doc.test.ts reacting to a workflow file that exists only on the throwaway measuring branch, whose sha1 happened to hash into shard 3/4. The instrument perturbed its own measurement.

Current main: all four coverage shards green — CI run 32397046084 on 32ef595f4, plus a local --shard=3/4 --coverage at 431 files / 5546 tests / exit 0.

So the backstop this card depends on — "the push lane actually runs and passes the suite" — is real. Label swapped pm:blocked → pm:dispatched.

⚠️ One live caveat, and it does not block this card

Test (coverage) is still red on every push to main, but for a reason that has nothing to do with the suite: CODECOV_TOKEN is unset (Token length: 0; Codecov answers Token required - not valid tokenless upload). Filed as #5436; it needs a maintainer action plus a policy choice.

That matters here only as a boundary: this card removes the release job's duplicate pnpm test because the push lane tests the same commit, and it does — the merge step succeeds and the thresholds are enforced there. The red is the upload, downstream of enforcement. ⛔ Do not treat #5436 as a reason to widen this card, and ⛔ do not "fix" the red by touching the upload — that is #5436's, and the loud-failure behaviour was accepted deliberately on #5403.

---

Generated by Claude Code

[os-support-ai]

Claim: PM loop round 22
Session: session_01RV6yuVCxymHYE16PL9vQkE
Branch: claude/issue-5404-release-lane-tests-and-concurrency
Worktree: objectui-issue-5404
Domain: repo:objectui
File surface: .github/workflows/changeset-release.yml only (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Clause-②: no — removes a duplicate test execution and changes how release runs are scheduled; no contract, no public surface, no assertion changed
Serial constraints cleared: changeset-release.yml is untouched by everything in flight — #5365 owns packages/components + packages/layout, #5358 has no file surface, #5378+#5377 own plugin-detail/react/the guide. ⛔ .github/workflows/ci.yml belongs to #5403, merged, and is out of bounds here. ⚠️ changeset:version must not be touched: #5396 wired the QUICK_REFERENCE sync into it and sync-quick-reference-release.test.ts pins this workflow's version: input — if your change trips that pin, that is the pin working.

Item 3 of 5 in the maintainer's 2026-08-20 ruling on #5393, and the last one outstanding.

---

Generated by Claude Code