Skip to content

[Task]: Introduce ModularityKit.Mutator.Governance package #3

Description

@rian-be

Summary

Introduce ModularityKit.Mutator.Governance as a separate package that owns governed mutation request lifecycle concerns without expanding the core ModularityKit.Mutator runtime.

Goal

Keep ModularityKit.Mutator focused on direct mutation execution while providing a dedicated extension package for request-based governance features such as pending execution, approval-oriented flows, version-aware deferred execution, and request storage.

Scope

What should be implemented?

  • Create a separate ModularityKit.Mutator.Governance package in the same repository
  • Keep governance source under src/ with its own project file and package boundary
  • Introduce a first governance model centered on MutationRequest
  • Add lifecycle abstractions for request status and pending reason
  • Add governance decision history abstractions for request transitions
  • Add request storage contract for future persistence and query packages
  • Add an in-memory runtime implementation for mutation request storage
  • Keep governance-specific types out of the core ModularityKit.Mutator runtime unless they are fundamental to direct execution
  • Document the architectural boundary in ADRs

Acceptance Criteria

  • ModularityKit.Mutator.Governance exists as a separate project under src/
  • Core runtime and governance compile as separate packages
  • Governance contains MutationRequest and related lifecycle abstractions
  • Governance provides request decision model and request storage contract
  • Governance includes an in-memory request store for local development and tests
  • Core ModularityKit.Mutator does not directly absorb pending request lifecycle concepts
  • ADRs document the package boundary and initial governance model
  • Solution and repository layout remain consistent with the existing src/, Examples/, Benchmarks/, and Docs/ structure

Notes

This is a package-boundary task, not the full approval workflow implementation.

The purpose is to establish the governance seam first, so later work such as pending mutation lifecycle, approval workflow, versioned request resolution, query APIs, and persistence providers can grow in the governance package without making the core runtime heavy.

Related ADRs:

  • ADR-019: Governance Package Separation
  • ADR-020: Governance MutationRequest Model
  • ADR-021: Governance Pending Mutation Lifecycle
  • ADR-022: Governance Request Decisions and Storage

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions