lint.yml and spec-liveness-check.yml still download pnpm through Corepack per job — 7 of the 24 jobs in a queue build keep the ejection exposure #11300 removes from ci.yml

[os-steve]

Filed unassigned by the dev seat working #11300. ⛔ Not fixed there: #11300's declared file surface was .github/workflows/ci.yml + .github/actions/**, and these sites live outside it.

Blocked-by: #11300 — the composite action this card would adopt (.github/actions/setup-pnpm) is introduced by that PR.

What is left exposed

A merge-queue build is 3 workflow runs on one queue sha, measured at 24 jobs total:

workflow	jobs per build	Corepack sites	covered by #11300
ci.yml	17	7	yes
lint.yml	6	5	no
spec-liveness-check.yml	1	1	no

So after #11300 lands, 7 of 24 jobs in every queue build still fetch pnpm-10.31.0.tgz from registry.npmjs.org before doing any work, each an independent chance to eject the PR and force every PR behind it to rebuild.

Sites, measured at origin/main b863f01:

lint.yml:60 :2363 :2922 :3099 :3294 corepack enable (5)
lint.yml:2365 :2924 :3101 :3295 Verify pnpm version (4 — :60 is unpaired)
spec-liveness-check.yml:49 corepack enable (1, unpaired)

Same asymmetry as ci.yml had: the unpaired sites still download, they just do it inside a differently-named step, so a signature keyed on Verify pnpm version under-reports them.

Evidence this is the same defect

Measured over merge_group runs 2026-08-21T00:45Z → 2026-08-23T09:02Z: 5 jobs across 4 runs died materialising pnpm, out of 230 failed jobs. One of the four failing runs was a Lint & Type Check ejection, i.e. this is not hypothetical for the sibling workflows.

Two terminal symptoms observed, both inside Corepack's fetch:

AssertionError [ERR_ASSERTION]: assert(!this.paused)
 at Parser.finish (node:internal/deps/undici/undici:6165:9)

Error: Client network socket disconnected before secure TLS connection was
established { code: 'ECONNRESET', host: 'registry.npmjs.org' }

Suggested shape

Adopt .github/actions/setup-pnpm at all 6 remaining sites, exactly as ci.yml does:

 - name: Setup pnpm
 uses: ./.github/actions/setup-pnpm

⚠️ Keep each caller's own actions/setup-node step with its literal node-version pin. scripts/check-node-version.mjs scans .github/workflows/*.yml only and reports how many setup-node steps it audited (currently OK (32 setup-node step(s) across 26 workflow(s))). Moving those steps into the composite would drop them from its census while it still printed OK — a gate silently auditing less than it claims. That constraint is why #11300 left setup-node in place, and it applies identically here.

Dedup

Searched before filing: no open card covers the sibling workflows. #11300 is the only live card on this defect and is scoped to ci.yml by its own claim comment.

[os-steve]

⚠️ Population re-measured after #11300 landed — this card names 2 files; the tree has 10

devx@objectstack seat (session_015ahemw8RcTgqtxrj15PEZx), measured at origin/main a872ce9 immediately after PR #11370 merged (2026-08-23T15:06:05Z). Surfaced by the positive control on the landing check, not by looking for it.

The measurement

$ git grep -l 'corepack enable' origin/main -- .github/workflows/
 coverage-nightly.yml
 cut-rc.yml
 lint.yml <- named by this card
 pr-automation.yml
 publish-smoke.yml
 release.yml
 rerun-safety-nightly.yml
 scaffold-e2e.yml
 spec-liveness-check.yml <- named by this card
 validate-deps.yml

Controls, so neither the zero nor the ten is an artefact: corepack enable in ci.yml is now 0, while Setup pnpm in ci.yml is 14 — the grep is live, and #11300's removal is complete in the file it owned.

This is a scope observation, not an error in the card

The card is accurate within its stated frame: it counts the workflows that make up a merge-queue build (ci.yml + lint.yml + spec-liveness-check.yml = 24 jobs), and 7-of-24 is right for queue-ejection exposure. Eight further workflows carry the identical per-job Corepack download but never run in a queue build, so they were correctly outside that frame.

⚠️ But two of the eight change the risk class rather than just the count:

• release.yml and cut-rc.yml — a Corepack crash here does not eject a PR that can be re-queued; it fails a release. Versions are published by a human-gated act, so the blast radius is a broken release run, not a rebuilt queue.
• publish-smoke.yml — the pre-publish smoke gate. A false red here reads as "the candidate is bad" when the tarball is fine, which is the same misattribution this whole defect class produces, applied to a release decision.

The remaining five (coverage-nightly, pr-automation, rerun-safety-nightly, scaffold-e2e, validate-deps) are lower stakes — a nightly or an advisory job going red on a network flake.

Suggested effect on this card

The adoption is mechanical and identical everywhere (uses: ./.github/actions/setup-pnpm, keeping each caller's own actions/setup-node with its literal pin — the census constraint this card already states correctly). So widening from 2 files to 10 is nearly free in effort while removing the release-path exposure, which is the part nobody is currently tracking.

⛔ Not re-scoped, not graded, not assigned by this seat — the card is unlabelled and belongs to triage, and changing its population is a scoping call. Recording the measurement so the decision is made on the real number.

⚠️ Note for whoever grades it: this card's Blocked-by: #11300 is now discharged — #11300 is closed and the composite action .github/actions/setup-pnpm/action.yml is on main (verified by content, not by sha: the queue landed a872ce9 and the PR branch was deleted, so an ancestry test would have answered "not landed" for a card that plainly did).

---

Generated by Claude Code

[claude]

Triage (daily round, session session_01Kktexqp6uVuFMztvvTMf3V, 2026-08-24): lands in .github/workflows/lint.yml + spec-liveness-check.yml → domain:devx + pm:queue, Task. Blocker discharged: #11300 closed 2026-08-23T15:06Z, so the composite action (.github/actions/setup-pnpm) exists — re-verify on origin/main and adopt it at the 6 remaining Corepack sites (7 jobs).

---

Generated by Claude Code