Skip to content

docs(sccm): record #326 production source gate #486

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
adamgell wants to merge 1 commit into from
Closed

docs(sccm): record #326 production source gate #486

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
85 changes: 85 additions & 0 deletions docs/sccm/preparation/issue-326-client-management-corpus.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -250,3 +250,88 @@ formatting/whitespace, and wasm32 compilation. It does not exercise native
candidate discovery, permissions, Windows layout, ConfigMgr version, Software
Center filename classes, notification transport, Intune behavior, or live SCCM
acceptance. Passing this preparation corpus is not an issue-closure condition.

## Production source-contract gate review

Reviewed on 2026-08-03 against integration head
`8329522742a4889565fba2c838f832208b7e7443`.

**Decision: no-go for a production reducer.** The checked-in corpus is a
strong preparation and adversarial contract, but it is not production source
evidence:

- every management fixture still declares
`contractState: proposedPending318And319` and `proposalOnly: true`;
- every admitted fixture profile is synthetic (`5.00.TEST.*`);
- the production client intake catalog has no co-management, scripts, client
notification, or Software Center source group;
- `SccmExtractionProfile::for_artifact_family` admits only the existing
experimental `5.00.9128.*` core profile, and management has no verified
artifact family or extraction profile;
- the stable correlation-profile registry is intentionally empty, so exact
fixture keys cannot become production corroboration; and
- the Microsoft Configuration Manager log reference verifies the existence
and broad purpose of `CoManagementHandler.log`, `Scripts.log`,
`CCMNotificationAgent.log`, and the per-user `SCClient_*`/`SCNotify_*`
filename classes, but it does not define the exact record fields,
transaction keys, phase transitions, terminal dispositions, or
version-specific grammar required by this issue.
Comment on lines +273 to +278

@coderabbitai coderabbitai Bot Aug 4, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

rg -n 'CcmNotificationAgent\.log|CCMNotificationAgent\.log' \
  docs/sccm crates/cmtraceopen-parser

Repository: adamgell/cmtraceopen

Length of output: 3635

🏁 Script executed:

#!/bin/bash
set -e
printf '%s\n' '--- preparation contract and documentation ---'
sed -n '40,60p;260,282p' docs/sccm/preparation/issue-326-client-management-corpus.md
printf '%s\n' '--- fixture-contract logic ---'
sed -n '220,265p;2440,2490p' crates/cmtraceopen-parser/tests/sccm_client_management_fixture_contract.rs
printf '%s\n' '--- related filename validation and normalization ---'
rg -n -C 3 'case.?fold|canonical|basename|sourceName|CcmNotificationAgent|CCMNotificationAgent|aliases|alias' \
  docs/sccm crates/cmtraceopen-parser

Repository: adamgell/cmtraceopen

Length of output: 50377

🏁 Script executed:

#!/bin/bash
set -e
printf '%s\n' '--- document ---'
sed -n '45,57p;268,279p' docs/sccm/preparation/issue-326-client-management-corpus.md
printf '%s\n' '--- client-specific references ---'
rg -n -C 4 'CcmNotificationAgent\.log|CCMNotificationAgent\.log|accepted_basenames|acceptedBasenames|case.?fold|to_ascii_lowercase|normalize.*basename' \
  crates/cmtraceopen-parser/src/sccm/client \
  crates/cmtraceopen-parser/tests/sccm_client_management_fixture_contract.rs \
  crates/cmtraceopen-parser/tests/fixtures/sccm/client/management \
  docs/sccm/preparation/issue-326-client-management-corpus.md
printf '%s\n' '--- classifier declarations ---'
rg -n -C 5 'client-notification|notification-agent|NotificationAgent|Scripts\.log|CoManagementHandler\.log' \
  crates/cmtraceopen-parser/src/sccm/client

Repository: adamgell/cmtraceopen

Length of output: 40288

🏁 Script executed:

#!/bin/bash
set -e
python3 - <<'PY'
from pathlib import Path
doc = Path("docs/sccm/preparation/issue-326-client-management-corpus.md").read_text()
hits = [(i, line) for i, line in enumerate(doc.splitlines(), 1)
        if "CcmNotificationAgent.log" in line or "CCMNotificationAgent.log" in line]
print("\n".join(f"{i}: {line}" for i, line in hits))
PY

Repository: adamgell/cmtraceopen

Length of output: 396

Use CcmNotificationAgent.log for the canonical fixture name. If CCMNotificationAgent.log remains in the Microsoft reference summary, label it as Microsoft’s external spelling.

