From the #2901 audit (doc).
The audit's most useful structural result: the recurring failure is rarely "renderer forgot a name". It is "a second definition of the vocabulary exists, and the renderer is faithful to the wrong one".
Five objectui declarations re-export under the spec's own symbol name, so an importer cannot tell which one they got. All five have already drifted.
| Fork |
Spec |
Drift |
types/src/zod/data-display.zod.ts:209 ChartTypeSchema |
19 |
7 |
types/src/zod/layout.zod.ts:258 PageTypeSchema |
5 |
4 — missing list |
types/src/layout.ts:432 PageType (TS) |
5 |
10 — adds the five visualizations the spec explicitly repudiates |
types/src/reports.ts:337 ReportType |
4 |
3 — missing joined |
types/src/ui-action.ts:72 ActionType |
6 |
5 — missing form, under a comment claiming it is canonical |
The ChartTypeSchema fork is why #2901 was filed with an inverted premise: the issue read the objectui copy (7 values) as the spec and concluded the renderer had outgrown it. The spec has 19.
The PageType trio is one package holding three disagreeing definitions of one vocabulary, drifting in both directions at once — the zod copy is narrower than the spec, the TS union is wider, and ui/page.zod.ts:191 explicitly states the extra five "are NOT page types".
Why this is cheap
All five are currently inert — nothing outside packages/types parses with them, so no runtime behavior changes. Verified by tracing consumers.
They are also already-settled policy, not open questions. #2231 established the doctrine — re-export by reference; a faithful copy is still a fork — and types/src/__tests__/spec-subschema-parity.test.ts pins reference identity (toBe, not structural equality) for the schemas it covers. These five simply aren't covered.
Work
- Replace each with a by-reference re-export of the spec schema.
- Extend
spec-subschema-parity.test.ts's covered set to include them, so a future re-fork fails.
ActionType needs one real decision: navigation is fully implemented at core/src/actions/ActionRunner.ts:539 (executeNavigation) and named in no spec enum. Promote it upstream or delete the case — don't leave it as dialect.
Related: #2231, #2901
From the #2901 audit (doc).
The audit's most useful structural result: the recurring failure is rarely "renderer forgot a name". It is "a second definition of the vocabulary exists, and the renderer is faithful to the wrong one".
Five objectui declarations re-export under the spec's own symbol name, so an importer cannot tell which one they got. All five have already drifted.
types/src/zod/data-display.zod.ts:209ChartTypeSchematypes/src/zod/layout.zod.ts:258PageTypeSchemalisttypes/src/layout.ts:432PageType(TS)types/src/reports.ts:337ReportTypejoinedtypes/src/ui-action.ts:72ActionTypeform, under a comment claiming it is canonicalThe
ChartTypeSchemafork is why #2901 was filed with an inverted premise: the issue read the objectui copy (7 values) as the spec and concluded the renderer had outgrown it. The spec has 19.The
PageTypetrio is one package holding three disagreeing definitions of one vocabulary, drifting in both directions at once — the zod copy is narrower than the spec, the TS union is wider, andui/page.zod.ts:191explicitly states the extra five "are NOT page types".Why this is cheap
All five are currently inert — nothing outside
packages/typesparses with them, so no runtime behavior changes. Verified by tracing consumers.They are also already-settled policy, not open questions. #2231 established the doctrine — re-export by reference; a faithful copy is still a fork — and
types/src/__tests__/spec-subschema-parity.test.tspins reference identity (toBe, not structural equality) for the schemas it covers. These five simply aren't covered.Work
spec-subschema-parity.test.ts's covered set to include them, so a future re-fork fails.ActionTypeneeds one real decision:navigationis fully implemented atcore/src/actions/ActionRunner.ts:539(executeNavigation) and named in no spec enum. Promote it upstream or delete the case — don't leave it as dialect.Related: #2231, #2901