Dynamic form system
Schema-driven composition of standardized fields, sections, conditions, validation and versioned mappings.
Shared componentFuture Spec 16 →Current-state summary
Forms share a black-and-white sectioned visual language across Project Opportunities, Tasks, Workspace Profile, Applications and builders. Standard inputs, native selects, date controls, address entry, required labels and modal actions exist, but option ordering, currency/number behavior, stable mappings and taxonomy reuse are inconsistent. The Application summary mapping defect demonstrates why display labels cannot substitute for stable field keys.
Interface inventory
Anatomy and verified behavior
Verification states separate observed behavior from requirements or assumptions.
| Element | Current behavior | Verification |
|---|---|---|
| Field registry | Field types exist across screens but one authoritative registry is not visible. | Inferred from inconsistencies |
| Sections | Forms use bordered groups and headings for complex records. | Verified |
| Selection controls | Single and multi-select patterns exist; ordering is inconsistent in Task Builder. | Verified |
| Numbers and money | Currency display exists; input parsing, precision and locale behavior are not consistently evidenced. | Partially verified |
| Addresses and dates | Address suggestions and native date inputs appear; normalization and timezone semantics are unverified. | Visible |
| Mappings | Application fields claim Profile/Matchmaking mappings but reviewer summary currently resolves incorrectly. | Critical defect |
User journeys
Current flows
Render and submit governed form
- Load published schema version
- Render standardized fields
- Validate locally and server-side
- Normalize canonical values
- Persist with provenance
- Emit Activity and Domain Events
State model
Current and expected states
Common initial form state.
Draft indicators exist in builders.
Exact cross-form behavior varies.
Not consistently evidenced.
Optimistic concurrency is not represented.
Product rules
Non-negotiable boundaries
- Every field has a stable key, type, validation, privacy classification and version.
- Display labels are editable without changing storage identity.
- Dropdowns are alphabetized unless a documented semantic order applies.
- Money stores amount and currency precisely.
- Dates distinguish date-only from timestamp and timezone.
- Addresses preserve raw and normalized values.
Known current limitations · 5 mapped
What is missing, broken or unverified
Future Spec 16 owns closure →- No visible authoritative registry.
- Option ordering conflicts.
- Mapping defect in Applications.
- Money, date/timezone and address normalization are not fully verified.
- Concurrency states are absent.
Future alignment
Required evolution
- 01Build one schema-driven form renderer and field registry.
- 02Add preview, schema diff and migration validation.
- 03Reuse exact controls in Admin, Designer, Provider, Client and public application surfaces.
Current baseline
Acceptance record
- Equivalent fields behave identically everywhere.
- Stable keys survive label changes.
- Formatting never changes stored meaning.
- Server validation is authoritative.
Reverse-spec completeness
Documentation coverage
The interface is still changing, so visual evidence and repository tracing remain intentionally incomplete.
Purpose and user outcome
DocumentedRoles and access
DocumentedRoutes and entry points
DocumentedPage and component anatomy
DocumentedFields and displayed data
DocumentedPrimary actions
DocumentedForms and validation
DocumentedStates and transitions
DocumentedEmpty, loading and error states
DocumentedResponsive behavior
PartialAccessibility behavior
PartialActivity and audit events
PartialData sources and persistence
DocumentedNotifications and automation
PartialKnown defects and limitations
DocumentedReusable component dependencies
DocumentedFuture-spec conflicts
PartialVisual and repository evidence
DeferredAcceptance of current baseline
Documented