🤖 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/sccm/preparation/issue-326-client-management-corpus.md` around lines 273
- 278, Update the Microsoft reference summary to use CcmNotificationAgent.log as
the canonical fixture filename, while retaining CCMNotificationAgent.log only as
Microsoft’s external spelling if it remains mentioned.

Source: MCP tools


Sources:

- Microsoft, *Log file reference - Configuration Manager*, content commit
`4e0c3fafed5dd00514a189f3b0ae8b23d08553d8`:
<https://learn.microsoft.com/en-us/intune/configmgr/core/plan-design/hierarchy/log-files>
- `crates/cmtraceopen-parser/src/sccm/catalog.rs`
- `crates/cmtraceopen-parser/src/sccm/client/intake.rs`
- `crates/cmtraceopen-parser/src/sccm/keys.rs`
- `crates/cmtraceopen-parser/src/sccm/findings.rs`

Cataloging these names now would establish only filename recognition while
leaving lifecycle semantics synthetic. That would violate the issue boundary
and could turn an Intune-owned workload or a user-facing observation into an
SCCM failure.

## Required split and smallest acquisition plan

The four artifact families do not share one lifecycle and must not be shipped
through one catch-all reducer:

1. **Co-management ownership:** acquire sanitized, independently reviewed
`CoManagementHandler.log` logical records for SCCM-owned, Intune-owned,
transitioning/shared, contradictory, and unknown-coverage cases from an
authorized development client. Record the ConfigMgr version and preserve
exact field names, complete CCM framing, offsets, and ordering.
Comment on lines +300 to +304

@coderabbitai coderabbitai Bot Aug 4, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift

Represent unknown coverage as an explicit absence, not as a log record.

UnknownOwnership can identify a bounded coverage gap. A coverage gap may have no CoManagementHandler.log record. Define an evidence-pack item for the capture window, profile, discovery result, and absence reason. Reserve logical records for observed ownership, transition, or contradiction cases.

Proposed clarification 
-   `CoManagementHandler.log` logical records for SCCM-owned, Intune-owned,
-   transitioning/shared, contradictory, and unknown-coverage cases from an
-   authorized development client.
+   `CoManagementHandler.log` logical records for SCCM-owned, Intune-owned,
+   transitioning/shared, and contradictory cases from an authorized
+   development client. For unknown-coverage cases, capture an explicit
+   absence/coverage manifest with the bounded gap and capture conditions.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
1. **Co-management ownership:** acquire sanitized, independently reviewed
`CoManagementHandler.log` logical records for SCCM-owned, Intune-owned,
transitioning/shared, contradictory, and unknown-coverage cases from an
authorized development client. Record the ConfigMgr version and preserve
exact field names, complete CCM framing, offsets, and ordering.
1. **Co-management ownership:** acquire sanitized, independently reviewed
`CoManagementHandler.log` logical records for SCCM-owned, Intune-owned,
transitioning/shared, and contradictory cases from an authorized
development client. For unknown-coverage cases, capture an explicit
absence/coverage manifest with the bounded gap and capture conditions.
Record the ConfigMgr version and preserve exact field names, complete CCM
framing, offsets, and ordering.
🤖 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/sccm/preparation/issue-326-client-management-corpus.md` around lines 300
- 304, Update the “Co-management ownership” evidence requirements to represent
unknown coverage as an explicit absence item containing the capture window,
profile, discovery result, and absence reason. Reserve CoManagementHandler.log
logical records for observed SCCM-owned, Intune-owned, transitioning/shared, or
contradictory cases, while retaining the required authorization, sanitization,
review, version, framing, offset, field-name, and ordering details for captured
records.

2. **Scripts execution:** separately acquire policy, execution, and report
records that prove the real versioned equivalents of `ScriptId`,
`ExecutionId`, `ResourceHandle`, phase, disposition, and terminal result.
A failure profile requires at least one completed, failed, deferred or
incomplete, rotation, malformed, and unrelated-same-time case.
3. **Client notification:** separately acquire receive, dispatch/defer, and
acknowledgement records with the real versioned notification/channel keys.
Server BGB evidence stays outside the client reducer.
4. **Software Center:** keep dynamic `SCClient_*` and `SCNotify_*` files
unsupported until native discovery can privacy-safely recognize the
per-user filename class and sanitized records establish an observational
request/action/outcome contract. UI state and user intent remain out of
scope.

For each family, the next implementation brief must provide:

- a native #319 capture/admission contract with exact basename or bounded
filename-class matching, role, rotation, encoding, byte/digest binding, and
privacy-safe provenance;
- a real ConfigMgr version prefix and an exact extraction profile derived from
sanitized source records rather than the `5.00.TEST.*` proposal;
- red tests for field lookalikes, duplicate/conflicting keys, incomplete
records, invalid offsets, coverage gaps, raw identity leakage, input
reordering, and unrelated same-time evidence;
- a focused reducer that emits explicit ownership, deferred, insufficient, or
terminal states only from that family's cited evidence; and
- a Windows development-client evidence pack naming the target build,
viewing/reproduction conditions, observed claims, and untested variants.

Only after one family clears those gates should its catalog entry, stable
profile, and reducer land together. The smallest safe first slice is
co-management ownership alone; scripts, notification, and Software Center
remain separate follow-up slices.
Loading