[Feature] Activate and restore effective Views for workflow instances and steps #7

Open
opened 2026-07-28 18:59:03 +02:00 by zemion · 1 comment
Owner

Outcome

A workflow definition can associate a governed View with the whole instance or a specific step, allowing the UI to focus on the current job while preserving an explicit escape and return path.

Acceptance criteria

  • Workflow definition revisions can reference a View id/revision and an optional step-local narrowing overlay.
  • Starting, resuming, and advancing an instance activates the effective View through the Core/Views contract; Workflow does not import Views internals.
  • Reopening an instance restores its current step and View context.
  • Users can intentionally leave focused mode and return from an open-work widget/notification without losing progress.
  • A workflow overlay may narrow but never broaden Policy ceilings, permissions, tenant scope, or resource access.
  • Missing, retired, or incompatible View revisions produce a clear recoverable state and use the documented fallback.
  • Module handoffs preserve workflow context and return routing without requiring domain-module imports.
  • Tests cover enter, step switch, leave, resume, stale View revision, and authorization changes during an active instance.

Dependencies

Depends on the Core View runtime contract, govoplan-views, and the Workflow instance runtime. Related user story: #3.

## Outcome A workflow definition can associate a governed View with the whole instance or a specific step, allowing the UI to focus on the current job while preserving an explicit escape and return path. ## Acceptance criteria - Workflow definition revisions can reference a View id/revision and an optional step-local narrowing overlay. - Starting, resuming, and advancing an instance activates the effective View through the Core/Views contract; Workflow does not import Views internals. - Reopening an instance restores its current step and View context. - Users can intentionally leave focused mode and return from an open-work widget/notification without losing progress. - A workflow overlay may narrow but never broaden Policy ceilings, permissions, tenant scope, or resource access. - Missing, retired, or incompatible View revisions produce a clear recoverable state and use the documented fallback. - Module handoffs preserve workflow context and return routing without requiring domain-module imports. - Tests cover enter, step switch, leave, resume, stale View revision, and authorization changes during an active instance. ## Dependencies Depends on the Core View runtime contract, `govoplan-views`, and the Workflow instance runtime. Related user story: #3.
Author
Owner

Codex State: note

Summary

  • Workflow now declares Views as an optional dependency and consumes the versioned views.resolver contract/capability without importing the Views implementation.
  • Workflow instance and step activation, pinned revision storage, leave/resume behavior, and stale-context recovery are not implemented and this issue remains open.

Changed Files

  • govoplan-workflow@b015569

Verification

  • govoplan-workflow: 13 tests passed

Next / Blocked

  • Add activation once the workflow instance runtime owns resumable instance/step context.
## Codex State: note ### Summary - Workflow now declares Views as an optional dependency and consumes the versioned views.resolver contract/capability without importing the Views implementation. - Workflow instance and step activation, pinned revision storage, leave/resume behavior, and stale-context recovery are not implemented and this issue remains open. ### Changed Files - `govoplan-workflow@b015569` ### Verification - `govoplan-workflow: 13 tests passed` ### Next / Blocked - Add activation once the workflow instance runtime owns resumable instance/step context.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-workflow#7
No description provided.