More updates based on testing

Author: franklesniak

.gitignore

@@ -35,6 +35,8 @@ evidence/
 Evidence/
 macoslab-preflight/
 macoslab-preflight*.zip
+mdatp*.zip
+prlctl-evidence*.zip
 .maclab/
 media-cache/
 .media-cache/

TODO-Phase-05-Parallels-Provider.md

@@ -20,18 +20,23 @@ Owner-supplied sanitized preflight evidence from a macOS host confirms:
 - `prlctl list -a` returned only the table header, confirming no registered Parallels VMs existed at capture time.
 - `prlctl list --help` supports `--all`, `--full`, `--output`, `--list`, `--template`, `--json`, `--no-header`, `--stopped`, and `--name`.
 - `prlctl snapshot-list --help` supports `--tree`, `--id`, `--json`, and `--no-header`.
+- Later owner-supplied disposable VM evidence confirmed `prlctl list -a` can see a running `macOSLab-Disposable` VM.
+- `prlctl list -i macOSLab-Disposable` reported `Type: APPLE_VZ_VM`, `OS: macosx`, Apple hypervisor usage, `BIOS type: efi-arm64`, Shared networking, 4 vCPU, 8192 MB RAM, and a 128 GB virtual disk.
+- The disposable VM evidence also showed Parallels defaults are not clean enough for the lab isolation policy: multiple integration/sharing settings were still enabled, including camera/gamepad auto-sharing, Shared Applications, SmartMount-style host resource sharing, shared clipboard/cloud, and host location sharing.
+- `prlctl snapshot-list --json` for the disposable VM produced an empty file before any snapshots existed. Treat empty snapshot output as an explicit parser case and re-test after a real named snapshot exists.
 
 Do not commit the raw or sanitized preflight capture bundle. Convert it into durable commands, expected fields, fixtures, and redacted examples only.
 
 ## Remaining Open Items
 
-- [ ] After the pinned IPSW download finishes, create one disposable same-major macOS Tahoe 26.4.1 Parallels VM and capture the exact `prlctl create <name> -o macos --restore-image <path>` behavior.
-- [ ] Verify and document VM list/info/start/stop/delete behavior against the disposable VM.
+- [ ] If not already captured elsewhere, record the exact `prlctl create <name> -o macos --restore-image <path>` command and output used to create the disposable same-major macOS Tahoe 26.4.1 VM.
+- [ ] Verify and document VM start/stop/delete behavior against the disposable VM. Do not run destructive delete except against a disposable VM.
+- [ ] Identify and verify the exact Parallels CLI or manual steps needed to disable host integration/sharing settings after VM creation, then prove the resulting `prlctl list -i` output is clean before `Clean-OS` snapshot capture.
 - [ ] Verify and document named snapshot create/list/restore behavior against the disposable VM.
 - [ ] Confirm whether this Parallels installation exposes edition as Pro through a parseable CLI field; current evidence proves Desktop 26.3.2-57398 and a valid license, but does not expose a clean "Pro" string.
 - [ ] Record the Provider Version Matrix for the disposable VM: host macOS version/build, guest macOS version/build, host/guest classification, Parallels version, IPSW path, IPSW checksum, and date tested.
 - [ ] Treat guest macOS versions higher than the host major version as rejected by default. The current macOS 26.4.1 host can verify same-major Tahoe behavior; older guest majors require explicit cross-major evidence only if they remain in scope for this host.
 
 ## Checklist
 
-- [ ] Owner: Repository owner; Status: Partially verified; Phase gate affected: Phase 5 Parallels provider; Why it matters: provider automation must match the installed Parallels Desktop Pro command surface and must not assume unsupported host/guest macOS pairings; Action: use the confirmed CLI/version facts above, then verify same-major macOS VM creation behavior, snapshot behavior, and rejection/warning behavior on the owner/demo host once the pinned IPSW is available; Acceptance condition: exact commands, expected outputs, host macOS version/build, guest macOS version/build, Parallels version/edition evidence, and host/guest compatibility classification are documented so provider tests can be written without guessing; Source: ADR-0005, ADR-0011, and spec Sections 8.1.1, 9.6, and 17.4.
+- [ ] Owner: Repository owner; Status: Partially verified; Phase gate affected: Phase 5 Parallels provider; Why it matters: provider automation must match the installed Parallels Desktop Pro command surface and must not assume unsupported host/guest macOS pairings or clean isolation defaults; Action: use the confirmed CLI/version/VM-info facts above, then verify same-major macOS VM creation, isolation hardening, snapshot behavior, and rejection/warning behavior on the owner/demo host; Acceptance condition: exact commands, expected outputs, host macOS version/build, guest macOS version/build, Parallels version/edition evidence, host/guest compatibility classification, and clean post-create isolation settings are documented so provider tests can be written without guessing; Source: ADR-0005, ADR-0011, and spec Sections 8.1.1, 9.6, and 17.4.

