Update documentation and scripts for Gatekeeper/System Policy Control demo

- Changed references from "Visual Studio Code blocked" to "Visual Studio Code first launch blocked" in multiple documents to clarify the demo narrative.
- Updated last modified dates to 2026-05-07 across various planning and specification documents.
- Revised demo scripts to ensure Visual Studio Code is installed but not launched before applying the Gatekeeper policy.
- Added new fixture for Firefox first-launch block dialog and updated existing VS Code block dialog fixture.
- Adjusted evidence bundle schema to reflect changes in the expected failure messages for Gatekeeper assessments.
- Enhanced test scripts to include broader app launch block dialog checks.

Author: franklesniak

README.md

@@ -5,7 +5,7 @@
 
 - **Status:** Active
 - **Owner:** Frank Lesniak
-- **Last Updated:** 2026-05-06
+- **Last Updated:** 2026-05-07
 - **Scope:** User-facing overview for `franklesniak/macOSLab`, including the fastest safe starting path, project boundaries, current phase status, validation commands, deferred work, and license information.
 - **Related:** [Start Here](docs/Start-Here.md), [Prerequisites](docs/Prereqs.md), [macOSLab repository specification](docs/spec/macOSLab-repository-spec.md), [macOSLab ADRs](docs/planning/macOS-imaging-08e-ADRs.md)
 
@@ -22,7 +22,7 @@ This repository is not a production Mac management platform, not legal advice, n
 
 Start at [docs/Start-Here.md](docs/Start-Here.md), then read [docs/Prereqs.md](docs/Prereqs.md) before running any provider or cloud workflow. The implementation is delivered in phase checkpoints; the coding agent can continue through locally verifiable, non-destructive phases and pauses at the owner-validation boundary before live demo validation, release, branch protection, destructive provider/cloud actions, or optional Phase 10 expansion.
 
-For the MMSMOA demo path, Demo 4 uses a Gatekeeper/System Policy Control pivot: a lab-only Intune Settings Catalog policy makes Visual Studio Code fail under App-Store-only execution rules, the fixture-backed validation captures that expected failure, and rollback proves the known-good VM state. FileVault and Defender remain required validation guides and backup proof paths, but they are not the live break-and-rollback failure.
+For the MMSMOA demo path, Demo 4 uses a Gatekeeper/System Policy Control pivot: a lab-only Intune Settings Catalog policy makes Visual Studio Code fail on first launch under App-Store-only execution rules, the fixture-backed validation captures that expected failure, and rollback proves the known-good VM state. FileVault and Defender remain required validation guides and backup proof paths, but they are not the live break-and-rollback failure.
 
 The intended v1 command path is:
 

TODO-Phase-08-Validation-Loop.md

@@ -5,7 +5,7 @@
 
 - **Status:** Local implementation complete; Defender retained and Gatekeeper pivot added
 - **Owner:** Repository owner
-- **Last Updated:** 2026-05-06
+- **Last Updated:** 2026-05-07
 - **Scope:** Deferred verification for Defender health evidence and Gatekeeper/System Policy Control fixture validation.
 
 ## Confirmed Preflight Evidence
@@ -16,7 +16,7 @@ Defender validation evidence should be collected inside a disposable macOS 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 then configured the Intune macOS Defender path and supplied a working guest `mdatp health` capture from a disposable enrolled VM.
 
-The Demo 4 live failure path is now Gatekeeper/System Policy Control blocking Visual Studio Code, with Defender retained as required validation content and backup proof. The committed Gatekeeper fixtures are sanitized text examples; final session sign-off still requires rehearsal capture from the actual demo guest.
+The Demo 4 live failure path is now Gatekeeper/System Policy Control blocking Visual Studio Code on first launch, with Defender retained as required validation content and backup proof. The committed Gatekeeper fixtures are sanitized text examples; final session sign-off still requires rehearsal capture from the actual demo guest.
 
 Owner-supplied Defender evidence from a lab macOS environment also confirms:
 

docs/Defender.md

@@ -5,15 +5,15 @@
 
 - **Status:** Active
 - **Owner:** Repository owner
-- **Last Updated:** 2026-05-06
+- **Last Updated:** 2026-05-07
 - **Scope:** Documents guest-scoped Microsoft Defender for Endpoint validation and Intune setup for the macOSLab demo path.
 - **Related:** [Evidence Redaction](Evidence-Redaction.md), [Evidence and CAB](Evidence-and-CAB.md), [Phase 8 TODO](../TODO-Phase-08-Validation-Loop.md), [Defender validation plan](../examples/TestCases/Defender-Validation.yml)
 
 ## Scope
 
 Defender validation is guest-scoped. The daily-driver host Mac is intentionally not required to have Defender installed. `mdatp health` evidence MUST be collected inside the disposable enrolled macOS guest.
 
