chore: sync GovOPlaN module split state
This commit is contained in:
11
README.md
Normal file
11
README.md
Normal file
@@ -0,0 +1,11 @@
|
||||
# GovOPlaN Forms
|
||||
|
||||
`govoplan-forms` owns reusable form definitions, validation rules, and form
|
||||
package fragments. Submission runtime behavior is a separate responsibility
|
||||
that should live in `govoplan-forms-runtime` when implemented.
|
||||
|
||||
This repository is currently a tag-only scaffold. It should gain package
|
||||
metadata and module manifests only after the first backend or WebUI slice is
|
||||
designed.
|
||||
|
||||
See [docs/FORMS_BOUNDARY.md](docs/FORMS_BOUNDARY.md) for the boundary decision.
|
||||
80
docs/FORMS_BOUNDARY.md
Normal file
80
docs/FORMS_BOUNDARY.md
Normal file
@@ -0,0 +1,80 @@
|
||||
# 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, when implemented:
|
||||
|
||||
- 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
|
||||
|
||||
## Candidate Capabilities
|
||||
|
||||
- `forms.catalog`
|
||||
- `forms.schema`
|
||||
- `forms.validation`
|
||||
- `forms.packageFragments`
|
||||
- `forms.runtime` when runtime is installed
|
||||
|
||||
## First Implementation Slice
|
||||
|
||||
1. Define manifest metadata, permissions, and capability names.
|
||||
2. Add form definition/version DTOs.
|
||||
3. Add validation metadata for one reusable form schema.
|
||||
4. Add package fragment import/export format.
|
||||
5. Add tests that portal/workflow/reporting can detect form capabilities
|
||||
without importing form internals.
|
||||
Reference in New Issue
Block a user