One named slot: its header, its children, its gaps, and its "+" buttons (ADR-0005 decisions 5, 6, 8, 11, 13).

Validity is a property of the slot, and it arrives as markup

Decision 5 makes drop-target validity per-slot rather than per-gap, and decision 6 makes it reach the client as markup. So during a drag session this component stamps data-drop="ok" on the slot when the server's one-shot Edit.Targets.droppable_slots/3 accepted it and data-drop="no" when it did not, and hover highlighting is CSS on that attribute. There is zero round-trip per hover, the client holds no validity logic to fall out of sync, and the highlight cannot disagree with the server because it is the server's answer.

Outside a drag session the attribute is absent entirely, which is what distinguishes "not a target for the block being dragged" from "no drag is happening".

The gaps, and why "+" is always there

A slot with n children has n+1 gaps, each carrying data-parent-id, data-slot and data-index - the DOM contract decision 7's hook reads. Each also carries a "+" button, and it is rendered whether or not a drag is in progress: decision 8 wants every drop target reachable without dragging, and an affordance that only appears mid-drag would be reachable only by dragging. The palette that opens is filtered by the same predicate the drag uses, not a parallel implementation of it.

Recursion

Slot renders children via BlockNode and BlockNode renders slots via Slot, and that is the whole tree. Groups, lanes, branch arms and interrupt rails are these same two components differing only by the layout and slot_style metadata decision 10 put on palette_entry/0. There is no Group component and no Parallel component, and decision 13 says there must never be one.