34 lines
1.6 KiB
Markdown
34 lines
1.6 KiB
Markdown
# govoplan-workflow
|
|
|
|
<!-- govoplan-repository-type:start -->
|
|
**Repository type:** module (platform).
|
|
<!-- govoplan-repository-type:end -->
|
|
|
|
`govoplan-workflow` owns process orchestration for GovOPlaN.
|
|
|
|
The module should execute configurable state machines and command handoffs
|
|
between modules without importing their implementations. It coordinates cases,
|
|
tasks, forms, files, templates, mail, appointments, payments, and records
|
|
through capabilities, events, commands, and DTOs.
|
|
|
|
Workflow exposes a workflow-specific node library, a full definition editor,
|
|
validation APIs, tenant-isolated definitions, and immutable graph revisions.
|
|
Activation pins the exact revision that future instances will execute. It uses
|
|
Core's domain-neutral definition graph contract, but applies Workflow
|
|
constraints: exactly one trigger, at least one outcome, governed configuration
|
|
fields, connected nodes, and permitted loops for correction and retry paths.
|
|
Dataflow uses the same graph contract with its own acyclic transformation
|
|
library.
|
|
|
|
The current slice deliberately stops before executing process instances.
|
|
Instance state, resumable transitions, human activities, retries, and event
|
|
subscriptions must build on the pinned definition and versioned module
|
|
capabilities rather than bypassing them.
|
|
|
|
See [docs/CONCEPT.md](docs/CONCEPT.md) for the complete module concept.
|
|
|
|
There is a BPMN component playing a major role here. Maybe this needs to
|
|
become a separate module. It is quite viable to think about workflow
|
|
modelling (and consequently import and export) in terms of BPMN, permitting
|
|
a standardized configuration of the system.
|