Filed unassigned by the domain:devx @ objectui execution seat (#5748), PM session session_012CZgmFFzqA9cX8tBMhvpFe, R32. ⛔ I do not set domain:* or type labels — routing and grading are the triage seat's.
Observed by the dev on #6369, flagged in PR #6389's body under "Note, not asserted", and deliberately not acted on — removing them is a judgement it declined to make inside a card about the merge driver. Correct call; it becomes its own card here.
⛔ Blocked-by: PR #6389. The premise does not exist until that PR lands — today the driver body (pnpm install --no-frozen-lockfile) is still in the file, so pnpm is still nominally needed. Do not dispatch this before #6389 merges.
The residue
.github/workflows/dependabot-auto-merge.yml :91–95 sets up pnpm:
corepack enable
pnpm --version
The job's own comment at :101 states it never runs pnpm install (it exists to explain why cache: 'pnpm' is deliberately absent — without a pnpm store, setup-node's post-job cache save fails with "Path Validation Error" and marks the whole job failed).
Once PR #6389 removes the merge-driver step, the driver body was the only thing in that job that needed pnpm at all. What remains is a package manager enabled and version-printed for no consumer.
Boundaries, stated so the next reader does not over-cut
- ⛔
actions/setup-node must stay regardless. scripts/dependabot-merge-gate.mjs is a node step and needs a Node runtime. This card is only about the two pnpm lines, not the Node setup around them.
- ⚠️
pnpm --version may not be dead weight. It is a cheap fail-fast that proves corepack actually activated; if something later in the job grows a pnpm dependency, its absence would surface as a confusing failure instead of a clear one. Whoever takes this should decide whether that is worth two seconds of runtime, and record the reasoning in the file either way — an unexplained removal is how the next reader re-adds it.
- ⚠️ The
cache: 'pnpm' comment at :101 is load-bearing and describes a real failure mode. If the pnpm steps go, that comment needs re-reading rather than deleting — it may still be the right warning for the next person who reaches for the cache option.
Why it is a finding rather than a queued fix
Nothing is broken. The cost is a few seconds of CI and one more thing a reader has to explain to themselves. It is recorded because it is the third residue in this file's neighbourhood traceable to one over-wide instruction — see #6369's disposition 3 for the sentence that produced the dead copies — and a job that sets up a tool it never uses is how the next dead step gets justified.
Related: #6369 / PR #6389 (removes the step that made pnpm necessary here) · #6358 / PR #6367
Generated by Claude Code
Filed unassigned by the
domain:devx@ objectui execution seat (#5748), PM sessionsession_012CZgmFFzqA9cX8tBMhvpFe, R32. ⛔ I do not setdomain:*or type labels — routing and grading are the triage seat's.Observed by the dev on #6369, flagged in PR #6389's body under "Note, not asserted", and deliberately not acted on — removing them is a judgement it declined to make inside a card about the merge driver. Correct call; it becomes its own card here.
⛔ Blocked-by: PR #6389. The premise does not exist until that PR lands — today the driver body (
pnpm install --no-frozen-lockfile) is still in the file, so pnpm is still nominally needed. Do not dispatch this before #6389 merges.The residue
.github/workflows/dependabot-auto-merge.yml:91–95sets up pnpm:The job's own comment at
:101states it never runspnpm install(it exists to explain whycache: 'pnpm'is deliberately absent — without a pnpm store,setup-node's post-job cache save fails with "Path Validation Error" and marks the whole job failed).Once PR #6389 removes the merge-driver step, the driver body was the only thing in that job that needed pnpm at all. What remains is a package manager enabled and version-printed for no consumer.
Boundaries, stated so the next reader does not over-cut
actions/setup-nodemust stay regardless.scripts/dependabot-merge-gate.mjsis anodestep and needs a Node runtime. This card is only about the two pnpm lines, not the Node setup around them.pnpm --versionmay not be dead weight. It is a cheap fail-fast that proves corepack actually activated; if something later in the job grows a pnpm dependency, its absence would surface as a confusing failure instead of a clear one. Whoever takes this should decide whether that is worth two seconds of runtime, and record the reasoning in the file either way — an unexplained removal is how the next reader re-adds it.cache: 'pnpm'comment at:101is load-bearing and describes a real failure mode. If the pnpm steps go, that comment needs re-reading rather than deleting — it may still be the right warning for the next person who reaches for the cache option.Why it is a finding rather than a queued fix
Nothing is broken. The cost is a few seconds of CI and one more thing a reader has to explain to themselves. It is recorded because it is the third residue in this file's neighbourhood traceable to one over-wide instruction — see #6369's disposition 3 for the sentence that produced the dead copies — and a job that sets up a tool it never uses is how the next dead step gets justified.
Related: #6369 / PR #6389 (removes the step that made pnpm necessary here) · #6358 / PR #6367
Generated by Claude Code