docs(architecture): establish Reducer Framework v1 - #519
Merged
Conversation
📝 WalkthroughWalkthroughThis PR adds the Reducer Framework v1 design, four architecture decision records, governance charters, routing updates, a Microsoft Store issue inventory, and a staged implementation plan. It does not change exported entities or runtime code. ChangesReducer Framework v1
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Contributor
There was a problem hiding this comment.
Pull request overview
Establishes “Reducer Framework v1” as a documentation-first governance layer for cross-lane reducer semantics (identity/correlation, chronology, evidence/coverage/confidence, conflicts, and redaction), plus a concrete Store-first implementation sequence and dedicated agent charters—explicitly without changing runtime behavior in cmtraceopen-parser.
Changes:
- Added the Reducer Framework v1 design spec and a Store-first phased implementation plan.
- Introduced a reducer-specific ADR ledger (4 initial ADRs + decisions README) and a Microsoft Store semantic issue inventory to drive Phase 2 RED tests.
- Added Reducer Contract/Adversary/Integration charters and updated Clairvoyance routing to point reducer work at these artifacts.
Reviewed changes
Copilot reviewed 12 out of 12 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| docs/superpowers/specs/2026-08-07-reducer-framework-v1-design.md | Defines the Reducer Framework v1 semantic boundaries, invariants, conformance suite, and agent organization. |
| docs/superpowers/plans/2026-08-07-reducer-framework-v1.md | Lays out the Store-first staged delivery plan and per-lane execution workflow/checklists. |
| docs/architecture/reducer-framework-v1-store-inventory.md | Captures Store semantic risk clusters and maps them to first executable tests and phases. |
| docs/architecture/decisions/README.md | Introduces the reducer decisions/ADR ledger purpose and scope. |
| docs/architecture/decisions/ADR-001-evidence-strength-confidence.md | Records the evidence-strength vs confidence contract boundary and invariants. |
| docs/architecture/decisions/ADR-002-identity-correlation.md | Records correlation-strength rules and prohibits time-only/weak-identity promotion. |
| docs/architecture/decisions/ADR-003-chronology-terminal-precedence.md | Records chronology rules and conservative terminal precedence/retry linkage expectations. |
| docs/architecture/decisions/ADR-004-redaction-scope.md | Establishes redaction as cross-lane architecture; defers token/equality scope until tested. |
| .Clairvoyance/staff/reducer-integration-charter.md | Defines the exact-head integration/conformance verification role and hard rules. |
| .Clairvoyance/staff/reducer-contract-charter.md | Defines the contract owner role and escalation/workflow constraints. |
| .Clairvoyance/staff/reducer-adversary-charter.md | Defines the adversarial reviewer role focused on producing failing fixtures/tests. |
| .Clairvoyance/library.md | Routes reducer-semantic work to the new spec/plan/ADRs/charters for consistent discovery. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 9
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.Clairvoyance/staff/reducer-contract-charter.md:
- Line 1: Replace every Unicode em dash in the affected governance headings with
a hyphen-minus or colon: .Clairvoyance/staff/reducer-contract-charter.md lines
1-1, .Clairvoyance/staff/reducer-adversary-charter.md lines 1-1,
.Clairvoyance/staff/reducer-integration-charter.md lines 1-1, and
docs/superpowers/plans/2026-08-07-reducer-framework-v1.md lines 1-1, 9-9, 32-32,
43-43, 64-64, 92-92, and 112-112. Preserve the existing heading text otherwise.
In @.Clairvoyance/staff/reducer-integration-charter.md:
- Around line 15-16: Create a repository-owned reducer validation document or
script containing the focused and conformance reducer tests, locked parser test,
strict Clippy, formatting check, diff check, and wasm32 parser check. Update
.Clairvoyance/staff/reducer-integration-charter.md lines 15-16 and
docs/superpowers/plans/2026-08-07-reducer-framework-v1.md lines 83-90 to
reference this single validation contract, replacing the current non-specific
validation instructions.
In `@docs/architecture/decisions/ADR-001-evidence-strength-confidence.md`:
- Around line 5-7: The ADR must resolve the evidence-to-confidence mapping
ambiguity. Update the “Decision,” “Consequences,” and/or “Executable invariants”
around IntuneFindingConfidence to either define normative confidence ceilings
for Weak, Corroborating, and Strong evidence consistent with the reducer
framework design, or explicitly declare the mapping workload-local and remove
any cross-lane requirement.
In `@docs/architecture/decisions/ADR-002-identity-correlation.md`:
- Around line 5-7: Explicitly add an executable invariant to ADR-002 stating
that an app_id match without compatible package or product identity is not
strong correlation and cannot drive a package-specific terminal outcome. Also
require a RED test covering this rule, alongside the existing invariants.
In `@docs/architecture/decisions/ADR-003-chronology-terminal-precedence.md`:
- Around line 5-7: Update the “Decision” statement in ADR-003 to require that
source-native monotonic identifiers are monotonic within a defined workload,
session, or family scope before using them for chronology. Preserve the existing
alternatives and ambiguity rules, and ensure the “Consequences” or “Executable
invariants” sections reflect that scoped monotonicity is required.
In `@docs/architecture/decisions/ADR-004-redaction-scope.md`:
- Around line 5-7: Define in ADR-004 how the existing sensitivity field maps to
restricted values, including which exported finding fields are covered. Update
the executable invariants accordingly, and add an export test proving every
restricted value is redacted or omitted while non-restricted fields remain
available.
In `@docs/superpowers/specs/2026-08-07-reducer-framework-v1-design.md`:
- Line 1: Update the “Reducer Framework v1 — Design” heading to replace the
Unicode em dash with a colon or hyphen-minus, preserving the title text and
Markdown heading structure.
- Around line 68-77: Clarify the status of the shared helpers is_assessable(),
can_correlate(), can_drive_terminal_state(), and timestamp_quality() by
explicitly designating them as either test-kit concepts or required runtime
APIs. Update the Store pilot sequence and Definition of Done to use the same
timing and delivery commitment, removing the contradiction between their initial
introduction and deferred implementation.
- Around line 261-264: Update the Definition of Done checklist near the
conformance criteria to include authoritative executable commands for parser
tests, strict Clippy, formatting, and wasm32 checks. Alternatively, link the CI
workflow that defines all four commands; ensure each gate is directly
verifiable.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 8ef13d5e-5e7c-4f15-90c9-9f23ce0dd9a6
📒 Files selected for processing (12)
.Clairvoyance/library.md.Clairvoyance/staff/reducer-adversary-charter.md.Clairvoyance/staff/reducer-contract-charter.md.Clairvoyance/staff/reducer-integration-charter.mddocs/architecture/decisions/ADR-001-evidence-strength-confidence.mddocs/architecture/decisions/ADR-002-identity-correlation.mddocs/architecture/decisions/ADR-003-chronology-terminal-precedence.mddocs/architecture/decisions/ADR-004-redaction-scope.mddocs/architecture/decisions/README.mddocs/architecture/reducer-framework-v1-store-inventory.mddocs/superpowers/plans/2026-08-07-reducer-framework-v1.mddocs/superpowers/specs/2026-08-07-reducer-framework-v1-design.md
| @@ -0,0 +1,50 @@ | |||
| # Reducer Architecture / Contract Charter — CMTrace Open | |||
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Replace the Unicode em dashes in the governance headings.
The same documentation-rule violation appears across these files. Replace each Unicode em dash with a hyphen-minus character or a colon.
.Clairvoyance/staff/reducer-contract-charter.md#L1-L1: Replace the Unicode em dash in the title..Clairvoyance/staff/reducer-adversary-charter.md#L1-L1: Replace the Unicode em dash in the title..Clairvoyance/staff/reducer-integration-charter.md#L1-L1: Replace the Unicode em dash in the title.docs/superpowers/plans/2026-08-07-reducer-framework-v1.md#L1-L1: Replace the Unicode em dash in the document title.docs/superpowers/plans/2026-08-07-reducer-framework-v1.md#L9-L9: Replace the Unicode em dash in the PR 1 heading.docs/superpowers/plans/2026-08-07-reducer-framework-v1.md#L32-L32: Replace the Unicode em dash in the PR 2 heading.docs/superpowers/plans/2026-08-07-reducer-framework-v1.md#L43-L43: Replace the Unicode em dash in the PR 3 heading.docs/superpowers/plans/2026-08-07-reducer-framework-v1.md#L64-L64: Replace the Unicode em dash in the PR 4 heading.docs/superpowers/plans/2026-08-07-reducer-framework-v1.md#L92-L92: Replace the Unicode em dash in the PR 5 heading.docs/superpowers/plans/2026-08-07-reducer-framework-v1.md#L112-L112: Replace the Unicode em dash in the PR 6 heading.
📍 Affects 4 files
.Clairvoyance/staff/reducer-contract-charter.md#L1-L1(this comment).Clairvoyance/staff/reducer-adversary-charter.md#L1-L1.Clairvoyance/staff/reducer-integration-charter.md#L1-L1docs/superpowers/plans/2026-08-07-reducer-framework-v1.md#L1-L1docs/superpowers/plans/2026-08-07-reducer-framework-v1.md#L9-L9docs/superpowers/plans/2026-08-07-reducer-framework-v1.md#L32-L32docs/superpowers/plans/2026-08-07-reducer-framework-v1.md#L43-L43docs/superpowers/plans/2026-08-07-reducer-framework-v1.md#L64-L64docs/superpowers/plans/2026-08-07-reducer-framework-v1.md#L92-L92docs/superpowers/plans/2026-08-07-reducer-framework-v1.md#L112-L112
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.Clairvoyance/staff/reducer-contract-charter.md at line 1, Replace every
Unicode em dash in the affected governance headings with a hyphen-minus or
colon: .Clairvoyance/staff/reducer-contract-charter.md lines 1-1,
.Clairvoyance/staff/reducer-adversary-charter.md lines 1-1,
.Clairvoyance/staff/reducer-integration-charter.md lines 1-1, and
docs/superpowers/plans/2026-08-07-reducer-framework-v1.md lines 1-1, 9-9, 32-32,
43-43, 64-64, 92-92, and 112-112. Preserve the existing heading text otherwise.
Source: Path instructions
Comment on lines
+15
to
+16
| - Re-run focused reducer tests, reducer conformance tests, full parser suite, strict Clippy, formatting/diff checks, and wasm32 validation. | ||
| - Confirm tests ran on the exact PR head being recommended. |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
rg -n '^name\s*=\s*"cmtraceopen-parser"$' --glob 'Cargo.toml' . || true
files="$(
fd -H -t f . |
rg '(^|/)(CLAUDE\.md|AGENTS\.md|Cargo\.toml|rust-toolchain.*|.*\.ya?ml)$' || true
)"
if [[ -n "$files" ]]; then
printf '%s\n' "$files" |
xargs -r rg -n -i 'cargo test|cargo fmt|clippy|wasm32|diff'
fiRepository: adamgell/cmtraceopen
Length of output: 2952
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
printf '%s\n' '--- workspace and toolchain files ---'
fd -H -t f 'Cargo.toml|rust-toolchain.*|rustfmt.toml|clippy.toml|config$' . | sort
printf '%s\n' '--- charter ---'
cat -n .Clairvoyance/staff/reducer-integration-charter.md
printf '%s\n' '--- implementation plan ---'
cat -n docs/superpowers/plans/2026-08-07-reducer-framework-v1.md | sed -n '75,100p'
printf '%s\n' '--- CI workflow relevant sections ---'
cat -n .github/workflows/cmtrace-ci.yml | sed -n '1,110p'
cat -n .github/workflows/cmtrace-ci.yml | sed -n '110,190p'
printf '%s\n' '--- manifests and toolchain ---'
for f in $(fd -H -t f 'Cargo.toml|rust-toolchain.*|rustfmt.toml|clippy.toml|config$' . | sort); do
echo "### $f"
cat -n "$f" | sed -n '1,100p'
doneRepository: adamgell/cmtraceopen
Length of output: 17510
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
printf '%s\n' '--- all validation references ---'
rg -n -i 'cargo (test|fmt|check|clippy)|rustfmt|wasm32|diff|parser|target' \
.github CLAUDE.md CONTRIBUTING.md README.md .Clairvoyance docs 2>/dev/null || true
printf '%s\n' '--- workflow target setup and validation ---'
rg -n -C 5 -i 'wasm32|target add|cargo (test|fmt|check|clippy)|git diff|format' \
.github/workflows 2>/dev/null || true
printf '%s\n' '--- package and workspace metadata ---'
python3 - <<'PY'
from pathlib import Path
import re
for p in Path(".").rglob("Cargo.toml"):
text = p.read_text()
if 'cmtraceopen-parser' in text or '[workspace]' in text:
print(f"### {p}")
for i, line in enumerate(text.splitlines(), 1):
if any(k in line for k in ("[workspace", "members", "name", "targets", "wasm")):
print(f"{i}:{line}")
PYRepository: adamgell/cmtraceopen
Length of output: 50377
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
printf '%s\n' '--- candidate validation files ---'
git ls-files | rg -i '(^|/)(ci|check|lint|validation|verify|quality|test|format|wasm)[^/]*$|(^|/)(scripts|\.github/workflows)/' | head -200
printf '%s\n' '--- validation references in the two reviewed documents ---'
rg -n -C 2 -i 'cargo|clippy|fmt|diff|wasm32|test|validation|acceptance' \
.Clairvoyance/staff/reducer-integration-charter.md \
docs/superpowers/plans/2026-08-07-reducer-framework-v1.md
printf '%s\n' '--- exact wasm, format, and diff commands in tracked CI or scripts ---'
rg -n -C 2 -i 'cargo (fmt|check).*wasm32|wasm32.*cargo|cargo fmt|git diff --check|git diff --exit-code' \
.github scripts 2>/dev/null | head -240
printf '%s\n' '--- parser-specific validation command occurrences outside large historical plans ---'
rg -l -i 'cargo (test|clippy|check).*cmtraceopen-parser|cmtraceopen-parser.*cargo (test|clippy|check)' \
.github scripts docs/superpowers/plans/2026-08-07-reducer-framework-v1.md \
.Clairvoyance 2>/dev/null | sortRepository: adamgell/cmtraceopen
Length of output: 26950
Create a repository-owned reducer validation contract.
Neither document defines exact commands, and CI does not provide one complete set. Add the focused and conformance tests, cargo test --locked -p cmtraceopen-parser, strict Clippy, cargo fmt --check --all, git diff --check, and cargo check --locked -p cmtraceopen-parser --target wasm32-unknown-unknown to one document or script. Reference it from both documents.
📍 Affects 2 files
.Clairvoyance/staff/reducer-integration-charter.md#L15-L16(this comment)docs/superpowers/plans/2026-08-07-reducer-framework-v1.md#L83-L90
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.Clairvoyance/staff/reducer-integration-charter.md around lines 15 - 16,
Create a repository-owned reducer validation document or script containing the
focused and conformance reducer tests, locked parser test, strict Clippy,
formatting check, diff check, and wasm32 parser check. Update
.Clairvoyance/staff/reducer-integration-charter.md lines 15-16 and
docs/superpowers/plans/2026-08-07-reducer-framework-v1.md lines 83-90 to
reference this single validation contract, replacing the current non-specific
validation instructions.
Source: Path instructions
Comment on lines
+5
to
+7
| - **Decision:** Keep `IntuneFindingConfidence` as the public conclusion projection. The five evidence-strength levels — `Authoritative`, `Strong`, `Corroborating`, `Weak`, and `Untrusted` — are a conceptual vocabulary for reasoning and review, not a requirement for a shared enum, envelope, or runtime representation. Workload contracts may express the distinctions in workload-appropriate types or tests. Evidence strength may constrain confidence, but confidence must never be used as a substitute for source authority. Non-assessable evidence cannot produce a terminal conclusion. | ||
| - **Consequences:** Workload reducers retain domain-specific confidence rules. Framework v1 adds no numeric score, universal reducer, or mandatory shared evidence-strength type. A later shared helper is justified only by a concrete Store test and must preserve this separation. | ||
| - **Executable invariants:** Weak evidence cannot become authoritative through duplication; untrusted or non-assessable evidence cannot produce high-confidence terminal success/failure; coverage gaps cannot raise confidence. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Define the evidence-to-confidence constraint.
The design requires this mapping at docs/superpowers/specs/2026-08-07-reducer-framework-v1-design.md:93-95, but this ADR only prohibits high confidence for untrusted or non-assessable evidence. It does not define the confidence ceiling for Weak, Corroborating, or Strong evidence. Add a normative mapping, or state that the mapping is workload-local and remove the cross-lane requirement.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/architecture/decisions/ADR-001-evidence-strength-confidence.md` around
lines 5 - 7, The ADR must resolve the evidence-to-confidence mapping ambiguity.
Update the “Decision,” “Consequences,” and/or “Executable invariants” around
IntuneFindingConfidence to either define normative confidence ceilings for Weak,
Corroborating, and Strong evidence consistent with the reducer framework design,
or explicitly declare the mapping workload-local and remove any cross-lane
requirement.
Comment on lines
+5
to
+7
| - **Decision:** Correlation is an explicit decision with a reason. Exact transaction/session keys, exact workload/package identity, and explicit shared keys may be strong; stable secondary identity may be moderate; composite name/version is weak/candidate; display name alone is insufficient; timestamp proximity alone never creates strong correlation or causality. The existing `IntuneObservationContext` remains the provenance/evidence basis. | ||
| - **Consequences:** Workload reducers choose the minimum correlation strength required for each transition. They must not promote weak or untyped fields locally into shared semantic authority. Framework v1 adds no universal correlation engine. | ||
| - **Executable invariants:** Weak identity cannot create strong correlation; timestamp proximity alone cannot produce high-confidence causality; unrelated package/session/family observations cannot alter a transaction. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
State the app_id mismatch rule explicitly.
The Store inventory at docs/architecture/reducer-framework-v1-store-inventory.md:7-17 requires an app_id match without compatible package or product identity to remain non-strong and unable to drive a package-specific terminal outcome. This ADR does not state that prohibition. Add it as an executable invariant and RED test requirement.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/architecture/decisions/ADR-002-identity-correlation.md` around lines 5 -
7, Explicitly add an executable invariant to ADR-002 stating that an app_id
match without compatible package or product identity is not strong correlation
and cannot drive a package-specific terminal outcome. Also require a RED test
covering this rule, alongside the existing invariants.
Comment on lines
+5
to
+7
| - **Decision:** Reducers may use caller order as chronology only when the source contract explicitly defines it. Otherwise use explicit transaction/session sequencing, valid source-native monotonic identifiers, or timestamps whose semantics and normalization are known. Preserve ambiguity for incomparable records. Terminal outcomes require assessable, correctly identified, sufficiently correlated evidence. Retry success may replace failure only when retry linkage is explicit. Unresolved authoritative contradictions become `Conflicting` or `Unknown` rather than an arbitrary winner. | ||
| - **Consequences:** Each workload documents its identity boundary, ordering guarantees, retry linkage, and terminal precedence. Framework v1 does not impose one universal state ranking. | ||
| - **Executable invariants:** Permuting non-ordered input does not change a result; unrelated success cannot overwrite failure; ambiguous retry cannot silently become success; unresolved authoritative conflict remains conservative. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Require a defined scope for monotonic identifiers.
Require source-native monotonic identifiers to be monotonic within a defined workload, session, or family scope. The design states this condition at docs/superpowers/specs/2026-08-07-reducer-framework-v1-design.md:121-125, but this ADR only says “valid source-native monotonic identifiers.” Without the scope condition, unrelated or reset sequences can affect terminal precedence.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/architecture/decisions/ADR-003-chronology-terminal-precedence.md` around
lines 5 - 7, Update the “Decision” statement in ADR-003 to require that
source-native monotonic identifiers are monotonic within a defined workload,
session, or family scope before using them for chronology. Preserve the existing
alternatives and ambiguity rules, and ensure the “Consequences” or “Executable
invariants” sections reflect that scoped monotonicity is required.
Comment on lines
+5
to
+7
| - **Decision:** Redaction is a shared architectural contract, not a workload-local convention; that boundary is accepted. The actual token algorithm, caller-controlled key, equality scope, and cross-artifact/session/export behavior remain provisional until they are explicitly defined and tested. Until then, new reducers must not introduce stable identifier tokens intended for cross-artifact, cross-session, or cross-export correlation. Redaction must not change non-sensitive semantic conclusions within one analysis. Raw restricted values must not appear in exported findings. | ||
| - **Consequences:** Framework v1 records the architecture boundary but does not add a token API or runtime abstraction. The Store pilot must define and test the required equality scope before changing its existing redaction implementation. | ||
| - **Executable invariants:** Same-scope redaction preserves intended equality; different scopes do not accidentally create equality; export/redaction does not alter non-sensitive reducer conclusions; restricted values are absent from export. |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Define which values are restricted.
The ADR prohibits raw restricted values in exported findings, but it does not define how restricted maps to the existing sensitivity field or which exported fields are covered. Add that mapping and an export test. Otherwise, an exporter can satisfy the wording while exposing a sensitive value that is not classified as restricted.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/architecture/decisions/ADR-004-redaction-scope.md` around lines 5 - 7,
Define in ADR-004 how the existing sensitivity field maps to restricted values,
including which exported finding fields are covered. Update the executable
invariants accordingly, and add an export test proving every restricted value is
redacted or omitted while non-restricted fields remain available.
| @@ -0,0 +1,265 @@ | |||
| # Reducer Framework v1 — Design | |||
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Replace the em dash in the title.
Line 1 uses a Unicode em dash. Replace it with a colon or a hyphen-minus.
As per path instructions, Markdown documentation must flag em dashes and en dashes.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/superpowers/specs/2026-08-07-reducer-framework-v1-design.md` at line 1,
Update the “Reducer Framework v1 — Design” heading to replace the Unicode em
dash with a colon or hyphen-minus, preserving the title text and Markdown
heading structure.
Source: Path instructions
Comment on lines
+68
to
+77
| The existing `IntuneObservationContext` remains the source of provenance, parse state, access state, timestamp, and sensitivity. Reducer Framework v1 adds shared helpers that answer semantic questions without each reducer reimplementing boolean combinations. | ||
|
|
||
| Initial helpers should include concepts equivalent to: | ||
|
|
||
| - `is_assessable()` — source is available and parsed strongly enough to drive semantic outcomes; | ||
| - `can_correlate()` — observation is usable as correlation evidence; | ||
| - `can_drive_terminal_state()` — observation is sufficiently authoritative for a terminal state; | ||
| - `timestamp_quality()` — normalized ordering strength, not an inferred timezone. | ||
|
|
||
| These should be small functions/enums over existing contracts, not a new parallel evidence envelope unless implementation proves the current context cannot express the distinction. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Resolve the shared-helper timing contradiction.
Line 68 says Framework v1 adds shared helpers. Lines 60 and 252 defer shared runtime helpers until the Store pilot proves reuse. State whether is_assessable(), can_correlate(), can_drive_terminal_state(), and timestamp_quality() are test-kit concepts or required runtime APIs. Align the pilot sequence and Definition of Done.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/superpowers/specs/2026-08-07-reducer-framework-v1-design.md` around
lines 68 - 77, Clarify the status of the shared helpers is_assessable(),
can_correlate(), can_drive_terminal_state(), and timestamp_quality() by
explicitly designating them as either test-kit concepts or required runtime
APIs. Update the Store pilot sequence and Definition of Done to use the same
timing and delivery commitment, removing the contradiction between their initial
introduction and deferred implementation.
Comment on lines
+261
to
+264
| - A reusable conformance harness exists in `cmtraceopen-parser`. | ||
| - Microsoft Store passes the agreed conformance/adversarial suite. | ||
| - At least one second reducer demonstrates that the shared helpers are actually reusable. | ||
| - Full parser tests, strict Clippy, formatting, and wasm32 checks pass. |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
fd -HI -t f 'AGENTS\.md|Cargo\.toml|Makefile|justfile|.*\.(yml|yaml)$' . -0 |
xargs -0 -r rg -n -C 2 \
'cargo (test|fmt|clippy)|wasm32-unknown-unknown|cmtraceopen-parser'Repository: adamgell/cmtraceopen
Length of output: 6082
Add executable validation commands.
The repository CI defines parser tests and strict Clippy commands, but it does not show formatting or wasm32 checks. Add the authoritative commands for all four Definition of Done gates, or link the workflow that defines them.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/superpowers/specs/2026-08-07-reducer-framework-v1-design.md` around
lines 261 - 264, Update the Definition of Done checklist near the conformance
criteria to include authoritative executable commands for parser tests, strict
Clippy, formatting, and wasm32 checks. Alternatively, link the CI workflow that
defines all four commands; ensure each gate is directly verifiable.
Source: Path instructions
This was referenced Aug 8, 2026
adamgell
added a commit
that referenced
this pull request
Aug 13, 2026
…under Unreleased (#530) Catch up the Unreleased section with all ten commits merged since the last changelog update (54d539e / #513): - Microsoft Store app evidence lane (#358 / #518) - Reducer Framework v1 governance, ADRs, and charters (#519) - Windows Autopilot evidence parser outside ESP (#362 / #450) - Company Portal Windows LocalState logs (#366 / #460) - Bounded advanced SCCM server capture (#500), folded into the existing native SCCM diagnostics path bullet - Agent tooling / Clairvoyance staff org scaffolding (#516) - Dependency bumps (quick-xml, time, install-action) and the GitHub Sponsors funding link No version bump: package.json/Cargo.toml/tauri.conf.json remain at 1.5.1 with no new tag, so this stays purely an Unreleased catch-up. Claude-Session: https://claude.ai/code/session_01A8z5Ysfa5Afts6gVPmHQZj Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
Establish the architecture and agent workflow for reliable parallel reducer development before changing runtime behavior. Governance is now explicitly Store-first: Phase 2 begins with typed-intent and input-order RED tests on a separate Store branch, followed by concrete Store fixes and targeted adversarial coverage. Generic conformance/semantic runtime extraction is deferred until the Store pilot proves the smallest reusable shape.
Why now
The Intune/SCCM diagnostic lanes increasingly share hard semantic problems: evidence authority, identity/correlation, chronology, terminal-state precedence, confidence, coverage, conflicts, and redaction. Green lane-specific CI is necessary but does not prove that a reducer cannot tell a plausible false story.
This PR makes those cross-lane rules explicit while preserving workload-specific reducers.
Included
Proposed implementation sequence
Contract clarifications
Core invariants
Runtime impact
None. This PR intentionally does not add production reducer code or refactor reducers. It establishes the contract and review surface first.
Next slice after acceptance
Create a separate Store branch and write the typed-intent and input-order RED tests. Record the real failing results before implementing the smallest concrete Store fixes.
Summary by CodeRabbit