Filed by the domain:devx dev seat while porting dashboard-widget-options for #12810. Triage on #12810 called this wiring out as binding sequencing and recorded that it remains unowned; recording it as its own card is what makes it findable.
The gap
This repo resolves no sdui.manifest.json. There is none in the tree, and @objectstack/console/dist/sdui.manifest.json is absent. So resolveSduiManifest() returns undefined and validateJsxPages runs parse-only: validateTree is never reached from the production gate.
Everything validateTree decides is therefore inert in production today — including both diagnostics that were just ported into it at real cost:
plus the six diagnostics that predate them (unknown-component, unknown-prop, missing-required-prop, not-a-container, inert-expression, invalid-enum).
Why it is worth a card rather than a note
Two independent reasons, and the second is the one that decays.
1. It is the step that pays for the ported work. Both lockstep ports were landed deliberately BEFORE this wiring, on triage's instruction, so that wiring the manifest does not turn a latent dialect split into an author-visible one on the same day. That ordering only makes sense if the wiring actually follows. Without it, two ports were paid for and nothing authors write is checked by either.
2. Unit tests are the only witness, and they cannot see this class. Every guard on validateTree in this repo constructs its own manifest object in-process. Not one of them exercises the path that would resolve a real manifest, because there is nothing to resolve. A green CI is compatible with this gate being entirely unreachable — and has been, for the whole life of the code.
What "settled" would mean
Not necessarily "wire it". The prior decision history is real and should be read first: #5960 (closed) records that sdui.manifest.json's SOURCE was left undecided and that its declaration-consistency ratchet only ever ran under a manual pnpm sdui:manifest, never in CI. So the honest options are at least:
- produce and ship the manifest so
validateJsxPages validates as designed; - or decide the hoisted parser's validation half is not this repo's job, and retire it rather than keep porting diagnostics into a function nothing calls.
The second is a real option and should not be dismissed just because two ports were recently paid for — sunk cost is not a reason to keep a surface. What is NOT an option is leaving it in the current state, where the code reads as a live save gate and is not one.
Related, deliberately not folded in
Filed by the
domain:devxdev seat while portingdashboard-widget-optionsfor #12810. Triage on #12810 called this wiring out as binding sequencing and recorded that it remains unowned; recording it as its own card is what makes it findable.The gap
This repo resolves no
sdui.manifest.json. There is none in the tree, and@objectstack/console/dist/sdui.manifest.jsonis absent. SoresolveSduiManifest()returns undefined andvalidateJsxPagesruns parse-only:validateTreeis never reached from the production gate.Everything
validateTreedecides is therefore inert in production today — including both diagnostics that were just ported into it at real cost:type-mismatchover union arms (Port the union-armtype-mismatchcheck into the hoistedsdui-parser— the half of the lockstep debt that CHANGES what this copy accepts and rejects #12814, landed as4a9f46179)unconsumed-widget-option(The twosdui-parsercopies still disagree on diagnostic codes after theinert-expressionport —dashboard-widget-optionsand the union-armtype-mismatchhave never been ported #12810)plus the six diagnostics that predate them (
unknown-component,unknown-prop,missing-required-prop,not-a-container,inert-expression,invalid-enum).Why it is worth a card rather than a note
Two independent reasons, and the second is the one that decays.
1. It is the step that pays for the ported work. Both lockstep ports were landed deliberately BEFORE this wiring, on triage's instruction, so that wiring the manifest does not turn a latent dialect split into an author-visible one on the same day. That ordering only makes sense if the wiring actually follows. Without it, two ports were paid for and nothing authors write is checked by either.
2. Unit tests are the only witness, and they cannot see this class. Every guard on
validateTreein this repo constructs its own manifest object in-process. Not one of them exercises the path that would resolve a real manifest, because there is nothing to resolve. A green CI is compatible with this gate being entirely unreachable — and has been, for the whole life of the code.What "settled" would mean
Not necessarily "wire it". The prior decision history is real and should be read first: #5960 (closed) records that
sdui.manifest.json's SOURCE was left undecided and that its declaration-consistency ratchet only ever ran under a manualpnpm sdui:manifest, never in CI. So the honest options are at least:validateJsxPagesvalidates as designed;The second is a real option and should not be dismissed just because two ports were recently paid for — sunk cost is not a reason to keep a surface. What is NOT an option is leaving it in the current state, where the code reads as a live save gate and is not one.
Related, deliberately not folded in
sdui-parsercopies still disagree on diagnostic codes after theinert-expressionport —dashboard-widget-optionsand the union-armtype-mismatchhave never been ported #12810 and Port the union-armtype-mismatchcheck into the hoistedsdui-parser— the half of the lockstep debt that CHANGES what this copy accepts and rejects #12814 — the two lockstep ports whose value this gates.