From abe2e237d745c347ac5f0d94d4317a3117f4b934 Mon Sep 17 00:00:00 2001
From: zemion <albrecht@degering.name>
Date: Sat, 1 Aug 2026 16:31:52 +0200
Subject: [PATCH] Sync Repo-docs-FORMS-BOUNDARY from project files

---
 Repo-docs-FORMS-BOUNDARY.-.md | 93 +++++++++++++++++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 Repo-docs-FORMS-BOUNDARY.-.md

diff --git a/Repo-docs-FORMS-BOUNDARY.-.md b/Repo-docs-FORMS-BOUNDARY.-.md
new file mode 100644
index 0000000..10ae212
--- /dev/null
+++ b/Repo-docs-FORMS-BOUNDARY.-.md
@@ -0,0 +1,93 @@
+<!-- codex-wiki-sync:bb9a1ad971d541ee34d8f9a2 -->
+
+> Mirrored from `/mnt/DATA/git/govoplan-forms/docs/FORMS_BOUNDARY.md`.
+> Origin: `repository`.
+> Active tasks and changing state belong in Gitea issues; this wiki page is durable project context.
+
+---
+# 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 layout,
+localization authoring, and package-fragment tooling remain product depth that
+can deepen this owner without changing the runtime boundary.