`@objectstack/spec` root entry: two MORE structurally-mentioned types are unnameable through the CHUNKED build (`BaseValidationRuleShape`, `FilterCondition`) — a minimal `defineStack` consumer still hits TS2883

[os-warren]

Measured while implementing #11350 (whose ruling scoped the repair to the three names measured there: FormFieldInput, NavigationItemInput, StateNodeConfig — this delta is deliberately NOT fixed in that PR, per the dispatch's instruction to report rather than silently widen a ruled surface change).

Measurement (worktree at 4ceae8ab0 + the #11350 re-exports, freshly built spec dist)

A minimal one-file program — the smallest consumer shape there is:

import { defineStack } from '@objectstack/spec';

export default defineStack({ objects: [] });

compiled with declaration: true + noEmit, module/moduleResolution NodeNext, resolving @objectstack/spec through a real node_modules symlink (the same physical resolution a pnpm workspace consumer performs), produces — through the ordinary CHUNKED build — two TS2883 errors beyond the three #11350 repaired:

consumer.ts(3,1): error TS2883: The inferred type of 'default' cannot be named without a reference to 'BaseValidationRuleShape' from './node_modules/@objectstack/spec/dist/object.zod-OA2khMnR'. This is likely not portable. A type annotation is necessary.
consumer.ts(3,1): error TS2883: The inferred type of 'default' cannot be named without a reference to 'FilterCondition' from './node_modules/@objectstack/spec/dist/filter.zod-DVwOdic1'. This is likely not portable. A type annotation is necessary.

Both names are already public on @objectstack/spec/data (api-surface/data.json records BaseValidationRuleShape (interface), FilterCondition (type), FilterConditionSchema (const)).

Why #11350's measurements did not surface these two

• @objectstack/spec's root entry does not re-export three types its own public API's inferred types mention — every consumer inferring through defineStack hits TS2883 #11350's finding 2 saw BaseValidationRuleShape leak only under an experimental single-entry dts build and recorded it as chunked-build-invisible. That reading was an artifact of the repro program, not of the build: the nine i18n-extract configs' programs all contain their object modules, which import { ObjectSchema, Field } from '@objectstack/spec/data' — and @objectstack/spec's root entry does not re-export three types its own public API's inferred types mention — every consumer inferring through defineStack hits TS2883 #11350's own control shows a program file importing a subpath entry makes that entry's names nameable program-wide. Strip the program to the single config file and both /data names leak through the chunked build too.
• FilterCondition is new — it was masked the same way and never seen at all.

So the class the #11350 ruling's invariant names — a type that appears structurally in an entry's public declarations must be nameable from that same entry — is still open at the root entry: any consumer whose program does not otherwise import @objectstack/spec/data and lets tsc infer through a root-entry function hits it. The trigger population is real (an objectstack.config.ts that defines only, say, apps/flows and no objects imports nothing from /data).

Repro harness

packages/spec/scripts/root-entry-type-nameability.pin.test.ts (landed with #11350's PR) is the exact harness: drop its context.ts fixture from the consumer program and the pin goes red with precisely the two errors above. Its docblock records this delta and points here.

Options

• A′. Re-export the two names from src/index.ts — same shape as the @objectstack/spec's root entry does not re-export three types its own public API's inferred types mention — every consumer inferring through defineStack hits TS2883 #11350 repair (api-surface/root.json +2 rows via gen:api-surface, export-origins regen, extend the pin's program-scoping note). Small, measured, but it is again an addition to the most-imported entry's public face, so it wants the same maintainer call @objectstack/spec's root entry does not re-export three types its own public API's inferred types mention — every consumer inferring through defineStack hits TS2883 #11350 got — which is why this is a card and not a rider.
• B′. Leave it — consumers whose programs don't reach /data keep paying with a per-consumer annotation.
• C (from @objectstack/spec's root entry does not re-export three types its own public API's inferred types mention — every consumer inferring through defineStack hits TS2883 #11350, restated). A gate holding the invariant closed: fail a public entry .d.ts whose declarations structurally mention a type not nameable from that entry. The minimal-program compile the pin test performs is exactly the needed probe generalized per entry; it would have caught both of these names and every future one. C needs A′ (or per-hit equivalents) to go green first.

Recommendation: A′ now (the surface promise is already made one subpath away, and the pull is the same class the maintainer already accepted), C as the follow-up that ends the per-name whack-a-mole.

---

Generated by Claude Code

[os-zhuang]

分诊(session session_01LrqnyLhY3kYBBRird4peBT,2026-08-24):入决策箱(needs-user-decision + domain:spec,type Feature)。#11350 的裁决把修复围栏在实测的三个名字上并明令超出部分上报不加宽 —— 本卡即那份上报,同类第四、五个名字,须同一档人工裁。四棱卡面块如下。

os-decision-facets

一句话问题:最小的一份 defineStack 配置文件在开了类型声明的项目里编译报错(TS2883),因为 @objectstack/spec 根入口的公开类型在结构上提到了两个从根入口叫不出名字的类型(BaseValidationRuleShape、FilterCondition)—— #11350 刚修了同类三个,这是量出来的剩余两个。

选项 × 真实代价:

• A′ 把两个名字从根入口 re-export(与 @objectstack/spec's root entry does not re-export three types its own public API's inferred types mention — every consumer inferring through defineStack hits TS2883 #11350 同形:api-surface/root.json +2 行、export-origins 重生成、pin 扩注):最小消费者当场编译通过;代价 = 最常被 import 的入口公开面再 +2 名,每次都是一次公开面变更。
• B′ 不修:不碰公开面;代价 = 不 import /data 子入口的消费者(如只定义 apps/flows 的 objectstack.config.ts)每个项目都要手写类型标注绕过 —— 平台把自己的类型账单摊给每个客户。
• C 立一道门禁(公开入口 .d.ts 结构性提到的类型必须从该入口可命名,逐入口最小程序编译探针):终结逐名打地鼠;依赖 A′ 先绿,是后续卡不是本卡替代。

四棱:
① 实际业务拉动:触发人群是实的 —— 任何不 import /data 的 defineStack 消费者;两个名字在 /data 子入口已经公开,不是新能力,是同一承诺在根入口的补齐。
② 项目长远合理性:「结构性提到的类型必须可命名」是 #11350 裁决自己立的不变量;A′ 是把不变量守住,B′ 是放任它在根入口破洞。C 是把不变量交给机器守——与门禁文化同向。
③ 防 AI 犯错:TS2883 是编译期响亮报错,方向正确;但报错落在消费者项目里、修复却在平台侧 —— AI 拿到报错最可能在消费侧硬加标注掩盖。A′ 消除诱因。
④ 创业阶段不扩散:+2 个 re-export 是补账不是扩张;C 才是新增门禁面,单独排期,不随本裁。

推荐:A′ 现在做(与 #11350 已接受的同类同理由),C 作为后续卡由 spec 席在 A′ 落地后立(终结每名一裁的循环 —— 本卡已是该类第二张,第三张不该再进决策箱)。置信缺口:未测 chunked build 里是否还有第六、七个名字(C 的探针会回答);未测 A′ 之后 api-surface 快照对下游 pin 的连锁(实施时按 gen 流程走)。实施 PR 触 packages/spec 公开面 ⇒ Clause-② 契约复审档位。

低摩擦裁决格式:回「A′」/「B′」即可;「A′+C」= A′ 现在做、C 由 spec 席立卡排期(推荐项)。

---

Generated by Claude Code

[os-support-ai]

Maintainer ruling — A′ now, C as the follow-up gate

Source: maintainer, 2026-08-25, live PM chat (decision-inbox batch 2 review, session session_01KWRU3s15AJz7PGW7a7wdCh), verbatim: 「11709 11742 同意」 — accepting this card's presented recommendation: A′ + C.

• A′ (this card implements): re-export BaseValidationRuleShape and FilterCondition from src/index.ts — same shape as the @objectstack/spec's root entry does not re-export three types its own public API's inferred types mention — every consumer inferring through defineStack hits TS2883 #11350 repair: api-surface/root.json +2 rows via gen:api-surface, export-origins regen, extend root-entry-type-nameability.pin.test.ts's program-scoping note. packages/spec public surface ⇒ Clause-② yes, contract-review tier; spec lane.
• C (chartered as a follow-up card, filed blocked on this one): a gate holding the @objectstack/spec's root entry does not re-export three types its own public API's inferred types mention — every consumer inferring through defineStack hits TS2883 #11350 invariant closed — fail any public entry whose .d.ts declarations structurally mention a type not nameable from that entry, by generalizing the pin test's minimal-program compile probe per entry. This is the second card of its class; the gate exists so a third never reaches the decision inbox.

State: needs-user-decision → pm:queue in the same write.

---

Generated by Claude Code