TODO-Phase-07-Evidence-Pipeline.md

@@ -17,6 +17,9 @@ Owner-supplied sanitized host preflight evidence confirms the future evidence mo
 - Provider command-surface captures, such as help output and list output.
 - Media discovery JSON from `mist`.
 - Provider inventory states where no VMs are registered yet.
+- Provider inventory states where a disposable VM is registered and running.
+- Provider configuration facts that are important evidence, including Apple Virtualization type, shared networking, vCPU/RAM/disk sizing, snapshot-list output, guest-tools state, and host integration/sharing settings.
+- Defender health output in key/value text form. An owner-supplied file named `mdatp-health.raw.json` contained the same key/value text as the `.txt` capture and was not parseable JSON.
 - Sanitization status for hostnames, user paths, UUIDs, MAC addresses, email addresses, license material, and other local identifiers.
 - A distinction between raw local captures, sanitized review bundles, and durable evidence summaries that are safe to commit.
 
@@ -26,9 +29,11 @@ Do not commit the raw or sanitized preflight capture bundle. The committed evide
 
 - [ ] Decide whether the real evidence schema stores raw command-output attachments, normalized parsed facts, or both.
 - [ ] Add fields for host/guest macOS compatibility classification and provider manual-step gaps.
-- [ ] Add redaction assertions that reject license strings, hardware identifiers, local usernames, VM UUIDs, MAC addresses, tenant identifiers, and device identifiers.
+- [ ] Add fields for provider isolation state, including whether host sharing, shared clipboard, shared applications, SmartMount/resource sharing, camera sharing, Bluetooth sharing, and host location sharing are disabled.
+- [ ] Add redaction assertions that reject license strings, hardware identifiers, local usernames, VM UUIDs, MAC addresses, tenant identifiers, device identifiers, Defender organization IDs, Defender machine IDs, Defender machine GUIDs, EDR device tags, and cloud configuration IDs.
 - [ ] Add fixtures for "tool installed but no VMs registered" states for Parallels and UTM.
 - [ ] Add fixtures for "Defender intentionally absent on host; validate inside guest" states if Phase 8 uses host/guest evidence separation.
+- [ ] Add fixtures for Defender unhealthy-but-installed states where `healthy` is `false` because event providers, network event provider, or Full Disk Access are missing.
 
 ## Checklist
 

TODO-Phase-08-Validation-Loop.md

@@ -14,13 +14,24 @@ 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.
 
+Owner-supplied Defender evidence from a lab macOS environment also confirms:
+
+- `mdatp` is available at `/usr/local/bin/mdatp`.
+- `mdatp version` reported product version 101.26032.0016.
+- The captured `mdatp health` output was key/value text, not JSON. A file named `mdatp-health.raw.json` contained the same text as `mdatp-health.raw.txt` and failed JSON parsing.
+- The captured health state was `healthy: false` with health issues for missing active event provider, network event provider not running, and Full Disk Access not granted.
+- 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.
+
 ## Remaining Open Items
 
 - [ ] After a disposable VM exists, install or deploy Defender for Endpoint inside the guest using the intended demo path.
 - [ ] 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.
-- [ ] Sanitize tenant, device, machine, user, and cloud identifiers before using the output as fixtures.
+- [ ] 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.
+- [ ] Sanitize tenant, device, machine, organization, EDR, user, and cloud identifiers before using the output as fixtures.
 - [ ] Decide whether Defender should be present in the `Pre-Enroll` snapshot or deployed live by Intune; do not accidentally hide the behavior the demo is meant to show.
+- [ ] Capture a healthy post-PPPC/onboarded state so tests can distinguish expected pre-approval failure from real Defender malfunction.
 
 ## Checklist
 
-- [ ] Owner: Repository owner; Status: Open, guest-only by design; 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: verify the current Defender `mdatp health` output shape inside a disposable macOS guest and create sanitized fixtures for evidence tests; 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.
+- [ ] Owner: Repository owner; Status: Partially verified, guest-only by design; 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.

docs/planning/macos-imaging-05c-recommended-software-step-by-step-revised.md

@@ -920,7 +920,8 @@ Anything Parallels-specific that doesn't serve those four beats is decoration.
    - **Options → Travel Mode:** off.
    - **Options → More Options → Time machine:** off.
 6. Start the installation. macOS installer reboots the VM several times. This is normal. Do **not** click anything during the reboots.
