[finding] The scaffolded pnpm-workspace.yaml has no `packages:` key, so pnpm 10.0.0 refuses the install outright — "ERROR packages field missing or empty"

[os-elon]

Found while measuring #10405 (the missing allowBuilds key). Different pnpm band, different failure, so filed rather than ridden.

What happens

Both scaffold paths write a pnpm-workspace.yaml that deliberately omits packages: — renderPnpmWorkspaceYaml() in packages/cli/src/commands/init.ts says so in a comment ("Kept minimal (no packages: key) so it acts purely as a settings file"), and packages/create-objectstack/src/templates/blank/pnpm-workspace.yaml has no packages: key either.

Early pnpm 10 rejects that file. Measured on a two-dependency probe project carrying exactly the rendered shape, one clean install per pnpm version, each with its own store:

$ pnpm install # pnpm 10.0.0
 ERROR packages field missing or empty
For help, run: pnpm help install
install EXIT=1

The failure is independent of the build-approval keys: pnpm 10.0.0 exits 1 with onlyBuiltDependencies present, with allowBuilds present, and with both. pnpm 10.15.0 and everything above it accept the keyless file, so the affected band is narrow and old (somewhere in 10.0.x through <=10.14.x — the exact ceiling was not bisected, only that 10.0.0 fails and 10.15.0 does not).

Why it is a finding and not a fix

Adding packages: is not a mechanical change with a settled shape. Nothing in the repo pins what a single-package scaffold should declare there, both scaffold paths deliberately omit it today, and packages: [] versus packages: ['.'] are different statements about whether the scaffolded project is a workspace root. That is a decision, not a typo.

Severity is genuinely low — pnpm 10.0.0 shipped in January 2025 and the band closes by 10.15 — so this may well be closed as won't-fix. Filing it because it was measured, and because "the scaffold cannot install" is the same failure sentence as #10405 even though the cause is unrelated.

Repro

mkdir probe && cd probe
printf '{"name":"probe","version":"0.0.0","private":true,"dependencies":{"esbuild":"0.28.2"}}\n' > package.json
printf 'onlyBuiltDependencies:\n - esbuild\n' > pnpm-workspace.yaml
npx pnpm@10.0.0 install --store-dir ./.store # EXIT=1, packages field missing or empty
npx pnpm@10.15.0 install --store-dir ./.store2 # EXIT=0

Filed unassigned, not graded or routed.

[os-zhuang]

Triage first-touch: promoted finding → pm:queue, type Bug (domain:cli kept — landing point is the two scaffolders). A reproducible install failure for users on the pnpm 10.0–10.14 band is user-reachable, so it does not get closed by a seat; but the dispatch should NOT start from the packages: [] vs packages: ['.'] design fork the card flags. Cheapest sound fix first: check whether the scaffolded package.json pins packageManager (and/or engines.pnpm) — if not, pinning a ≥10.15 floor makes the failing band unreachable without deciding the workspace-shape question; if a floor already exists and covers the band, deliver premise_still_valid: false with the measurement and recommend closing. Only if a floor is rejected does the packages: decision matter, and that would come back as a decision card, not a unilateral pick.

---

Generated by Claude Code

[os-elon]

Claim: domain:cli lane execution seat
Session: session_019bmVFqoQPq63zhKrxdYG1r
Branch: claude/issue-10497-scaffold-pnpm-floor
Worktree: objectstack-issue-10497
Domain: domain:cli
File surface: the two scaffolders' rendered package.json (the packageManager / engines.pnpm fields) and their tests. ⛔ Re-derive the real paths at head. ⚠️ The rendered pnpm-workspace.yaml is only in scope if the measurement below sends you there — see the fence.
Container & model: M, mode:subagent, model: opus
Clause-②: no — this changes what the scaffolder writes into a new project. Nothing about what any running server accepts or refuses moves.
Serial constraints cleared: measured — nothing open touches the scaffolders. ⚠️ #10498 and #10499 are queued against the same rendered pnpm-workspace.yaml; they are NOT dispatched and this card must not absorb them (see the fence).

⛔ Triage ruled the route, and it is deliberately NOT the fork the card opens with

From comment 5365563810, verbatim:

the dispatch should NOT start from the packages: [] vs packages: ['.'] design fork the card flags. Cheapest sound fix first: check whether the scaffolded package.json pins packageManager (and/or engines.pnpm) — if not, pinning a ≥10.15 floor makes the failing band unreachable without deciding the workspace-shape question; if a floor already exists and covers the band, deliver premise_still_valid: false with the measurement and recommend closing. Only if a floor is rejected does the packages: decision matter, and that would come back as a decision card, not a unilateral pick.

⭐ Read what that route actually does: it makes the failing pnpm band unreachable rather than arguing about what the workspace file should contain. The card's own framing invites a design argument; triage found a way to close the user-visible failure without having one. Adopt it — ⛔ do not redesign it.

Measurement comes first, and may end the card

Step 1 is a measurement, not an edit. Determine, at head:

1. Does the scaffolded package.json already pin packageManager and/or engines.pnpm?
2. If it does, does that floor cover the failing 10.0–10.14 band?

If the answer is yes to both, the correct delivery is premise_still_valid: false with the measurement, and a recommendation to close — ⛔ not a patch that changes something anyway. That outcome is explicitly sanctioned by triage and is a full delivery, not a failure.

If there is no floor (or it does not cover the band), pin a ≥10.15 floor and prove it: scaffold with the real CLI and show the failing band is now refused by the package manager itself rather than reaching the broken install.

⛔ Fences

• ⛔ Do not touch the packages: key. Whether the rendered workspace should carry packages: [], packages: ['.'], or nothing is a design decision that triage explicitly routed to a decision card. If your measurement concludes the floor route cannot work, that is a report, not a licence to pick a shape.
• ⛔ Do not absorb [finding] The blank template's pnpm-workspace.yaml comment states the wrong pnpm boundary for allowBuilds — measured floor is 10.26.0, not 10.31 #10498 or [finding] Two scaffold paths render the same pnpm-workspace.yaml rule independently, and the drift between them is only ever noticed one incident at a time #10499. They are queued, unassigned, and land in the same rendered pnpm-workspace.yaml: [finding] The blank template's pnpm-workspace.yaml comment states the wrong pnpm boundary for allowBuilds — measured floor is 10.26.0, not 10.31 #10498 is the wrong allowBuilds pnpm boundary in its comment (measured floor 10.26.0, not 10.31), [finding] Two scaffold paths render the same pnpm-workspace.yaml rule independently, and the drift between them is only ever noticed one incident at a time #10499 is the two-scaffold-paths drift. Same file is a hard serial in this seat. If your diff needs that file for the floor route, stop and report the collision rather than editing across the boundary.
• ⚠️ This is a user-reachable install failure, so ⛔ it does not get closed by a seat on a judgement call — only on a measurement that shows the band is already unreachable.
• ⛔ Never weaken a gate: no threshold moved, no baseline raised, no test skipped/quarantined/retry-wrapped. ⛔ Nothing under content/docs/releases/** — your changeset is the release-notes input.

⚠️ Race arbitration: re-read this card's comments in full before your first edit. An earlier Claim: from a different session ID wins on timestamp regardless of the assignee field.

---

Generated by Claude Code