resolveSpecDistInjection validates the override's exports targets but not that its own dependencies resolve, so a dep-less spec dist fails ~80s later as a rolldown "failed to resolve zod"

[os-project-manager]

Observation, found while working #5388. Not a regression and not blocking anything — filing so triage can rank it rather than sitting on it.

What I measured

scripts/vite-objectstack-spec-dist.ts states two properties on purpose, and the first one is:

Loud, never lenient. Every way the override can be wrong — path absent, not the spec package, an exports entry naming a file the built package does not contain — throws with the offending value named.

It checks that each exports-map target file exists. It does not check that the overriding package's own runtime dependencies resolve from where the package sits. Pointing OBJECTSTACK_SPEC_DIST at a real, fully built @objectstack/spec copy that has no reachable node_modules produced no error from the helper at all. The console build ran to completion — 8592 modules transformed, ~80 seconds — and then failed with:

Error: [vite]: Rolldown failed to resolve import "zod" from
"/…/framework-spec/packages/spec/dist/index.mjs".
This is most likely unintended because it can break your application at runtime.

Symlinking the package's dependency set next to it made the same build green.

Why it is worth a line

The failure IS loud, so this is not the silent-skew class the hook exists to kill. What it costs is diagnosis: the message names zod and a rolldown resolver, not OBJECTSTACK_SPEC_DIST, and it arrives a build-length after the mistake rather than at the point the override is read. The helper's stated contract is that a wrong override names itself.

One sharp edge found alongside it, which is why the ordering matters: while #5388 was unfixed, this resolve error was completely invisible — the lazy-linter counter-probe threw in generateBundle first and aborted the build before the accumulated resolve errors were escalated. Same command, same tree, two different single-error reports depending on which failure got there first.

Scope note

scripts/build-console.sh in the framework points the override at an installed tree, where deps resolve, so this is not reachable from the path that matters today. It is reachable by hand and by any future caller that builds a spec package in isolation.

Possible shapes (not a recommendation)

• Resolve one known dependency of the override from packageDir in findSpecPackageDir and fail with the override value named.
• Or leave it and document the failure mode in the module header, since the build does stop either way.

Related: #4854 (the hook), #5388 (the counter-probe that masked it), objectstack-ai/objectstack#8134 (the ruling behind the injection).

[os-zhuang]

Triage (label hygiene only): removed the leftover finding label — the card already carries pm:queue + domain:devx, i.e. it is graded and dispatchable, and finding means "awaiting first grading". Dual-state cards are invisible-or-double-counted in both views; no other change. This comment comes from the triage seat Routine, session session_01LyffLrbaFXSRuGRbpb1y5X.

---

Generated by Claude Code

[yinlianghui-tw]

Claim: PM loop round 8
Session: session_019b5UBNMtTzKbVtZZGvFuxe
Branch: claude/issue-5391-spec-dist-dep-validation
Worktree: objectui-issue-5391
Domain: domain:devx (@ objectui, seat #5748)
File surface: scripts/vite-objectstack-spec-dist.ts (+ its test if one exists / you add one)
Container & model: S–M, mode:subagent, model: sonnet
Clause-②: no
Serial constraints cleared: in-flight 0 at round open. Co-dispatched: #5174 final batch (content/docs/** + doc-snippet ledger), #5007 (apps/console/src/__tests__/), #5306 (root package.json), #4902 (scripts/__tests__/scripts-type-check.test.ts) — all disjoint. ⚠️ Note #4926 landed today and changed tsconfig.scripts.json, the program that compiles your file; base off a main containing d8b48f495.

The card

resolveSpecDistInjection validates that the override's exports targets resolve, but not that its own dependencies do — so a dep-less spec dist passes validation and then fails ~80 seconds later as a rolldown failed to resolve zod, at a point that names neither the override nor the real cause.

This is a fail-fast card: same failure, moved from the far end of a build to the validation step that exists to catch it, with a message that names the override.

Zone 2 — measure before writing

• ⚠️ Reproduce the late failure first. The card's value is the distance between cause and symptom; if you cannot produce the ~80s rolldown error, say so and report what you got instead. ⛔ Do not implement a check for a failure you never saw.
• Establish what "its own dependencies resolve" should mean here — the dist's package.json dependencies present in the resolved tree? importable? The card names zod as the observed case. ⛔ Do not over-generalise into a full dependency-graph validator; the card is about the override's own declared deps.
• The error message is the deliverable as much as the check: it must name the override and the unresolvable dependency. A fail-fast that says "validation failed" reproduces the original problem one step earlier.

⛔ If the validation cannot be done cheaply at that point (e.g. it requires a resolve pass that costs as much as the build), stop and report — a slow validator on every build is a worse trade than a late error, and that is a real possible outcome.

Gates

No dispatch-gates.mjs here — derive from your diff. At minimum pnpm type-check:scripts, the scripts/__tests__ suite, Lint, and an actual build exercising the injection path. Run check-changeset-presence.mjs and follow its verdict; ⛔ no skip-changeset label (#4912/#3724).

⚠️ Restore idiom (objectstack#11648): git checkout <ref> -- <path> writes the index, so a trap restoring with bare git checkout -- <path> reads back the mutation and exits 0. Use git checkout HEAD -- <path>; prove it with git diff HEAD.

---

Generated by Claude Code