feat: Enhance demo runbook with conference pre-stage enrollment instructions

- Added detailed steps for preparing the Company Portal installer and VM setup for conference presentations.
- Emphasized the importance of using a pre-enrolled checkpoint for live demos.

fix: Update macOS imaging ADRs with Defender validation details

- Included owner-supplied evidence of Defender health states.
- Clarified documentation requirements for Intune-based Defender deployment setup.

docs: Revise recommended software step-by-step guide for Defender

- Added reference to a sanitized healthy fixture for expected evidence model.

docs: Specify Defender documentation requirements in repository spec

- Updated acceptance criteria to ensure step-by-step Intune setup instructions are included.

test: Modify Defender validation test cases for health states

- Renamed test cases to reflect unhealthy and healthy states.
- Added assertions for healthy baseline captured from guest.

feat: Introduce ConfigMgr Inventory Bridge documentation

- Documented optional Phase 10 adjacency for ConfigMgr integration with macOSLab evidence.

feat: Add Log Analytics Integration documentation

- Outlined optional Phase 10 posture for Log Analytics with emphasis on redaction and disabled ingestion.

feat: Implement Reset-IntuneMacLabDevice script for cloud record cleanup guidance

- Created a report-only cleanup plan for Intune, Entra, and Defender records.

feat: Develop Send-LabEventToLogAnalytics script for future Log Analytics ingestion

- Prepared a disabled-by-default event envelope for local evidence export.

test: Add Phase 10 tests for new scripts

- Verified report-only cleanup guidance and Log Analytics envelope behavior.

Author: franklesniak

TODO-Phase-08-Validation-Loop.md

@@ -3,7 +3,7 @@
 
 ## Metadata
 
-- **Status:** Local implementation complete; owner guest validation deferred
+- **Status:** Local implementation complete; owner healthy guest validation captured
 - **Owner:** Repository owner
 - **Last Updated:** 2026-05-05
 - **Scope:** Deferred verification for Defender health evidence before implementing Phase 8.
@@ -14,7 +14,7 @@ The owner does not want Microsoft Defender for Endpoint installed on the daily-d
 
 Defender validation evidence should be collected inside a disposable macOS guest VM after the pinned VM build exists. This keeps the host clean and better matches the lab's purpose: validating Defender, PPPC/FDA, onboarding, and health from inside the managed guest.
 
-The owner approved the recommended Defender lifecycle on 2026-05-05: use Intune-based Defender deployment as the default demo path, with a preinstalled-Defender fallback for rehearsal or live-cloud timing issues. The owner's tenant does not currently have the Intune macOS Defender deployment configured, so Phase 8 documentation must include step-by-step setup instructions.
+The owner approved the recommended Defender lifecycle on 2026-05-05: use Intune-based Defender deployment as the default demo path, with a preinstalled-Defender fallback for rehearsal or live-cloud timing issues. The owner then configured the Intune macOS Defender path and supplied a working guest `mdatp health` capture from a disposable enrolled VM.
 
 Owner-supplied Defender evidence from a lab macOS environment also confirms:
 
@@ -25,16 +25,27 @@ Owner-supplied Defender evidence from a lab macOS environment also confirms:
 - The output can simultaneously show useful positive signals such as `licensed: true`, engine load success, `cloud_enabled: true`, real-time protection enabled, automatic definition updates enabled, definitions up to date, and tamper protection set to block.
 - Fields requiring redaction include at least organization ID, machine GUID, EDR machine ID, EDR device tags, EDR configuration identifiers, and any future tenant/device/user identifiers.
 
+Owner-supplied working Defender evidence from the enrolled guest also confirms:
+
+- The working guest state reported `healthy: true`.
+- Defender app version remained `101.26032.0016`.
+- Real-time protection was available and backed by `endpoint_security_extension`.
+- Network event collection was backed by `network_filter_extension`.
+- Full Disk Access was enabled.
+- Defender settings showed MDM management for cloud protection, sample submission consent, passive mode, real-time protection, tamper protection, and automatic definition updates.
+- Sensitive organization, machine, EDR, and cloud configuration identifiers were present in the raw capture and are intentionally not committed.
+
 ## Remaining Open Items
 
