MVP: Capture a nested instance's non-default slot fill when generating a composed spec

[nathanacurtis]

Problem

When a composed spec is generated, content filling a non-default slot on a nested instance is dropped. Figma holds the fill; the generated spec has no record of it, and nothing warns.

Observed on a host whose default-slot fill contains an instance with a second, non-default slot filled two levels below the host root. The fetched payload carries it:

INSTANCE 'twoSlots'
  SLOT 'children' → TEXT 'aChild'     ← captured
  SLOT 'aside'    → TEXT 'Aside'      ← dropped

The generated spec contains no aside entry, no $slotContent reference, and no $nested path. Only the default slot survives, so a composition loses any content a designer placed in a sibling slot.

ADR-099 narrowed only the single-default-slot case and left the explicit reference mechanism in place for every other slot — so the reference should still be emitted here, anchored on the instance that holds the fill.

Potential solution(s)

• Capture a nested instance's non-default slot fills and emit the explicit slot-content reference for each, anchored on the instance now holding it rather than as a path on the level above
• Where a fill genuinely cannot be represented, warn rather than drop it silently

Acceptance criteria

• A nested instance with both a default and a non-default slot filled emits both fills
• The non-default fill is referenced from the instance that holds it, not as a $nested path on the level above
• The fill survives at composition depth, two or more levels below the host root
• A fill that cannot be captured produces a warning naming the slot and node id

Case data

• Fixture: Slot Non Default Nested (1660:441)
• Workspace: specs-testing — TEST New Layout Test Cases page
• Territory: specs-from-figma
• Size: m

Notes

Found while verifying the #656 fixtures. Render has a matching gap on the write side — PropConfigurations.apply skips every object-valued config, including $slotContent — so a round trip currently loses the fill in both directions.

---

Implementation details are tracked internally.

[nathanacurtis]

Fixed by the same change as #677, which was filed against this symptom before I found this issue — same fixture (1660:441), same aside fill, same cause.

The cause was a deliberate gate, not an oversight. Crossing a default slot re-enters the host's own space, so a non-default slot beside one has no containing slot left to be addressed through. That moved its fill onto the one wiring route a component had switched off — detected, registered, and unreachable, so it vanished with no warning. Instrumenting the pipeline showed exactly that: the relation was created, and the pass that stamps the pointer never ran.

The route now opens for a component whenever the default-slot convention is in force, so every acceptance criterion here is met:

• both fills emitted
• the non-default fill is referenced from the instance that holds it, not as a $nested path on the level above
• survives at composition depth
• an unresolvable fill warns rather than dropping

Result on the fixture — the tree consolidates only default slots, and the rest binds:

layout: [root: [levelZeroText, level1: [twoSlots: [aChild]]]]
twoSlots:
  propConfigurations:
    aside: { $slotContent: "…/slotContentExamples/testSlotTwoSlots__aside__default" }

slotContentExamples went from three entries to one rather than to zero.

Verified at scale: eg's card went 57 entries to 53 with no content lost; the de-library card is byte-identical, because its chain comes from container promotion rather than this route. 2060 tests green.

The write-side gap this issue's notes predict is #673, which is still open and is the reason a round trip still loses the fill on the way back.