-Defender remains a required validation model for the accepted session contract, but it is no longer the live Demo 4 break-and-rollback failure. Demo 4 uses Gatekeeper/System Policy Control to block VS Code because that rollback story is deterministic and does not depend on Defender portal timing. The default Defender path is Intune-based Defender deployment after enrollment. A preinstalled-Defender guest MAY be kept only as a rehearsal or live-cloud timing fallback and MUST be labeled as a fallback.
+Defender remains a required validation model for the accepted session contract, but it is no longer the live Demo 4 break-and-rollback failure. Demo 4 uses Gatekeeper/System Policy Control to block VS Code on first launch because that rollback story is deterministic and does not depend on Defender portal timing. The default Defender path is Intune-based Defender deployment after enrollment. A preinstalled-Defender guest MAY be kept only as a rehearsal or live-cloud timing fallback and MUST be labeled as a fallback.
 
 ## Enrollment Demo Posture
 

docs/Demo-Runbook.md

@@ -5,7 +5,7 @@
 
 - **Status:** Active
 - **Owner:** Repository owner
-- **Last Updated:** 2026-05-06
+- **Last Updated:** 2026-05-07
 - **Scope:** MMSMOA demo runbook for media verification, provider paths, validation evidence, recovery pivots, and owner dry-run boundaries.
 - **Related:** [Start Here](Start-Here.md), [Troubleshooting](Troubleshooting.md), [Evidence and CAB](Evidence-and-CAB.md), [Snapshot Strategy](Snapshot-Strategy.md)
 
@@ -56,7 +56,7 @@ Before traveling or presenting:
 5. Do not sign in to Company Portal yet.
 6. Shut down the guest.
 7. Capture the `Pre-Enroll` checkpoint.
-8. Start from `Pre-Enroll` on reliable network, complete Company Portal enrollment, install and launch Visual Studio Code, wait for Intune sync and baseline policy delivery, then capture `Post-Enroll-Baseline`.
+8. Start from `Pre-Enroll` on reliable network, complete Company Portal enrollment, install Visual Studio Code, verify baseline acceptance with `spctl --assess -vv "/Applications/Visual Studio Code.app"`, do not launch Visual Studio Code, wait for Intune sync and baseline policy delivery, then capture `Post-Enroll-Baseline`.
 9. Use `Post-Enroll-Baseline` as the default live demo starting point.
 
 Use live enrollment during the talk only as an optional walkthrough. If the network is slow, say: "Enrollment is cloud-timed, so the stage path starts from a prepared enrolled checkpoint and the evidence records what changed."
@@ -82,7 +82,7 @@ Run the checklist helper:
 ```
 
 1. Start from the prepared enrolled Demo 4 VM at `Post-Enroll-Baseline`.
-2. Confirm Visual Studio Code launches before the break policy lands.
+2. Confirm Visual Studio Code is installed but has not been launched before the break policy lands.
 3. Assign or sync the lab-only Gatekeeper policy.
 4. In Company Portal, run **Check Status**.
 5. Leave the VM alone while Demo 3 runs.
@@ -152,7 +152,7 @@ Audience-visible summary:
 PASS  MDM enrollment profile present
 PASS  Gatekeeper assessment enabled
 PASS  System Policy Control profile detected
-FAIL  VS Code blocked by App-Store-only policy (expected failure)
+FAIL  VS Code first launch blocked by App-Store-only policy (expected failure)
 PASS  Blocking dialog captured
 PASS  Evidence redaction applied
 PASS  Rollback restored Post-Enroll-Baseline

docs/Evidence-Redaction.md

@@ -5,7 +5,7 @@
 
 - **Status:** Active
 - **Owner:** Repository owner
-- **Last Updated:** 2026-05-06
+- **Last Updated:** 2026-05-08
 - **Scope:** Documents `Protect-MacLabEvidence` behavior, sensitive field names, value-shape redaction, and verification expectations for macOSLab evidence.
 - **Related:** [macOSLab Repository Specification](spec/macOSLab-repository-spec.md), [Evidence and CAB](Evidence-and-CAB.md), [Evidence bundle schema](../schemas/evidence-bundle.schema.json), [Phase 7 TODO](../TODO-Phase-07-Evidence-Pipeline.md)
 
@@ -55,4 +55,4 @@ Pester tests cover:
 - evidence export preserving redaction.
 - Gatekeeper fixture scans that fail if committed fixtures contain Team IDs, profile UUIDs, or local home paths.
 
-Gatekeeper screenshots and recordings are local stage assets only. The repository may keep a generic text reference that a VS Code block dialog was captured during rehearsal, but it MUST NOT commit the screenshot, recording, exact personal file path, Team ID, tenant identifier, profile UUID, device identifier, UPN, or app bundle.
+Gatekeeper screenshots and recordings are local stage assets only. The repository may keep generic text references or sanitized dialog transcripts for VS Code first-launch evidence and secondary-app rehearsal evidence, but it MUST NOT commit the screenshot, recording, exact personal file path, Team ID, tenant identifier, profile UUID, device identifier, UPN, or app bundle.

docs/Evidence-and-CAB.md

@@ -5,7 +5,7 @@
 
 - **Status:** Active
 - **Owner:** Repository owner
-- **Last Updated:** 2026-05-06
+- **Last Updated:** 2026-05-07
 - **Scope:** Describes the evidence-bundle shape, summary files, Provider Version Matrix, and CAB-facing usage boundary for macOSLab validation runs.
 - **Related:** [macOSLab Repository Specification](spec/macOSLab-repository-spec.md), [Evidence Redaction](Evidence-Redaction.md), [Provider Version Matrix](Provider-Version-Matrix.md), [Evidence bundle schema](../schemas/evidence-bundle.schema.json)
 
@@ -46,7 +46,7 @@ For the Demo 4 Gatekeeper pivot, the CAB-facing summary should be explicit that
 ```text
 Policy: MacLab - Gatekeeper - App Store Only
 Checkpoint: Broken-Policy-State