-- [ ] After a disposable VM exists, deploy Defender for Endpoint inside the guest using the intended Intune demo path.
+- [x] After a disposable VM exists, deploy Defender for Endpoint inside the guest using the intended Intune demo path.
 - [x] Write step-by-step Intune setup instructions for macOS Defender deployment, including package/app assignment, system extension approval, network extension approval when used, Full Disk Access/PPPC delivery, onboarding, group assignment, sync timing, and verification.
-- [ ] Capture `mdatp health` output before and after onboarding, after required system extension and Full Disk Access approvals, and after any intentionally broken policy state used in the demo.
+- [x] Capture `mdatp health` output before and after onboarding and after required system extension and Full Disk Access approvals.
+- [ ] Capture `mdatp health` after any intentionally broken Defender policy state if the final demo uses one.
 - [x] Verify whether the installed `mdatp` has a true JSON output mode. If not, implement and test a parser for key/value text output rather than assuming JSON.
 - [x] Sanitize tenant, device, machine, organization, EDR, user, and cloud identifiers before using the output as fixtures.
 - [x] Owner decision on 2026-05-05: default to live Intune deployment after enrollment, and retain a preinstalled fallback only for rehearsal or cloud-timing backup.
-- [ ] Capture a healthy post-PPPC/onboarded state so tests can distinguish expected pre-approval failure from real Defender malfunction.
+- [x] Capture a healthy post-PPPC/onboarded state so tests can distinguish expected pre-approval failure from real Defender malfunction.
 
 ## Checklist
 
-- [x] Owner: Repository owner; Status: Local implementation complete with owner healthy guest capture deferred; Phase gate affected: Phase 8 validation loop; Why it matters: Defender `mdatp health` output can change and evidence fixtures must not leak real tenant or device data; Action: use the confirmed key/value health-output fields above, verify true JSON availability or implement text parsing, then capture healthy and unhealthy disposable-guest fixtures; Acceptance condition: fixture fields needed by validation code are documented, sanitized, and covered by tests before Defender validation ships; Source: ADR-0005 and spec Section 9.6.
+- [x] Owner: Repository owner; Status: Local implementation complete with owner healthy guest capture recorded on 2026-05-05; Phase gate affected: Phase 8 validation loop; Why it matters: Defender `mdatp health` output can change and evidence fixtures must not leak real tenant or device data; Action: use the confirmed key/value health-output fields above, verify true JSON availability or implement text parsing, then capture healthy and unhealthy disposable-guest fixtures; Acceptance condition: fixture fields needed by validation code are documented, sanitized, and covered by tests before Defender validation ships; Source: ADR-0005 and spec Section 9.6.

TODO-Phase-10-Deferred-Work.md

@@ -3,13 +3,20 @@
 
 ## Metadata
 
-- **Status:** Active
+- **Status:** Active; v1 stubs and documentation complete, future expansion deferred
 - **Owner:** Repository owner
 - **Last Updated:** 2026-05-05
 - **Scope:** Deferred optional or owner-approval-dependent work that is outside Phase 0 and not required for the first working local lab path.
 
 ## Checklist
 
