feat: add workflow engine contribution contracts

docs/ACTION_EFFECT_AUTOMATION_LAYER.md

@@ -5,7 +5,7 @@ only linear screen flows. Workflows, schedules, imports, connectors, policies,
 and external events all need to request governed actions without bypassing the
 same safety rules that apply to human users.
 
-The first implementation should live in `govoplan-workflow` and core contracts.
+The first implementation lives in `govoplan-workflow-engine` and Core contracts.
 Create a separate `govoplan-automation` module only if action planning,
 schedulers, rule execution, or cross-module automation become too broad for
 workflow ownership.
@@ -122,7 +122,7 @@ recovery decisions, and workflow advancement.
 ## Boundary
 
 Core may own stable DTOs, registry contracts, and generic audit/event hooks.
-`govoplan-workflow` should own the first runner because workflow is the first
+`govoplan-workflow-engine` owns the first runner because workflow is the first
 module that coordinates cross-module process actions.
 
 Domain modules own their own action providers. For example, templates own

docs/DEPLOYMENT_OPERATOR_GUIDE.md

@@ -157,7 +157,7 @@ release evidence.
 | --- | --- | --- |
 | `REDIS_URL` | `redis://redis:6379/0` | Celery broker/result backend when async workers are enabled. |
 | `CELERY_ENABLED` | `false` | Local/dev can send synchronously. Production campaign delivery should run workers and set this to `true`. |
-| `CELERY_QUEUES` | `send_email,append_sent,notifications,calendar,dataflow,events,default` | Queue list expected by worker/process manager definitions. The `events` queue drains transactional platform events; `dataflow` drains trigger deliveries and schedules. |
+| `CELERY_QUEUES` | `send_email,append_sent,notifications,calendar,dataflow,workflow,events,default` | Queue list expected by worker/process manager definitions. The `events` queue drains transactional platform events; `dataflow` drains trigger deliveries and schedules; `workflow` reconciles Workflow Engine instances and module standards. |
 | `PLATFORM_EVENT_OUTBOX_MAX_ATTEMPTS` | `8` | Failed durable consumer deliveries are quarantined after this many attempts. |
 | `PLATFORM_EVENT_OUTBOX_TERMINAL_RETENTION_DAYS` | `90` | Successful event envelopes older than this are removed by the daily retention task. Quarantined evidence is retained. |
 

docs/MODULE_ARCHITECTURE.md

@@ -148,6 +148,16 @@ Other stable runtime capabilities currently include:
 - `calendar.outbox` and `calendar.scheduling`
 - `poll.scheduling`
 - `notifications.dispatch`
+- `workflow.definitionContributions` and `workflow.runtimeWorker`
+
+Modules contribute reusable process baselines through
+`ModuleManifest.workflow_definitions`. Each contribution pins its origin module
+and version, stable key, schema and content hash, native graph/BPMN content,
+governance ceilings, execution mode, and required capabilities/interfaces.
+`govoplan-workflow-engine` reconciles these declarations idempotently. A module
+upgrade appends a baseline revision without replacing the active revision or
+mutating a local override; the optional `govoplan-workflow` package supplies
+the comparison, derivation, and reset UI.
 
 ### Named Interface Contracts
 
@@ -889,7 +899,7 @@ First slice:
 - `govoplan-files` owns file-backed governed locations and uploaded/stored file
   evidence.
 - `govoplan-reporting` owns report/data views and scheduled outputs.
-- `govoplan-workflow` owns process state, approvals, scheduling of process
+- `govoplan-workflow-engine` owns process state, approvals, scheduling of process
   steps, and human review.
 
 Future `govoplan-datasources` is justified when GovOPlaN needs a broad source

docs/RELEASE_DEPENDENCIES.md

@@ -151,7 +151,8 @@ Current tag-only module repositories:
 - `govoplan-search`
 - `govoplan-tasks`
 - `govoplan-templates`
-- `govoplan-workflow`
+- `govoplan-workflow-engine` (headless definitions, migrations, and execution)
+- `govoplan-workflow` (optional authoring and inspection WebUI)
 - `govoplan-xoev`
 - `govoplan-xrechnung`
 - `govoplan-xta-osci`