`showcase-smoke.yml` acquires pnpm via `pnpm/action-setup@v6` — a third acquisition path that a `corepack enable`-keyed census cannot see

[os-steve]

Filed unassigned by the dev seat working #11369. ⛔ Not touched there — #11369's population was defined by corepack enable, and this site does not contain that string.

The observation

#11369 adopted .github/actions/setup-pnpm at all 16 corepack enable sites, taking .github/workflows/ to 0 occurrences across 0 files. That count is true and still leaves one workflow downloading pnpm per job, because it acquires pnpm by a different mechanism:

# .github/workflows/showcase-smoke.yml
 - uses: actions/checkout@v7
 - uses: pnpm/action-setup@v6 # <- not Corepack, so invisible to the census
 - uses: actions/setup-node@v7
 with:
 node-version: '22'
 cache: pnpm

Measured on origin/main: pnpm/action-setup appears in exactly 1 workflow (showcase-smoke.yml), and it is the only workflow using it. Control, so the 1 is not an artefact: corepack enable across .github/workflows/ is 0 post-#11369, while uses: ./.github/actions/setup-pnpm is 23.

Why this is worth recording rather than just fixing

This is the same asymmetry the #11369 card itself named, one level up. That card observed that a signature keyed on the step name Verify pnpm version under-reported the sites, because the unpaired ones downloaded inside a differently-named step. The same thing is true of the census keyed on corepack enable: it is now a complete answer about Corepack and reads as a complete answer about pnpm acquisition, which it is not. Anyone who greps corepack enable in six months gets 0 and concludes the class is closed.

Stakes: low, and deliberately stated as such

showcase-smoke.yml is workflow_dispatch + nightly (0 7 * * *), explicitly NON-BLOCKING ("it never gates PRs" — its own header). So a flake here is a red nightly, not a queue ejection and not a failed release. This is an observation, not a defect worth pre-empting a queued card for.

Also note it is not a pure swap: this job relies on actions/setup-node's cache: pnpm, which requires pnpm to be on PATH before the setup-node step runs — the opposite of the ordering every setup-pnpm caller uses (setup-node first, then the composite). Whoever picks this up should treat it as an ordering question, not a find-and-replace.

Dedup

Searched open issues before filing (showcase-smoke, pnpm/action-setup, pnpm acquisition, corepack, composite action): nothing covers this. #11369 is scoped to the Corepack population by its own measurement and does not reach here.

[os-steve]

Claim: devx lane PM seat, session e2eac1a7-8000-5c95-9749-38aec2ace6fc, branch claude/issue-11765-showcase-smoke-pnpm-path.

Graded pm:queue → pm:dispatched, domain:devx + ci/cd. Verified the premise by content on origin/main before grading: .github/workflows/showcase-smoke.yml:22 is uses: pnpm/action-setup@v6, and it is the only occurrence across .github/workflows/ — so it is genuinely a third acquisition path and not one of the sixteen corepack enable sites #11369 is converting.

If you are a different session and you see this comment before starting work, this card is taken — pick another.

---

Generated by Claude Code

[claude]

{
 "issue": 11765,
 "status": "done",
 "branch": "claude/issue-11765-showcase-smoke-pnpm-path",
 "pr": "https://github.com/objectstack-ai/objectstack/pull/11779",
 "premise_still_valid": true,
 "summary": "Premise held: showcase-smoke.yml:22 is `uses: pnpm/action-setup@v6`, the only occurrence across .github/workflows/, and its `cache: pnpm` (line 26) genuinely does require pnpm on PATH before setup-node. One correction to the card's stated control: `corepack enable` is 16 occurrences across 10 files at my merge base 5cb62d88b, NOT 0 -- the conversion PR had not landed, so that zero is still a projection. Chose (b): left the acquisition alone and built the census. (a) loses on cost/benefit and, more importantly, would have made the reported defect WORSE -- converting removes the last visible anomaly, so every mechanism-keyed count reads 0 and the class reads 'closed' with nothing keeping it closed; the census was needed either way, and once it exists conversion stops being urgent. (c) loses: pnpm/action-setup is the same exposure CLASS (per-job registry fetch of the pnpm tarball, uncached), just 1 nightly non-blocking job instead of the per-queue-build multiplier -- the card already stated its stakes as low and did not overstate them. New gate scripts/check-pnpm-acquisition.mjs is keyed on the NEED (every job that RUNS pnpm) rather than any mechanism spelling, which is the inversion that makes it self-repairing: an unknown mechanism cannot become a silent zero, it surfaces as a job running pnpm with no recognised acquisition. It also pins the setup-node store-cache ordering that killed two jobs here with 'Unable to locate executable file: pnpm', which is what makes showcase-smoke's inverted order safe to leave. Full census confirms NO fourth path: the 7 workflows mentioning pnpm without acquisition are dependency-free and name it only in comments; release.yml's docker job delegates to docker-publish.yml (0 pnpm mentions); docker/Dockerfile installs the CLI via npm, not pnpm.",
 "tests": "All on the tree at 44fecec83, clean working tree. (1) FULL repo lint, no narrowing: `eslint . --no-inline-config` (== `pnpm lint`) -> exit 0, 5019 files linted, 0 findings; population read from eslint's own config, count from --format json; scripts/check-pnpm-acquisition.mjs confirmed IN that population at 0e/0w, so the zero is a measurement not an exclusion. (2) `pnpm check:pnpm-acquisition` -> exit 0, printing 'check-pnpm-acquisition: OK'; self-test '12 cases pass (real fixture roots through the real scan())' covering both population traps (pnpm-lock.yaml must not count; a comment-only mention must not count -- 7 real workflows depend on that), all five recognised spellings, both ordering failures, and the reusable-workflow job. (3) Gate families derived by `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack` with NO paths passed; all green: agent-test-spelling, cross-package-test-inputs, entry-guard, node-version, parse-guard, pnpm-acquisition, pnpm-filter-targets, required-contexts, shard-attestation, workflow-status-functions, aggregator-roster, step-collectors, ci-failure --self-test, nul-bytes, type-check-coverage. (4) check:type-check-debt DECLINED to run locally -- a precondition, not a red: it refuses to measure without a built workspace closure ('would silently measure a DIFFERENT WORLD'); CI builds it at lint.yml:3426 immediately before the step, and this diff has no .ts, no tsconfig and no ledger file so it cannot move a debt number. ABLATIONS: no rebuild leg applies -- the gate is a .mjs script reading .github/workflows/ from disk at runtime, nothing is compiled and no dist/ is involved, so the only falsifiable step is that the mutation reached disk, which was confirmed on EXACT anchors (not bare `git diff --stat`) each time. Both carried `trap '<git checkout -->' EXIT INT TERM`; tree verified byte-identical to the commit afterwards. Ablation 1 (delete the acquisition step; anchor '^ - uses: pnpm/action-setup@v6$' confirmed 1->0): gate exit 0->1 reporting 'showcase-smoke.yml:51 (job: smoke) -- runs pnpm but no step in the job acquires it by any recognised mechanism', action-setup census row 1->0, CONTROLS composite 7->7 and corepack-inline 16->16 unmoved. Ablation 2, the naive conversion this card invites (move acquisition below setup-node, keep `cache: pnpm`; on-disk confirmed acquisition still present=1, cache: pnpm still present=1, order inverted to lines 50/51): gate exit 0->1 reporting the setup-node store-cache ordering failure while EVERY mechanism count stayed put (7/1/16/0/0) -- the sharpest control, proving the failure is about order and not population.",
 "open_questions": [],
 "out_of_scope_findings": []
}

---

Generated by Claude Code