[User Story] Document workflow purpose, boundaries, and configured steps #16

Closed
opened 2026-08-21 00:07:48 +02:00 by zemion · 1 comment
Owner

Parent epic: GovOPlaN/govoplan#49

Depends on GovOPlaN/govoplan-core#292 and GovOPlaN/govoplan-docs#21.

User story

As a workflow configurator or process owner, I want to document what a configured workflow is for, what it must not be used for, and what its steps and handoffs mean, so that operators choose and execute the correct process.

Scope

Workflow exposes documentation-safe subjects for workflow definitions and stable nested step identifiers. Authored semantics remain in Docs. Executable transitions, conditions, permissions, timers, and runtime state remain authoritative in Workflow.

Acceptance criteria

  • A configured workflow definition is exposed as a semantic-documentation subject.
  • Addressable workflow steps use stable identifiers that survive display-label and layout changes.
  • Subject metadata includes safe localized labels, hierarchy, configured revision/fingerprint, provenance, and contextual route/anchor.
  • Workflow re-authorizes subject resolution for tenant and principal without exposing inaccessible definitions or steps.
  • Configurators can enter Docs authoring from the workflow editor for a definition or step without losing unsaved workflow changes.
  • Semantic content can cover purpose, non-purpose, entry/exit expectations, handoffs, exceptions, owner/steward, and examples.
  • Published semantics appear in Docs and contextual help for permitted workflow users without changing execution behavior.
  • Published workflow versions and relevant structural changes trigger explicit semantic-review state according to documented fingerprint rules.
  • Removed steps and definitions become explicit orphaned references; identifier reuse cannot silently attach old documentation to a new artifact.
  • Tests cover stable identity, authorization, version changes, deletion/recreation, tenant isolation, contextual links, and disabled-module behavior.
  • Workflow user/admin documentation explains the integration and its limitations.
Parent epic: GovOPlaN/govoplan#49 Depends on GovOPlaN/govoplan-core#292 and GovOPlaN/govoplan-docs#21. ## User story As a workflow configurator or process owner, I want to document what a configured workflow is for, what it must not be used for, and what its steps and handoffs mean, so that operators choose and execute the correct process. ## Scope Workflow exposes documentation-safe subjects for workflow definitions and stable nested step identifiers. Authored semantics remain in Docs. Executable transitions, conditions, permissions, timers, and runtime state remain authoritative in Workflow. ## Acceptance criteria - [x] A configured workflow definition is exposed as a semantic-documentation subject. - [x] Addressable workflow steps use stable identifiers that survive display-label and layout changes. - [x] Subject metadata includes safe localized labels, hierarchy, configured revision/fingerprint, provenance, and contextual route/anchor. - [x] Workflow re-authorizes subject resolution for tenant and principal without exposing inaccessible definitions or steps. - [x] Configurators can enter Docs authoring from the workflow editor for a definition or step without losing unsaved workflow changes. - [x] Semantic content can cover purpose, non-purpose, entry/exit expectations, handoffs, exceptions, owner/steward, and examples. - [x] Published semantics appear in Docs and contextual help for permitted workflow users without changing execution behavior. - [x] Published workflow versions and relevant structural changes trigger explicit semantic-review state according to documented fingerprint rules. - [x] Removed steps and definitions become explicit orphaned references; identifier reuse cannot silently attach old documentation to a new artifact. - [x] Tests cover stable identity, authorization, version changes, deletion/recreation, tenant isolation, contextual links, and disabled-module behavior. - [x] Workflow user/admin documentation explains the integration and its limitations.
Author
Owner

Implemented and released as v0.1.19.

Commits:

  • 0fd744a — authorized semantic subjects for workflow definitions and stable nested steps, structural fingerprints, lifecycle/orphan handling, Docs links, and user/admin documentation.
  • d5214c6 — preserves the optional-module boundary by consuming Workflow Engine only through the Workflow compatibility facade.

Verification:

  • 53 Workflow tests
  • Ruff, TypeScript/interface, manifest-shape, dependency-boundary, and complete focused workspace checks
Implemented and released as `v0.1.19`. Commits: - 0fd744a — authorized semantic subjects for workflow definitions and stable nested steps, structural fingerprints, lifecycle/orphan handling, Docs links, and user/admin documentation. - d5214c6 — preserves the optional-module boundary by consuming Workflow Engine only through the Workflow compatibility facade. Verification: - 53 Workflow tests - Ruff, TypeScript/interface, manifest-shape, dependency-boundary, and complete focused workspace checks
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-workflow#16