Context
Onboarding is a form document (0279 decision 2), but@stackra/builder had no form kind, so onboarding answers were a
typed input. Automations had no editor kernel: the block editor edits trees, and automations and forms are a step list
and a field list.
Decision
- The form kind.
FormDocument$: a key<module>.<name>, a version, a lang-key label, the action key it submits to (forms.submit@1by default) and 1 to 20 steps of 1 to 50 fields. A field type is one ofFormFieldType(text, long text, email, phone, number, money, date, yes or no, choice, multiple choice); the registry of types is code, the forms are documents.checkFormis the write-time check;formAnswersSchema(form, now)is the answers’ zod schema for submit (and,partial, for save and resume), shared by server and client. - Conditions are rule-engine nodes. A step or field may carry a
@stackra/rulescondition overanswers.<field>: a step’s over earlier steps, a field’s over its own and earlier steps. Money fields are not testable. Hidden answers are dropped. - One kernel for structured kinds.
DocumentEditorholds a structured document, takes each change as the whole next document, keeps undo and redo, and runs the kind’s check (automationProblems,formProblems) without throwing;useDocumentEditoropens it. The automation editor is this kernel over@stackra/workflow’s check and building blocks; the host saves through the kind’s service, which refuses what the check reports.
Consequences
- Each product seeds its forms (onboarding first) as documents; the renderer, the submit action and the submission model are the experience service’s.
@stackra/builderdepends on@stackra/rulesand@stackra/workflow.
Enforcement
packages/experience/builder/src/core/{functions,values}/__tests__/ and
src/react/document-editor/__tests__/use-document-editor.test.tsx.
Supersedes and sources
Supersedes: none. Sources: STA-843 (tenancy SPEC G4), STA-773; ADR 0115, 0270, 0279.