Release v0.1.7

.gitignore

@@ -0,0 +1,348 @@
+# ---> Node
+# Logs
+logs
+*.log
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+lerna-debug.log*
+.pnpm-debug.log*
+
+# Diagnostic reports (https://nodejs.org/api/report.html)
+report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json
+
+# Runtime data
+pids
+*.pid
+*.seed
+*.pid.lock
+
+# Directory for instrumented libs generated by jscoverage/JSCover
+lib-cov
+
+# Coverage directory used by tools like istanbul
+coverage
+*.lcov
+
+# nyc test coverage
+.nyc_output
+
+# Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files)
+.grunt
+
+# Bower dependency directory (https://bower.io/)
+bower_components
+
+# node-waf configuration
+.lock-wscript
+
+# Compiled binary addons (https://nodejs.org/api/addons.html)
+build/Release
+
+# Dependency directories
+node_modules/
+jspm_packages/
+
+# Snowpack dependency directory (https://snowpack.dev/)
+web_modules/
+
+# TypeScript cache
+*.tsbuildinfo
+
+# Optional npm cache directory
+.npm
+
+# Optional eslint cache
+.eslintcache
+
+# Optional stylelint cache
+.stylelintcache
+
+# Microbundle cache
+.rpt2_cache/
+.rts2_cache_cjs/
+.rts2_cache_es/
+.rts2_cache_umd/
+
+# Optional REPL history
+.node_repl_history
+
+# Output of 'npm pack'
+*.tgz
+
+# Yarn Integrity file
+.yarn-integrity
+
+# dotenv environment variable files
+.env
+.env.development.local
+.env.test.local
+.env.production.local
+.env.local
+
+# parcel-bundler cache (https://parceljs.org/)
+.cache
+.parcel-cache
+
+# Next.js build output
+.next
+out
+
+# Nuxt.js build / generate output
+.nuxt
+dist
+
+# Gatsby files
+.cache/
+# Comment in the public line in if your project uses Gatsby and not Next.js
+# https://nextjs.org/blog/next-9-1#public-directory-support
+# public
+
+# vuepress build output
+.vuepress/dist
+
+# vuepress v2.x temp and cache directory
+.temp
+.cache
+
+# vitepress build output
+**/.vitepress/dist
+
+# vitepress cache directory
+**/.vitepress/cache
+
+# Docusaurus cache and generated files
+.docusaurus
+
+# Serverless directories
+.serverless/
+
+# FuseBox cache
+.fusebox/
+
+# DynamoDB Local files
+.dynamodb/
+
+# TernJS port file
+.tern-port
+
+# Stores VSCode versions used for testing VSCode extensions
+.vscode-test
+
+# yarn v2
+.yarn/cache
+.yarn/unplugged
+.yarn/build-state.yml
+.yarn/install-state.gz
+.pnp.*
+
+# Local WebUI test/build scratch directories
+.component-test-build/
+.module-test-build/
+.policy-test-build/
+.template-preview-test-build/
+.import-test-build/
+webui/.component-test-build/
+webui/.module-test-build/
+webui/.policy-test-build/
+webui/.template-preview-test-build/
+webui/.import-test-build/
+
+# ---> Python
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py,cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+#Pipfile.lock
+
+# UV
+#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#uv.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+#poetry.lock
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#pdm.lock
+#   pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
+#   in version control.
+#   https://pdm.fming.dev/latest/usage/project/#working-with-version-control
+.pdm.toml
+.pdm-python
+.pdm-build/
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#  and can be added to the global gitignore or merged into this file.  For a more nuclear
+#  option (not recommended) you can uncomment the following to ignore the entire idea folder.
+#.idea/
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# ---> VisualStudioCode
+.vscode/*
+!.vscode/settings.json
+!.vscode/tasks.json
+!.vscode/launch.json
+!.vscode/extensions.json
+!.vscode/*.code-snippets
+
+# Local History for Visual Studio Code
+.history/
+
+# Built Visual Studio Code Extensions
+*.vsix
+
+*.db
+
+# GovOPlaN local runtime state
+runtime/
+
+# GovOPlaN WebUI test output
+webui/.module-test-build/
+webui/.component-test-build/

README.md

@@ -0,0 +1,15 @@
+# govoplan-workflow
+
+`govoplan-workflow` will own 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.
+
+See [docs/CONCEPT.md](docs/CONCEPT.md) for the current 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.

docs/CONCEPT.md

@@ -0,0 +1,184 @@
+# govoplan-workflow Concept
+
+## Purpose
+
+`govoplan-workflow` is the process orchestration module. It turns a configured
+administrative procedure into state transitions, guards, commands, timers, and
+operator-visible progress.
+
+Workflow does not own business records. A case, task, file, appointment,
+template, payment, or postbox message remains owned by its domain module.
+Workflow coordinates those modules through stable contracts.
+
+Workflow is also the first home for GovOPlaN's action/effect automation layer.
+That layer must keep automated actions governed, previewable, idempotent,
+auditable, and recoverable. If action catalogues, schedules, rule execution, or
+cross-module automation grow beyond workflow ownership, the runner can later be
+split into a dedicated `govoplan-automation` module without changing the
+action/effect contracts.
+
+## Ownership
+
+The module owns:
+
+- workflow definitions and versions
+- workflow instances and current state
+- transitions, guards, and transition history
+- timers, deadlines, and wait states that belong to process execution
+- command plans and command execution records
+- retry/manual-intervention state for failed command handoffs
+- action/effect execution records for workflow-triggered automation
+- workflow audit/event emission
+- workflow diagram metadata and WebUI route contributions
+
+The module does not own:
+
+- case records and case evidence
+- task queues and task completion semantics
+- form schemas or submissions
+- file storage, documents, mail, notifications, appointments, payments, ledgers,
+  or records
+- external protocol adapters
+
+## Workflow Model
+
+A workflow definition should contain:
+
+- definition id, version, tenant scope, status
+- states with labels, categories, and terminal markers
+- transitions with from/to states, required scopes, guards, and commands
+- input/output data schema references
+- timers and escalation rules
+- extension metadata for diagrams and operator UI
+
+Instances should contain:
+
+- instance id, tenant id, definition id/version
+- subject references such as `case_id` or `submission_id`
+- current state and previous state
+- process variables with strict redaction rules
+- transition history
+- pending commands and manual actions
+
+## Core Contracts
+
+The module should integrate through:
+
+- module manifest metadata, route factories, permissions, and migrations
+- events such as `workflow.instance_started`, `workflow.transitioned`,
+  `workflow.command_requested`, `workflow.command_failed`, and
+  `workflow.instance_completed`
+- commands such as `workflow.start`, `workflow.transition`,
+  `workflow.retry_command`, and `workflow.cancel`
+- capability lookups for domain commands, for example cases, tasks, templates,
+  appointments, and payments
+- configuration-package fragments that install workflow definitions
+
+Command handoff must be explicit. A transition should record which module
+capability was requested, with input payload, result summary, and failure reason.
+
+The shared action/effect doctrine lives in
+`govoplan-core/docs/ACTION_EFFECT_AUTOMATION_LAYER.md`.
+
+## Reference Journey
+
+Permit-to-payment MVP:
+
+1. A form submission starts a workflow instance.
+2. Workflow commands cases to create a case.
+3. Workflow commands tasks to create an intake task.
+4. Completion of the task transitions the instance to appointment proposal.
+5. Appointment acceptance transitions to review/decision.
+6. Workflow commands templates to generate a permit or decision.
+7. Workflow commands payments/ledger handoff.
+8. Workflow closes the case and emits evidence events.
+
+## MVP Slice
+
+The first implementation should provide:
+
+- static workflow definition registration from configuration packages
+- create/read/list workflow instances
+- transition execution with permission checks
+- guard hooks implemented through capability calls
+- command execution records with retry/manual-resolution state
+- action/effect previews for transitions that call other modules
+- idempotency keys for command execution
+- explicit blocked, retryable, quarantined, manual-required, and
+  compensation-required states
+- basic WebUI instance detail and definition viewer
+- dashboard summary provider
+- event emission and audit integration
+
+## Permissions
+
+Candidate scopes:
+
+- `workflow:definition:read`
+- `workflow:definition:write`
+- `workflow:instance:read`
+- `workflow:instance:start`
+- `workflow:instance:transition`
+- `workflow:instance:admin`
+
+State transitions may require both workflow scopes and domain-module permission
+checks for the command being executed.
+
+Workflow guard evaluation should consume access semantics through kernel
+capabilities instead of importing access internals:
+
+- `access.semanticDirectory` resolves identity, account, organization unit,
+  function assignment, delegation, and role facts.
+- `access.explanation` records why a transition was allowed or denied in terms
+  of identity/account/function/role/right provenance.
+
+Transitions that allow a person to act in place of another function holder must
+require an explicit acting context and must record both the real actor account
+and the represented account/function assignment in transition history and audit
+details.
+
+## Data Model Sketch
+
+Candidate tables:
+
+- `workflow_definitions`
+- `workflow_definition_versions`
+- `workflow_instances`
+- `workflow_transition_history`
+- `workflow_command_records`
+- `workflow_timers`
+
+Definitions should be immutable by version after activation. Instances should
+reference the exact version used at start.
+
+## WebUI
+
+Initial route contributions:
+
+- `/workflow`
+- `/workflow/instances/:instanceId`
+- `/workflow/definitions/:definitionId`
+
+The UI should show current state, available transitions, pending commands,
+failed handoffs, audit trace, and linked subject records. It should not import
+case/task/template components directly; panels are contributed through core UI
+extension points.
+
+## Tests
+
+Minimum tests:
+
+- core starts with workflow installed but cases/tasks/templates absent
+- workflow definition versioning is immutable after activation
+- transition guard denial is recorded and visible
+- command failure is retryable and does not partially advance state
+- events are emitted for start/transition/completion
+- configuration package can install a simple workflow definition
+
+## Open Decisions
+
+- Whether to implement BPMN import later or keep a GovOPlaN-native JSON model.
+- How much visual workflow editing belongs in the first WebUI.
+- Whether long-running timers use Celery beat, a module scheduler, or an ops
+  scheduler abstraction.
+- How workflow variables are redacted and retained.