You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implement a first-class pending mutation lifecycle in ModularityKit.Mutator.Governance so governed mutation requests can exist as deferred runtime objects rather than only immediate execution attempts.
Goal
Make pending execution a durable lifecycle in governance, so requests can wait for approval, external checks, scheduling, dependencies, or quota without being reduced to a terminal mutation result.
Scope
What should be implemented?
Introduce runtime lifecycle handling for MutationRequestStatus.Pending
Support explicit pending reasons through PendingMutationReason
Define request transitions for Pending, Approved, Rejected, Canceled, Expired, Superseded, and Executed
Add APIs or services that can move requests through the pending lifecycle
Persist lifecycle transitions through MutationRequestDecision
Define expiration behavior for pending requests
Define cancellation behavior for pending requests
Define how pending requests are listed and resolved
Acceptance Criteria
Pending mutation requests are represented as first-class governance objects
Pending state is not modeled only as a terminal block or error outcome
Lifecycle transitions are explicit and recorded in decision history
Pending requests can be canceled or expired through defined runtime paths
Governance runtime can list pending requests by state and reason
The implementation remains inside ModularityKit.Mutator.Governance
Notes
This issue is the runtime realization of ADR-021.
Approval is only one kind of pending flow. The lifecycle must also leave room for:
external checks
scheduling
dependency waits
quota holds
manual review
The current runtime covers the generic pending lifecycle and leaves approval-specific workflow behavior for the next issue.
Activity