Observation-class finding, measured from the domain:spec @ objectui seat while accepting objectui PR #8297. Filed unassigned, no labels — grading and domain:* are the triage seat's. ⛔ Not claiming; this repo is not my lane.
The claim
A 2026-09-07 maintainer-adopted ruling (objectui#6950, director seat decision batch #69, verbatim 「其他同意」) retires the binding: 'field' arm under ADR-0049 on the ground that it has zero writers. That ruling names one coordinate, in objectui. This repo's packages/sdui-parser carries the same arm in three declarations, and no mechanism carries the retirement across.
Measured on this repo's origin/main = f2f6684
packages/sdui-parser/src/index.ts:81 binding?: 'object' | 'field';
packages/sdui-parser/src/types.ts:84 binding?: 'object' | 'field';
packages/sdui-parser/src/types.ts:107 bindings: Array<{ tag: string; input: string; kind: 'object' | 'field'; value: unknown }>;
And on objectstack-ai/objectui origin/main = 8f9d87a, the same three, one of which objectui PR #8297 is narrowing to 'object':
packages/sdui-parser/src/index.ts:90 ← narrowed by objectui PR #8297
packages/sdui-parser/src/types.ts:100 ← residue, carried by objectui#8315
packages/sdui-parser/src/types.ts:138 ← residue, carried by objectui#8315
The zero-writer reading, with a live control. In objectui, binding: 'field' occurs 0 times across packages/ / apps/ / examples/, while the control word binding: 'object' occurs 7 times across 5 files — so the discriminator works and the zero is real.
⚠️ What I have NOT measured, and am not asserting: the writer count for 'field' in this repo. I measured this repo's declarations only. ⇒ Whoever takes this runs the same grep here first; if this repo has a 'field' writer, the premise differs on this side and the answer may differ with it.
Why it is worth a card here rather than a line on the objectui one
Rule 1: the issue lives where the fix lands. Two copies, two fixes, two repos. Filing it only on the objectui side would leave this copy to be discovered by whoever next reads the port-parity gate — which is exactly the accretion pattern #12810's family is about.
⛔ I have not measured which copy is upstream of which, and this card does not assert a direction. What is measured: both repos carry a packages/sdui-parser with these declarations, and objectui runs a check:upstream-port-parity gate, so the copies are kept in step by some mechanism whose owner decides whether a retirement propagates.
Family, checked rather than assumed
Refs
Filed by the domain:spec @ objectui PM seat, session session_01QtGhnU3WnnWyiWeYQhw2aX.
Generated with Claude Code
https://claude.ai/code/session_01QtGhnU3WnnWyiWeYQhw2aX
Observation-class finding, measured from the
domain:spec @ objectuiseat while accepting objectui PR #8297. Filed unassigned, no labels — grading anddomain:*are the triage seat's. ⛔ Not claiming; this repo is not my lane.The claim
A 2026-09-07 maintainer-adopted ruling (objectui#6950, director seat decision batch #69, verbatim 「其他同意」) retires the
binding: 'field'arm under ADR-0049 on the ground that it has zero writers. That ruling names one coordinate, in objectui. This repo'spackages/sdui-parsercarries the same arm in three declarations, and no mechanism carries the retirement across.Measured on this repo's
origin/main=f2f6684And on
objectstack-ai/objectuiorigin/main=8f9d87a, the same three, one of which objectui PR #8297 is narrowing to'object':The zero-writer reading, with a live control. In objectui,
binding: 'field'occurs 0 times acrosspackages//apps//examples/, while the control wordbinding: 'object'occurs 7 times across 5 files — so the discriminator works and the zero is real.'field'in this repo. I measured this repo's declarations only. ⇒ Whoever takes this runs the same grep here first; if this repo has a'field'writer, the premise differs on this side and the answer may differ with it.Why it is worth a card here rather than a line on the objectui one
Rule 1: the issue lives where the fix lands. Two copies, two fixes, two repos. Filing it only on the objectui side would leave this copy to be discovered by whoever next reads the port-parity gate — which is exactly the accretion pattern #12810's family is about.
⛔ I have not measured which copy is upstream of which, and this card does not assert a direction. What is measured: both repos carry a
packages/sdui-parserwith these declarations, and objectui runs acheck:upstream-port-paritygate, so the copies are kept in step by some mechanism whose owner decides whether a retirement propagates.Family, checked rather than assumed
assertFullyLoaded/RegistryConfigLike.lazy),pm:on-hold. Same family, different key ⇒ ⛔ not a duplicate.sdui-parsercopies still disagree on diagnostic codes after theinert-expressionport —dashboard-widget-optionsand the union-armtype-mismatchhave never been ported #12810 — the parent the above is filed against.type-mismatchcheck into the hoistedsdui-parser— the half of the lockstep debt that CHANGES what this copy accepts and rejects #12814, The hoisted@objectstack/sdui-parserneeds theinert-expressiondiagnostic in lockstep with objectui, or the save gate and the renderer speak different dialects #12719 — earlier lockstep ports, both closed; precedent that changes to this copy's accept/reject behaviour are handled as their own cards.Refs
/meta/:type/:name/publishedis a 501 on any topology whosemetadataslot lacks the optionalgetPublished#8297 — the ruling and the producer-face retirement.Filed by the
domain:spec @ objectuiPM seat, sessionsession_01QtGhnU3WnnWyiWeYQhw2aX.Generated with Claude Code
https://claude.ai/code/session_01QtGhnU3WnnWyiWeYQhw2aX