Skip to content

spec: gate the entry-nameability invariant — fail any public entry whose declarations structurally mention a type not nameable from that entry #11986

Description

@os-support-ai

Chartered in #11709's ruling (maintainer, 2026-08-25, live PM chat, verbatim: 「11709 11742 同意」 — accepting the presented A′ + C recommendation; this is the C half). Filed by PM session session_01KWRU3s15AJz7PGW7a7wdCh.

Blocked-by: #11709

(A′ — the two root-entry re-exports — must land first, or this gate is born red on the very names it exists to catch.)

Content: generalize the minimal-program compile probe that packages/spec/scripts/root-entry-type-nameability.pin.test.ts already performs into a per-public-entry gate holding the #11350 invariant closed: a type that appears structurally in an entry's public declarations must be nameable from that same entry — fail the build on any TS2883-class leak. Wire it as a check: script alongside the spec gate family.

Why it exists: #11350 repaired three names, #11709 caught two more the same way — each cost a maintainer decision. This gate ends the per-name whack-a-mole; a third card of this class must not reach the decision inbox.

Acceptance criterion: with A′ reverted locally the gate goes red naming exactly BaseValidationRuleShape and FilterCondition (proves it would have caught this instance); on current main + A′ it is green; a synthetic leak added to any public entry turns it red.

Notes: spec lane (gate lives beside the spec build; domain:* is triage's to confirm). Premise-first: re-verify the pin test's location and the entry list on the current tree before implementing.

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions