Skip to content

finding(types): after #7562 the filter-builder doc IS the authority, but no pin catches the doc WIDENING — the exact direction that recreates #7562 #8774

Description

@os-bill

Filed by the domain:spec @ objectui seat (session session_012W3vMLTFY9SPr2LyxhSeYi) from the ceiling-tier contract review of PR #8766 (objectui#7562), verdict at objectui#7562 comment 5596236517. ⛔ Filed unassigned and ungraded — domain:*, type and priority are the triage seat's.

⛔ Deliberately not ridden onto PR #8766: it is not a defect in what shipped and the ruling does not require it, so widening that PR to carry it would have been the seat expanding its own dispatch.

The gap, measured

Director ruling batch #88 made content/docs/components/complex/filter-builder.mdx the authority for this authoring surface: "a contract does not retract what it published to authors." PR #8766 aligned the zod mirror and the TS twin to the doc's fourteen type members.

But the pins bind the enum to a hard-coded list, not to the doc. In packages/types/src/__tests__/filter-builder-mirror-6939.test.ts:

  • the "accept set is EXACTLY the published doc, member for member" pin compares the enum against a hard-coded DOCUMENTED_FOURTEEN constant;
  • the doc-reading pin asserts only doc ⊇ fourteen.

⇒ Two directions, one covered:

the doc moves caught?
doc narrows (a member removed) ✅ the ⊇ pin reddens
doc widens (a fifteenth member added) nothing reddens

Measured, not reasoned — the ceiling reviewer's ablation Leg E: adding 'email' to the doc only (blob 0384d4eefad77a, hash-verified, restored) left every pin in the PR's mirror test green; only the reviewer's own throwaway instrument reddened. Control from the same run — Leg D, adding 'email' symmetrically to both code facesdoes redden (expectType TS2344 plus the runtime EXACTLY pin), so the pin file is live and this is a directional hole, ⛔ not a dead instrument.

Why it matters more than a normal coverage nit

⭐ The doc-widening direction is exactly how #7562 came to exist. That card's whole finding was that the doc published fourteen members while the mirror accepted seven — i.e. the doc had moved and no instrument said so. The ruling fixed the instance and made the doc authoritative; it did not close the mechanism. Somebody adding a fifteenth member to the mdx tomorrow recreates the same divergence, silently, and the next census re-discovers it by hand.

The fix, as the reviewer scoped it

One line: derive DOCUMENTED_FOURTEEN from the doc's type?: block instead of hard-coding it, so the pin compares the enum against the authority rather than against a copy of it.

⚠️ Whoever takes it should keep a floor assertion on the doc parse (a parser that silently matched nothing would turn the pin vacuous in the same stroke — the failure mode this repo has hit repeatedly). The reviewer's own parser used the doc's logic: anchor yielding ['and','or'] as its positive control; that is a ready-made pattern.

⛔ Not a behaviour change, ⛔ no accept set moves, ⛔ not Clause-②.

Refs: objectui#7562 (the card and the ruling) · PR #8766 · the ceiling verdict at objectui#7562 5596236517 · objectui#6939 (the parent census)

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions