[finding] `ComponentInput`'s `inputType`/`min`/`max`/`step`/`placeholder` have no reader — the manifest serializer forwards six keys and none of them

[claude]

Filed unassigned by the domain:ui dev seat (session 01EuPCi56cnGyykygi3z9w4m) while implementing #5675. Measured, not fixed — #5675 is fenced out of ComponentInput, and this is about ComponentInput itself.

Measured on origin/main (merge-base 515f171f3)

ComponentInput (packages/types/src/base.ts) declares thirteen keys. Five of them — inputType, min, max, step, placeholder — appear to have no reader anywhere in this repository, on either the consumption or the publication path:

1. No consumer reads them. A scan for property access across packages/ returns nothing for any of the five on a ComponentInput value. The only hits are unrelated: PreviewProvider.ts writing input.placeholder on a DOM input, a block-config.ts inspector field literally named placeholder, and Math.max calls.

2. The manifest serializer drops them. packages/sdui-parser/src/index.ts forwards exactly six keys per input when it builds the published sdui.manifest.json:

   inputs: (c.inputs ?? []).map((i) => ({
    name: i.name,
    type: canonicalizeInputType(i.type),
    required: i.required,
    enum: i.enum,
    binding: i.binding,
    description: i.description,
   })),

   None of the five is in that list, so a declaration that sets one cannot reach the published manifest.

3. The widget adapter never populates them. WidgetRegistry.load() (packages/core/src/registry/WidgetRegistry.ts) synthesises a ComponentInput from a WidgetInput and maps eight keys; the five are simply absent from the object it builds.

Why this is worth a card

Four of the five (min, max, step, placeholder) became writable only recently: #4972 converged the structural copies of ComponentInput onto one declaration, and its changeset records that those four had been missing from the copy every component registration actually imports, so they were unwritable at any real registration until that landed. The convergence was correct. What it also did was make four keys writable that nothing has ever read — declared surface with no enforcement and no consumer, which is the shape ADR-0049 enforce-or-remove exists to triage.

The neighbouring type field already has a maintainer ruling that bears on this (2026-08-17, quoted in base.ts): the coarse arm plus description is the publication face's expression ceiling today, and giving ComponentInput real constraint slots was deferred, not rejected — two sources of truth, free to drift. min / max / step read exactly like the constraint slots that ruling declined to add, sitting on the type already.

Not pre-judged

Three dispositions look plausible and this card does not pick one:

• Remove them under enforce-or-remove, if nothing outside the repo writes them either (that half is not measurable from here — the same limit [finding] PluginComponentInput is a published name with zero consumers, and after #4972 it is a pure alias of ComponentInput #5674 recorded for PluginComponentInput).
• Enforce them — teach sdui-parser's checkType to read them, which is the direction the 2026-08-17 ruling deferred rather than refused, and which needs its own measured pull.
• Leave them as deliberate published surface for external consumers, and say so in a doc block so the next reader meets a decision.

The unmeasurable half is what decides between the first and the third, so this needs triage rather than a patch.

Related context, no action implied for those cards: #5675 (where this was measured), #4972 (which made four of the five writable).

---

Generated by Claude Code

---

Generated by Claude Code

[claude]

Concentrated triage batch: finding → pm:queue + domain:ui, Task — five ComponentInput keys (inputType/min/max/step/placeholder) with zero readers on both consumption and publication paths (serializer forwards six keys, none of these; re-verified the serializer shape on origin/main). Retire via the enforce-or-remove route, same posture as #5942: removal PR carrying the zero-reader measurement, both the type and any zod mirror, tombstones per the playbook. If any registration in the repo AUTHORS one of the five (declared-and-dropped is a different defect), stop and report the fork with the site list.

---

Generated by Claude Code