-- [ ] Owner: Repository owner; Status: Deferred outside v1; Phase gate affected: Phase 10 optional providers and CI; Why it matters: Tart is useful for advanced CLI and CI paths but is not a v1 parity provider, and any future macOS guest creation path must respect Apple Virtualization host/guest compatibility constraints; Action: keep Tart as a documented/stubbed provider in v1, and revisit full provider parity only after a later explicit owner approval; Acceptance condition: v1 mutating Tart primitives fail clearly as unsupported, the docs explain the license posture, and any later full implementation re-verifies scope, licensing, compatibility, and provider tests; Source: ADR-0006, ADR-0011, and owner decision on 2026-05-05.
-- [ ] Owner: Repository owner; Status: Deferred outside v1; Phase gate affected: Phase 10 cloud cleanup; Why it matters: local VM rollback does not rewind Intune, Entra, Defender portal state, audit logs, or reporting history, and unsafe matching could mutate the wrong cloud record; Action: keep `Reset-IntuneMacLabDevice.ps1` report-only in v1, and revisit soft-delete/retire or hard-delete only after a later explicit owner approval; Acceptance condition: v1 reports candidate records without mutating cloud state, and any later mutation mode has tests for scoping, confirmation, redaction, soft-delete/retire behavior, and failure paths; Source: ADR-0010 and owner decision on 2026-05-05.
+- [x] Owner: Repository owner; Status: Closed for v1 on 2026-05-05; Phase gate affected: Phase 10 optional providers and CI; Why it matters: Tart is useful for advanced CLI and CI paths but is not a v1 parity provider, and any future macOS guest creation path must respect Apple Virtualization host/guest compatibility constraints; Action: keep Tart as a documented/stubbed provider in v1; Acceptance condition: v1 mutating Tart primitives fail clearly as unsupported and the docs explain the license posture; Source: ADR-0006, ADR-0011, and owner decision on 2026-05-05.
+- [ ] Owner: Repository owner; Status: Deferred outside v1; Phase gate affected: Future Tart provider parity; Why it matters: a full Tart provider would add macOS guest lifecycle and CI behavior that is outside the approved demo path; Action: revisit full provider parity only after a later explicit owner approval; Acceptance condition: future implementation re-verifies scope, licensing, Apple Virtualization compatibility, provider tests, and default-test independence from real Tart infrastructure; Source: ADR-0006, ADR-0011, and owner decision on 2026-05-05.
+- [x] Owner: Repository owner; Status: Closed for v1 on 2026-05-05; Phase gate affected: Phase 10 cloud cleanup; Why it matters: local VM rollback does not rewind Intune, Entra, Defender portal state, audit logs, or reporting history, and unsafe matching could mutate the wrong cloud record; Action: ship `Reset-IntuneMacLabDevice.ps1` as report-only in v1; Acceptance condition: v1 reports candidate records without mutating cloud state and points operators to manual portal review; Source: ADR-0010 and owner decision on 2026-05-05.
+- [ ] Owner: Repository owner; Status: Deferred outside v1; Phase gate affected: Future cloud cleanup mutation; Why it matters: soft-delete, retire, wipe, or hard-delete can affect the wrong cloud record when VM identity drift exists; Action: revisit cloud mutation modes only after a later explicit owner approval; Acceptance condition: mutation mode has tests for scoping, confirmation, redaction, soft-delete/retire behavior, hard-delete refusal or approval boundaries, and failure paths; Source: ADR-0010 and owner decision on 2026-05-05.
+- [x] Owner: Repository owner; Status: Closed for v1 on 2026-05-05; Phase gate affected: Phase 10 Log Analytics; Why it matters: evidence ingestion is useful later, but live ingestion can leak sensitive identifiers if redaction or credentials are wrong; Action: add `docs/Log-Analytics-Integration.md` and keep `scripts/Send-LabEventToLogAnalytics.ps1` disabled by default; Acceptance condition: v1 documents env-var-based future configuration, requires redaction-first behavior, and does not send network traffic; Source: spec Sections 8.2, 19.2, and 21.11.
+- [ ] Owner: Repository owner; Status: Deferred outside v1; Phase gate affected: Future live Log Analytics ingestion; Why it matters: cloud ingestion requires Azure resources, authentication, retry behavior, and privacy review; Action: enable live ingestion only after later explicit owner approval; Acceptance condition: future implementation has tests for missing env vars, authentication failure, network failure, redaction failure, and no default requirement for Azure credentials; Source: spec Sections 8.2, 19.2, and 21.11.
+- [x] Owner: Repository owner; Status: Closed for v1 on 2026-05-05; Phase gate affected: Phase 10 ConfigMgr adjacency; Why it matters: ConfigMgr admins may ask where inventory fits, but ConfigMgr is not the control plane for this lab; Action: add `docs/ConfigMgr-Inventory-Bridge.md` as inventory-adjacency documentation only; Acceptance condition: the doc explains safe redacted export shape and explicitly avoids client install, database writes, and secret export; Source: spec Sections 8.2, 19.2, and 21.11.
+- [ ] Owner: Repository owner; Status: Deferred outside v1; Phase gate affected: Future ConfigMgr import bridge; Why it matters: direct inventory import can spread lab-only or sensitive identifiers into production inventory systems; Action: add any import bridge only after later explicit owner approval; Acceptance condition: future bridge has schema documentation, redaction tests, dry-run mode, and no production ConfigMgr dependency in default tests; Source: spec Sections 8.2, 19.2, and 21.11.
+- [ ] Owner: Repository owner; Status: Deferred outside v1; Phase gate affected: Future visual artifacts; Why it matters: screenshots and recordings can leak tenant names, UPNs, device IDs, recovery-key state, and portal identifiers; Action: keep screenshots and recordings out of the public repo unless a later explicit owner-approved Phase 10 change allows specific redacted artifacts; Acceptance condition: any future visual artifact has a redaction checklist, source review, and no real tenant, user, device, token, recovery-key, or policy identifiers; Source: spec Sections 9.4, 14.2, and 21.11.
 - [x] Owner: Repository owner; Status: Closed on 2026-05-05; Phase gate affected: Phase 1 or later security documentation; Why it matters: ADR-0009 approves only a narrow optional project-specific paragraph for `SECURITY.md`; Action: add the ADR-0009 paragraph after owner approval; Acceptance condition: owner explicitly approves the exact paragraph and the inherited responsible-disclosure process remains intact; Source: ADR-0009 and owner approval on 2026-05-05.