-Expected failure: Visual Studio Code is rejected by System Policy Control
+Expected failure: VS Code first launch is rejected by System Policy Control
 Recovery proof: Post-Enroll-Baseline restores `spctl --assess` acceptance and app launch
 Cloud caveat: Intune assignment remains until removed or narrowed
 ```

docs/Intune-Validation.md

@@ -5,7 +5,7 @@
 
 - **Status:** Active
 - **Owner:** Repository owner
-- **Last Updated:** 2026-05-06
+- **Last Updated:** 2026-05-07
 - **Scope:** Documents fixture-backed Intune compliance and Gatekeeper/System Policy Control validation, plus cloud-state warnings for macOSLab.
 - **Related:** [Evidence and CAB](Evidence-and-CAB.md), [Snapshot Strategy](Snapshot-Strategy.md), [Gatekeeper App Store only test](../examples/TestCases/Gatekeeper-AppStoreOnly.yml), [Gatekeeper recovered test](../examples/TestCases/Gatekeeper-Recovered.yml), [Compliance smoke test](../examples/TestCases/Compliance-SmokeTest.yml)
 
@@ -47,7 +47,9 @@ The repository does not commit a sample `.mobileconfig`. A local profile install
 
 Use split validation plans:
 
-- [Gatekeeper-AppStoreOnly.yml](../examples/TestCases/Gatekeeper-AppStoreOnly.yml) represents `Broken-Policy-State`; it expects the profile to be present and VS Code to be rejected as an expected failure.
+- [Gatekeeper-AppStoreOnly.yml](../examples/TestCases/Gatekeeper-AppStoreOnly.yml) represents `Broken-Policy-State`; it expects the profile to be present and VS Code first launch to be rejected as an expected failure.
 - [Gatekeeper-Recovered.yml](../examples/TestCases/Gatekeeper-Recovered.yml) represents rollback to `Post-Enroll-Baseline`; it expects `spctl` to accept VS Code and launch evidence to show recovery.
 
+The live demo MUST NOT use an app that was already launched and admitted before the App-Store-only policy arrived. A previously launched app can continue opening and make the policy look ineffective. The preferred path is to install or stage Visual Studio Code before `Post-Enroll-Baseline`, verify baseline acceptance with `spctl --assess -vv "/Applications/Visual Studio Code.app"`, and reserve the first GUI launch for `Broken-Policy-State`. Firefox MAY be used as a secondary staged app only when it follows the same not-launched-before-policy rule.
+
 This pattern is for high-risk policies, repeated validation loops, demo scenarios, and evidence that must be reproducible. It is not a requirement to create a YAML plan for every low-risk Intune setting change.

docs/Prereqs.md

@@ -5,7 +5,7 @@
 
 - **Status:** Active
 - **Owner:** Frank Lesniak
-- **Last Updated:** 2026-05-06
+- **Last Updated:** 2026-05-07
 - **Scope:** Host, provider, tooling, and tenant prerequisites for building and validating a `macOSLab` environment.
 - **Related:** [Start Here](Start-Here.md), [Hypervisor Decision Guide](Hypervisor-Decision-Guide.md), [Apple Silicon Constraints](Apple-Silicon-Constraints.md), [Provider Version Matrix](Provider-Version-Matrix.md), [macOSLab repository specification](spec/macOSLab-repository-spec.md)
 
@@ -27,7 +27,7 @@ Recommended:
 - Separate local folder for installers, such as `~/Demo/Installers`.
 - Separate local folder for VM storage, outside the repository.
 - Network path that allows APNs, Intune, Microsoft Graph, Defender, and Apple software update endpoints when running live validation.
-- Visual Studio Code installed inside the enrolled demo guest before capturing `Post-Enroll-Baseline` when rehearsing Demo 4.
+- Visual Studio Code installed inside the enrolled demo guest before capturing `Post-Enroll-Baseline` when rehearsing Demo 4. Do not launch Visual Studio Code before the broken-state step; the live block depends on first-launch Gatekeeper behavior. Firefox MAY be staged as a secondary app under the same rule.
 - Sanitized Gatekeeper fixture text under `examples/TestCases/fixtures/` for stage-safe validation without live cloud timing.
 
 Do not place `.ipsw`, `.dmg`, `.iso`, `.app`, screenshots, recordings, VM bundles, private keys, or credential files inside the repository.

docs/Snapshot-Strategy.md

@@ -5,7 +5,7 @@
 
 - **Status:** Active
 - **Owner:** Frank Lesniak
-- **Last Updated:** 2026-05-06
+- **Last Updated:** 2026-05-07
 - **Scope:** Defines the five-checkpoint model, restore warnings, report-only cloud cleanup posture, and checkpoint readiness expectations for `macOSLab`.
 - **Related:** [Fidelity Boundaries](Fidelity-Boundaries.md), [Provider Version Matrix](Provider-Version-Matrix.md), [Prerequisites](Prereqs.md), [macOSLab repository specification](spec/macOSLab-repository-spec.md)
 
@@ -17,8 +17,8 @@ Snapshots are the reason the lab is fast, but they are also where local state an
 | --- | --- |
 | `Clean-OS` | Freshly installed guest, Setup Assistant complete, no demo software, never enrolled. |
 | `Pre-Enroll` | `Clean-OS` plus Intune Company Portal at the sign-in screen; not enrolled. |
-| `Post-Enroll-Baseline` | Fully enrolled, recently synced, deterministic healthy baseline. For Demo 4, Visual Studio Code is installed and launches successfully here. |
-| `Broken-Policy-State` | Deterministic intentionally broken state for the engineered demo failure. For Demo 4, the Gatekeeper/System Policy Control profile blocks VS Code. |
+| `Post-Enroll-Baseline` | Fully enrolled, recently synced, deterministic healthy baseline. For Demo 4, Visual Studio Code is installed or staged but has not been launched, and baseline `spctl` assessment accepts it. |
+| `Broken-Policy-State` | Deterministic intentionally broken state for the engineered demo failure. For Demo 4, the Gatekeeper/System Policy Control profile blocks VS Code on first launch. |
 | `Recovered-Known-Good` | Post-rollback healthy state, captured after report-only cloud cleanup review or manual reconciliation notes. For Demo 4, `spctl` accepts VS Code and the app launches again. |
 
 Alternative checkpoint names are not allowed in v1 unless a caller explicitly opts into non-canonical names for local experimentation.

docs/Start-Here.md

@@ -5,7 +5,7 @@
 
 - **Status:** Active
 - **Owner:** Frank Lesniak
-- **Last Updated:** 2026-05-06
+- **Last Updated:** 2026-05-07
 - **Scope:** Canonical first-read guide for Windows-first Microsoft endpoint administrators starting with `macOSLab`.
 - **Related:** [README](../README.md), [Prerequisites](Prereqs.md), [Fidelity Boundaries](Fidelity-Boundaries.md), [Snapshot Strategy](Snapshot-Strategy.md), [macOSLab repository specification](spec/macOSLab-repository-spec.md)
 
@@ -38,7 +38,7 @@ Use the VM lab for faster iteration, then use physical hardware where the fideli
 4. Read [Snapshot-Strategy.md](Snapshot-Strategy.md) so checkpoint names and cloud-state warnings are clear before you enroll a VM.
 5. Read [Fidelity-Boundaries.md](Fidelity-Boundaries.md) before turning VM evidence into a change ticket.
 
-The first risky-policy sample is a lab-only Gatekeeper/System Policy Control validation against a disposable VM. The broken-state plan proves an App-Store-only policy blocks Visual Studio Code, and the recovered plan proves rollback restores the known-good app-launch state. The first expected evidence artifact is a redacted JSON record under the evidence output root configured by the test plan.
+The first risky-policy sample is a lab-only Gatekeeper/System Policy Control validation against a disposable VM. The broken-state plan proves an App-Store-only policy blocks Visual Studio Code on first launch, and the recovered plan proves rollback restores the known-good app-launch state. The first expected evidence artifact is a redacted JSON record under the evidence output root configured by the test plan.
 
 ## First Command