90 lines
3.2 KiB
Markdown
90 lines
3.2 KiB
Markdown
# Forms Module Boundary
|
|
|
|
`govoplan-forms` owns reusable form definitions and validation metadata.
|
|
Runtime submissions and workflow handoff are separate behavior.
|
|
|
|
The core boundary decision register is in
|
|
`/mnt/DATA/git/govoplan-core/docs/MODULE_ARCHITECTURE.md`.
|
|
|
|
## Ownership
|
|
|
|
Forms owns:
|
|
|
|
- form definitions, field schemas, sections, validation rules, and visibility
|
|
rules
|
|
- localization, accessibility metadata, versioning, draft/published lifecycle,
|
|
and admin editing
|
|
- form import/export and configuration-package fragments
|
|
- schema contracts that let portal, workflow, cases, and reporting understand a
|
|
form without importing form internals
|
|
|
|
`govoplan-forms-runtime` owns:
|
|
|
|
- public/internal submission sessions, drafts, receipts, submitted values,
|
|
validation evidence, attachment references, and submission status
|
|
- submission handoff events to workflow, cases, tasks, mail, reporting, files,
|
|
DMS, or portal
|
|
|
|
## Boundaries
|
|
|
|
Forms does not own:
|
|
|
|
- public portal identity and anonymous/authenticated public entry points
|
|
- file storage and file permissions for uploaded attachments
|
|
- cases, workflow transitions, tasks, or assignment state
|
|
- DMS document lifecycle and generated record storage
|
|
- reporting aggregation or dataflow transformation
|
|
|
|
## Submission Status Model
|
|
|
|
Candidate runtime statuses:
|
|
|
|
- `draft`
|
|
- `submitted`
|
|
- `validated`
|
|
- `needs_review`
|
|
- `accepted`
|
|
- `rejected`
|
|
- `handed_off`
|
|
- `archived`
|
|
|
|
The definition module can declare valid transitions and required evidence, but
|
|
runtime state belongs to the runtime module.
|
|
|
|
## Accessibility And Validation Requirements
|
|
|
|
Form definitions should carry:
|
|
|
|
- labels, descriptions, required markers, and help text
|
|
- machine-readable validation rules
|
|
- field grouping and ordering
|
|
- keyboard and screen-reader metadata where needed
|
|
- localization keys and fallback text
|
|
- data classification for privacy/retention decisions
|
|
|
|
## Capabilities
|
|
|
|
- `forms.definitions` resolves an exact, tenant-bound immutable definition.
|
|
- The API provides bounded catalogue and history reads plus OCC-guarded writes.
|
|
- The designer provides explicit revision, publication, field-order, type,
|
|
option, constraint, draft, attachment, signature, policy, and handoff editing.
|
|
- Forms Runtime performs value validation against the resolved definition; the
|
|
definition owner does not persist submissions.
|
|
|
|
## Recovery And Operations
|
|
|
|
Definition revisions are append-only. Recovery restores the database and then
|
|
verifies that every runtime submission's `form_id` and `form_revision` resolves
|
|
to the same payload. Destructive module retirement requires a verified database
|
|
snapshot and is blocked while definition rows remain. The transactional event
|
|
boundary emits only schema identity, revision, publication state, and field
|
|
count; field content remains in the owning database.
|
|
|
|
The schema vocabulary covers scalar, choice, structured, attachment, signature,
|
|
policy-reference, and handoff constraints. Conditional page/section layout,
|
|
cycle-safe predicates, localization authoring, accessibility assessment, and
|
|
verified package-fragment assessment/import are implemented. Remaining depth is
|
|
concrete attachment/signature providers, richer authoring ergonomics, public
|
|
identity profiles, and target-produced accessibility evidence; those do not
|
|
change the runtime boundary.
|