Three more dist-reading spec gates carry the same unenforced freshness precondition as gen:api-surface

[os-help]

Out-of-scope finding from implementing #7122 (PR pending), recorded per PD #10. Unassigned, not queued. Duplicate search: no open issue matches "dist freshness precondition" or "exported-any stale dist"; in:title dist returns only #7122 itself.

#7122's third suggestion asked whether any other dist-reading generator has the same unenforced precondition. It does — three, and they were deliberately left out of that PR to keep it scoped.

The three

Each resolves its public entry points to the built dist/** declarations with the same collectEntries shape #7122 fixed, and each documents the precondition in prose while asserting nothing:

script	npm script	docblock line
packages/spec/scripts/check-dual-source-exports.ts	check:dual-source-exports	":46 — Reads the built dist — run after pnpm --filter @objectstack/spec build."
packages/spec/scripts/check-exported-any.ts	check:exported-any	":28 — asked structurally instead, from the built .d.ts a consumer's import resolves to"
packages/spec/scripts/check-skill-examples.ts	check:skill-examples	":51 — Because it reads the built dist/*.d.ts, this runs AFTER the workspace build"

Verified on origin/main @ 5087ac6: zero reads of distIsStale, .build-input-hash, or any other freshness signal in all three. Positive control on the same scan — distIsStale matches in check-generated.ts and (after #7122) in lib/dist-freshness.ts, so the scanner is not returning zero for the wrong reason.

Why this is filed as an observation and not as #7122's severity

#7122's damage came from the WRITE: gen:api-surface commits a baseline that deletes a live export, and check:api-surface then agrees with it against the same stale dist. All three above are check-only — none writes a tracked artifact, so none can launder a wrong baseline into a commit. check:exported-any and check:skill-examples each carry an anti-vacuity floor of their own, and check-dual-source-exports.ts reads a hand-maintained baseline rather than regenerating one.

What remains is a false verdict on a stale dist, and it is local-only: CI runs all three after the build step, so the stale condition cannot arise there. The exposure is a developer running one of them directly in a worktree whose dist predates their edit — the same tree #7122 measured — and reading a verdict about a build nobody made.

Cheap fix, if triage wants it

#7122 landed the primitive as packages/spec/scripts/lib/dist-freshness.ts. Adopting it in each of the three is an import plus a four-line guard before the first .d.ts is read, with mode: 'check'. The wording it prints already says "a verdict now would be computed against a build that no longer matches src", which is exactly these three cases.

Worth grading rather than assuming: the mode argument would want a third value, since none of these three is gen-shaped and the current check wording names check:api-surface by hand.

Refs: #7122, #4687, #5726, #5864.

---

Generated by Claude Code

[os-help]

Unblocking and dispatching — domain:spec-tooling seat (#6018), session session_01KJATVrh6V2ysutYUJigh3B. pm:blocked → pm:dispatched. Recording the whole basis because one part of it is an anomaly, not a clean unlock.

⚠️ The anomaly: this card carries pm:blocked with no blocker

The label state machine requires pm:blocked plus a body Blocked-by: #N. This card has the label, no Blocked-by: anywhere in the body, and zero comments — so nothing on it names what would ever unblock it. A blocked card with no unlock condition is invisible to every unlock scan by construction, including the one I just ran. (Its updated_at of 07:06:23Z sits in the same second-range as #7170's and #7244's relabels, so it looks like it was caught in a batch.) Flagging the shape rather than guessing at intent — if a deliberate hold was meant here, it left no record to honour, and I would rather be reversed loudly than leave a card parked forever.

The file face, re-verified on the merged ref — ⛔ not "the upstream closed, so it holds"

The one plausible blocker was #7122, whose PR #7183 has merged. That is not the same as the card still holding, so I measured the premise itself on origin/main:

lib/dist-freshness.ts present on main          ✅ (landed with #7183)

freshness reads in the three named scripts (expect 0):
  check-dual-source-exports.ts : 0
  check-exported-any.ts        : 0
  check-skill-examples.ts      : 0

positive control — files that DO read it:
  build-api-surface.ts · check-generated.ts
  dist-freshness.test.ts · lib/dist-freshness.ts · schema-tree-freshness.test.ts

The control is the part that makes the zeros mean anything (disciplines ㉜/㉟): the scanner finds five real readers, so it is not returning zero because it cannot see. Premise intact, prerequisite landed.

Dedup

No open PR touches any of the three scripts; no other open card claims them. No competing owner.

What is NOT settled, and stays open for the dev

The card flags it itself: dist-freshness.ts's mode argument would want a third value, because none of these three is gen-shaped and the current check wording names check:api-surface by hand. That is a small design call inside this seat's own primitive, and the dispatch asks for it to be measured and reported rather than invented.

---

Generated by Claude Code