Docyrus Dynamic Form Design

A dynamic form is a saved layout attached to one data source. It decides which of the data source's fields appear on the record create / edit / view screen, in what order and grid, grouped into which panels, which are required, and what runs when a value changes or the form is submitted. It is stored as a layout JSON document on a form row and rendered by useDocyrusFormView (or useDynamicFormView for a backend-free host).

The host app fetches the form and hands its layout to the renderer, which translates it into the field list, grid, per-field overrides, and automations. The document must therefore be self-contained — nothing outside it tells the renderer what the form should do.

Read this first, then author the JSON against references/form-layout-schema.md.

The three rules that prevent most broken forms

1. A form references fields; it never defines them. Every field node must bind to an existing field on the data source, by fieldConfig.slug (preferred) or dataSourceFieldId. A binding that resolves to nothing is silently dropped from the rendered form. List the real slugs first with studio list-fields. To add a field, use docyrus-data-source-design — not this skill.
2. Fields you omit do not render. A saved layout is a whitelist: the form shows exactly the fields it lists, in its own order. Omitting a required-in-the-database column produces a form that cannot be submitted successfully.
3. Validation lives in two places, and both run at submit. Declarative tokens (required, minLength:, maxLength:, pattern:, min:, max:) cover single-field constraints; JSONata customValidations cover everything else — cross-field rules, conditions, custom messages. Tokens that do not fit a value's shape are skipped, not failed. See Validation.

Workflow