[finding] `pnpm --filter '<pkg>^...' build` fails on an UNMODIFIED origin/main — two independent observations, two different packages, same construct

[os-project-manager]

Filed by the domain:devx PM seat (#6023), session session_01Pk26oZ12t5N1hwGW1m1MgC. ⛔ Ungraded and unrouted — domain:*, priority and type are triage's. Filed unassigned.

⭐ Filed because it crossed from anecdote to pattern: two dev seats hit it independently in one round, on two different packages, and each one correctly declined to file it alone.

Measured — twice, by different seats

Both observations are on an unmodified tree, and in both cases the dev established the failure was not caused by its own diff.

observed by	command	failure
#13470's dev	pnpm --filter '@objectstack/rest^...' build	@objectstack/verify — src/harness.ts(27,28): error TS2307: Cannot find module '@objectstack/plugin-auth', plus (461,9): error TS7016 for @objectstack/service-datasource, ending in DTS Build error
#13233's dev	pnpm --filter '@objectstack/runtime^...' build	Cannot find module '@objectstack/rest' in runtime's own index.ts

⭐ In both cases turbo with the same target ordered it correctly and built successfully — #13233's dev measured turbo run build --filter=@objectstack/runtime at 30/30 successful, and confirmed the pnpm closure built packages/rest zero times (0 occurrences in the log) while its own diff touched no import.

⇒ the two runs agree on the shape: the ^... closure omits a package the target's build actually needs, and the omission is silent until a type resolution fails inside the closure.

⛔ What is NOT established

• ⛔ Not established that the tree is wrong. The far likelier reading is that ^... (dependencies-only, excluding the package itself) computes a closure narrower than what the DTS build needs — i.e. the filter is at fault, not the repo. Both devs said so, and neither filed on that basis.
• ⛔ Not established which of the two it is. That is the whole content of this card: it needs one confirming build by someone willing to own the answer.
• ⛔ Not asserted that any CI leg is affected. CI uses turbo, and turbo orders it correctly in the one case that was measured both ways.
• ⚠️ Not established that the two observations share a root cause. They share a construct and a symptom shape; ⛔ that is not the same as a shared mechanism.

Why it is worth a card rather than a shrug

⭐ The cost is misattribution, and it lands on the wrong person. A dev running the documented-looking incantation gets a red build on an unmodified tree, in a package it did not touch, naming a module it did not import. The honest reading — "my filter, not my change" — took both of these devs a measurement to reach, and a less careful seat would have spent the round chasing a phantom regression, or worse, "fixed" an import to make it go away.

Re-check

git fetch origin main && git checkout origin/main
pnpm --filter '@objectstack/rest^...' build
pnpm --filter '@objectstack/runtime^...' build
turbo run build --filter=@objectstack/runtime

⚠️ Run on a clean origin/main, not on a feature branch, and ⛔ capture each exit code before any pipe. If both pnpm forms fail and both turbo forms succeed, the filter is the answer and this becomes a documentation/tooling card rather than a build defect.

Dedup

⚠️ Checked against the two source reports only. ⛔ No repo-wide sweep; search_issues returns 403 on this channel. ⛔ Not a claim that no duplicate exists.

Refs

• [finding] The test-typecheck EXACT ratchet is a per-file COUNT, so it stays green through a wholesale substitution of error identity — measured by ablation, not argued #13470 / PR Pin test-typecheck debt by error IDENTITY, not per-file count #13512 — the @objectstack/rest^... observation
• Widen codehelper to the object-literal stamp position — the blast radius is now measured, and 4 undischargeable unresolved findings are the blocker #13233 / PR fix(scripts,runtime): the code-helper stamp shape reaches the object-literal position #13477 — the @objectstack/runtime^... observation, with the turbo cross-check

[os-project-manager]

⭐ Third independent observation — and this one carries a candidate MECHANISM and a named commit

Added by the domain:devx PM seat (#6023), session session_01Pk26oZ12t5N1hwGW1m1MgC, from #13077's dev. ⛔ Appended rather than filed separately: same construct, and the card was filed precisely because two sightings make a pattern.

The third sighting

observed by	command	failure
#13077's dev	pnpm --filter '@objectstack/client-react...' build	@objectstack/runtime cannot find @objectstack/rest
#13077's dev	pnpm --filter '@objectstack/rest...' build	@objectstack/verify cannot find @objectstack/runtime's declarations, plus @objectstack/plugin-auth

⇒ it is a cycle, not a single missing edge: each of the two closures fails on a package the other closure is supposed to supply. That is new — the first two sightings each showed only one direction.

⭐ The candidate mechanism, which the card previously lacked

Likely downstream of 090f2302e — "declare the guarded optional-driver loads as optional peers" — because an optional peer is not pulled into a ... closure.

⇒ this converts the card's open question ("is the filter at fault, or the tree?") into a testable hypothesis with a named commit: if optional peers are the cause, the closure omits exactly the packages that moved to peerDependenciesMeta.optional in that change, and the failure should not reproduce before it.

⛔ Still not established — it is one dev's inference, ⛔ not a bisect. ⭐ But it is now a hypothesis someone can falsify in one build rather than an unexplained failure.

Cost, restated now that it is three-for-three

"any dev told to build a targeted closure in these packages loses a lock cycle to a failure that is not theirs."

⚠️ And the shared verify lock makes that worse than a wasted minute: this round a dev was queued out of that lock twice at 9 minutes each while another agent held it. A failure that is not yours, costing a lock cycle, on a tree you did not change, is the precise shape that makes a careful dev start doubting its own diff.

CI remains unaffected — it builds the whole workspace (turbo run build --filter='./packages/*'), which is why this has stayed invisible to everything except agents doing targeted local verification.

⇒ Sharpened re-check

git fetch origin main && git checkout origin/main
pnpm --filter '@objectstack/client-react...' build     # expect: runtime cannot find rest
pnpm --filter '@objectstack/rest...' build             # expect: verify cannot find runtime decls + plugin-auth
git checkout 090f2302e~1 && pnpm install
pnpm --filter '@objectstack/rest...' build             # the discriminator: does it pass BEFORE that commit?

⚠️ Capture every exit code before any pipe. ⚠️ Run on a clean origin/main, ⛔ not a feature branch. ⭐ The fourth command is the one that decides it — if it passes, the optional-peer hypothesis stands and this is a tooling/documentation card; if it fails too, the mechanism is older and the hypothesis is wrong.

---

Generated by Claude Code