ADR-024: Governance Runtime Pending Request Handling

Tag

#adr_024

Accepted

2026-06-22

ModularityKit.Mutator.Governance.Runtime

The governance package already defines:

That gives the package a request model, but not yet a runtime lifecycle.

To become operational, governance must handle requests that stay pending over time instead of treating them as static records. This includes:

Without this runtime layer, governance remains only a set of abstractions and cannot drive actual request lifecycle flows.

The governance package should introduce first-class runtime handling for pending mutation requests.

Expected direction:

a governance runtime service should own pending request transitions
pending transitions must be recorded through MutationRequestDecision
expiration and cancellation must be explicit runtime actions
pending requests must remain queryable by status and pending reason
the runtime must not collapse pending state into ordinary mutation failure semantics

The first implementation uses:

IMutationRequestLifecycleManager as the runtime transition contract
MutationRequestLifecycleManager as the default runtime implementation
explicit MutationRequestDecision entries for pending, approval, rejection, cancellation, expiration, superseding, and execution transitions
IMutationRequestStore.GetPendingByStateIdAsync(...) for listing pending requests by state and reason

The model already distinguishes request lifecycle from direct execution.
Pending execution is central to governance and should be handled explicitly.
Runtime transitions should remain inside the governance package instead of leaking into the core mutation engine.

Governance can evolve from static request records into a real deferred execution runtime.
Future approval, scheduling, and external check flows can share one pending lifecycle engine.

This introduces a new runtime layer with state transition rules that need consistent enforcement.
The first implementation must define carefully which transitions are allowed from each status.