How the form arranges itself. In left-nav the chrome folds every field section into
one "Details" tab, so the section names the user can choose from are a level below
anything the form shows them.
The rail the form shows, in order. Empty when it could not be resolved, which the preview treats as "no rail to draw" rather than as a form with no sections.
Slots this form emits. A slot outside this list still accepts a panel, but the slot
coordinator sends it down the fallback chain to the container's after-everything
terminator — the bottom of the form. A generated form emits whichever slots CodeGen
knew about when it last ran, so the set differs from form to form.
Whether SlotsPresent was read from a form, rather than assumed from the shape CodeGen produces. Separate from TargetsVerified because the two are learned apart: a slot probe answers the slot question without answering the section question.
Whether these targets came from the form itself.
True means the open form reported them, so a section key here is one the form really renders. False means they were derived from entity metadata on the server, which is a different thing: a generated form is frozen at the moment CodeGen last ran, so a field recategorised since then moves in the metadata and not on the form. A key that only exists in the metadata hides nothing and reports no error.
What the form actually contains, so the dialog offers real targets.
FullCustomFormis the case with no good answer yet: a full custom form renders its own body, so a panel applied to that entity is stored and never seen.