docs/CI-and-Tart.md

@@ -17,7 +17,7 @@ The default MMSMOA demo path uses Parallels for live automation. UTM is a docume
 
 ## License Boundary
 
-The Tart and Orchard public repositories currently publish Fair Source License 0.9 license files. Owner-supplied documentation describes the Tart free tier as 100 CPU cores and Orchard as 4 Orchard Workers. The Orchard license file defines the relevant user concept as a device running macOS.
+The [Tart licensing page](https://tart.run/licensing/) says Tart Virtualization and Orchard Orchestration are licensed under Fair Source License. It describes the free tier as 100 CPU cores for Tart and 4 Orchard Workers for Orchard. The same page links to the free-tier license text in the [Tart repository](https://github.com/cirruslabs/tart/blob/main/LICENSE) and [Orchard repository](https://github.com/cirruslabs/orchard/blob/main/LICENSE).
 
 This repository does not provide legal advice. Users MUST verify Tart, Orchard, Apple, and organizational license suitability before using Tart or Orchard in their own environment.
 

docs/ConfigMgr-Inventory-Bridge.md

@@ -0,0 +1,39 @@
+<!-- markdownlint-disable MD013 -->
+# ConfigMgr Inventory Bridge
+
+## Metadata
+
+- **Status:** Active
+- **Owner:** Repository owner
+- **Last Updated:** 2026-05-05
+- **Scope:** Documents the optional Phase 10 ConfigMgr adjacency for macOSLab evidence and inventory. It does not define a v1 ConfigMgr integration or a production inventory pipeline.
+- **Related:** [Windows Admin Cheat Sheet](Windows-Admin-Cheat-Sheet.md), [Evidence and CAB](Evidence-and-CAB.md), [Phase 10 TODO](../TODO-Phase-10-Deferred-Work.md), [macOSLab Repository Specification](spec/macOSLab-repository-spec.md)
+
+## V1 Posture
+
+ConfigMgr is an inventory adjacency for this repository, not the control plane. The control plane for the lab is Intune, and the portable proof artifact is the redacted macOSLab evidence bundle.
+
+V1 does not:
+
+- install a ConfigMgr client on the macOS guest;
+- write directly to a ConfigMgr database;
+- create hardware inventory classes;
+- upload tenant, user, device, or Defender identifiers to ConfigMgr;
+- replace Intune assignment, compliance, or cleanup workflows.
+
+## Safe Bridge Shape
+
+If ConfigMgr adjacency is useful later, start with a redacted export that a ConfigMgr administrator can review before importing anywhere:
+
+| Evidence field | Inventory use | Redaction expectation |
+| --- | --- | --- |
+| `runId` | Correlate the lab run with a change ticket. | Safe synthetic value only. |
+| `vmName` | Identify the disposable lab VM. | Lab-only name such as `MMS-MACLAB-001`. |
+| `provider` | Record Parallels, UTM, or Tart. | Not sensitive. |
+| `providerVersionMatrix` | Record host, guest, provider, PowerShell, Pester, and Defender versions. | No serials, tenant IDs, or device IDs. |
+| `tests` | Summarize policy validation results. | No raw command output unless already redacted. |
+| `cloudStateWarning` | Preserve rollback boundary. | Required. |
+
+## Future Acceptance
+
+A later owner-approved bridge must include schema documentation, redaction tests, import instructions that do not require production ConfigMgr access, and a clear statement that Intune remains the source for policy assignment and compliance state.