Edit the field where it sits, and draw it as it will look

[AllTerrainDeveloper]

Why

The canvas was a list of descriptions of fields — an icon, the label as static text, the type name underneath — and everything you could actually change lived in a pane on the right.

So the two things you do most, writing the question and writing what goes in the box, happened at arm's length from the thing they belong to. And the canvas never answered the one question you open a form builder to ask: what will this form look like?

What changed

The card now draws the control and its text is editable in place:

• Click the question to rewrite it.
• Click the box to set its placeholder.
• Click an option to rename it, and + Add option sits where the options are.
• Required is a switch on the card, not a badge that told you the state and then made you go somewhere else to change it.
• The inspector stays in step while you type, in both directions.

Each control looks like itself: radios are radios, checkboxes are checkboxes, a dropdown has a chevron, a paragraph field is a taller box.

Logic, validation and prefill stay in the inspector, as asked — those are properties of a field rather than parts of it.

Why this is not a second renderer

A builder that draws its own approximation of a control is a builder that drifts from what it ships. Two things prevent that.

The stylesheet is the real one. builder.css is registered with form.css as a dependency, so every front-end class is already in the document. Emitting .atf-input and .atf-choice__input inside an .atf-form means the theme's own radius, borders, spacing and label position apply because it is the same CSS, not a copy of it.

The token values come from the server's own renderer. One request per theme change; its <style> block is lifted and its selector repointed at the canvas. Resolving a form's theme again in TypeScript would be a second answer to "what colour is this" — the same twin-engine problem the logic and calculation code goes to some length to avoid.

The honest limits

The map is type → shape, not type → markup: 37 types share about a dozen visual shapes. field-preview.test.ts asserts every registered type has one, because an unmapped type falls back to a text box, and a signature pad drawn as a one-line input is a preview that lies.

The elaborate controls — Likert, signature, rating, scale, repeater — render as a labelled summary saying what they are and pointing at the inspector. A preview that is confidently wrong is worse than one that is visibly a summary.

Bugs found while building this

Three, all of which would have shipped silently.

A blank new option disappeared. atf_normalize_choices() drops a choice whose label and value are both empty, and the schema is normalised on every save — so a freshly added option looked fine and then vanished a couple of seconds later when the autosave returned. New options are named.

Anything typed after an autosave was discarded. A save replaces this.schema with the server's normalised copy, so every card — which closed over the field object it was rendered from — was writing to a detached one. The autosave fires 2.5s after the last keystroke, which is exactly when somebody pauses mid-sentence and carries on. PreviewHandlers now hands the caller the live field, resolved by id at write time. (Deferring the rebuild was my first attempt and made it worse: it keeps the stale binding alive longer.)

A pre-existing guard that never fired. The inspector's choices editor guarded its value-follows-label behaviour with choice.value === choices[ index ].value — the same object compared with itself. Always true, so the value followed the label unconditionally, which is exactly what the comment beside it says must not happen: an entry is stored against the value, so rewriting it orphans every submission recorded under it.

Testing

• 173 Vitest (7 new), 465 PHPUnit, tsc clean, 0 PHPCS errors.
• Verified against a live form with real keystrokes: the caret survives typing; the inspector's Label and Choice boxes update as you type on the canvas, and the reverse; a label edit made after an autosave reaches the server; adding and removing options round-trips; the dependent card's condition chip follows a renamed question.

Worth a reviewer's eye

• contenteditable over <input> — the label has to wrap, sit on the theme's line-height and inherit its font. plaintext-only keeps pasted markup out.
• Two write paths — edit updates the model and mirrors to the inspector without re-rendering (so the caret survives); restructure snapshots and re-renders, and is used only when the shape changes.
• Known gap, not addressed here: changing a choice's value can orphan a conditional-logic rule that references the old one. That predates this PR — the inspector has always allowed it — but inline renaming makes it much easier to reach. Worth its own change.