Docs: Define governance request query API

Added

- ADR-026 for storage-agnostic governance request queries
- ADR index entry for governance query capabilities

Result

The governance architecture now has an explicit decision for operational request querying so future providers can implement one consistent query surface for pending queues, request history, and governance metadata filters.

Author: rian-be

Docs/Decision/Adr/ADR_026_Governance_Request_Query_API.md

@@ -0,0 +1,67 @@
+# ADR-026: Governance Request Query API
+
+## Tag
+#adr_026
+
+## Status
+Proposed
+
+## Date
+2026-06-22
+
+## Scope
+ModularityKit.Mutator.Governance
+
+## Context
+
+The governance package is moving toward durable request lifecycle, approval history, and future persistence providers.
+
+Point lookups by request id are not enough for operational governance scenarios. Users need queries such as:
+
+- all pending approvals
+- requests for a given state
+- requests by actor
+- requests by category or risk level
+- requests filtered by tags, metadata, or blast radius
+- recent approval decisions
+
+Without a query API, persistence becomes only storage and governance data remains hard to use operationally.
+
+## Decision
+
+The governance package should define a storage-agnostic request query API.
+
+Expected direction:
+
+- expose query-oriented contracts in the governance package
+- support filtering by status, pending reason, actor, category, and time range
+- support governance-specific filters such as tags, metadata, and blast radius
+- support approval-oriented views such as pending approval queues and recent decisions
+- keep the query surface provider-neutral so future persistence packages can implement it consistently
+
+The exact query object model is intentionally left open for the first implementation.
+
+## Design Rationale
+
+- Governance data becomes useful only when it is operationally queryable.
+- Query semantics should be owned by governance rather than improvised in store implementations.
+- A storage-agnostic contract keeps future provider packages aligned.
+
+## Consequences
+
+### Positive
+
+- Governance can support real review and operational workflows.
+- Future persistence providers have a clear contract to implement.
+- Tags, metadata, and blast radius fields get a practical consumer path.
+
+### Negative
+
+- Query surface design can grow quickly if not kept disciplined.
+- Different storage providers may support different performance characteristics for the same filters.
+
+## Related ADRs
+
+- ADR-020: Governance MutationRequest Model
+- ADR-022: Governance Request Decisions and Storage
+- ADR-023: Governance Versioned Request Resolution

Docs/Decision/listadr.md

@@ -41,5 +41,6 @@ These ADRs describe the `ModularityKit.Mutator.Governance` extension layer and i
 | ADR-023 | Governance Versioned Request Resolution              | [ADR-023](Adr/ADR_023_Governance_Versioned_Request_Resolution.md)              |
 | ADR-024 | Governance Runtime Pending Request Handling          | [ADR-024](Adr/ADR_024_Governance_Runtime_Pending_Request_Handling.md)          |
 | ADR-025 | Governance Approval Workflow                         | [ADR-025](Adr/ADR_025_Governance_Approval_Workflow.md)                         |
+| ADR-026 | Governance Request Query API                         | [ADR-026](Adr/ADR_026_Governance_Request_Query_API.md)                         |
 
 > See individual ADRs for detailed context, decision rationale, and consequences.