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
{{ message }}
Repository navigation
Commit 41f747e
Browse filesBrowse the repository at this point in the historyBrowse files
Feat: Decompose governance query models and align runtime integrations (#41)
## Summary
Decompose the governance query model into grouped request filters plus
dedicated approval and decision namespaces, then align runtime, Redis,
docs, examples, and tests with that split.
## Added
- grouped request query filters for scope, actor, intent, metadata,
lifecycle, and time range
- `MutationRequestQueries` presets for common governance request query
shapes
- approval and decision query models under dedicated namespaces
- `MutationRequestDecision` category-specific helpers for lifecycle,
approval, and version-resolution decisions
- ADR-033 covering governance query model decomposition
- regression coverage for grouped query filters, metadata scope
separation, decision helpers, governed execution metadata propagation,
and Redis serialization roundtrips
## Changed
- governance request queries no longer accumulate all filters on one
flat `MutationRequestQuery` surface
- runtime and in-memory governance query flows now resolve the
decomposed request query model and dedicated approval and decision types
- Redis candidate selection, query reading, materialization, and
ordering now use the decomposed query namespaces and grouped filters
- governed execution now carries request and intent metadata through
execution-facing audit surfaces
- governance and Redis examples now use the updated query namespaces and
decision helper factories
- governance and Redis docs now reflect the decomposed query API and
practical usage surface
## Result
The governance read model is now organized by concern instead of one
expanding flat query namespace. Request filters have clearer ownership,
approval and decision projections are separated cleanly, and the runtime
plus Redis integrations stay aligned with the same query contracts. The
execution path also preserves richer governance metadata for downstream
audit and history consumers.
## Testing
- `dotnet test
Tests/ModularityKit.Mutator.Governance.Tests/ModularityKit.Mutator.Governance.Tests.csproj`
- `dotnet test
Tests/ModularityKit.Mutator.Governance.Redis.Tests/ModularityKit.Mutator.Governance.Redis.Tests.csproj`
- `dotnet build Examples/Governance/Queries/Queries.csproj`
- `dotnet build Examples/Governance/RedisQueries/RedisQueries.csproj`
## Linked Issues
- Closes#22
## Checklist
- [x] governance query abstractions are decomposed into request,
approval, and decision concerns
- [x] runtime and Redis query flows are aligned with the new grouped
filter model
- [x] docs, examples, and tests cover the updated governance query
surface
ADR-026 established that governance needs storage agnostic query API, but it intentionally left the exact query object model open.
18
+
19
+
As the query surface grew, `MutationRequestQuery` started to accumulate several distinct concerns:
20
+
21
+
- request and state identity filters
22
+
- actor filters
23
+
- intent classification filters such as category, tags, metadata, and blast radius
24
+
- lifecycle and decision-history filters
25
+
- approval oriented and decision oriented projections adjacent to the same flat namespace
26
+
27
+
Without more explicit structure, the query model would keep growing as one wide record with loosely related fields. That creates several problems:
28
+
29
+
- the request query type becomes harder to read and evolve
30
+
- approval and decision query types remain mixed into the same flat model namespace
31
+
- future additions such as risk level or execution specific filters would further flatten unrelated concepts into one type
32
+
33
+
## Decision
34
+
35
+
The governance query abstractions should be decomposed into grouped models and organized by query concern.
36
+
37
+
Request query shape:
38
+
39
+
-`MutationRequestQuery` remains the root request query contract
40
+
- request query filters are grouped into explicit components:
41
+
-`Scope`
42
+
-`Actor`
43
+
-`Intent`
44
+
-`Metadata`
45
+
-`Lifecycle`
46
+
-`TimeRange`
47
+
- request query presets move into `MutationRequestQueries`
48
+
49
+
Namespace and folder organization:
50
+
51
+
- request query abstractions live under `...Queries.Model.Requests`
52
+
- request query filter types live under `...Queries.Model.Requests.Filters`
53
+
- approval query types live under `...Queries.Model.Approvals`
54
+
- decision query types live under `...Queries.Model.Decisions`
55
+
56
+
Evaluation semantics:
57
+
58
+
- query evaluators compose groupspecific matches rather than expanding one flat request query type indefinitely
59
+
- approval and decision query types continue to depend on the request query contract where needed, but remain organized as distinct concerns
60
+
61
+
## Design Rationale
62
+
63
+
- The request query contract stays explicit without becoming one ever growing bag of filters.
64
+
- Filter grouping makes new additions easier to place without weakening the model.
65
+
- Approval and decision queries are part of the same read side, but not the same concern as request filters, so they should not share one flat namespace.
66
+
- Moving presets out of `MutationRequestQuery` keeps the model closer to a DTO and avoids mixing data shape with convenience factories.
67
+
68
+
## Consequences
69
+
70
+
### Positive
71
+
72
+
- The query model is easier to scan and extend.
73
+
- Filter placement becomes more disciplined as the governance read side grows.
74
+
- Namespace organization better reflects actual query responsibilities.
75
+
- The query API stays storage agnostic while becoming more explicit internally.
76
+
77
+
### Negative
78
+
79
+
- Consumers need a small amount of additional object construction when building request queries.
80
+
- Existing code that referenced the old flat model or flat namespaces must be updated.
81
+
- Some changes that are semantically query related now span several small types instead of one file.
82
+
83
+
## Related ADRs
84
+
85
+
- ADR-026: Governance Request Query API
86
+
- ADR-030: Governance Redis Request Storage and Query Strategy
| ADR-031 | Governance Redis Serialization and Document Compatibility |[ADR-031](Adr/ADR_031_Governance_Redis_Serialization_and_Document_Compatibility.md)|
50
50
| ADR-032 | Governance Redis Concurrency and Index Maintenance Model |[ADR-032](Adr/ADR_032_Governance_Redis_Concurrency_and_Index_Maintenance_Model.md)|
51
+
| ADR-033 | Governance Query Model Decomposition |[ADR-033](Adr/ADR_033_Governance_Query_Model_Decomposition.md)|
51
52
52
53
> See individual ADRs for detailed context, decision rationale, and consequences.
Copy file name to clipboardExpand all lines: Tests/ModularityKit.Mutator.Governance.Redis.Tests/Serialization/Converters/RedisMutationRequestSerializerTests.cs
+1Lines changed: 1 addition & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -73,6 +73,7 @@ public void Roundtrip_preserves_request_shape_needed_by_governance_runtime()
0 commit comments