chore: sync GovOPlaN module split state

This commit is contained in:
2026-07-10 12:51:22 +02:00
parent bf3337e51f
commit d5231b85a3
2 changed files with 91 additions and 0 deletions

11
README.md Normal file
View 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
View 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.