Filed by the domain:ui seat (session session_012wwHa4aaFybxXrfmfHioDM) on behalf of #7064's implementer, who measured it while verifying that card and could not file it themselves — see the channel note at the bottom, which is a finding in its own right.
The defect
packages/plugin-detail/src/index.tsx, in the record:details registration comment:
Those are undeclared upstream, so the spec's section object STRIPS them on parse: publishing them here would advertise keys the contract throws away…
Measured against the installed @objectstack/spec (17.2.0): it does not strip them, it REFUSES them.RecordDetailsProps.safeParse over a section carrying hideEmpty returns success: false with unrecognized_keys: ['hideEmpty'] and the message "Unrecognized key(s) on this record:details section". Control in the same probe: a section carrying columns: 2 parses and the value survives — so the failure is about the key, not a broken probe.
⭐ The comment contradicts itself, two sentences apart
This is what makes it worth a card rather than a shrug. The same block, a few lines earlier, already states the correct behaviour:
Re-adding it here would republish a key the spec now rejects on parse
So one paragraph says rejects and the next says STRIPS. Those are materially different contracts — a stripped key is silently dropped and the page still renders; a refused key fails the parse and the page does not. A reader who reaches the second sentence first will believe undeclared keys are harmless.
The comment even records why the behaviour changed — "Until #4001 batch A an undeclared prop was dropped in silence…" — so the block contains its own evidence that "STRIPS" is the pre-#4001 wording that was never updated when the rest of the paragraph was.
Why it matters beyond tidiness
That comment is a decision record: it exists to stop a future editor from publishing title / showBorder / hideEmpty as authorable inputs. Its argument is "the contract throws them away". The real argument is stronger — the contract rejects the document — and an editor who tests the weaker claim, finds a hard parse failure, and concludes the comment is unreliable may discount the whole block, including the part that is right.
⭐ Same class the seat has been tracking all round: a comment that certifies behaviour the code no longer has — #7092 (PALETTE_EXCLUSIONS reason falsified by a renderer), #7070 (the #3129 note vouching for the gantt branch beside it), #7008 (RequiredFieldsDialog's "takes no id" workaround rationale, stale since #7009). Four instances in one round on one lane.
Scope
One comment. ⛔ Not a code change — the surrounding decision (do not publish those keys as inputs) is correct and stays verbatim; only the stated mechanism is wrong. Direct precedent for this shape: #6071 and #7092, both of which corrected a stated reason in place without touching the decision.
⚠️ Whoever takes it should re-measure against the spec version installed at that time rather than quoting 17.2.0 from this card.
Related — a real contract question, deliberately NOT folded in
The same measurement exposes a three-way divergence about one key, which is decision-shaped and cross-repo, so it is routed on #7064 rather than fixed here:
| party | says about hideEmpty on a record:details section |
|---|
@objectstack/spec 17.2.0 | ⛔ refuses it (unrecognized_keys) |
@object-ui/typesviews.ts:230 | ✅ declares it (hideEmpty?: boolean) |
packages/types/src/zod/views.zod.ts | ⛔ absent — 0 hits, against a control (headerColor) hitting 2 in the same file |
RecordDetailsRenderer | ✅ honours it |
(The seat verified the two objectui-side rows independently, with the control shown.)
Filed by the
domain:uiseat (sessionsession_012wwHa4aaFybxXrfmfHioDM) on behalf of #7064's implementer, who measured it while verifying that card and could not file it themselves — see the channel note at the bottom, which is a finding in its own right.The defect
packages/plugin-detail/src/index.tsx, in therecord:detailsregistration comment:Measured against the installed
@objectstack/spec(17.2.0): it does not strip them, it REFUSES them.RecordDetailsProps.safeParseover a section carryinghideEmptyreturnssuccess: falsewithunrecognized_keys: ['hideEmpty']and the message "Unrecognized key(s) on thisrecord:detailssection". Control in the same probe: a section carryingcolumns: 2parses and the value survives — so the failure is about the key, not a broken probe.⭐ The comment contradicts itself, two sentences apart
This is what makes it worth a card rather than a shrug. The same block, a few lines earlier, already states the correct behaviour:
So one paragraph says rejects and the next says STRIPS. Those are materially different contracts — a stripped key is silently dropped and the page still renders; a refused key fails the parse and the page does not. A reader who reaches the second sentence first will believe undeclared keys are harmless.
The comment even records why the behaviour changed — "Until #4001 batch A an undeclared prop was dropped in silence…" — so the block contains its own evidence that "STRIPS" is the pre-#4001 wording that was never updated when the rest of the paragraph was.
Why it matters beyond tidiness
That comment is a decision record: it exists to stop a future editor from publishing
title/showBorder/hideEmptyas authorable inputs. Its argument is "the contract throws them away". The real argument is stronger — the contract rejects the document — and an editor who tests the weaker claim, finds a hard parse failure, and concludes the comment is unreliable may discount the whole block, including the part that is right.⭐ Same class the seat has been tracking all round: a comment that certifies behaviour the code no longer has — #7092 (
PALETTE_EXCLUSIONSreason falsified by a renderer), #7070 (the#3129note vouching for the gantt branch beside it), #7008 (RequiredFieldsDialog's "takes noid" workaround rationale, stale since #7009). Four instances in one round on one lane.Scope
One comment. ⛔ Not a code change — the surrounding decision (do not publish those keys as inputs) is correct and stays verbatim; only the stated mechanism is wrong. Direct precedent for this shape: #6071 and #7092, both of which corrected a stated reason in place without touching the decision.
Related — a real contract question, deliberately NOT folded in
The same measurement exposes a three-way divergence about one key, which is decision-shaped and cross-repo, so it is routed on #7064 rather than fixed here:
hideEmptyon arecord:detailssection@objectstack/spec17.2.0unrecognized_keys)@object-ui/typesviews.ts:230hideEmpty?: boolean)packages/types/src/zod/views.zod.tsheaderColor) hitting 2 in the same fileRecordDetailsRenderer(The seat verified the two objectui-side rows independently, with the control shown.)