chore: sync GovOPlaN module split state

README.md

@@ -0,0 +1,12 @@
+# GovOPlaN Templates
+
+`govoplan-templates` owns reusable renderable template definitions and render
+contracts for GovOPlaN. It is intentionally separate from reporting, DMS/files,
+mail delivery, forms runtime, and workflow state.
+
+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/TEMPLATE_BOUNDARY.md](docs/TEMPLATE_BOUNDARY.md) for the boundary
+decision.

docs/TEMPLATE_BOUNDARY.md

@@ -0,0 +1,113 @@
+# Template Module Boundary
+
+`govoplan-templates` owns reusable renderable templates, not the data selection
+or persistence semantics around the generated output.
+
+The core boundary decision register is in
+`/mnt/DATA/git/govoplan-core/docs/MODULE_ARCHITECTURE.md`.
+
+## Ownership
+
+Templates owns:
+
+- template definitions for letters, decisions, permits, emails, forms, reports,
+  certificates, notices, and workflow messages
+- template versions, draft/published lifecycle, localization, and merge-field
+  declarations
+- render profiles such as output format, page/layout hints, fallback language,
+  and safe preview mode
+- render-context schema declarations so callers know which fields are required
+- reusable template fragments inside configuration packages
+- rendering capability contracts exposed to mail, campaign, reporting, forms,
+  workflow, cases, DMS, and files
+
+## Boundaries
+
+Templates does not own:
+
+- report data selection, aggregation, dashboards, scheduled exports, or BI
+  semantics; those belong to `govoplan-reporting`
+- document lifecycle, collaborative editing, locks, approvals, legal hold, or
+  records management; those belong to `govoplan-dms` and `govoplan-records`
+- file/blob storage and file permissions; those belong to `govoplan-files`
+- mail sending, mailbox behavior, and mail profile policy; those belong to
+  `govoplan-mail`
+- form submissions, drafts, receipts, and public submission state; those belong
+  to `govoplan-forms-runtime` when implemented
+- workflow transitions, tasks, and case lifecycle
+
+## Initial Template Types
+
+- `letter`
+- `decision_document`
+- `permit`
+- `email`
+- `form`
+- `report`
+- `certificate`
+- `notice`
+- `workflow_message`
+
+Template types can share a render engine but should keep type-specific metadata
+explicit, especially when retention, signature, accessibility, or delivery
+rules differ.
+
+## Render Context Contract
+
+Candidate render request:
+
+```json
+{
+  "template_id": "permit-decision",
+  "template_version_id": "v1",
+  "template_type": "permit",
+  "locale": "de-DE",
+  "output_format": "pdf",
+  "context": {
+    "case_id": "case-1",
+    "recipient": {"display_name": "Example Person"},
+    "decision": {"approved": true}
+  },
+  "trace": {"correlation_id": "request-1"}
+}
+```
+
+Candidate render response:
+
+```json
+{
+  "render_id": "render-1",
+  "template_id": "permit-decision",
+  "template_version_id": "v1",
+  "output_format": "pdf",
+  "artifact": {
+    "content_type": "application/pdf",
+    "storage_ref": "files://generated/render-1.pdf",
+    "checksum": "sha256:..."
+  },
+  "warnings": []
+}
+```
+
+Generated artifact storage can be delegated to files/DMS through capabilities.
+Templates should not import those modules directly.
+
+## Candidate Capabilities
+
+- `templates.catalog`
+- `templates.renderer`
+- `templates.preview`
+- `templates.schema`
+- `templates.packageFragments`
+
+Consumers should request these through core-mediated capability lookup. The
+template module should not import consumer modules.
+
+## First Implementation Slice
+
+1. Define manifest metadata, permissions, and capability names.
+2. Add template definition/version DTOs.
+3. Add render-context schema validation for one safe text/PDF preview path.
+4. Add package fragment format for reusable templates.
+5. Add tests that mail/campaign/reporting/forms can detect template capability
+   presence without importing template internals.