A render loses props, prop provenance, and bindings the spec states

[nathanacurtis]

Rendering a component and reading it back loses several facts its spec states about the component's API, and adds a few the spec does not. All of them survive independently of the slot content problems tracked in #342 and #345 — they were present before those fixes and are unchanged by them, verified against a round trip taken before the fixes landed.

API facts lost

• A string prop disappears entirely. A prop declared type: string with an example value is absent from the round trip. Nothing replaces it.
• A binding is dropped. An element's content bound to a minItems prop reads back with no binding.

Content facts that change

• The root gains dimensions it never declared — width: 100 and height: 100 appear where the source states neither.
• The root gains an explicit text colour — textColor: "#000000FF", which the source does not state.
• The root loses clipsContent: true.

Not part of this

• Differences carried by VARIANT-based code-only props are out of scope for launch and tracked in Round trip loses provenance and Figma type of a code-only prop backed by a variant picker #350.
• Prop ordering differences are the known Figma limitation: properties order by creation and cannot be reordered.
• instanceExamples not surviving a render is inherent — a render of the component asset cannot recreate instances placed elsewhere in the file.

Where it was seen

A text input, which is the densest component in the sample: code-only props, paired visibility props, a slot with content, and a subcomponent. Any of the above may well be general rather than specific to it — worth checking a second component before assuming otherwise.

[nathanacurtis]

Closing — every item here traces to authoring in the source file, not to the reader or render. Confirmed case by case with Nathan against the Figma component.

• A string prop disappears entirely. The Decorative icon property's only binding is into the default slot content. That is the withdrawn slot-content-to-host capability covered by Round trip: slot content renders with bindings baked to values, so distinct examples collapse and variants drop #342, and legacy authoring.
• A binding is dropped. Children minItems sits in a Code only props frame nested four levels deep, inside Input container > Display > Start visual. ADR-027 places that container as a direct child of the component root, so it is an authoring mistake. The reader follows the ADR correctly.
• The container gains dimensions and a text colour, and loses clipsContent. Same cause — that nested frame is emitted as ordinary anatomy, so a render treats it as an ordinary frame.

Two further cases found while checking whether the mechanism was general, both also authoring:

• A slider's Step interval layer carries two property references at once, characters and visible. One code-only prop per layer, and a code-only layer's own visibility should not be bound.
• A toast's Auto dismiss is bound to the code-only container layer itself.

One real limitation did come out of it, now recorded on the render command page: a mask is neither read nor rendered. An image's corner shaping is done with a mask, so those shapes are read as the shapes they are and a render reproduces them unmasked.

No code changes. Two speculative fixes were written and backed out — extending the code-only container search to any depth, and choosing a property reference by extraction kind — because each would have bent a documented convention to accommodate a file that does not follow it.