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:

{
  "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:

{
  "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

Define manifest metadata, permissions, and capability names.
Add template definition/version DTOs.
Add render-context schema validation for one safe text/PDF preview path.
Add package fragment format for reusable templates.
Add tests that mail/campaign/reporting/forms can detect template capability presence without importing template internals.

3.3 KiB Raw Blame History