-7. Plan to **shut the VM down cleanly** before any snapshot capture (Steps 32, 35, 37). Snapshotting a running or paused VM is the most common cause of MDM identity drift on restore.
+7. After creation and configuration, capture `prlctl list -i "<vm-name>"` and verify the VM is an Apple Virtualization macOS VM with Shared networking and no unwanted host integration. Owner preflight evidence showed a disposable Parallels macOS VM defaulting to several enabled integration settings, including shared applications, shared clipboard/cloud, host resource sharing, camera/gamepad sharing, and host location sharing. Treat the VM as not ready for a `Clean-OS` snapshot until those settings are disabled or explicitly accepted in the Provider Version Matrix.
+8. Plan to **shut the VM down cleanly** before any snapshot capture (Steps 32, 35, 37). Snapshotting a running or paused VM is the most common cause of MDM identity drift on restore.
 
 ### Step 30: Create the macOS VM in UTM (only if you will demo UTM live)
 
@@ -1025,6 +1026,7 @@ Do this **only** if your Demo 4 design assumes Defender is already present at th
    - an Intune-driven install captured **before** you take the snapshot. (Note: this requires enrolling the VM, which means this approach belongs in `Post-Enroll-Baseline`, not `Pre-Enroll`. Choose deliberately.)
 2. Launch Defender once.
 3. Approve any first-run permission prompts that you can approve without enrolling. Leave anything that requires MDM-pushed PPPC payloads alone — those are part of the demo.
+4. Capture `mdatp version` and `mdatp health` output after install. Do not assume a file named `.json` is parseable JSON; owner evidence showed `mdatp health` output as key/value text even when saved to a `.json` filename. Record whether the installed `mdatp` build supports a true JSON output mode, and sanitize organization, machine, EDR, tenant, device, user, and cloud identifiers before using the output as evidence fixtures.
 
 ### Step 35: Capture the `Pre-Enroll` snapshot
 
@@ -1268,6 +1270,7 @@ The evidence-protection helper is named `Protect-MacLabEvidence.ps1`. Do **not**
   - PowerShell 7.4+ version
   - Pester 5.7.1
   - Defender for Endpoint version, if used
+  - Defender health output format and redaction status, if used
   - Intune policy-set version or change identifier
   - date tested
 
@@ -1333,6 +1336,7 @@ The evidence-protection helper is named `Protect-MacLabEvidence.ps1`. Do **not**
 - **PowerShell floor.** Use PowerShell 7.4 or newer only.
 - **Tart license and scope.** Tart is optional and stubbed in v1 unless later work explicitly approves a fuller provider. Treat Tart's Fair Source/free-tier 100 CPU-core limit and Orchard's 4-worker limit as planning constraints, not legal advice.
 - **Host/guest macOS coverage.** Same-major host/guest macOS is the safest default for Apple-silicon macOS guests. If you need reliable coverage for macOS 14.x, 15.x, and 26.x at the same time, plan for up to three Apple-silicon host Macs and verify each model can boot the required host macOS. Newest hardware is not automatically best for older guest coverage because it may not support older host macOS releases.
+- **Parallels isolation verification.** Do not trust the Parallels macOS VM defaults to match this lab's isolation policy. Verify the created VM's provider info and disable host integration before the first durable snapshot.
 - **VM fidelity boundary.** The VM lab is for safe iteration, regression, and evidence automation. It does **not** replace physical Mac sign-off for hardware/security-model-dependent flows such as ADE / ABM zero-touch, Platform SSO, Touch ID, Secure Enclave-dependent behavior, and final FileVault rollout validation. **VM first, hardware last.**
 - **Cloud rollback boundary.** Snapshot rollback restores the VM. It does **not** rewind Intune, Entra, Defender portal state, audit logs, compliance history, or cloud reporting. In v1, `Reset-IntuneMacLabDevice.ps1` is report-only and documents manual cleanup steps; it does not mutate cloud records.
 

docs/spec/macOSLab-repository-spec.md

@@ -1189,7 +1189,8 @@ Required behavior:
 - Create, list, and restore snapshots/checkpoints.
 - Return stable VM identity metadata.
 - Use Shared networking.
-- Disable Coherence, shared clipboard, shared folders, shared cameras, shared Bluetooth, and similar host integrations when creating VMs.
+- Disable Coherence, shared clipboard, shared folders, shared cameras, shared Bluetooth, shared applications, SmartMount-style host resource sharing, host location sharing, and similar host integrations when creating VMs.
+- Verify the resulting VM configuration after creation because Parallels defaults may leave host integration settings enabled even when the lab requires isolation.
 
 ### 17.5 UTM Provider