What part of a form a palette component plays, what part a node in the document plays, and how a field is staged for preview.

One answer, four callers

form_node?/2 and field_node?/2 are the whole editor's answer to "is this node a form" and "is this node a field". MishkaCmsCore.Runtime.PageBuilder.Containment refuses a form dropped inside one, MishkaCmsCore.Runtime.PageBuilder.PageForms.FormPlacement binds a field to the form it lands in, MishkaCmsCore.Runtime.PageBuilder.PageForms.FormChecks reports what is wrong with each, and the compiled page reads the same markup back through MishkaCmsCore.Runtime.PageBuilder.PageForms. They had four implementations and the narrowest one — Containment's — never asked the kit at all, so a kit's own form wrapper was allowed to nest inside another form and the audit then reported the nesting the drop was supposed to refuse.

Deciding a component's role parses that component's markup, and a page holds hundreds of copies of one card, so both questions take the memo roles/2 builds: one answer per distinct component name, not one per node.

The catalog is not the whole palette

A name with no catalog row is asked of the CMS's own function components — local_modules/0, the same two modules the canvas resolves a dotted tag from — and their __components__/0 metadata is translated into the shape a catalog row carries, so everything downstream reads one dialect.

Without that, <.input> answered :none. It is MishkaCmsCore.CoreComponents.input/1 rather than a database row, and it is what every shipped Forms block and every Forms element is built out of — so the drop never bound one to the form it landed in, and no field-level check ever fired on one. Dragging a field out of its form left a page that renders on the canvas, raises nothing in the audit rail, and then fails to compile on publish, because field={f[:email]} with no :let in scope is an undefined variable.

Declaration first, inference second

role/1 asks MishkaCmsCore.Builder.FormRole what the component's own kit declared in its extra.form. A kit that declares nothing — which is every kit that shipped before the key existed — falls to inference over the component's attributes and its own markup.

An inferred role then passes through the builder:form:role transform (MishkaCmsCore.Builder.Events.form_role/2); a declared one never does.

:error is never inferred

An error component renders ordinary markup and declares the same errors list a field does, so nothing in its structure says what it is. A kit that wants the role declares it.

Detecting a Send button

A component is :submit when its template's one OUTER element is a <button> whose type can be submit, or an <input> whose type can be submit or image — through its literal, the default of the attribute it is bound to, or that attribute's values. Buttons inside the markup never count. A row with no markup (the CMS's own <.button>) is asked of its declared type attribute.

Whether a placed node sends its form is decided per node by submit_node?/3: the node's own literal type, else the component's default, else HTML's own default. A component that renders a link in place of its button (one with no markup that declares href, navigate or patch) never sends when given one; an outer <button> is rendered whatever the node carries, so it still sends. A type the node computes (type={@kind}) cannot be read: type_unread?/3.

Passing its form inside

lends_form?/2 is true when the markup has render_slot(@inner_block, v) under a :let={v} on something that hands out a form (hands_form?/2): Phoenix's <.form>, or a component that itself lends one, followed through the called component's markup. A raw <form> hands out nothing, because HEEx refuses :let on an HTML tag.

Detecting a field

The load-bearing signal is an attribute typed as a Phoenix.HTML.FormField struct — 23 of the installed kit's 136 components declare one, and it is exactly the set that renders a value-carrying control. The attribute may be called anything at all: binding_attr/1 answers with its name rather than assuming the name field.

Only Phoenix's own struct is inferred, because only Phoenix's own struct is what the editor can write. What goes into that attribute is f[:email], and Phoenix.Component.to_form/2 produces nothing but a %Phoenix.HTML.FormField{}. Matching on the last dot-segment recognised a vendor's Acme.FormField as well — and then wrote a Phoenix struct into it, which the kit's own %Acme.FormField{} = field clause head cannot match, so the call fell through to the rendering clause and raised KeyError :name on the published page. A kit with its own struct declares extra.form instead, which is the kit saying what to write and where.

A kit that binds fields some other way falls to structural?/1: the component's markup is PARSED, and a control it renders whose name and value (or checked) are bound to assigns the component declares is a field. Reading that as text called a kit's submit button a field — the same markup appears in <input type="submit" name={@name} value={@value} /> — and called a component that merely quotes an input inside a comment one too. The parse answers both: a control whose type submits carries no value, and a comment is not a control.

Neither branch reads helpers. Helper clauses are bundled per source MODULE, so chelekom-select-option-group carries native_select's %Phoenix.HTML.FormField{} clause head while rendering nothing but <option> — a detector that trusted them would call it a field.

Detecting a wrapper

A wrapper is a component that renders a form of its own. Its template is PARSED and walked for a form or .form node, so a wrapper emitting a raw <form> element is found and a template that merely names one in a comment or a code sample is not.

chelekom-simple-form renders neither: it forwards everything to chelekom-form-wrapper through an {assigns} splat, so its own markup never mentions a form. A for attribute the component declares REQUIRED counts as well, because required is the component saying the form's data is its own to hand on. So does a template whose one outer element is a component that is itself a wrapper, read from that component's own markup.

Which attributes a binding supersedes

pair_attrs/1 names the two attributes a kit derives from the form field, so the drop can clear the blanks a palette card is seeded with — leave name="" beside the binding that replaces it and the blank wins, because a kit fills it with assign_new/3, which only fills an ABSENT key.

The kit's declaration wins; the kit's own markup answers next, read by the same parse that decides structural?/1; and nil is the honest answer when neither says. It used to fall back to the literal names "name" and "value", which are Phoenix's spelling rather than the kit's — so a kit calling them input_name and input_value had two attributes it does not have dropped and its two real blanks left in place, which is exactly the failure the drop exists to prevent.

bindings/1 answers the binding attribute and the pair together, for the caller that needs both — which is every caller that writes one, because writing the binding and clearing what it supersedes is one decision made once.

Where the author's own word comes from

field_label/2 is the read side of the same doctrine, and it was the half still written in Phoenix's spelling: a two-word vocabulary of name then label, so a kit that calls them something else contributed nothing an author had typed. It asks pair_attrs/1 for the kit's name attribute instead. See the function for what is left hardcoded and why.

Why the previews need a field

A text field previewed on its own is a box with a label. It is not wrong — the kit's own docs render all 589 field examples unwrapped, and no field template depends on a form ancestor — but it is not what the reader is being asked about either. The modal exists to answer "what does this look like", and a field's answer includes the form it lives in.

So stage/2 wraps the preview source, and only the preview source.

Why a dropped field IS wrapped, elsewhere

HTML forbids a nested <form>, and the failure is silent rather than loud: the parser's form-element pointer discards the inner start tag — data-node-id and all — and lets the inner </form> close the OUTER one, ejecting every later sibling from submission.

So the wrapping a dropped field needs is conditional, and it does not belong here. The insert funnel wraps a field that lands with no form ancestor, in one undoable step, and Containment refuses a form dropped inside a form.