[finding] `packages/client` has no `check:exported-any` equivalent — #8140 fixed 51 sites and nothing stops the 52nd

[os-zhuang]

Filed separately as triage directed on #8140 (2026-08-12: "A client-side check:exported-any
equivalent gate is a natural follow-up; file it separately rather than growing this card"), and
again in its 2026-08-25 dispatch. Observation class: this proposes a ratchet, it does not report a
broken one.

Measured at 1f6d04703.

The gap, re-verified at head

• check:exported-any is declared only in packages/spec/package.json and is scoped to that
  package's built dist (packages/spec/scripts/check-exported-any.ts). No other package
  registers it.
• packages/client's whole script set is build, test, test:integration,
  check:test-typecheck, typecheck. None of them inspects what an export resolves to.
• Repo-wide the only any-shaped lint rule is query-options/no-any-erasure
  (eslint.config.mjs), which bans erasing an engine query-options argument at a call site. It
  never reads a declared return type.

That reproduces the #8140 census's reading of 2026-08-20 independently.

Why now specifically

#8140 just bound 51 return-type sites across packages/client/src/index.ts. That buys a
snapshot, not a property. The card's own census put it plainly: "Nothing stops the 33rd from
landing tomorrow. A card that fixes 49 sites without adding a ratchet buys a snapshot, not a
property."

And the surface is measurably still moving: implementing #8140 turned up a fifth erasure
spelling the census's greps could not see — 38 methods with no return annotation at all, typed from
unwrapResponse< …any… > (filed as #11925). A source-text grep for Promise< any > would not
catch those; a gate reading the built .d.ts would, because it asks what an export resolves to
rather than how it is spelled. That is the whole reason check:exported-any exists in
packages/spec:

the api-surface snapshot records that an export exists, never what it resolves to

Suggested shape

• Reuse, don't re-author. packages/spec/scripts/check-exported-any.ts already does this job
  against a built dist. The work is generalising it to take a package and wiring a
  shrink-only baseline, not writing a second detector.
• Baseline, not zero. Four methods keep Promise< any > on purpose after client SDK drops the precise spec types at its boundary: 32 methods return Promise< any > on a package that already depends on @objectstack/spec #8140 —
  automation.create, automation.update, search, data.clone — because no contract exists to
  bind (Four client SDK routes answer a shape no published contract declares — automation.create / automation.update / search / data.clone #11924). A gate demanding zero would either block on Four client SDK routes answer a shape no published contract declares — automation.create / automation.update / search / data.clone #11924 or invite someone to mint a
  false declaration to get green. A shrink-only ledger with those four named, and their reason
  recorded, is the honest starting count.
• Do not count caller-supplied generics as erasure. data.* and actions.* take a
  caller-supplied < T = any > by design — the record type and the action handler's payload really
  are the caller's. client SDK drops the precise spec types at its boundary: 32 methods return Promise< any > on a package that already depends on @objectstack/spec #8140 left those alone deliberately. A detector that reads a resolved dist
  type needs to distinguish "the default is any" from "this method has no business knowing the
  shape", or it will produce exactly the pressure that turns a correct generic into a wrong
  concrete type.
• packages/client-react is the obvious second consumer once the shape works for one package.

Scope note

⛔ Not built inside #8140, on triage's instruction. Filed unassigned; the sizing above is a
suggestion for whoever grades it, not a plan.

---

Generated by Claude Code

[claude]

Triage routing: domain:devx — the missing gate would land under scripts/ (an exported-any check for packages/client). Awaits first-touch grading.

---

Generated by Claude Code

[claude]

Concentrated triage batch (grading the earlier routing): finding → pm:queue, Task, M (domain:devx stands) — build the client-side check:exported-any equivalent the 2026-08-12 triage direction on #8140 already asked to be filed separately: a shrink-only ratchet over what packages/client's built exports RESOLVE to, modeled on packages/spec's existing gate. Hard serial: after #8140's PR (#11929) merges — the baseline must be taken against the post-narrowing surface, and the census in this card names the residual populations (#11924 four undeclared-contract sites, #11925 the 38 unannotated) that the baseline must carry as ledger entries, not silently absorb.

---

Generated by Claude Code

[yinlianghui]

Claim: PM seat domain:devx @ objectstack, session session_01UjM2ia8Av1v5NqfqQEQmC6, round R3.

field	value
branch	claude/issue-11927-client-exported-any-gate
worktree	../objectstack-11927 (dedicated)
domain	domain:devx — landing repo objectstack
file surface	a new gate under root scripts/ + a script alias in packages/client/package.json + a shrink-only baseline. ⛔ packages/spec/** is out of bounds — see below.
model tier	opus — above the sonnet floor. Triage graded M, and the expensive part is judgement, not code: telling a caller-supplied generic from an erasure, and choosing a baseline shape that stays honest.
Clause ②	not triggered. A new repo gate over what packages/client's built exports resolve to; no published contract accept/reject behaviour moves, no public surface widens. It is a strengthening.

⭐ Triage's hard serial is SATISFIED — verified, not assumed

Triage attached: "Hard serial: after #8140's PR (#11929) merges — the baseline must be taken against the post-narrowing surface." PR #11929 is merged, 2026-08-25T02:46:06Z by os-zhuang. So the baseline taken today describes the post-#8140 surface, which is the whole point of the serial.

⚠️ This card was carrying that serial in a comment while wearing pm:queue — i.e. it read as dispatchable to the selection query the entire time the blocker was live. It happened to be satisfied by the time I got here, so no harm landed, but the same shape would have burned a dispatch. Recorded as a state-model observation, not a complaint about the grading: a hard serial belongs in pm:blocked + a body Blocked-by: line, which is what the unlock scan greps. I am not retro-labelling a now-unblocked card.

Premise re-verified on origin/main = 8450eeacb:

claim	reading
check:exported-any declared only in packages/spec	✅ exactly one package.json declares it
the detector exists there	✅ packages/spec/scripts/check-exported-any.ts
packages/client has no equivalent	✅ its scripts are build, test, test:integration, check:test-typecheck, gen:test-typecheck-debt, typecheck — none reads what an export resolves to

(The card said five scripts; there are six — gen:test-typecheck-debt has since been added. Immaterial to the claim.)

⛔ Territory rule, and it is load-bearing on this card

The card's suggested shape says "generalise packages/spec/scripts/check-exported-any.ts". packages/spec is the spec seat's sole territory — this seat may not write there, and neither may its dev. Triage's own routing comment is the operative one: "the missing gate would land under scripts/."

⭐ There is a clean precedent for exactly that, inside this very package: packages/client's existing check:test-typecheck is tsx ../../scripts/check-test-typecheck.mts … — a root scripts/ module with a per-package alias. That shape keeps the whole landing in devx territory. If the dev concludes the job genuinely cannot be done without editing packages/spec/**, that is a cross-seat request: stop, report, and it becomes a card in the spec lane — ⛔ never a quiet edit.

Serial constraints. No hot-file collision; nothing in flight touches root scripts/check-*exported-any* or packages/client/package.json. Fold-or-serial: nothing to fold — no other queued card in this lane touches this surface.

---

Generated by Claude Code