ci: skip CI and CodeQL on gitlink bumps and prose-only commits

Every "chore: bump internal gitlink" commit ran the full CI matrix and
both CodeQL analyses, because a gitlink bump reports the bare path
'internal' (no trailing slash) and the existing 'internal/**' filter
does not match it. Both workflows now ignore the bare and nested forms
of the three private submodule paths plus markdown, LICENSE and the
.github metadata files. CodeQL's weekly unfiltered schedule remains
the backstop.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

.claude/CLAUDE.md

@@ -1,79 +1,42 @@
-## Workflow Orchestration
-# Agent Directives: Mechanical Overrides
+# Agent Directives
 
-You are operating within a constrained context window and strict system prompts. To produce production-grade code, you MUST adhere to these overrides:
+- **Plan first.** Enter plan mode for any non-trivial task (3+ steps or an architectural decision) and write the spec before building. If something goes sideways, stop and re-plan instead of pushing on.
+- **Use subagents liberally** for research, exploration, and parallel analysis — one focus each — to keep the main context clean.
+- **Verify before claiming done.** Run the tests, check the logs, show the evidence. Diff against `main` where behaviour could regress.
+- **Fix bugs autonomously.** Given a report, a failing test, or an error, resolve it — no hand-holding.
+- Read files over 500 LOC in chunks. Never treat one grep as proof of absence.
 
+## Where knowledge lives
 
+| Content | Location | Rule |
+|---|---|---|
+| Customer documentation | separate repo `autopilotmonitor-docs` (GitBook; baked into the MCP `search_docs` corpus) | Any change ⇒ MCP redeploy. Commit in that repo (`cd` first). |
+| Technical concept docs (OKF bundle) | `internal/` — private submodule, entry point `internal/docs/index.md` | Read the index first. Concept docs only for invariants, mechanisms and architecture a later change could silently break. |
+| Decisions, including "we will not build X" | `internal/decisions.md` | One entry per decision: date, decision, why, applies-to, status. |
+| Working files, lessons, plans | `internal/work/` | Rules in `internal/CLAUDE.md`. |
+| Agent review criteria | `internal/docs/agent/architecture-principles.md` | Check every agent change against it. |
+| Private operator instructions | `internal/CLAUDE.md` | Imported at the end of this file. Absent for contributors without submodule access; nothing in it may be copied into this public repo. |
+| Infrastructure and operator scripts | `infra/` — private submodule | Bicep plus deploy/backup/migration scripts. Scripts never carry credentials; secrets come from env or a gitignored file next to the script. |
+| Skills | `.claude/commands/` — private submodule | Each skill's frontmatter says when to use it. |
+| Claude auto-memory | outside the repo, per machine | Private notes only. Anything the project must keep goes into `internal/`. |
 
-### 1. Plan Mode Default
-- Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)
-- If something goes sideways, STOP and re-plan immediately — don't keep pushing
-- Use plan mode for specification steps, not just building
-- Write detailed specs upfront to reduce ambiguity
+## Hard rules
 
-### 2. Subagent Strategy
-- Use subagents liberally to keep main context window clean
-- Offload research, exploration, and parallel analysis to subagents
-- For complex problems, throw more compute at it via subagents
-- One tack per subagent for focused execution
+- Agent projects stay on .NET Framework 4.8.
+- .NET build warnings are errors; only the NU1901–NU1904 advisories remain warnings.
+- Never put real customer domains, tenant names or tenant IDs into code, tests, commits, comments or public docs.
+- Deploy order is Backend → Web → MCP. Backend deploys are `workflow_dispatch` only. Verify the deployed version before claiming anything is live.
+- Submodules (`internal/`, `infra/`, `.claude/commands/`): commit inside the submodule first, then bump the gitlink here.
+- Stage explicit file lists; never `git add -A` or a directory. Pushing is the user's call.
+- New API responses need a typed DTO plus the parity fact. MCP vocabularies are generated from the wire types, never retyped.
+- Every route belongs in the route policy catalog; every new event type goes into the MCP resource catalog.
+- The about, terms and privacy pages under `src/Web/autopilot-monitor-web/app/` state facts customers rely on: verify every claim against the code before writing it and update them in the same change as the fact they describe.
 
-### 3. Self-Improvement Loop
-- After ANY correction from the user: update `tasks/lessons.md` with the pattern
-- Write rules for yourself that prevent the same mistake
-- Ruthlessly iterate on these lessons until mistake rate drops
-- Review lessons at session start for relevant project
+## Code Quality
 
-### 4. Verification Before Done
-- Never mark a task complete without proving it works
-- Diff behavior between main and your changes when relevant
-- Ask yourself: "Would a staff engineer approve this?"
-- Run tests, check logs, demonstrate correctness
+- Simplicity first: minimal, targeted changes. No temporary fixes — find the root cause.
+- Where architecture is flawed, state is duplicated, or patterns are inconsistent, propose and implement the structural fix. Ask what a perfectionist reviewer would reject, and fix that too.
+- On non-trivial changes, ask whether there is a more elegant way before presenting. Skip it for simple fixes — don't over-engineer.
+- English for code comments and everything that carries knowledge.
 
-### 5. Demand Elegance (Balanced)
-- For non-trivial changes: pause and ask "is there a more elegant way?"
-- If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"
-- Skip this for simple, obvious fixes — don't over-engineer
-- Challenge your own work before presenting it
-
-### 6. Autonomous Bug Fixing
-- When given a bug report: just fix it. Don't ask for hand-holding
-- Point at logs, errors, failing tests — then resolve them
-- Zero context switching required from the user
-- Go fix failing CI tests without being told how
-
-
-
-### Tools Execution
-- Read any file over 500 LOC in chunks using offset and limit parameters.
-- Do not assume a single grep caught everything.
-
-### Code Quality
-- If architecture is flawed, state is duplicated, or patterns are inconsistent - propose and implement structural fixes. Ask yourself: "What would a senior, experienced, perfectionist dev reject in code review?" Fix all of it.
-
-
-Codex will review your output once you are done!
-
-
-## Task Management
-
-1. **Plan First**: Write plan to `tasks/todo.md` with checkable items
-2. **Verify Plan**: Check in before starting implementation
-3. **Track Progress**: Mark items complete as you go
-4. **Explain Changes**: High-level summary at each step
-5. **Document Results**: Add review section to `tasks/todo.md`
-6. **Capture Lessons**: Update `tasks/lessons.md` after corrections
-
-## Core Principles
-
-- **Simplicity First**: Make every change as simple as possible. Impact minimal code.
-- **No Laziness**: Find root causes. No temporary fixes. Senior developer standards.
-- **Minimal Impact**: Changes should only touch what's necessary. Avoid introducing bugs.
-
-## Technical Docs — OKF Knowledge Bundle (`docs/`)
-
-`docs/` is an [Open Knowledge Format (OKF) v0.1](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md) knowledge bundle for contributor/AI-facing technical documentation (customer docs live in the separate autopilotmonitor-docs repo).
-
-- **Consume first**: start at `docs/index.md` for progressive disclosure before opening individual documents.
-- **When new durable technical knowledge emerges** (architecture decisions, flows, non-obvious mechanisms), capture it as an OKF concept document in `docs/` — markdown with YAML frontmatter: `type` (mandatory), plus `title`, `description`, `resource`, `tags`, `timestamp` (recommended).
-- **Maintain the bundle**: add every new document to `docs/index.md`, note changes in `docs/log.md` (grouped by ISO date). Use standard RELATIVE markdown links between docs — never the OKF `/`-prefixed bundle-absolute form (GitHub resolves those from the repo root and navigation breaks). `index.md` and `log.md` are reserved filenames.
-- Documents are English, structural markdown over prose (`# Schema`, `# Examples`, `# Citations` sections where applicable).
+Private half of these instructions (process, working files, technical docs, operations): @../internal/CLAUDE.md

.claude/architecture-principles.md

@@ -1,136 +0,0 @@
-# Autopilot-Monitor — Agent Architecture Principles
-
-The principles are **not nice-to-haves**, they are review criteria: any code
-change that violates a principle is either (a) a bug, (b) a reason to change the principle
-(with user sign-off), or (c) an explicitly documented exception with rationale.
-
----
-
-## L.1 Truth Hierarchy (immutable)
-
-`SignalLog` (input) → `Journal` (decisions) → `Snapshot` (cache) → `Projections` (derivable).
-No projection patches backwards into the journal or the signal log. On inconsistency, the
-lower layer always wins (e.g. discard the snapshot, do not "repair" the signal log).
-
-## L.2 Event Sourcing as Foundation
-
-`SignalLog` is the only input truth. The reducer is pure:
-`(oldState, signal) → (newState, transition, effects)`. The backend can re-derive at any
-time from `SignalLog`. Replay yields the same `Journal` content.
-
-## L.3 Immutable State
-
-All DTOs in the decision core are `sealed` with get-only properties. No in-place mutation.
-"Change" = new instance via `With…` method. This is the difference between "purely testable"
-and "subtle heisenbugs".
-
-## L.4 Hypothesis Model instead of Flow Plugins
-
-Fuzziness is constitutive (White-Glove, enrollment type, device-only). A single reducer with
-hypothesis fields (`Unknown/Weak/Strong/Confirmed/Rejected`), organized by scenario in partial
-classes. **No** plugin runtime, because clean flow boundaries do not match reality.
-
-## L.5 Evidence Determinism
-
-Signal-log determinism is guaranteed: same log → same outcome. Every signal carries an
-`Evidence` record with `Kind` (Raw / Derived / Synthetic) and mandatory fields. A signal
-without evidence = adapter rejection = bug.
-
-## L.6 Signal Schema Versioning
-
-Every `DecisionSignalKind` has a `SchemaVersion`. The reducer dispatches on
-`(Kind, SchemaVersion)` — old versions stay replay-capable. A new version or a new kind
-without a replay fixture in `tests/fixtures/signal-kinds/{kind}-v{n}.json` = merge block.
-
-## L.7 Timer Monopoly
-
-Only the Deadline Scheduler (the EffectRunner role) holds decision-relevant timers. Collectors,
-signal adapters and the orchestrator must not. `Task.Delay` or `new Timer(...)` in those
-layers with session-state impact = merge block. `IClock` interface + virtual clock for
-testability.
-
-## L.8 Classifier as Post-Hook Kernel Service
-
-`IClassifier` interface, swappable. The `ClassifierVerdict` flows back into the log as a
-synthetic `ClassifierVerdictIssued` signal. `InputHash` (SHA256 over classifier-relevant
-snapshot fields) is the anti-loop guard. Classifiers are not baked into the state machine.
-
-## L.9 Clean-Agent Principle on Refactors
-
-For structural refactors: build the new project in parallel to the legacy one, do not flag-
-route inside the same process. Strict separation rule: no direct reference to legacy
-projects. Code is copied, not shared. Legacy runs out, then gets removed.
-
-## L.10 Generic Telemetry Transport
-
-One spool for all telemetry types (events, signals, decision transitions). `TelemetryItemId`
-is the type-agnostic upload cursor; the type-specific counters (`Event.Sequence`,
-`SignalOrdinal`, `StepIndex`) remain storage / UI / reducer semantics. Drain guarantee:
-"coordinated + idempotent + resumable" — **not** cross-table atomic, which is not achievable
-with three separate tables anyway.
-
-## L.11 Separation: Agent Lifecycle vs Session State
-
-`DecisionState` is session-pure. Agent-process flags (crash, admin actions, boot time,
-heartbeat status) live separately in `agent-lifecycle.json`, managed by the orchestrator,
-never by the reducer. Prevents replay dilution by lifecycle events.
-
-## L.12 Flush-on-Append Persistence
-
-No batching of append operations. `FileOptions.WriteThrough` plus an explicit
-`FlushAsync(flushToDisk: true)` per append. Every successful `Append` return means: on disk.
-Durability > performance in the crash-prone OOBE context.
-
-## L.13 UI Primacy — End-Users vs Dev Tooling
-
-Product views (EventTimeline, PhaseTimeline) stay slim and stable. Debug / analysis tools
-(Inspector with DecisionGraph, SignalStream, VerifierReport) live on their own subpage behind
-an `adminMode` gate. The session-detail page does not get overloaded with dev components.
-
-## L.14 Forward Compatibility by Default
-
-Enums via `StringEnumConverter` + `UnknownFallbackEnumConverter` (unknown values → default,
-never crash). New schema fields are nullable. The `ReducerVersion` stamp per journal row
-allows older backends to read newer rows. Deletions only after a major version bump with
-user sign-off.
-
-## L.15 Test Discipline
-
-Flow / scenario tests are prioritized over structural tests. Coverage targets per component
-(DecisionCore ≥95 %, classifier 100 %, backend functions ≥85 %). A missing fixture for a
-scenario = merge block. CI threshold check is a build failure, not a warning.
-
-## L.16 Fail-Safe Reducer Exceptions
-
-Exception in the reducer → `DecisionTransition` with `DeadEndReason=reducer_exception`, state
-unchanged (fail-safe, never destroy state). Signal counts as processed (no retry loop). After
-five consecutive exceptions → the orchestrator emits
-`enrollment_failed(reason=reducer_instability)`.
-
-## L.17 Effect Error Handling by Class
-
-Three effect classes with their own strategy:
-
-- **Transient** (retry with exponential backoff 100 ms / 400 ms / 1600 ms):
-  `EmitEventTimelineEntry`, `PersistSnapshot`
-- **Critical** (session abort, e.g. on timer-register failure): `ScheduleDeadline`,
-  `CancelDeadline`
-- **Optional** (best-effort, classifier exception → `Inconclusive` verdict, no abort):
-  `RunClassifier`
-
-Every effect failure is logged as a `DecisionTransition`.
-
-## L.18 Implementation Discipline
-
-- **R1** Pre-flight plan check before every work step
-- **R2** Delegate self-contained sub-tasks **and exploration** to subagents (Anthropic
-  recommendation: preserve main-context window on large refactors — quality assurance)
-- **R3** Real verification (DB round-trip, index dual-write, agent signal emission) — no
-  "it compiles and runs"
-- **R4** The plan is authority — deviations require user sign-off
-- **R5** Out-of-scope items land in `tasks/todo.md`, not in memory
-- **R6** High test coverage is a prerequisite for future refactorability, not a nice-to-have
-- **R7** Code-structure discipline: small files (guideline ≤300 LoC), clear folders, partial
-  classes by scenario, check in with the user on any uncertainty (placement, naming, scope)
-
----

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,49 @@
+name: Bug report
+description: Something does not work as documented.
+labels: [bug]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for the report. Please redact tenant IDs, device names, serial numbers, and anything personal before posting.
+        For a failed enrollment in your own tenant, the fastest path is the **Report Session** button in the portal — it attaches the session context for support without exposing it here.
+  - type: dropdown
+    id: component
+    attributes:
+      label: Component
+      options:
+        - Web portal
+        - Agent (on device)
+        - Bootstrap script / Intune deployment
+        - MCP server / AI integration
+        - Analysis rules / log patterns
+        - Backend / API
+        - Documentation
+        - Not sure
+    validations:
+      required: true
+  - type: textarea
+    id: what
+    attributes:
+      label: What happened?
+      description: What did you do, what did you expect, what happened instead?
+    validations:
+      required: true
+  - type: textarea
+    id: repro
+    attributes:
+      label: Steps to reproduce
+      placeholder: |
+        1. …
+        2. …
+  - type: input
+    id: version
+    attributes:
+      label: Agent version / portal date
+      description: Agent version from the session details, or the date you saw it in the portal.
+  - type: textarea
+    id: logs
+    attributes:
+      label: Logs or screenshots
+      description: Relevant excerpts only, redacted. Paste text rather than screenshots of text where possible.
+      render: text

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,11 @@
+blank_issues_enabled: false
+contact_links:
+  - name: Question or idea
+    url: https://github.com/okieselbach/AutopilotMonitor/discussions
+    about: Ask how something works or float a feature idea before it becomes a request.
+  - name: Documentation
+    url: https://docs.autopilotmonitor.com
+    about: Setup guides, troubleshooting, and the security FAQ.
+  - name: Security vulnerability
+    url: https://github.com/okieselbach/AutopilotMonitor/security/advisories/new
+    about: Report privately. Please never open a public issue for a security finding.

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,34 @@
+name: Feature request
+description: Propose something Autopilot Monitor should do.
+labels: [enhancement]
+body:
+  - type: textarea
+    id: problem
+    attributes:
+      label: What problem are you trying to solve?
+      description: Describe the situation, not the solution. What are you doing today instead?
+    validations:
+      required: true
+  - type: textarea
+    id: proposal
+    attributes:
+      label: Proposed change
+      description: What would you like to see? Rough is fine.
+    validations:
+      required: true
+  - type: dropdown
+    id: area
+    attributes:
+      label: Area
+      options:
+        - Web portal
+        - Agent (on device)
+        - Analysis rules / diagnostics
+        - MCP server / AI integration
+        - Notifications / integrations
+        - Reporting
+        - Other
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: Alternatives considered

.github/assets/social-preview.html

@@ -0,0 +1,55 @@
+<!doctype html>
+<html><head><meta charset="utf-8">
+<link rel="preconnect" href="https://fonts.googleapis.com">
+<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600;700;800&display=swap" rel="stylesheet">
+<style>
+  html,body{margin:0;padding:0;}
+  body{width:1280px;height:640px;overflow:hidden;font-family:Inter,system-ui,-apple-system,"Segoe UI",sans-serif;color:#0f172a;
+    background:
+      radial-gradient(900px 600px at 105% 110%, #dcfce7 0%, rgba(220,252,231,0) 60%),
+      radial-gradient(700px 500px at -10% -10%, #e0f2fe 0%, rgba(224,242,254,0) 60%),
+      linear-gradient(180deg,#ffffff 0%,#f6f8f7 100%);
+    position:relative;}
+  .grid{position:absolute;inset:0;background-image:linear-gradient(rgba(15,23,42,.045) 1px,transparent 1px),linear-gradient(90deg,rgba(15,23,42,.045) 1px,transparent 1px);background-size:40px 40px;mask-image:linear-gradient(180deg,rgba(0,0,0,.7),rgba(0,0,0,0) 85%);}
+  .left{position:absolute;left:72px;top:0;height:640px;width:520px;display:flex;flex-direction:column;justify-content:center;z-index:2;}
+  .brand{display:flex;align-items:center;gap:14px;margin-bottom:26px;}
+  .brand svg{width:44px;height:40px;}
+  .brand span{font-size:22px;font-weight:600;letter-spacing:-.01em;color:#0f172a;}
+  h1{margin:0 0 18px;font-size:50px;line-height:1.06;font-weight:800;letter-spacing:-.035em;}
+  h1 em{font-style:normal;color:#16a34a;}
+  p.tag{margin:0 0 30px;font-size:20px;line-height:1.45;color:#475569;font-weight:400;max-width:480px;}
+  .chips{display:flex;flex-wrap:wrap;gap:10px;margin-bottom:34px;}
+  .chip{display:inline-flex;align-items:center;gap:8px;padding:8px 14px;border-radius:999px;background:#fff;border:1px solid #e2e8f0;box-shadow:0 1px 2px rgba(15,23,42,.05);font-size:15px;font-weight:500;color:#1e293b;}
+  .chip i{width:8px;height:8px;border-radius:50%;background:#22c55e;display:inline-block;}
+  .chip.b i{background:#3b82f6}.chip.p i{background:#8b5cf6}
+  .foot{display:flex;align-items:center;gap:14px;font-size:15px;color:#64748b;font-weight:500;}
+  .foot b{color:#0f172a;font-weight:600;}
+  .foot .dot{width:4px;height:4px;border-radius:50%;background:#cbd5e1;}
+  .shot{position:absolute;left:600px;top:76px;width:1000px;height:640px;border-radius:14px;background:#fff;
+    box-shadow:0 30px 80px -20px rgba(15,23,42,.35),0 0 0 1px rgba(15,23,42,.08);overflow:hidden;z-index:1;}
+  .bar{position:relative;z-index:2;height:34px;background:#f8fafc;border-bottom:1px solid #e2e8f0;display:flex;align-items:center;padding:0 14px;gap:7px;}
+  .bar i{width:10px;height:10px;border-radius:50%;background:#e2e8f0;display:inline-block;}
+  .bar .url{margin-left:12px;flex:0 0 auto;height:20px;padding:0 10px;border-radius:6px;background:#fff;border:1px solid #e2e8f0;font-size:11px;line-height:20px;color:#64748b;}
+  .shot img{position:absolute;left:-214px;top:-16px;width:1440px;height:900px;transform-origin:top left;transform:scale(.94);}
+</style></head>
+<body>
+<div class="grid"></div>
+<div class="left">
+  <div class="brand">
+    <svg viewBox="0 0 209 191" fill="none" xmlns="http://www.w3.org/2000/svg"><path d="M0 180.201L208.401 190.502L188.157 76.2438L5.48363e-06 0L0 180.201Z" fill="#33B161"/></svg>
+    <span>Autopilot Monitor</span>
+  </div>
+  <h1>See every Windows<br>enrollment <em>as it happens</em></h1>
+  <p class="tag">Live session timelines, fleet health, and on-demand diagnostics for Windows Autopilot and Intune.</p>
+  <div class="chips">
+    <span class="chip"><i></i>Live session timeline</span>
+    <span class="chip b"><i></i>Fleet health</span>
+    <span class="chip p"><i></i>MCP server for AI troubleshooting</span>
+  </div>
+  <div class="foot"><b>autopilotmonitor.com</b><span class="dot"></span>Open source<span class="dot"></span>Free Community plan</div>
+</div>
+<div class="shot">
+  <div class="bar"><i></i><i></i><i></i><span class="url">portal.autopilotmonitor.com/dashboard</span></div>
+  <img src="social-preview-dashboard.png" alt="">
+</div>
+</body></html>

.github/codeql/codeql-config.yml

@@ -0,0 +1,31 @@
+# CodeQL configuration.
+#
+# The default query suites stay active — this file only filters out two C# queries
+# that fire structurally on this codebase, where the flagged behavior is the feature,
+# not a defect:
+#
+#   cs/exposure-of-sensitive-information
+#     Audit and operational logs record WHO performed an action (actor UPN / email)
+#     and notification services deliver mail to a recipient address. Writing that
+#     identity to the log / notification IS the purpose of the field. Every such site
+#     is a legitimate, reviewed use — the query cannot distinguish it from a leak.
+#
+#   cs/cleartext-storage-of-sensitive-information
+#     The rate limiters and distress guard use the trusted client IP as their bucket
+#     key. The IP is an identifier for throttling, not a secret at rest; storing it in
+#     the in-memory / table rate-limit key is by design.
+#
+# Genuine one-off false positives from OTHER queries (e.g. an open-redirect the taint
+# model can't see is allow-listed, a rate-limited route it doesn't recognize) are
+# dismissed individually in the Security tab so those queries stay sharp — they are
+# NOT suppressed here.
+#
+# Log-injection (cs/log-forging) is deliberately NOT filtered: user-controlled values
+# are sanitized at the sink via Helpers/LogSanitizer, so the query stays useful for
+# catching a future unsanitized sink.
+
+query-filters:
+  - exclude:
+      id: cs/exposure-of-sensitive-information
+  - exclude:
+      id: cs/cleartext-storage-of-sensitive-information

.github/dependabot.yml

@@ -0,0 +1,67 @@
+version: 2
+
+# Grouping: every ecosystem gets one batched PR for minor/patch version
+# updates and one batched PR for security updates. Groups apply to version
+# updates only by default, so the security-updates groups are declared
+# explicitly — otherwise every advisory lands as its own PR.
+
+updates:
+  - package-ecosystem: nuget
+    directory: /
+    schedule:
+      interval: weekly
+    open-pull-requests-limit: 5
+    groups:
+      dotnet:
+        patterns: ['*']
+        update-types: [minor, patch]
+      dotnet-security:
+        applies-to: security-updates
+        patterns: ['*']
+
+  - package-ecosystem: npm
+    directory: /src/Web/autopilot-monitor-web
+    schedule:
+      interval: weekly
+    open-pull-requests-limit: 5
+    groups:
+      web:
+        patterns: ['*']
+        update-types: [minor, patch]
+      web-security:
+        applies-to: security-updates
+        patterns: ['*']
+    # Major bumps are breaking and reviewed deliberately, not auto-PR'd.
+    # Security updates ignore this filter, so the Security tab stays clean.
+    ignore:
+      - dependency-name: '*'
+        update-types: ['version-update:semver-major']
+
+  - package-ecosystem: npm
+    directory: /src/McpServer/autopilot-monitor-mcp
+    schedule:
+      interval: weekly
+    open-pull-requests-limit: 5
+    groups:
+      mcp:
+        patterns: ['*']
+        update-types: [minor, patch]
+      mcp-security:
+        applies-to: security-updates
+        patterns: ['*']
+    # Major bumps are breaking and reviewed deliberately, not auto-PR'd.
+    # Security updates ignore this filter, so the Security tab stays clean.
+    ignore:
+      - dependency-name: '*'
+        update-types: ['version-update:semver-major']
+
+  - package-ecosystem: github-actions
+    directory: /
+    schedule:
+      interval: monthly
+    groups:
+      actions:
+        patterns: ['*']
+      actions-security:
+        applies-to: security-updates
+        patterns: ['*']

.github/scripts/Publish-BootstrapScripts.ps1

@@ -0,0 +1,367 @@
+<#
+.SYNOPSIS
+    Publishes the customer-facing PowerShell scripts behind download.autopilotmonitor.com/agent/.
+
+.DESCRIPTION
+    Single owner of the script-publishing chain. Called from two places:
+
+      * publish-scripts.yml  -- on every push to main that touches the sources,
+                                so a script fix reaches customers without waiting
+                                for an agent release.
+      * build-agent.yml      -- on a publish_as_stable run, so a release always
+                                lands a consistent set (ZIP + manifest + scripts).
+
+    Both callers run the same code. The scripts on the download alias are the live
+    copy the WDP bootstrap MSI (Invoke-BootstrapDownload.ps1) downloads on every
+    enrolling device, so "current" is a correctness property, not cosmetics.
+
+    Steps, in order:
+      1. Parse $ScriptVersion from the bootstrap source.
+      2. Render the -Dev variant by literal substitution of the two URL/manifest
+         defaults. A missing anchor is a hard failure -- a silently un-substituted
+         dev script would point the dev fleet at the stable agent.
+      3. Version-bump guard: if the published bootstrap differs from the source
+         but carries the same $ScriptVersion, abort. Otherwise the docs badge,
+         version.json.bootstrapVersion and the portal's "your script is outdated"
+         hint would all keep asserting a version that is no longer what ships.
+      4. Upload every script blob with Cache-Control: no-cache (they rotate in
+         place), mirrored fail-soft to the legacy account.
+      5. Reconcile the two version oracles: version.json.bootstrapVersion
+         (read-modify-write under If-Match, so a concurrent agent release cannot
+         lose its agent fields) and AdminConfiguration.LatestBootstrapV2ScriptVersion.
+      6. Verify through the alias -- re-download each blob and compare SHA-256.
+
+.PARAMETER SasToken
+    Container SAS for the eu storage account with write permission. Leading '?' tolerated.
+
+.PARAMETER LegacySasToken
+    Container SAS for the legacy account. Optional -- a mirror failure warns, never fails.
+
+.PARAMETER TableSasToken
+    Table SAS for AdminConfiguration. Optional -- omitted or 'XXX' skips the oracle update.
+
+.PARAMETER RepoRoot
+    Repository root. Defaults to the parent of .github/scripts.
+
+.PARAMETER DryRun
+    Run every check and render, upload nothing.
+
+.EXAMPLE
+    ./Publish-BootstrapScripts.ps1 -DryRun
+
+.EXAMPLE
+    ./Publish-BootstrapScripts.ps1 -SasToken $env:SAS -TableSasToken $env:TABLE_SAS
+#>
+[CmdletBinding()]
+param(
+    [string]$SasToken,
+    [string]$LegacySasToken,
+    [string]$TableSasToken,
+    [string]$RepoRoot,
+    [switch]$DryRun
+)
+
+$ErrorActionPreference = 'Stop'
+
+if (-not $RepoRoot) {
+    $RepoRoot = (Resolve-Path (Join-Path $PSScriptRoot '../..')).Path
+}
+if (-not $DryRun -and [string]::IsNullOrWhiteSpace($SasToken)) {
+    throw 'SasToken is required unless -DryRun is used.'
+}
+
+$ContainerUrl       = 'https://autopilotmonitoreu.blob.core.windows.net/agent'
+$LegacyContainerUrl = 'https://autopilotmonitor.blob.core.windows.net/agent'
+$AliasUrl           = 'https://download.autopilotmonitor.com/agent'
+$TableUrl           = "https://autopilotmonitoreu.table.core.windows.net/AdminConfiguration(PartitionKey='GlobalConfig',RowKey='config')"
+
+$BootstrapSource   = Join-Path $RepoRoot 'scripts/Bootstrap/Install-AutopilotMonitor.ps1'
+$BootstrapBlob     = 'Install-AutopilotMonitor.ps1'
+$DevBlob           = 'Install-AutopilotMonitor-Dev.ps1'
+$ScriptContentType = 'text/plain; charset=utf-8'
+
+function Get-HttpStatus {
+    param($ErrorRecord)
+    if ($ErrorRecord.Exception.PSObject.Properties['Response'] -and $ErrorRecord.Exception.Response) {
+        return [int]$ErrorRecord.Exception.Response.StatusCode
+    }
+    return 0
+}
+
+function Get-Sha256 {
+    param([byte[]]$Bytes)
+    $sha = [System.Security.Cryptography.SHA256]::Create()
+    try { return [BitConverter]::ToString($sha.ComputeHash($Bytes)).Replace('-', '').ToLowerInvariant() }
+    finally { $sha.Dispose() }
+}
+
+# Raw bytes of a published blob, or $null when it does not exist yet.
+function Get-PublishedBytes {
+    param([string]$Url)
+    try {
+        $resp = Invoke-WebRequest -Uri $Url -Method Get -UseBasicParsing
+    } catch {
+        if ((Get-HttpStatus $_) -eq 404) { return $null }
+        throw
+    }
+    # Comma operator: PowerShell unrolls an array returned from a function into the output
+    # stream and reassembles it as Object[], which would silently defeat every [byte[]] use
+    # downstream. ',' wraps it so the byte[] survives the return.
+    if ($resp.Content -is [byte[]]) { return ,$resp.Content }
+    return ,[System.Text.Encoding]::UTF8.GetBytes([string]$resp.Content)
+}
+
+# Deterministic publish form: CRLF, UTF-8 without BOM. Git normalises line endings on
+# checkout (a Windows runner yields CRLF, a core.autocrlf=false clone yields LF), so
+# publishing the raw working-copy bytes would emit different blobs for identical source
+# and make every byte comparison -- guard and verify alike -- environment-dependent.
+# CRLF is also what PS 5.1 on the device expects and what is published today.
+function Get-PublishBytes {
+    param([string]$Text)
+    $normalised = $Text.Replace("`r`n", "`n").Replace("`n", "`r`n")
+    # ',' keeps this a byte[]: without it PowerShell unrolls the array into the output stream
+    # and the caller receives Object[]. Invoke-RestMethod then serialises an Object[] body as
+    # space-separated decimals instead of raw bytes -- a silent corruption of the upload.
+    return ,(New-Object System.Text.UTF8Encoding $false).GetBytes($normalised)
+}
+
+function Get-BootstrapScriptVersion {
+    param([string]$Content, [string]$Origin, [switch]$Optional)
+    if ($Content -match '\$ScriptVersion\s*=\s*"([\d\.\-a-zA-Z]+)"') { return $Matches[1] }
+    # Unreadable SOURCE is fatal. An unreadable PUBLISHED copy must not be: that is exactly
+    # the state a republish is meant to repair, and a guard that blocks the repair is worse
+    # than no guard.
+    if ($Optional) { return $null }
+    throw "Could not parse ScriptVersion from $Origin"
+}
+
+# What the script actually DOES, with comments and layout removed: the PowerShell token
+# stream minus comments, newlines and line continuations. Lets the version-bump guard tell
+# a behaviour change (must be versioned -- consumers act on the version) apart from a
+# comment fix or reflow (nobody needs to know). Tokenising rather than regex-stripping
+# keeps '#' inside strings from being mistaken for a comment.
+function Get-CodeFingerprint {
+    param([string]$Text, [string]$Origin)
+    $tokens = $null
+    $errors = $null
+    [System.Management.Automation.Language.Parser]::ParseInput($Text, [ref]$tokens, [ref]$errors) | Out-Null
+    if ($errors -and $errors.Count -gt 0) {
+        throw "Parse error in ${Origin}: $($errors[0])"
+    }
+    $ignored = @('Comment', 'NewLine', 'LineContinuation', 'EndOfInput')
+    return (($tokens | Where-Object { $ignored -notcontains $_.Kind.ToString() } | ForEach-Object { $_.Text }) -join "`n")
+}
+
+# ------------------------------------------------------------------ 1. source
+$sourceContent = Get-Content $BootstrapSource -Raw
+$sourceBytes   = Get-PublishBytes $sourceContent
+$scriptVersion = Get-BootstrapScriptVersion -Content $sourceContent -Origin $BootstrapSource
+Write-Host "Bootstrap script version: $scriptVersion"
+
+# ------------------------------------------------------------------ 2. dev render
+$stableUrlLiteral = '$AgentDownloadUrl = "https://download.autopilotmonitor.com/agent/AutopilotMonitor-Agent.zip"'
+$devUrlLiteral    = '$AgentDownloadUrl = "https://download.autopilotmonitor.com/agent/AutopilotMonitor-Agent-dev.zip"'
+$stableManLiteral = '$VersionJsonName = "version.json"'
+$devManLiteral    = '$VersionJsonName = "version-dev.json"'
+
+if ($sourceContent.IndexOf($stableUrlLiteral) -lt 0 -or $sourceContent.IndexOf($stableManLiteral) -lt 0) {
+    throw "Bootstrap dev-render: anchor literal missing in $BootstrapSource"
+}
+$devContent = $sourceContent.Replace($stableUrlLiteral, $devUrlLiteral).Replace($stableManLiteral, $devManLiteral)
+Write-Host "Rendered $DevBlob (dev agent URL + version-dev.json)"
+
+# ------------------------------------------------------------------ 3. bump guard
+$publishedBytes = Get-PublishedBytes "$AliasUrl/$BootstrapBlob"
+if ($null -eq $publishedBytes) {
+    Write-Host 'No published bootstrap yet -- version-bump guard skipped (first publish)'
+} elseif ((Get-Sha256 $publishedBytes) -eq (Get-Sha256 $sourceBytes)) {
+    Write-Host 'Published bootstrap is already byte-identical to the source'
+} else {
+    $publishedText    = [System.Text.Encoding]::UTF8.GetString($publishedBytes)
+    $publishedVersion = Get-BootstrapScriptVersion -Content $publishedText -Origin "$AliasUrl/$BootstrapBlob" -Optional
+
+    if ($null -eq $publishedVersion) {
+        Write-Host "::warning::The published $BootstrapBlob is not a readable bootstrap script (no ScriptVersion found). Republishing over it."
+    } elseif ($publishedVersion -ne $scriptVersion) {
+        Write-Host "Version bump: $publishedVersion -> $scriptVersion"
+    } elseif ((Get-CodeFingerprint -Text $publishedText -Origin "$AliasUrl/$BootstrapBlob") -eq
+              (Get-CodeFingerprint -Text $sourceContent -Origin $BootstrapSource)) {
+        # Comments, typos in comments, reflow -- nothing a consumer of the version can act on.
+        Write-Host "::warning::$BootstrapBlob changed in comments or formatting only; publishing under the unchanged version $scriptVersion."
+    } else {
+        throw ("Version-bump guard: $BootstrapBlob changed behaviour but ScriptVersion is still $scriptVersion. " +
+               "Bump it in $BootstrapSource -- the docs badge, version.json.bootstrapVersion and the " +
+               'portal outdated-script hint all read that value, and customers decide from it whether ' +
+               'to re-upload their Intune copy. Comment-only and formatting changes do not need a bump.')
+    }
+}
+
+# ------------------------------------------------------------------ 4. upload
+# Sources beyond the bootstrap pair, read straight from the repo.
+$extraSources = @(
+    @{ Path = 'scripts/Bootstrap/Test-ShouldBootstrapAgent.ps1';       BlobName = 'Test-ShouldBootstrapAgent.ps1' }
+    # Customer-side Graph add-on grant script -- docs and admin UI link it directly.
+    @{ Path = 'scripts/CustomerSetup/Grant-AutopilotMonitorAddOn.ps1'; BlobName = 'Grant-AutopilotMonitorAddOn.ps1' }
+)
+# Uninstall-AutopilotMonitor.ps1 is deliberately NOT published: nothing links it, and
+# an unauthenticated uninstall script on the public download host is not a feature.
+
+$publishSet = [System.Collections.Generic.List[object]]::new()
+$publishSet.Add([pscustomobject]@{ BlobName = $BootstrapBlob; Bytes = $sourceBytes })
+$publishSet.Add([pscustomobject]@{ BlobName = $DevBlob;       Bytes = (Get-PublishBytes $devContent) })
+foreach ($extra in $extraSources) {
+    $extraPath = Join-Path $RepoRoot $extra.Path
+    if (-not (Test-Path $extraPath)) {
+        throw "Publish source missing: $extraPath"
+    }
+    $publishSet.Add([pscustomobject]@{ BlobName = $extra.BlobName; Bytes = (Get-PublishBytes (Get-Content $extraPath -Raw)) })
+}
+
+$legacySas = if ($LegacySasToken) { $LegacySasToken.TrimStart('?') } else { '' }
+$writeSas  = if ($SasToken) { $SasToken.TrimStart('?') } else { '' }
+
+foreach ($item in $publishSet) {
+    # Explicit type, not a convenience: an Object[] body is uploaded as space-separated
+    # decimals rather than raw bytes, and every hash check still passes because [byte[]]
+    # parameter coercion repairs it everywhere EXCEPT the wire.
+    [byte[]]$bytes = $item.Bytes
+    $item | Add-Member -NotePropertyName Sha256 -NotePropertyValue (Get-Sha256 $bytes) -Force
+
+    if ($DryRun) {
+        # Doubles as a drift check: says per blob whether the alias already serves this source.
+        $served = Get-PublishedBytes "$AliasUrl/$($item.BlobName)"
+        $state = if ($null -eq $served) { 'MISSING on the alias' }
+                 elseif ((Get-Sha256 $served) -eq $item.Sha256) { 'already current' }
+                 else { 'STALE on the alias' }
+        Write-Host "  [dry-run] $($item.BlobName) ($($bytes.Length) bytes, sha256 $($item.Sha256)) -- $state"
+        continue
+    }
+
+    # no-cache on every blob: they all rotate in place and the download alias fronts them
+    # with Front Door. Route caching is disabled there, but a stale script paired with a
+    # fresh manifest would fail the bootstrap SHA check -- this keeps that class of bug
+    # impossible even if caching is ever re-enabled.
+    $headers = @{ 'x-ms-blob-type' = 'BlockBlob'; 'Content-Type' = $ScriptContentType; 'x-ms-blob-cache-control' = 'no-cache' }
+    Invoke-RestMethod -Uri "$ContainerUrl/$($item.BlobName)?$writeSas" -Method Put -Headers $headers -Body $bytes | Out-Null
+
+    # Read straight back from the blob (authoritative, no CDN in the way) before touching the
+    # mirror or the next file. The alias verification at the end would catch a bad body too,
+    # but only after every blob was already overwritten -- these are live customer downloads.
+    $written = Get-PublishedBytes "$ContainerUrl/$($item.BlobName)"
+    if ($null -eq $written -or (Get-Sha256 $written) -ne $item.Sha256) {
+        $writtenLength = if ($null -eq $written) { 'missing' } else { "$($written.Length) bytes" }
+        throw ("Upload of $($item.BlobName) did not round-trip: sent $($bytes.Length) bytes, " +
+               "blob now holds $writtenLength. Publishing stopped before the mirror and the " +
+               'remaining files, so no further blob was touched.')
+    }
+    Write-Host "  uploaded $($item.BlobName) ($($bytes.Length) bytes, round-trip verified)"
+
+    if ($legacySas) {
+        try {
+            Invoke-RestMethod -Uri "$LegacyContainerUrl/$($item.BlobName)?$legacySas" -Method Put -Headers $headers -Body $bytes | Out-Null
+            Write-Host "  mirrored $($item.BlobName) to legacy storage"
+        } catch {
+            Write-Host "::warning::legacy mirror failed for $($item.BlobName) -- $($_.Exception.Message)"
+        }
+    }
+}
+
+# ------------------------------------------------------------------ 5. version oracles
+# version.json is the agent manifest; only bootstrapVersion belongs to us. Read from the
+# blob (not the alias) for an authoritative ETag, write back under If-Match so a concurrent
+# agent release cannot lose its version/sha256 fields.
+if (-not $DryRun) {
+    try {
+        $manifestResp = Invoke-WebRequest -Uri "$ContainerUrl/version.json" -Method Get -UseBasicParsing
+        $manifestRaw = if ($manifestResp.Content -is [byte[]]) {
+            [System.Text.Encoding]::UTF8.GetString($manifestResp.Content)
+        } else { [string]$manifestResp.Content }
+        $manifest = $manifestRaw | ConvertFrom-Json
+
+        if ($manifest.bootstrapVersion -eq $scriptVersion) {
+            Write-Host "version.json already reports bootstrapVersion $scriptVersion"
+        } else {
+            $etag = '"' + ([string]($manifestResp.Headers['ETag'] | Select-Object -First 1)).Trim('"') + '"'
+            $manifest | Add-Member -NotePropertyName 'bootstrapVersion' -NotePropertyValue $scriptVersion -Force
+            $body = [System.Text.Encoding]::UTF8.GetBytes(($manifest | ConvertTo-Json -Compress))
+            $manifestHeaders = @{
+                'x-ms-blob-type'          = 'BlockBlob'
+                'Content-Type'            = 'application/json'
+                'x-ms-blob-cache-control' = 'no-cache'
+                'If-Match'                = $etag
+            }
+            Invoke-RestMethod -Uri "$ContainerUrl/version.json?$writeSas" -Method Put -Headers $manifestHeaders -Body $body | Out-Null
+            Write-Host "version.json bootstrapVersion -> $scriptVersion (agent fields untouched)"
+
+            if ($legacySas) {
+                try {
+                    $legacyHeaders = @{ 'x-ms-blob-type' = 'BlockBlob'; 'Content-Type' = 'application/json'; 'x-ms-blob-cache-control' = 'no-cache' }
+                    Invoke-RestMethod -Uri "$LegacyContainerUrl/version.json?$legacySas" -Method Put -Headers $legacyHeaders -Body $body | Out-Null
+                } catch {
+                    Write-Host "::warning::legacy mirror failed for version.json -- $($_.Exception.Message)"
+                }
+            }
+        }
+    } catch {
+        if ((Get-HttpStatus $_) -eq 412) {
+            throw 'version.json changed while publishing (concurrent agent release). Re-run this workflow.'
+        }
+        throw
+    }
+}
+
+$tableSas = if ($TableSasToken) { $TableSasToken.TrimStart('?') } else { '' }
+if ($DryRun) {
+    Write-Host "  [dry-run] would set AdminConfiguration.LatestBootstrapV2ScriptVersion = $scriptVersion"
+} elseif ([string]::IsNullOrEmpty($tableSas) -or $tableSas -eq 'XXX') {
+    Write-Host 'SKIPPED: AdminConfiguration update -- set AZURE_TABLE_ADMIN_SAS_TOKEN to enable the portal version oracle'
+} else {
+    $tableHeaders = @{
+        'Content-Type' = 'application/json'
+        'Accept'       = 'application/json;odata=nometadata'
+        'If-Match'     = '*'
+    }
+    $tableBody = @{ LatestBootstrapV2ScriptVersion = $scriptVersion } | ConvertTo-Json
+    Invoke-RestMethod -Uri "$TableUrl`?$tableSas" -Method Merge -Headers $tableHeaders -Body $tableBody | Out-Null
+    Write-Host "AdminConfiguration.LatestBootstrapV2ScriptVersion = $scriptVersion"
+}
+
+# ------------------------------------------------------------------ 6. verify via alias
+if (-not $DryRun) {
+    $pending = [System.Collections.ArrayList]::new()
+    $publishSet | ForEach-Object { [void]$pending.Add($_) }
+
+    for ($attempt = 1; $attempt -le 6 -and $pending.Count -gt 0; $attempt++) {
+        if ($attempt -gt 1) { Start-Sleep -Seconds 20 }
+        foreach ($item in @($pending)) {
+            $servedBytes = Get-PublishedBytes "$AliasUrl/$($item.BlobName)"
+            if ($null -ne $servedBytes -and (Get-Sha256 $servedBytes) -eq $item.Sha256) {
+                Write-Host "  verified $($item.BlobName) via $AliasUrl"
+                $pending.Remove($item)
+            }
+        }
+        if ($pending.Count -gt 0) {
+            Write-Host "  attempt $attempt : $($pending.Count) blob(s) not current on the alias yet"
+        }
+    }
+
+    if ($pending.Count -gt 0) {
+        $names = ($pending | ForEach-Object { $_.BlobName }) -join ', '
+        throw ("Alias still serves stale content for: $names. The blobs were written, so this is a Front Door " +
+               'cache issue -- purge with: az afd endpoint purge --resource-group rg-autopilotmonitor-prd-gwc ' +
+               "--profile-name autopilotmonitor-fd --endpoint-name apm-download --content-paths '/agent/*'")
+    }
+}
+
+if ($env:GITHUB_STEP_SUMMARY) {
+    $mode = if ($DryRun) { 'DRY RUN -- nothing uploaded' } else { 'published + verified via the download alias' }
+    $summary = @(
+        "### Bootstrap scripts: $mode",
+        '',
+        "Bootstrap script version: **$scriptVersion**",
+        ''
+    ) + ($publishSet | ForEach-Object { "- $($_.BlobName) -- sha256 $($_.Sha256)" })
+    ($summary -join [Environment]::NewLine) | Out-File -FilePath $env:GITHUB_STEP_SUMMARY -Append -Encoding utf8
+}
+
+Write-Host 'Done.'

.github/scripts/Request-BuildNumber.ps1

@@ -0,0 +1,102 @@
+<#
+.SYNOPSIS
+    Reserves a monotone build number from a counter blob (ETag compare-and-swap).
+
+.DESCRIPTION
+    Single source of build numbers for every component that ships from this repo
+    (agent, backend, MCP). Each component owns one counter blob holding a plain
+    integer; this script reads it, writes value+1 back under If-Match, and returns
+    the reserved number.
+
+    Reserve-BEFORE-build: two concurrent builds can never mint the same number.
+    A failed build burns a number, which is harmless -- uniqueness matters,
+    density does not.
+
+    The blob is public-read; only the write needs the container SAS.
+
+    Why a counter and not the published version manifest: manifests are written
+    on publish, not on build (the agent writes version.json only for stable
+    releases), so two dev builds in a row would derive the same number and
+    overwrite each other's versioned artifact.
+
+.PARAMETER CounterUrl
+    Full URL of the counter blob, without SAS.
+
+.PARAMETER SasToken
+    Container SAS with create+write permission. A leading '?' is tolerated.
+
+.PARAMETER Override
+    Explicit build number instead of counter+1. If it is not greater than the
+    current counter the blob is left untouched (re-build of a number that was
+    already reserved). 0 = no override.
+
+.PARAMETER MaxAttempts
+    CAS retries before giving up.
+
+.OUTPUTS
+    [int] the reserved build number. Progress goes to the host, not the pipeline.
+
+.EXAMPLE
+    $n = ./Request-BuildNumber.ps1 -CounterUrl $url -SasToken $sas
+#>
+[CmdletBinding()]
+param(
+    [Parameter(Mandatory = $true)][string]$CounterUrl,
+    [Parameter(Mandatory = $true)][string]$SasToken,
+    [int]$Override = 0,
+    [int]$MaxAttempts = 5
+)
+
+$ErrorActionPreference = 'Stop'
+
+# Tolerate both secret formats ("sp=cw&..." and "?sp=cw&...").
+$writeUrl = $CounterUrl + '?' + $SasToken.TrimStart('?')
+
+function Get-HttpStatus {
+    param($ErrorRecord)
+    if ($ErrorRecord.Exception.PSObject.Properties['Response'] -and $ErrorRecord.Exception.Response) {
+        return [int]$ErrorRecord.Exception.Response.StatusCode
+    }
+    return 0
+}
+
+function Read-Counter {
+    try {
+        $resp = Invoke-WebRequest -Uri $CounterUrl -Method Get -UseBasicParsing
+    } catch {
+        if ((Get-HttpStatus $_) -eq 404) {
+            throw "Counter blob not found at $CounterUrl. Seed it once with the last used build number: PUT the plain integer with 'x-ms-blob-type: BlockBlob' and 'If-None-Match: *'. See internal/docs/versioning.md."
+        }
+        throw
+    }
+    $raw = if ($resp.Content -is [byte[]]) { [System.Text.Encoding]::UTF8.GetString($resp.Content) } else { [string]$resp.Content }
+    # If-Match requires the quoted ETag form; PowerShell strips the quotes on read.
+    $etag = '"' + ([string]($resp.Headers['ETag'] | Select-Object -First 1)).Trim('"') + '"'
+    return [pscustomobject]@{ Value = [int]$raw.Trim(); ETag = $etag }
+}
+
+for ($attempt = 1; $attempt -le $MaxAttempts; $attempt++) {
+    $counter = Read-Counter
+
+    if ($Override -gt 0 -and $Override -le $counter.Value) {
+        Write-Host "  Build number $Override <= counter $($counter.Value) -- already reserved, counter blob unchanged"
+        return $Override
+    }
+    $target = if ($Override -gt 0) { $Override } else { $counter.Value + 1 }
+
+    try {
+        $headers = @{ 'x-ms-blob-type' = 'BlockBlob'; 'If-Match' = $counter.ETag }
+        Invoke-RestMethod -Uri $writeUrl -Method Put -Headers $headers -Body "$target" -ContentType 'text/plain' | Out-Null
+        Write-Host "  Reserved build number $target (CAS write ok, attempt $attempt)"
+        return $target
+    } catch {
+        if ((Get-HttpStatus $_) -eq 412) {
+            Write-Host "  CAS conflict on attempt $attempt (another build reserved concurrently) -- retrying"
+            Start-Sleep -Seconds ($attempt * 2)
+        } else {
+            throw
+        }
+    }
+}
+
+throw "Could not reserve a build number after $MaxAttempts CAS attempts"

.github/workflows/bootstrap-script-gates.yml

@@ -0,0 +1,63 @@
+name: Bootstrap script gates
+
+# Quality gate for the customer-facing PowerShell scripts, factored out so it exists
+# once and both callers run the identical checks:
+#   * pester.yml           -- pull requests (reports, does not block the merge button)
+#   * publish-scripts.yml  -- pushes to main, where it BLOCKS the upload to the
+#                             download alias. Devices execute these scripts as SYSTEM
+#                             during enrollment, so a red suite must never ship.
+
+on:
+  workflow_call:
+
+permissions:
+  contents: read
+
+jobs:
+  gates:
+    name: Bootstrap guard tests (PS 5.1)
+    runs-on: windows-latest
+    steps:
+      - uses: actions/checkout@v7
+
+      - name: Install Pester 5+
+        shell: powershell
+        run: |
+          Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force -Scope CurrentUser | Out-Null
+          Install-Module Pester -Scope CurrentUser -Force -SkipPublisherCheck -MinimumVersion 5.5.0
+
+      # Windows PowerShell 5.1 on purpose: that is the runtime IME uses to execute
+      # platform scripts, so guard/relax logic is verified without resetting a device.
+      - name: Run Pester
+        shell: powershell
+        run: |
+          Import-Module Pester -MinimumVersion 5.5.0
+          $c = New-PesterConfiguration
+          $c.Run.Path = 'scripts/Bootstrap'
+          $c.Run.Exit = $true
+          $c.Output.Verbosity = 'Detailed'
+          Invoke-Pester -Configuration $c
+
+      - name: Guard scripts stay pure ASCII
+        shell: powershell
+        run: |
+          $failed = $false
+          Get-ChildItem 'scripts/Bootstrap' -Filter '*.ps1' | ForEach-Object {
+            $bytes = [System.IO.File]::ReadAllBytes($_.FullName)
+            for ($i = 0; $i -lt $bytes.Length; $i++) {
+              if ($bytes[$i] -gt 127) {
+                Write-Host "::error file=scripts/Bootstrap/$($_.Name)::Non-ASCII byte 0x$('{0:X2}' -f $bytes[$i]) at offset $i. PS 5.1 (IME) reads BOM-less files as ANSI and corrupts multi-byte chars."
+                $failed = $true
+                break
+              }
+            }
+          }
+          if ($failed) { exit 1 }
+          Write-Host 'All bootstrap scripts are pure ASCII.'
+
+      # The publish chain renders the -Dev variant by literal substitution and refuses to
+      # ship when an anchor moved. Running it dry here surfaces that (and any drift against
+      # the alias) on the PR instead of on the push that would have published.
+      - name: Publish dry run (dev-render anchors + version-bump guard + drift)
+        shell: pwsh
+        run: ./.github/scripts/Publish-BootstrapScripts.ps1 -DryRun

.github/workflows/build-agent.yml

@@ -33,6 +33,13 @@ permissions:
   id-token: write      # keyless Sigstore signing (artifact attestation)
   attestations: write  # store the provenance attestation
 
+# Shared with publish-scripts.yml: both write version.json (this workflow the agent fields,
+# the script publisher bootstrapVersion under If-Match). Serialising them keeps a script push
+# from colliding with a release. Never cancel -- a half-published set is worse than a queue.
+concurrency:
+  group: agent-blob-publish
+  cancel-in-progress: false
+
 env:
   LINE_MAJOR: 2
   AGENT_PROJECT: src/Agent/AutopilotMonitor.Agent.V2/AutopilotMonitor.Agent.V2.csproj
@@ -46,8 +53,6 @@ env:
   VERSIONED_ZIP: AutopilotMonitor-Agent-v2.zip
   STABLE_ZIP: AutopilotMonitor-Agent.zip
   STABLE_MANIFEST: version.json
-  STABLE_BOOTSTRAP: Install-AutopilotMonitor.ps1
-  STABLE_BOOTSTRAP_DEV: Install-AutopilotMonitor-Dev.ps1
 
 jobs:
   build:
@@ -56,78 +61,38 @@ jobs:
 
     steps:
       - name: Checkout repository
-        uses: actions/checkout@v5
+        uses: actions/checkout@v7
 
       # SDK 10 = single build toolchain (parity with local build.ps1 / global.json).
       - name: Setup .NET
-        uses: actions/setup-dotnet@v5
+        uses: actions/setup-dotnet@v6
         with:
           dotnet-version: '10.0.x'
 
-      # Build numbers come from the shared counter blob (single source of truth for CI
-      # AND local build.ps1). Reserve-before-build with ETag-CAS: concurrent builds can
-      # never mint the same number; a failed build burns a number, which is harmless.
-      # The blob is public-read (like the rest of the container); writes need the SAS.
+      # Build numbers come from the shared counter blob -- one counter and one
+      # implementation for CI and the local build (.github/scripts/Request-BuildNumber.ps1).
+      # Reserve-before-build with ETag-CAS: concurrent builds can never mint the same
+      # number; a failed build burns a number, which is harmless.
       - name: Reserve build number (counter blob CAS)
         id: version
         shell: pwsh
+        # Input and secret reach the script only as environment variables, never as script
+        # text: ${{ }} is substituted before pwsh parses the block, so a crafted
+        # build_number could otherwise break out of the quotes and run arbitrary code.
+        env:
+          BUILD_NUMBER_OVERRIDE: ${{ inputs.build_number }}
+          AGENT_SAS_TOKEN: ${{ secrets.AZURE_BLOB_AGENT_SAS_TOKEN }}
         run: |
-          $counterBlob = "buildcounter-v$env:LINE_MAJOR.txt"
-          $counterUrl = "https://autopilotmonitoreu.blob.core.windows.net/agent/$counterBlob"
-          # Tolerate both secret formats ("sp=cw&..." and "?sp=cw&...") -- the URL below adds the '?'.
-          $sasToken = "${{ secrets.AZURE_BLOB_AGENT_SAS_TOKEN }}".TrimStart('?')
-          $override = "${{ inputs.build_number }}"
-
-          function Get-Counter {
-            try {
-              $resp = Invoke-WebRequest -Uri $counterUrl -Method Get
-              $raw = if ($resp.Content -is [byte[]]) { [System.Text.Encoding]::UTF8.GetString($resp.Content) } else { [string]$resp.Content }
-              # If-Match requires the quoted ETag form; pwsh strips the quotes on read.
-              $etag = '"' + ([string]($resp.Headers['ETag'] | Select-Object -First 1)).Trim('"') + '"'
-              return @{ Value = [int]$raw.Trim(); ETag = $etag }
-            } catch {
-              $status = if ($_.Exception.Response) { [int]$_.Exception.Response.StatusCode } else { 0 }
-              if ($status -eq 404) {
-                Write-Error "Counter blob '$counterBlob' not found. Seed it once with the last used build number (see docs/agent/build-counter-blob.md) -- do NOT seed from the repo's buildcounter.txt, it is a stale offline fallback."
-              }
-              throw
+          $override = 0
+          if ($env:BUILD_NUMBER_OVERRIDE -ne '') {
+            if ($env:BUILD_NUMBER_OVERRIDE -notmatch '^\d+$') {
+              throw "build_number must be a positive integer, got '$($env:BUILD_NUMBER_OVERRIDE)'"
             }
+            $override = [int]$env:BUILD_NUMBER_OVERRIDE
           }
 
-          $buildNumber = $null
-          for ($attempt = 1; $attempt -le 5; $attempt++) {
-            $counter = Get-Counter
-            if ($override -ne '') {
-              $target = [int]$override
-              if ($target -le $counter.Value) {
-                # Re-build of an already-reserved number: counter stays monotonic, no write.
-                Write-Host "Manual build number $target <= counter $($counter.Value) -- counter blob unchanged"
-                $buildNumber = $target
-                break
-              }
-              Write-Host "Manual build number $target > counter $($counter.Value) -- advancing counter"
-            } else {
-              $target = $counter.Value + 1
-            }
-            try {
-              $headers = @{ 'x-ms-blob-type' = 'BlockBlob'; 'If-Match' = $counter.ETag }
-              Invoke-RestMethod -Uri "$counterUrl`?$sasToken" -Method Put -Headers $headers -Body "$target" -ContentType 'text/plain' | Out-Null
-              $buildNumber = $target
-              Write-Host "Reserved build number ${target} (CAS write ok, attempt $attempt)"
-              break
-            } catch {
-              $status = if ($_.Exception.Response) { [int]$_.Exception.Response.StatusCode } else { 0 }
-              if ($status -eq 412) {
-                Write-Host "CAS conflict on attempt $attempt (another build reserved concurrently) -- retrying"
-                Start-Sleep -Seconds ($attempt * 2)
-              } else {
-                throw
-              }
-            }
-          }
-          if ($null -eq $buildNumber) {
-            Write-Error "Could not reserve a build number after 5 CAS attempts"
-          }
+          $counterUrl = "https://autopilotmonitoreu.blob.core.windows.net/agent/buildcounter-v$($env:LINE_MAJOR).txt"
+          $buildNumber = & ./.github/scripts/Request-BuildNumber.ps1 -CounterUrl $counterUrl -SasToken $env:AGENT_SAS_TOKEN -Override $override
 
           $csproj = Get-Content $env:CSPROJ_PATH -Raw
           if ($csproj -match '<VersionPrefix>(\d+\.\d+)</VersionPrefix>') {
@@ -228,37 +193,27 @@ jobs:
             Write-Warning "Could not parse bootstrap `$ScriptVersion from $env:BOOTSTRAP_SOURCE"
           }
 
-          # Enrich the per-line manifest emitted by MSBuild (version-v2.json, read above)
+          # Enrich the per-line manifest emitted by MSBuild (version-v2.json, read above).
+          # commit/buildUtc are the same two fields the backend and MCP manifests carry —
+          # additive, and the bootstrap reads this file by field name, so older installers
+          # ignore them. sha256/bootstrapVersion stay: those are the customer contract.
+          # bootstrapVersion is seeded here so the published manifest is never briefly
+          # missing it; Publish-BootstrapScripts.ps1 owns and re-asserts the field afterwards.
           $manifest | Add-Member -NotePropertyName "sha256" -NotePropertyValue $sha256Hash -Force
+          $manifest | Add-Member -NotePropertyName "commit" -NotePropertyValue '${{ github.sha }}'.Substring(0, 7) -Force
+          $manifest | Add-Member -NotePropertyName "buildUtc" -NotePropertyValue ([DateTime]::UtcNow.ToString('o')) -Force
           if ($bootstrapVersion) {
             $manifest | Add-Member -NotePropertyName "bootstrapVersion" -NotePropertyValue $bootstrapVersion -Force
           }
           $manifest | ConvertTo-Json -Compress | Set-Content $env:MANIFEST_NAME -Encoding UTF8
           Write-Host "$env:MANIFEST_NAME content: $(Get-Content $env:MANIFEST_NAME)"
 
-          # Bootstrap = single generic source. Stable variant = source 1:1.
-          # Dev variant = literal-string substitution of the two URL/manifest defaults.
-          # Both are uploaded only on -PublishAsStable runs (versioned namespace doesn't carry bootstrap).
-          if ('${{ inputs.publish_as_stable }}' -eq 'true') {
-            $stableUrl = '$AgentDownloadUrl = "https://autopilotmonitor.blob.core.windows.net/agent/AutopilotMonitor-Agent.zip"'
-            $devUrl    = '$AgentDownloadUrl = "https://autopilotmonitor.blob.core.windows.net/agent/AutopilotMonitor-Agent-dev.zip"'
-            $stableMan = '$VersionJsonName = "version.json"'
-            $devMan    = '$VersionJsonName = "version-dev.json"'
-
-            Copy-Item $env:BOOTSTRAP_SOURCE $env:STABLE_BOOTSTRAP -Force
-            $content = Get-Content $env:BOOTSTRAP_SOURCE -Raw
-            if ($content.IndexOf($stableUrl) -lt 0 -or $content.IndexOf($stableMan) -lt 0) {
-              Write-Error "Bootstrap dev-render: anchor literal missing in $env:BOOTSTRAP_SOURCE"
-              exit 1
-            }
-            $devContent = $content.Replace($stableUrl, $devUrl).Replace($stableMan, $devMan)
-            [System.IO.File]::WriteAllText("$env:STABLE_BOOTSTRAP_DEV", $devContent, (New-Object System.Text.UTF8Encoding $false))
-          }
+          # The customer-facing scripts (stable + dev render, test script, grant script) are
+          # published by .github/scripts/Publish-BootstrapScripts.ps1 -- see the upload step.
 
           "versioned_zip_release=$versionedZip" >> $env:GITHUB_OUTPUT
           "sha256=$sha256Hash" >> $env:GITHUB_OUTPUT
           "exe_sha256=$exeSha256Hash" >> $env:GITHUB_OUTPUT
-          "bootstrap_version=$bootstrapVersion" >> $env:GITHUB_OUTPUT
 
       - name: Upload to Azure Blob Storage
         if: inputs.upload_blob
@@ -277,7 +232,12 @@ jobs:
             param([string]$Local, [string]$BlobName, [string]$ContentType)
             $url = "$containerUrl/$BlobName`?$sasToken"
             $bytes = [System.IO.File]::ReadAllBytes($Local)
-            $headers = @{ "x-ms-blob-type" = "BlockBlob"; "Content-Type" = $ContentType }
+            # no-cache on EVERY blob: they all rotate in place (even the per-line ZIP is
+            # overwritten each build), and the download alias fronts them with Front Door.
+            # Route caching is disabled there, but a stale manifest paired with a fresh ZIP
+            # (independent cache entries) would fail the bootstrap SHA check -- this header
+            # keeps that class of bug impossible even if caching is ever re-enabled.
+            $headers = @{ "x-ms-blob-type" = "BlockBlob"; "Content-Type" = $ContentType; "x-ms-blob-cache-control" = "no-cache" }
             if ($ContentType -eq "application/zip") {
               $md5 = [System.Security.Cryptography.MD5]::Create()
               $headers["Content-MD5"] = [Convert]::ToBase64String($md5.ComputeHash($bytes))
@@ -305,16 +265,21 @@ jobs:
             Write-Host "PUBLISH AS STABLE -- writing V2 into stable namespace (customer-facing)" -ForegroundColor Magenta
             Send-Blob -Local $env:VERSIONED_ZIP -BlobName $env:STABLE_ZIP -ContentType "application/zip"
             Send-Blob -Local $env:MANIFEST_NAME -BlobName $env:STABLE_MANIFEST -ContentType "application/json"
-            Send-Blob -Local $env:STABLE_BOOTSTRAP -BlobName $env:STABLE_BOOTSTRAP -ContentType "text/plain; charset=utf-8"
-            Send-Blob -Local $env:STABLE_BOOTSTRAP_DEV -BlobName $env:STABLE_BOOTSTRAP_DEV -ContentType "text/plain; charset=utf-8"
 
-            if (Test-Path "scripts/Bootstrap/Test-ShouldBootstrapAgent.ps1") {
-              Send-Blob -Local "scripts/Bootstrap/Test-ShouldBootstrapAgent.ps1" -BlobName "Test-ShouldBootstrapAgent.ps1" -ContentType "text/plain; charset=utf-8"
-            }
+            # Customer-facing scripts: same publisher publish-scripts.yml runs on every push
+            # to main, so a release lands a set that is consistent with what is already live
+            # (dev render, version-bump guard, bootstrapVersion oracles, alias verification).
+            # Runs AFTER version.json so its bootstrapVersion read sees this build's manifest.
+            ./.github/scripts/Publish-BootstrapScripts.ps1 `
+              -SasToken '${{ secrets.AZURE_BLOB_AGENT_SAS_TOKEN }}' `
+              -LegacySasToken '${{ secrets.AZURE_BLOB_AGENT_LEGACY_SAS_TOKEN }}' `
+              -TableSasToken '${{ secrets.AZURE_TABLE_ADMIN_SAS_TOKEN }}'
           }
 
           # Update AdminConfiguration LatestAgentV2* -- ONLY on stable cutover. The hash-oracle
           # must never point at a build that is not actually in the stable namespace.
+          # LatestBootstrapV2ScriptVersion is NOT set here: it belongs to the script publisher
+          # above, which also owns it on script-only pushes. One writer per field.
           $tableSasToken = "${{ secrets.AZURE_TABLE_ADMIN_SAS_TOKEN }}".TrimStart('?')
           if ('${{ inputs.publish_as_stable }}' -ne 'true') {
             Write-Host "SKIPPED: AdminConfiguration update (versioned-only run -- stable namespace unchanged)"
@@ -324,22 +289,18 @@ jobs:
             $sha256 = "${{ steps.artifact.outputs.sha256 }}"
             $exeSha256 = "${{ steps.artifact.outputs.exe_sha256 }}"
             $agentVersion = "${{ steps.version.outputs.version }}"
-            $bootstrapVersion = "${{ steps.artifact.outputs.bootstrap_version }}"
             $tableUrl = "https://autopilotmonitoreu.table.core.windows.net/AdminConfiguration(PartitionKey='GlobalConfig',RowKey='config')?$tableSasToken"
             $tableBody = @{
               LatestAgentV2Version    = $agentVersion
               LatestAgentV2Sha256     = $sha256
               LatestAgentV2ExeSha256  = $exeSha256
             }
-            if ($bootstrapVersion) {
-              $tableBody["LatestBootstrapV2ScriptVersion"] = $bootstrapVersion
-            }
             Invoke-RestMethod -Uri $tableUrl -Method Merge -Headers @{
               "Content-Type" = "application/json"
               "Accept"       = "application/json;odata=nometadata"
               "If-Match"     = "*"
             } -Body ($tableBody | ConvertTo-Json)
-            Write-Host "AdminConfiguration updated: V2 version=$agentVersion, sha256=$sha256, exeSha256=$exeSha256, bootstrapVersion=$bootstrapVersion"
+            Write-Host "AdminConfiguration updated: V2 version=$agentVersion, sha256=$sha256, exeSha256=$exeSha256"
           }
 
       # Sigstore keyless provenance: binds the ZIP digest to this workflow run (repo, ref,
@@ -352,24 +313,30 @@ jobs:
           subject-path: ${{ steps.artifact.outputs.versioned_zip_release }}
 
       - name: Upload build artifact
-        uses: actions/upload-artifact@v6
+        uses: actions/upload-artifact@v7
         with:
           name: AutopilotMonitor-Agent-v${{ steps.version.outputs.version }}
           path: ${{ steps.artifact.outputs.versioned_zip_release }}
 
       - name: Upload version metadata
-        uses: actions/upload-artifact@v6
+        uses: actions/upload-artifact@v7
         with:
           name: version-metadata
           path: ${{ env.MANIFEST_NAME }}
 
+      # First-party `gh` instead of a third-party action: this job holds contents:write,
+      # id-token:write and attestations:write, so no code we do not control runs here.
+      # --generate-notes appends the auto-generated notes below the body.
       - name: Create GitHub Release
         if: inputs.create_release
-        uses: softprops/action-gh-release@v3
-        with:
-          tag_name: ${{ steps.version.outputs.tag }}
-          name: Autopilot Monitor Agent ${{ steps.version.outputs.version }}
-          body: |
+        shell: pwsh
+        env:
+          GH_TOKEN: ${{ github.token }}
+          RELEASE_TAG: ${{ steps.version.outputs.tag }}
+          RELEASE_NAME: Autopilot Monitor Agent ${{ steps.version.outputs.version }}
+          RELEASE_PRERELEASE: ${{ inputs.prerelease }}
+          RELEASE_ZIP: ${{ steps.artifact.outputs.versioned_zip_release }}
+          RELEASE_BODY: |
             ## Autopilot Monitor Agent ${{ steps.version.outputs.version }}
 
             ### Installation
@@ -394,9 +361,22 @@ jobs:
             ```
             gh attestation verify AutopilotMonitor-Agent-v${{ steps.version.outputs.version }}.zip --repo okieselbach/AutopilotMonitor
             ```
-          draft: false
-          prerelease: ${{ inputs.prerelease }}
-          files: |
-            ${{ steps.artifact.outputs.versioned_zip_release }}
-            ${{ env.MANIFEST_NAME }}
-          generate_release_notes: true
+        run: |
+          $ErrorActionPreference = 'Stop'
+          $notesFile = Join-Path $env:RUNNER_TEMP 'release-notes.md'
+          Set-Content -Path $notesFile -Value $env:RELEASE_BODY -Encoding utf8 -NoNewline
+
+          $ghArgs = @(
+            'release', 'create', $env:RELEASE_TAG,
+            $env:RELEASE_ZIP, $env:MANIFEST_NAME,
+            '--repo', $env:GITHUB_REPOSITORY,
+            '--target', $env:GITHUB_SHA,
+            '--title', $env:RELEASE_NAME,
+            '--notes-file', $notesFile,
+            '--generate-notes'
+          )
+          if ($env:RELEASE_PRERELEASE -eq 'true') { $ghArgs += '--prerelease' }
+
+          & gh @ghArgs
+          if ($LASTEXITCODE -ne 0) { throw "gh release create failed with exit code $LASTEXITCODE" }
+          Write-Host "Release $env:RELEASE_TAG created"

.github/workflows/build-msi.yml

@@ -0,0 +1,139 @@
+name: Build & Publish Bootstrap MSI
+
+# Thin MDM LOB delivery vehicle for WDP (Autopilot v2) — see
+# src/Agent/AutopilotMonitor.BootstrapMsi/Package.wxs. The MSI carries no bootstrap
+# logic (only the runner script that downloads the CURRENT server-hosted
+# Install-AutopilotMonitor.ps1), so it is rebuilt rarely: only when the runner script
+# or the WiX package changes. Version lives in Package.wxs — bump it there before
+# dispatching so Intune LOB update detection sees a new ProductVersion.
+
+on:
+  workflow_dispatch:
+    inputs:
+      upload_blob:
+        description: 'Upload to blob (customer-facing via download.autopilotmonitor.com/agent/)'
+        required: true
+        type: boolean
+        default: true
+
+permissions:
+  contents: read
+  id-token: write      # keyless Sigstore signing (artifact attestation)
+  attestations: write  # store the provenance attestation
+
+env:
+  MSI_PROJECT_DIR: src/Agent/AutopilotMonitor.BootstrapMsi
+  RUNNER_SCRIPT: src/Agent/AutopilotMonitor.BootstrapMsi/Invoke-BootstrapDownload.ps1
+  STABLE_MSI: AutopilotMonitor-Bootstrap.msi
+
+jobs:
+  build:
+    runs-on: windows-latest
+    name: Build Bootstrap MSI
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v7
+
+      # The runner executes as SYSTEM on every enrolling device — a parse error or
+      # non-ASCII mojibake (PS 5.1 codepage roulette) must fail the build, not the fleet.
+      - name: Validate runner script (parse + ASCII-only)
+        shell: pwsh
+        run: |
+          $errs = $null
+          [System.Management.Automation.Language.Parser]::ParseFile((Resolve-Path $env:RUNNER_SCRIPT), [ref]$null, [ref]$errs) | Out-Null
+          if ($errs) { $errs | ForEach-Object { Write-Error $_.ToString() }; exit 1 }
+          if ((Get-Content $env:RUNNER_SCRIPT -Raw) -match '[^\x00-\x7F]') {
+            Write-Error "Runner script contains non-ASCII characters"
+            exit 1
+          }
+          Write-Host "Runner script parse + ASCII check passed"
+
+      - name: Read MSI version from Package.wxs
+        id: version
+        shell: pwsh
+        run: |
+          $wxs = Get-Content "$env:MSI_PROJECT_DIR/Package.wxs" -Raw
+          if ($wxs -notmatch 'Version="(\d+\.\d+\.\d+)"') {
+            Write-Error "Could not parse Version from Package.wxs"
+            exit 1
+          }
+          $version = $Matches[1]
+          Write-Host "MSI version (from Package.wxs): $version"
+          "version=$version" >> $env:GITHUB_OUTPUT
+
+      - name: Install WiX toolset
+        run: dotnet tool install --global wix --version "5.*"
+
+      - name: Build MSI
+        shell: pwsh
+        run: |
+          # wix resolves File/@Source relative to the working directory, not the wxs —
+          # build from inside the project dir (same as the local build documented in the wxs).
+          $out = Join-Path (Get-Location) $env:STABLE_MSI
+          Push-Location $env:MSI_PROJECT_DIR
+          wix build Package.wxs -arch x64 -o $out
+          Pop-Location
+          if (-not (Test-Path $env:STABLE_MSI)) { Write-Error "wix build produced no MSI"; exit 1 }
+          $sha256 = (Get-FileHash $env:STABLE_MSI -Algorithm SHA256).Hash.ToLowerInvariant()
+          Write-Host "Built $env:STABLE_MSI ($([math]::Round((Get-Item $env:STABLE_MSI).Length / 1KB)) KB)"
+          Write-Host "SHA-256: $sha256"
+
+      - name: Upload to Azure Blob Storage
+        if: inputs.upload_blob
+        shell: pwsh
+        run: |
+          $containerUrl = "https://autopilotmonitoreu.blob.core.windows.net/agent"
+          $sasToken = "${{ secrets.AZURE_BLOB_AGENT_SAS_TOKEN }}".TrimStart('?')
+          $version = "${{ steps.version.outputs.version }}"
+
+          # Same Send-Blob contract as build-agent.yml: no-cache on every blob because the
+          # stable name rotates in place behind the download alias. No legacy mirror — the
+          # MSI channel never existed on the legacy account.
+          function Send-Blob {
+            param([string]$Local, [string]$BlobName)
+            $bytes = [System.IO.File]::ReadAllBytes($Local)
+            $headers = @{
+              "x-ms-blob-type" = "BlockBlob"
+              "Content-Type" = "application/octet-stream"
+              "x-ms-blob-cache-control" = "no-cache"
+            }
+            $md5 = [System.Security.Cryptography.MD5]::Create()
+            $headers["Content-MD5"] = [Convert]::ToBase64String($md5.ComputeHash($bytes))
+            $md5.Dispose()
+            Write-Host "Uploading $BlobName ($([math]::Round($bytes.Length / 1KB)) KB)..."
+            Invoke-RestMethod -Uri "$containerUrl/$BlobName`?$sasToken" -Method Put -Headers $headers -Body $bytes
+            Write-Host "  uploaded $BlobName"
+          }
+
+          # Versioned copy for provenance/rollback + stable customer-facing name.
+          Send-Blob -Local $env:STABLE_MSI -BlobName "AutopilotMonitor-Bootstrap-v$version.msi"
+          Send-Blob -Local $env:STABLE_MSI -BlobName $env:STABLE_MSI
+
+      # E2E: the Front Door route /agent/* must serve the fresh bytes on the public alias.
+      - name: Verify download alias serves the MSI
+        if: inputs.upload_blob
+        shell: pwsh
+        run: |
+          $localSize = (Get-Item $env:STABLE_MSI).Length
+          $resp = Invoke-WebRequest -Uri "https://download.autopilotmonitor.com/agent/$env:STABLE_MSI" -Method Head -UseBasicParsing
+          if ($resp.StatusCode -ne 200) { Write-Error "Alias HEAD returned $($resp.StatusCode)"; exit 1 }
+          $remoteSize = [long]$resp.Headers['Content-Length'][0]
+          if ($remoteSize -ne $localSize) {
+            Write-Error "Size mismatch: alias serves $remoteSize bytes, local MSI is $localSize bytes"
+            exit 1
+          }
+          Write-Host "Alias verified: https://download.autopilotmonitor.com/agent/$env:STABLE_MSI ($remoteSize bytes)"
+
+      # Sigstore keyless provenance, same as the agent ZIP. Verify:
+      # gh attestation verify AutopilotMonitor-Bootstrap.msi --repo okieselbach/AutopilotMonitor
+      - name: Attest build provenance (MSI)
+        uses: actions/attest-build-provenance@v4
+        with:
+          subject-path: ${{ env.STABLE_MSI }}
+
+      - name: Upload build artifact
+        uses: actions/upload-artifact@v7
+        with:
+          name: AutopilotMonitor-Bootstrap-v${{ steps.version.outputs.version }}
+          path: ${{ env.STABLE_MSI }}

.github/workflows/ci.yml

@@ -0,0 +1,203 @@
+name: CI
+
+# Tests, typechecks and drift-checks every push to main and every pull request:
+# the .NET suites, the web and MCP suites, and a guard that the generated rule
+# files still match rules/guardrails.json.
+#
+# The deploy workflows build but never test, so this is the only place the suites
+# actually run. It does not gate anything — main is deliberately unprotected, so a
+# red run reports rather than blocks. Read the result and follow up.
+#
+# Path filters: commits that only bump a private submodule gitlink (internal/, infra/,
+# .claude/commands) or touch prose cannot change anything the suites cover, so they are
+# skipped instead of burning ~15 runner-minutes each. A gitlink bump reports the bare
+# path ('internal', no trailing slash), which 'internal/**' does NOT match — both forms
+# are listed. GitHub skips only when EVERY changed path matches; a commit that touches
+# docs AND code still runs.
+on:
+  push:
+    branches: [main]
+    paths-ignore:
+      - 'internal'
+      - 'internal/**'
+      - 'infra'
+      - 'infra/**'
+      - '.claude/**'
+      - '.gitmodules'
+      - '**/*.md'
+      - 'LICENSE'
+      - '.github/ISSUE_TEMPLATE/**'
+      - '.github/FUNDING.yml'
+      - '.github/dependabot.yml'
+      - '.github/assets/**'
+  pull_request:
+    branches: [main]
+    paths-ignore:
+      - 'internal'
+      - 'internal/**'
+      - 'infra'
+      - 'infra/**'
+      - '.claude/**'
+      - '.gitmodules'
+      - '**/*.md'
+      - 'LICENSE'
+      - '.github/ISSUE_TEMPLATE/**'
+      - '.github/FUNDING.yml'
+      - '.github/dependabot.yml'
+      - '.github/assets/**'
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+concurrency:
+  group: ci-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  dotnet:
+    name: .NET tests (backend + agent)
+    # windows-latest is required: the agent test projects target net48.
+    runs-on: windows-latest
+    steps:
+      - uses: actions/checkout@v7
+
+      - uses: actions/setup-dotnet@v6
+        with:
+          dotnet-version: '10.0.x'
+
+      - name: Restore
+        run: dotnet restore AutopilotMonitor.sln
+
+      - name: Build
+        run: dotnet build AutopilotMonitor.sln --configuration Release --no-restore
+
+      - name: Backend tests
+        run: dotnet test src/Backend/AutopilotMonitor.Functions.Tests --configuration Release --no-build --verbosity quiet --logger "console;verbosity=minimal"
+
+      - name: Agent V2 Core tests
+        run: dotnet test src/Agent/AutopilotMonitor.Agent.V2.Core.Tests --configuration Release --no-build --verbosity quiet --logger "console;verbosity=minimal"
+
+      - name: Decision Core tests
+        run: dotnet test src/Agent/AutopilotMonitor.DecisionCore.Tests --configuration Release --no-build --verbosity quiet --logger "console;verbosity=minimal"
+
+      - name: Summary Dialog tests
+        run: dotnet test src/Agent/AutopilotMonitor.SummaryDialog.Tests --configuration Release --no-build --verbosity quiet --logger "console;verbosity=minimal"
+
+  web:
+    name: Web (typecheck + tests)
+    runs-on: ubuntu-latest
+    defaults:
+      run:
+        working-directory: src/Web/autopilot-monitor-web
+    steps:
+      - uses: actions/checkout@v7
+
+      - uses: actions/setup-node@v7
+        with:
+          node-version: '22'
+          cache: npm
+          cache-dependency-path: src/Web/autopilot-monitor-web/package-lock.json
+
+      - run: npm ci
+
+      # next-env.d.ts + .next type stubs are gitignored (Next-managed since
+      # v16); typegen generates them so tsc sees the same types as a build.
+      - name: Generate Next.js types
+        run: npx next typegen
+
+      - name: Typecheck
+        run: npx tsc --noEmit
+
+      # Errors fail outright, and so does ANY warning: the codebase is
+      # warning-clean and must stay that way — fix new findings, never
+      # raise the cap.
+      - name: Lint
+        run: npm run lint -- --max-warnings 0
+
+      - name: Tests
+        run: npm test
+
+  mcp:
+    name: MCP server tests
+    runs-on: ubuntu-latest
+    defaults:
+      run:
+        working-directory: src/McpServer/autopilot-monitor-mcp
+    steps:
+      - uses: actions/checkout@v7
+
+      - uses: actions/setup-node@v7
+        with:
+          node-version: '22'
+          cache: npm
+          cache-dependency-path: src/McpServer/autopilot-monitor-mcp/package-lock.json
+
+      - run: npm ci
+
+      - name: Typecheck
+        run: npx tsc --noEmit
+
+      # The vector-search tests tokenize with the real all-MiniLM-L6-v2 model
+      # (~23 MB tokenizer + ONNX weights). transformers.js caches under
+      # node_modules by default, which npm ci recreates — so every CI run
+      # re-downloaded from huggingface.co and rate-limits (429) failed the job
+      # (run 31252869254). Persist the model across runs instead; HF_CACHE_DIR
+      # is honored by vector-search-provider.ts.
+      - name: Cache embedding model
+        uses: actions/cache@v6
+        with:
+          path: ${{ github.workspace }}/.hf-cache
+          key: hf-model-Xenova-all-MiniLM-L6-v2
+
+      - name: Tests
+        run: npm test
+        env:
+          HF_CACHE_DIR: ${{ github.workspace }}/.hf-cache
+
+  guardrails-in-sync:
+    name: Generated guardrails match rules/guardrails.json
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v7
+
+      - uses: actions/setup-node@v7
+        with:
+          node-version: '22'
+
+      - name: Regenerate
+        run: node rules/scripts/combine.js
+
+      - name: Fail if the generated files drifted
+        run: |
+          if ! git diff --quiet; then
+            echo "::error::Generated files are out of date. Run 'node rules/scripts/combine.js' and commit the result."
+            git diff --stat
+            exit 1
+          fi
+
+  shared-manifests-in-sync:
+    name: Generated wire types match shared-manifests.json
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v7
+
+      - uses: actions/setup-node@v7
+        with:
+          node-version: '22'
+
+      # JSON ↔ C# parity is the dotnet job's SharedManifestParityTests; this job pins
+      # JSON ↔ generated TS (shared-manifests.generated.ts, wire-types.generated.ts and the
+      # MCP's wire-types + wire-vocabularies copies - the vocabularies are what the MCP
+      # tool input schemas derive their z.enum() from).
+      - name: Regenerate
+        run: node scripts/generate-shared-manifest-types.js
+        working-directory: src/Web/autopilot-monitor-web
+
+      - name: Fail if the generated files drifted
+        run: |
+          if ! git diff --quiet -- src/Web/autopilot-monitor-web/utils/shared-manifests.generated.ts src/Web/autopilot-monitor-web/utils/wire-types.generated.ts src/McpServer/autopilot-monitor-mcp/src/generated/wire-types.generated.ts src/McpServer/autopilot-monitor-mcp/src/generated/wire-vocabularies.generated.ts; then
+            echo "::error::Generated wire types are out of date. Run 'npm run generate:manifests' in src/Web/autopilot-monitor-web and commit the result."
+            git diff --stat
+            exit 1
+          fi

.github/workflows/codeql.yml

@@ -0,0 +1,94 @@
+name: CodeQL
+
+# Documentation-only changes and private-submodule gitlink bumps (internal/, infra/,
+# .claude/commands) cannot affect what CodeQL analyzes (C# and TypeScript), so they
+# are filtered out rather than spending ~10 minutes to re-report an unchanged result.
+# A gitlink bump reports the bare path ('internal', no trailing slash), which
+# 'internal/**' does NOT match — both forms are listed. A commit that touches docs
+# AND code still runs: GitHub skips only when EVERY changed path matches the filter.
+# Same list as ci.yml; keep them in step.
+on:
+  push:
+    branches: [main]
+    paths-ignore:
+      - 'internal'
+      - 'internal/**'
+      - 'infra'
+      - 'infra/**'
+      - '.claude/**'
+      - '.gitmodules'
+      - '**/*.md'
+      - 'LICENSE'
+      - '.github/ISSUE_TEMPLATE/**'
+      - '.github/FUNDING.yml'
+      - '.github/dependabot.yml'
+      - '.github/assets/**'
+  pull_request:
+    branches: [main]
+    paths-ignore:
+      - 'internal'
+      - 'internal/**'
+      - 'infra'
+      - 'infra/**'
+      - '.claude/**'
+      - '.gitmodules'
+      - '**/*.md'
+      - 'LICENSE'
+      - '.github/ISSUE_TEMPLATE/**'
+      - '.github/FUNDING.yml'
+      - '.github/dependabot.yml'
+      - '.github/assets/**'
+  schedule:
+    # Weekly, so advisories published after a merge still surface. Deliberately
+    # unfiltered — it re-analyzes the whole tree regardless of what changed, which
+    # is also the backstop if the filters above ever skip too much.
+    - cron: '17 3 * * 1'
+
+permissions:
+  contents: read
+
+jobs:
+  analyze:
+    name: Analyze ${{ matrix.language }}
+    runs-on: ${{ matrix.runner }}
+    permissions:
+      security-events: write
+      packages: read
+      actions: read
+      contents: read
+
+    strategy:
+      fail-fast: false
+      matrix:
+        include:
+          # csharp needs the net48 agent projects to build, so Windows.
+          - language: csharp
+            runner: windows-latest
+            build-mode: manual
+          - language: javascript-typescript
+            runner: ubuntu-latest
+            build-mode: none
+
+    steps:
+      - uses: actions/checkout@v7
+
+      - uses: actions/setup-dotnet@v6
+        if: matrix.language == 'csharp'
+        with:
+          dotnet-version: '10.0.x'
+
+      - name: Initialize CodeQL
+        uses: github/codeql-action/init@v4.37.9
+        with:
+          languages: ${{ matrix.language }}
+          build-mode: ${{ matrix.build-mode }}
+          config-file: .github/codeql/codeql-config.yml
+
+      - name: Build
+        if: matrix.build-mode == 'manual'
+        run: dotnet build AutopilotMonitor.sln --configuration Release
+
+      - name: Analyze
+        uses: github/codeql-action/analyze@v4.37.9
+        with:
+          category: /language:${{ matrix.language }}

.github/workflows/combine-rules.yml

@@ -8,6 +8,7 @@ on:
       - 'rules/ime-log-patterns/**'
       - 'rules/schema/**'
       - 'rules/scripts/**'
+      - 'rules/guardrails.json'
   pull_request:
     paths:
       - 'rules/gather/**'
@@ -15,6 +16,7 @@ on:
       - 'rules/ime-log-patterns/**'
       - 'rules/schema/**'
       - 'rules/scripts/**'
+      - 'rules/guardrails.json'
 
 jobs:
   validate-and-combine:
@@ -22,11 +24,11 @@ jobs:
     permissions:
       contents: write
     steps:
-      - uses: actions/checkout@v5
+      - uses: actions/checkout@v7
 
-      - uses: actions/setup-node@v5
+      - uses: actions/setup-node@v7
         with:
-          node-version: '20'
+          node-version: '22'
 
       - name: Install ajv-cli
         run: npm install -g ajv-cli ajv-formats
@@ -52,12 +54,32 @@ jobs:
             ajv validate -s rules/schema/ime-log-pattern.schema.json -d "$f" --spec=draft2020 -c ajv-formats
           done
 
+      # guardrails.json values are baked verbatim into generated TypeScript that is
+      # auto-committed to main and shipped to the portal - the schema forbids control
+      # and line-terminator characters so a "data" PR can never become code.
+      - name: Validate Guardrails
+        run: ajv validate -s rules/schema/guardrails.schema.json -d rules/guardrails.json --spec=draft2020 -c ajv-formats
+
       - name: Combine rules into dist/
         run: node rules/scripts/combine.js
 
-      - name: Commit dist/ changes
+      # Plain git instead of a third-party action: this step runs with contents:write on
+      # main, so no code we do not control gets to push. Checkout leaves the job's
+      # GITHUB_TOKEN in the remote credential helper, which is all `git push` needs.
+      # NOTE: combine.js writes THREE outputs; committing only dist/ would silently discard
+      # the two generated TS modules and leave the guardrails-in-sync CI check red.
+      - name: Commit generated outputs
         if: github.ref == 'refs/heads/main' && github.event_name == 'push'
-        uses: stefanzweifel/git-auto-commit-action@v7
-        with:
-          commit_message: "chore: regenerate rules/dist from individual files"
-          file_pattern: "rules/dist/*"
+        run: |
+          set -euo pipefail
+          git config user.name "github-actions[bot]"
+          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
+          git add -- rules/dist/ \
+            src/Web/autopilot-monitor-web/utils/guardrails.generated.ts \
+            src/McpServer/autopilot-monitor-mcp/src/rule-authoring.generated.ts
+          if git diff --cached --quiet; then
+            echo "Generated outputs unchanged - nothing to commit"
+            exit 0
+          fi
+          git commit -m "chore: regenerate rules/dist + generated TS from individual files"
+          git push origin HEAD:main

.github/workflows/deploy-backend.yml

@@ -7,37 +7,117 @@ permissions:
   id-token: write   # OIDC federated login (secret-less)
   contents: read
 
+env:
+  FUNCTION_APP: autopilotmonitor-api-eu
+  HEALTH_URL: https://autopilotmonitor-api-eu.azurewebsites.net/api/health
+  VERSIONS_CONTAINER: https://autopilotmonitoreu.blob.core.windows.net/versions
+  CSPROJ_PATH: src/Backend/AutopilotMonitor.Functions/AutopilotMonitor.Functions.csproj
+
 jobs:
   build-and-deploy:
     runs-on: ubuntu-latest
     name: Build and Deploy Backend
 
     steps:
-      - uses: actions/checkout@v5
+      - uses: actions/checkout@v7
 
       - name: Login to Azure (OIDC)
-        uses: azure/login@v3
+        uses: azure/login@7ddb5af1ef8758cf1353cf3b42f940aee27ba21c # v3
         with:
           client-id: ${{ secrets.AZURE_CLIENT_ID }}
           tenant-id: ${{ secrets.AZURE_TENANT_ID }}
           subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
 
       - name: Setup .NET 10
-        uses: actions/setup-dotnet@v5
+        uses: actions/setup-dotnet@v6
         with:
           dotnet-version: '10.0.x'
 
+      # Same counter mechanism as the agent line: reserve-before-build with ETag-CAS
+      # against a per-component counter blob. BuildTimestampUtc is pinned here rather
+      # than left to MSBuild's default so the published manifest and the value baked
+      # into the assembly (reported by /api/health) are the same instant.
+      - name: Reserve build number (counter blob CAS)
+        id: version
+        shell: pwsh
+        run: |
+          $buildNumber = & ./.github/scripts/Request-BuildNumber.ps1 -CounterUrl "${{ env.VERSIONS_CONTAINER }}/backend.txt" -SasToken '${{ secrets.AZURE_BLOB_VERSIONS_SAS_TOKEN }}'
+
+          $csproj = Get-Content ${{ env.CSPROJ_PATH }} -Raw
+          if ($csproj -notmatch '<VersionPrefix>(\d+\.\d+)</VersionPrefix>') {
+            throw "VersionPrefix not found in ${{ env.CSPROJ_PATH }}"
+          }
+          $version = "$($Matches[1]).$buildNumber"
+          $buildUtc = [DateTime]::UtcNow.ToString('o')
+          Write-Host "Backend version: $version (built $buildUtc)"
+
+          "build_number=$buildNumber" >> $env:GITHUB_OUTPUT
+          "version=$version" >> $env:GITHUB_OUTPUT
+          "build_utc=$buildUtc" >> $env:GITHUB_OUTPUT
+
       - name: Restore dependencies
-        run: dotnet restore src/Backend/AutopilotMonitor.Functions/AutopilotMonitor.Functions.csproj
+        run: dotnet restore ${{ env.CSPROJ_PATH }}
 
       - name: Build
-        run: dotnet build src/Backend/AutopilotMonitor.Functions/AutopilotMonitor.Functions.csproj --configuration Release --no-restore -p:SourceRevisionId=${{ github.sha }}
+        run: dotnet build ${{ env.CSPROJ_PATH }} --configuration Release --no-restore -p:SourceRevisionId=${{ github.sha }} -p:BuildNumber=${{ steps.version.outputs.build_number }} -p:BuildTimestampUtc=${{ steps.version.outputs.build_utc }}
 
       - name: Publish
-        run: dotnet publish src/Backend/AutopilotMonitor.Functions/AutopilotMonitor.Functions.csproj --configuration Release --output ./publish --no-build -p:SourceRevisionId=${{ github.sha }}
+        run: dotnet publish ${{ env.CSPROJ_PATH }} --configuration Release --output ./publish --no-build -p:SourceRevisionId=${{ github.sha }} -p:BuildNumber=${{ steps.version.outputs.build_number }} -p:BuildTimestampUtc=${{ steps.version.outputs.build_utc }}
 
       - name: Deploy to Azure Functions
-        uses: Azure/functions-action@v1
+        uses: Azure/functions-action@c5060b3b8bb1ebbcb531abd00c822ecbaa8ea656 # v1
         with:
-          app-name: autopilotmonitor-api-eu
+          app-name: ${{ env.FUNCTION_APP }}
           package: ./publish
+
+      # A green deploy step only means the package was accepted. This gate makes the
+      # workflow assert what is actually being served, so the manifest published below
+      # can be trusted as "this is live" rather than "this was uploaded".
+      # /api/health is IP rate-limited at 30/min; one poll per 10s stays well under.
+      - name: Verify deployed build is live
+        shell: pwsh
+        run: |
+          $expectedCommit = '${{ github.sha }}'.Substring(0, 7)
+          $expectedVersion = '${{ steps.version.outputs.version }}'
+          $deadline = [DateTime]::UtcNow.AddMinutes(3)
+          $attempt = 0
+
+          while ([DateTime]::UtcNow -lt $deadline) {
+            $attempt++
+            try {
+              $health = Invoke-RestMethod -Uri '${{ env.HEALTH_URL }}' -Method Get -TimeoutSec 30
+              if ($health.commitHash -eq $expectedCommit -and $health.version -eq $expectedVersion) {
+                Write-Host "Live after $attempt attempt(s): $($health.version) @ $($health.commitHash), built $($health.buildUtc)"
+                exit 0
+              }
+              Write-Host "Attempt ${attempt}: serving $($health.version) @ $($health.commitHash) -- waiting for $expectedVersion @ $expectedCommit"
+            } catch {
+              Write-Host "Attempt ${attempt}: /api/health not answering yet -- $($_.Exception.Message)"
+            }
+            Start-Sleep -Seconds 10
+          }
+
+          throw "Backend did not report $expectedVersion @ $expectedCommit within 3 minutes -- deployment not verified, version manifest NOT published"
+
+      # The manifest is the cross-component record of what is deployed where. It is
+      # written last and only on a verified deploy, so a difference between the
+      # manifest and /api/health means the running app drifted after the fact
+      # (rollback, stale instance) rather than a half-finished pipeline.
+      - name: Publish version manifest
+        shell: pwsh
+        run: |
+          $manifest = [ordered]@{
+            component   = 'backend'
+            version     = '${{ steps.version.outputs.version }}'
+            commit      = '${{ github.sha }}'.Substring(0, 7)
+            buildUtc    = '${{ steps.version.outputs.build_utc }}'
+            deployedUtc = [DateTime]::UtcNow.ToString('o')
+            runId       = '${{ github.run_id }}'
+          } | ConvertTo-Json
+
+          $sas = '${{ secrets.AZURE_BLOB_VERSIONS_SAS_TOKEN }}'.TrimStart('?')
+          $url = "${{ env.VERSIONS_CONTAINER }}/backend.json?$sas"
+          # no-cache: rotating pointer, must never be served stale by any fronting cache.
+          Invoke-RestMethod -Uri $url -Method Put -Headers @{ 'x-ms-blob-type' = 'BlockBlob'; 'x-ms-blob-cache-control' = 'no-cache' } -Body $manifest -ContentType 'application/json' | Out-Null
+          Write-Host "Published versions/backend.json"
+          Write-Host $manifest

.github/workflows/deploy-mcp.yml

@@ -11,7 +11,14 @@ env:
   ACR_NAME: autopilotmonitoreuacr
   CONTAINER_APP_NAME: autopilotmonitor-mcp
   RESOURCE_GROUP: ${{ secrets.AZURE_MCP_RESOURCE_GROUP }}
-  IMAGE_TAG: ${{ github.sha }}
+  # Unique per RUN, not per commit: the docs corpus is baked into the image, so a
+  # docs-only redeploy at an unchanged code sha must still produce a new image
+  # reference — with a sha-only tag `az containerapp update` saw the same image
+  # and silently created no revision (2026-08-28).
+  IMAGE_TAG: ${{ github.sha }}-${{ github.run_number }}
+  HEALTH_URL: https://mcp.autopilotmonitor.com/health
+  VERSIONS_CONTAINER: https://autopilotmonitoreu.blob.core.windows.net/versions
+  PACKAGE_JSON: src/McpServer/autopilot-monitor-mcp/package.json
 
 jobs:
   build-and-deploy:
@@ -19,15 +26,56 @@ jobs:
     name: Build and Deploy MCP Server
 
     steps:
-      - uses: actions/checkout@v5
+      - uses: actions/checkout@v7
+
+      # The published customer documentation lives in its own PUBLIC repo and is
+      # baked into the image as the search_docs corpus (see the Dockerfile). No
+      # token is needed. Checking it out here rather than vendoring it keeps the
+      # docs single-sourced — but it also means EDITING THE DOCS DOES NOT UPDATE A
+      # RUNNING SERVER; this workflow must be re-run (IMAGE_TAG is per run so the
+      # re-run actually rolls a new revision). /health reports the SHA captured
+      # below so that staleness is checkable.
+      - name: Check out documentation bundle
+        uses: actions/checkout@v7
+        with:
+          repository: autopilotmonitor/autopilotmonitor-docs
+          path: mcp-docs
+
+      - name: Resolve docs commit
+        id: docs
+        run: echo "sha=$(git -C mcp-docs rev-parse HEAD)" >> "$GITHUB_OUTPUT"
 
       - name: Login to Azure (OIDC)
-        uses: azure/login@v3
+        uses: azure/login@7ddb5af1ef8758cf1353cf3b42f940aee27ba21c # v3
         with:
           client-id: ${{ secrets.AZURE_CLIENT_ID }}
           tenant-id: ${{ secrets.AZURE_TENANT_ID }}
           subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
 
+      # Same counter mechanism as agent and backend: reserve-before-build with
+      # ETag-CAS against the component's own counter blob. major.minor stays curated
+      # in package.json; only the build part is minted here.
+      - name: Reserve build number (counter blob CAS)
+        id: version
+        shell: pwsh
+        run: |
+          $buildNumber = & ./.github/scripts/Request-BuildNumber.ps1 -CounterUrl "${{ env.VERSIONS_CONTAINER }}/mcp.txt" -SasToken '${{ secrets.AZURE_BLOB_VERSIONS_SAS_TOKEN }}'
+
+          $pkgVersion = (Get-Content ${{ env.PACKAGE_JSON }} -Raw | ConvertFrom-Json).version
+          $prefix = ($pkgVersion -split '\.')[0..1] -join '.'
+          $version = "$prefix.$buildNumber"
+          $buildUtc = [DateTime]::UtcNow.ToString('o')
+          Write-Host "MCP version: $version (built $buildUtc)"
+
+          # 7 chars, matching what the backend's BackendBuildInfo reports — one commit
+          # shape across all components so the values can be compared as-is.
+          $shortSha = '${{ github.sha }}'.Substring(0, 7)
+
+          "build_number=$buildNumber" >> $env:GITHUB_OUTPUT
+          "version=$version" >> $env:GITHUB_OUTPUT
+          "build_utc=$buildUtc" >> $env:GITHUB_OUTPUT
+          "short_sha=$shortSha" >> $env:GITHUB_OUTPUT
+
       - name: Login to ACR
         run: az acr login --name ${{ env.ACR_NAME }}
 
@@ -35,6 +83,10 @@ jobs:
         run: |
           docker build \
             -f src/McpServer/autopilot-monitor-mcp/Dockerfile \
+            --build-arg DOCS_COMMIT=${{ steps.docs.outputs.sha }} \
+            --build-arg BUILD_NUMBER=${{ steps.version.outputs.build_number }} \
+            --build-arg BUILD_COMMIT=${{ steps.version.outputs.short_sha }} \
+            --build-arg BUILD_UTC=${{ steps.version.outputs.build_utc }} \
             -t ${{ env.ACR_NAME }}.azurecr.io/${{ env.CONTAINER_APP_NAME }}:${{ env.IMAGE_TAG }} \
             -t ${{ env.ACR_NAME }}.azurecr.io/${{ env.CONTAINER_APP_NAME }}:latest \
             .
@@ -46,3 +98,55 @@ jobs:
             --name ${{ env.CONTAINER_APP_NAME }} \
             --resource-group ${{ env.RESOURCE_GROUP }} \
             --image ${{ env.ACR_NAME }}.azurecr.io/${{ env.CONTAINER_APP_NAME }}:${{ env.IMAGE_TAG }}
+
+      # `az containerapp update` returns once the revision is provisioned, not once
+      # it serves traffic — and with minReplicas=0 the first request also pays a cold
+      # start. Polling /health until it reports THIS build is what makes the manifest
+      # below mean "live"; a full 5 minutes because the cold start alone is ~25s.
+      - name: Verify deployed build is live
+        shell: pwsh
+        run: |
+          $expectedCommit = '${{ steps.version.outputs.short_sha }}'
+          $expectedVersion = '${{ steps.version.outputs.version }}'
+          $deadline = [DateTime]::UtcNow.AddMinutes(5)
+          $attempt = 0
+
+          while ([DateTime]::UtcNow -lt $deadline) {
+            $attempt++
+            try {
+              $health = Invoke-RestMethod -Uri '${{ env.HEALTH_URL }}' -Method Get -TimeoutSec 60
+              if ($health.commit -eq $expectedCommit -and $health.version -eq $expectedVersion) {
+                Write-Host "Live after $attempt attempt(s): $($health.version) @ $($health.commit), docs $($health.docs.commit) ($($health.docs.chunks) chunks)"
+                exit 0
+              }
+              Write-Host "Attempt ${attempt}: serving $($health.version) @ $($health.commit) -- waiting for $expectedVersion @ $expectedCommit"
+            } catch {
+              Write-Host "Attempt ${attempt}: /health not answering yet -- $($_.Exception.Message)"
+            }
+            Start-Sleep -Seconds 15
+          }
+
+          throw "MCP did not report $expectedVersion @ $expectedCommit within 5 minutes -- deployment not verified, version manifest NOT published"
+
+      # Cross-component record of what is deployed where; written last and only on a
+      # verified deploy. docsCommit rides along because for this component "which
+      # build" and "which documentation" are two separate questions.
+      - name: Publish version manifest
+        shell: pwsh
+        run: |
+          $manifest = [ordered]@{
+            component   = 'mcp'
+            version     = '${{ steps.version.outputs.version }}'
+            commit      = '${{ steps.version.outputs.short_sha }}'
+            buildUtc    = '${{ steps.version.outputs.build_utc }}'
+            deployedUtc = [DateTime]::UtcNow.ToString('o')
+            runId       = '${{ github.run_id }}'
+            docsCommit  = '${{ steps.docs.outputs.sha }}'.Substring(0, 7)
+          } | ConvertTo-Json
+
+          $sas = '${{ secrets.AZURE_BLOB_VERSIONS_SAS_TOKEN }}'.TrimStart('?')
+          $url = "${{ env.VERSIONS_CONTAINER }}/mcp.json?$sas"
+          # no-cache: rotating pointer, must never be served stale by any fronting cache.
+          Invoke-RestMethod -Uri $url -Method Put -Headers @{ 'x-ms-blob-type' = 'BlockBlob'; 'x-ms-blob-cache-control' = 'no-cache' } -Body $manifest -ContentType 'application/json' | Out-Null
+          Write-Host "Published versions/mcp.json"
+          Write-Host $manifest

.github/workflows/deploy-web.yml

@@ -1,5 +1,13 @@
 name: Deploy Web (Static Web App)
 
+# Build here, upload with the pinned SWA CLI. No third-party action sees the deploy token
+# (the CLI is Microsoft-published npm code at an exact version), the build runs on the same
+# path ci.yml tests (setup-node 22 + npm ci + next build) instead of Oryx guessing inside the
+# action's container, and the exported site is attested like the agent ZIP and the MSI.
+#
+# PR preview environments were dropped with the action: their per-PR URLs are never
+# registered as redirect URIs, so nobody could log in on them anyway.
+
 on:
   push:
     branches:
@@ -8,57 +16,140 @@ on:
       - 'src/Web/autopilot-monitor-web/**'
       - '.github/workflows/deploy-web.yml'
   workflow_dispatch:
-  pull_request:
-    types: [opened, synchronize, reopened, closed]
-    branches:
-      - main
-    paths:
-      - 'src/Web/autopilot-monitor-web/**'
-      - '.github/workflows/deploy-web.yml'
+
+permissions:
+  contents: read
+  id-token: write      # keyless Sigstore signing (artifact attestation)
+  attestations: write  # store the provenance attestation
+
+env:
+  PORTAL_VERSION_URL: https://portal.autopilotmonitor.com/version.json
+  VERSIONS_CONTAINER: https://autopilotmonitoreu.blob.core.windows.net/versions
+  WEB_DIR: src/Web/autopilot-monitor-web
+  # Exact version: `npx --package` resolves from the registry at run time, so the pin is the
+  # only thing that keeps the deploy step's code fixed. Bump deliberately.
+  SWA_CLI_VERSION: 2.0.10
 
 jobs:
   build_and_deploy_job:
-    if: github.event_name == 'push' || github.event_name == 'workflow_dispatch' || (github.event_name == 'pull_request' && github.event.action != 'closed')
     runs-on: ubuntu-latest
     name: Build and Deploy Job
     steps:
-      - uses: actions/checkout@v5
+      - uses: actions/checkout@v7
         with:
           lfs: false
           fetch-depth: 0  # Full history needed for git-based sitemap lastmod dates
-      - name: Build And Deploy
-        id: builddeploy
-        uses: Azure/static-web-apps-deploy@v1
+
+      - uses: actions/setup-node@v7
+        with:
+          node-version: '22'
+          cache: npm
+          cache-dependency-path: ${{ env.WEB_DIR }}/package-lock.json
+
+      - name: Install dependencies
+        working-directory: ${{ env.WEB_DIR }}
+        run: npm ci
+
+      # next.config output:'export' -- `next build` writes the static site to out/
+      # (prebuild: sync-error-codes, generate-lastmod, generate-version).
+      - name: Build
+        working-directory: ${{ env.WEB_DIR }}
         env:
           NEXT_PUBLIC_ENTRA_CLIENT_ID: ${{ vars.NEXT_PUBLIC_ENTRA_CLIENT_ID }}
+          # Dual app-reg window: previous app registration (unset = single-app behaviour)
+          # and the default app for browsers without a stored selection (legacy|primary).
+          NEXT_PUBLIC_ENTRA_LEGACY_CLIENT_ID: ${{ vars.NEXT_PUBLIC_ENTRA_LEGACY_CLIENT_ID }}
+          NEXT_PUBLIC_ENTRA_DEFAULT_APP: ${{ vars.NEXT_PUBLIC_ENTRA_DEFAULT_APP }}
           NEXT_PUBLIC_ENTRA_REDIRECT_URI: ${{ vars.NEXT_PUBLIC_ENTRA_REDIRECT_URI }}
           NEXT_PUBLIC_ENTRA_POST_LOGOUT_REDIRECT_URI: ${{ vars.NEXT_PUBLIC_ENTRA_POST_LOGOUT_REDIRECT_URI }}
           NEXT_PUBLIC_API_BASE_URL: ${{ vars.NEXT_PUBLIC_API_BASE_URL }}
           NEXT_PUBLIC_PLATFORM_STATS_MANIFEST_URL: ${{ vars.NEXT_PUBLIC_PLATFORM_STATS_MANIFEST_URL }}
           NEXT_PUBLIC_APPINSIGHTS_CONNECTION_STRING: ${{ secrets.NEXT_PUBLIC_APPINSIGHTS_CONNECTION_STRING }}
+          # Build stamp for public/version.json (scripts/generate-version.js in prebuild);
+          # the verify step below polls the deployed file for exactly this commit.
+          GITHUB_SHA: ${{ github.sha }}
+        run: |
+          npm run build
+          test -f out/version.json || { echo "out/version.json missing - export did not run"; exit 1; }
+
+      # One archive of the exact bytes that get uploaded, so the attestation has a single subject.
+      - name: Package export
+        id: package
+        run: |
+          archive="portal-${GITHUB_SHA::7}.tar.gz"
+          tar -C "$WEB_DIR/out" -czf "$archive" .
+          echo "archive=$archive" >> "$GITHUB_OUTPUT"
+          sha256sum "$archive"
+
+      # Sigstore keyless provenance: binds the export digest to this workflow run (repo, ref,
+      # commit, workflow file) in a public transparency log.
+      # Verify: gh attestation verify portal-<sha>.tar.gz --repo okieselbach/AutopilotMonitor
+      - name: Attest build provenance (portal export)
+        uses: actions/attest-build-provenance@v4
         with:
-          azure_static_web_apps_api_token: ${{ secrets.AZURE_SWA_DEPLOY_TOKEN }}
-          repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
-          action: "upload"
-          ###### Repository/Build Configurations - These values can be configured to match your app requirements. ######
-          # For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
-          app_location: "src/Web/autopilot-monitor-web" # App source code path
-          api_location: "" # Api source code path - optional
-          output_location: "" # Built app content directory - optional
-          ###### End of Repository/Build Configurations ######
+          subject-path: ${{ steps.package.outputs.archive }}
 
-  close_pull_request_job:
-    if: github.event_name == 'pull_request' && github.event.action == 'closed'
-    runs-on: ubuntu-latest
-    name: Close Pull Request Job
-    steps:
-      - name: Close Pull Request
-        id: closepullrequest
-        uses: Azure/static-web-apps-deploy@v1
+      - name: Upload build artifact
+        uses: actions/upload-artifact@v7
         with:
-          azure_static_web_apps_api_token: ${{ secrets.AZURE_SWA_DEPLOY_TOKEN }}
-          action: "close"
+          name: portal-${{ github.sha }}
+          path: ${{ steps.package.outputs.archive }}
 
+      # Upload only -- out/ is already built. --swa-config-location points at the app root,
+      # where staticwebapp.config.json lives (next export does not copy it into out/).
+      - name: Deploy to Static Web App
+        env:
+          SWA_CLI_DEPLOYMENT_TOKEN: ${{ secrets.AZURE_SWA_DEPLOY_TOKEN }}
+        run: |
+          npx --yes --package "@azure/static-web-apps-cli@${SWA_CLI_VERSION}" swa deploy \
+            --app-location "$WEB_DIR" \
+            --output-location out \
+            --swa-config-location "$WEB_DIR" \
+            --env production \
+            --no-use-keychain
 
+      # The CLI reporting success proves the upload, not that the production host serves the
+      # new build -- verify against the live /version.json (Cache-Control: no-store via
+      # staticwebapp.config.json) before publishing the version manifest.
+      - name: Verify deployed portal build is live
+        shell: pwsh
+        run: |
+          $expectedCommit = '${{ github.sha }}'.Substring(0, 7)
+          $deadline = [DateTime]::UtcNow.AddMinutes(5)
+          $attempt = 0
 
+          while ([DateTime]::UtcNow -lt $deadline) {
+            $attempt++
+            try {
+              $v = Invoke-RestMethod -Uri '${{ env.PORTAL_VERSION_URL }}' -Method Get -TimeoutSec 30 -Headers @{ 'Cache-Control' = 'no-cache' }
+              if ($v.commit -eq $expectedCommit) {
+                Write-Host "Live after $attempt attempt(s): web @ $($v.commit), built $($v.buildUtc)"
+                exit 0
+              }
+              Write-Host "Attempt ${attempt}: serving $($v.commit) -- waiting for $expectedCommit"
+            } catch {
+              Write-Host "Attempt ${attempt}: /version.json not answering yet -- $($_.Exception.Message)"
+            }
+            Start-Sleep -Seconds 15
+          }
 
+          throw "Portal did not serve commit $expectedCommit within 5 minutes -- deployment not verified, version manifest NOT published"
+
+      # Cross-component deploy record, written last and only on a verified deploy --
+      # same contract as versions/backend.json and versions/mcp.json.
+      - name: Publish version manifest
+        shell: pwsh
+        run: |
+          $manifest = [ordered]@{
+            component   = 'web'
+            commit      = '${{ github.sha }}'.Substring(0, 7)
+            deployedUtc = [DateTime]::UtcNow.ToString('o')
+            runId       = '${{ github.run_id }}'
+          } | ConvertTo-Json
+
+          $sas = '${{ secrets.AZURE_BLOB_VERSIONS_SAS_TOKEN }}'.TrimStart('?')
+          $url = "${{ env.VERSIONS_CONTAINER }}/web.json?$sas"
+          # no-cache: rotating pointer, must never be served stale by any fronting cache.
+          Invoke-RestMethod -Uri $url -Method Put -Headers @{ 'x-ms-blob-type' = 'BlockBlob'; 'x-ms-blob-cache-control' = 'no-cache' } -Body $manifest -ContentType 'application/json' | Out-Null
+          Write-Host "Published versions/web.json"
+          Write-Host $manifest

.github/workflows/oidc-login-test.yml

@@ -15,7 +15,7 @@ jobs:
     name: Federated login + read check
     steps:
       - name: Login to Azure (OIDC)
-        uses: azure/login@v3
+        uses: azure/login@7ddb5af1ef8758cf1353cf3b42f940aee27ba21c # v3
         with:
           client-id: ${{ secrets.AZURE_CLIENT_ID }}
           tenant-id: ${{ secrets.AZURE_TENANT_ID }}

.github/workflows/pester.yml

@@ -0,0 +1,29 @@
+name: Pester (Bootstrap scripts)
+
+# Pull-request view of the bootstrap script gates. Like ci.yml it reports rather than
+# blocks the merge button.
+#
+# There is deliberately no push trigger: publish-scripts.yml runs the very same
+# reusable gate workflow on every push to main and blocks the upload to the download
+# alias on it. A push trigger here would only duplicate that run, with no consequence.
+
+on:
+  pull_request:
+    branches: [main]
+    paths:
+      - 'scripts/Bootstrap/**'
+      - 'scripts/CustomerSetup/**'
+      - '.github/scripts/Publish-BootstrapScripts.ps1'
+      - '.github/workflows/bootstrap-script-gates.yml'
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+concurrency:
+  group: pester-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  gates:
+    uses: ./.github/workflows/bootstrap-script-gates.yml

.github/workflows/publish-scripts.yml

@@ -0,0 +1,56 @@
+name: Publish customer scripts
+
+# Keeps the scripts behind download.autopilotmonitor.com/agent/ current WITHOUT waiting
+# for an agent release. Before this workflow existed, the script blobs rotated only on a
+# publish_as_stable run of build-agent.yml, so a bootstrap fix sat unpublished until the
+# next agent cutover -- while the WDP bootstrap MSI downloads the published copy on every
+# enrolling device.
+#
+# Same publish code as the release path (.github/scripts/Publish-BootstrapScripts.ps1);
+# this workflow only supplies a second trigger for it.
+
+on:
+  push:
+    branches: [main]
+    paths:
+      - 'scripts/Bootstrap/**'
+      - 'scripts/CustomerSetup/**'
+      - '.github/scripts/Publish-BootstrapScripts.ps1'
+  workflow_dispatch:
+    inputs:
+      dry_run:
+        description: 'Run every check and report drift, upload nothing'
+        required: true
+        type: boolean
+        default: false
+
+permissions:
+  contents: read
+
+# Shared with build-agent.yml: a script publish and an agent release both touch
+# version.json, and the bootstrapVersion read-modify-write must not interleave with the
+# release writing its agent fields. Never cancel -- a half-published set is worse than a queue.
+concurrency:
+  group: agent-blob-publish
+  cancel-in-progress: false
+
+jobs:
+  gates:
+    uses: ./.github/workflows/bootstrap-script-gates.yml
+
+  publish:
+    name: Publish to the download alias
+    needs: gates
+    runs-on: windows-latest
+    steps:
+      - uses: actions/checkout@v7
+
+      - name: Publish bootstrap + customer scripts
+        shell: pwsh
+        run: |
+          $dryRun = '${{ inputs.dry_run }}' -eq 'true'
+          ./.github/scripts/Publish-BootstrapScripts.ps1 `
+            -SasToken '${{ secrets.AZURE_BLOB_AGENT_SAS_TOKEN }}' `
+            -LegacySasToken '${{ secrets.AZURE_BLOB_AGENT_LEGACY_SAS_TOKEN }}' `
+            -TableSasToken '${{ secrets.AZURE_TABLE_ADMIN_SAS_TOKEN }}' `
+            -DryRun:$dryRun

.gitignore

@@ -15,7 +15,7 @@ bld/
 [Ll]ogs/
 
 # Build counter files: the authoritative counter is the shared blob
-# (agent container, buildcounter-v{N}.txt, ETag-CAS — see docs/agent/build-counter-blob.md).
+# (agent container, buildcounter-v{N}.txt, ETag-CAS — see internal/docs/agent/build-counter-blob.md).
 # The local file is only an offline fallback for -SkipUpload/bare-dotnet smoke builds.
 buildcounter.txt
 
@@ -53,6 +53,9 @@ __azurite_db*__.json
 node_modules/
 .next/
 out/
+# Managed by Next.js since v16 (regenerated by next dev/build/typegen; path
+# inside flips between .next/types and .next/dev/types) — must not be tracked.
+next-env.d.ts
 build/
 dist/
 !rules/dist/
@@ -111,14 +114,10 @@ tmpclaude-*-cwd
 # Claude skills and scripts are now in a private submodule (.claude/commands/)
 # No individual file ignores needed — the submodule handles everything
 
-# Deployment scripts (local only — contain tokens + SAS URLs)
-scripts/Deployment/
-
-# Migration tooling (local only, vorerst) — cross-tenant storage/cert migration scripts
-scripts/Migration/
-
-# Infra (local only)
-infra/
+# Infra: tracked. The Bicep templates carry no credentials — every secret is a
+# @secure() parameter with an empty default, injected at deploy time, and image
+# pull runs on managed identity. Keep it that way: never commit a resolved secret
+# value or a *.parameters.json holding one.
 
 # M2 — local raw session fixtures before anonymization (plan §4 M2)
 tests/fixtures/enrollment-sessions-local/
@@ -129,19 +128,24 @@ tests/fixtures/enrollment-sessions-local/
 TODO.txt
 tools/orphan-analysis.py
 tools/export-session-fixture.mjs
-tasks/
 
 # Azure Table cleanup backups (dry-run exports + delete manifests)
-# Produced by /cleanup-table skill — never commit deletion payloads
+# Produced by operator tooling — never commit deletion payloads
 db-backups/
 plans/REFACTOR_AGENT_V2.md
 .claude/scheduled_tasks.lock
 .claude/plans/health-script-remediation-fix.md
+internal/docs/Introduction-AutopilotMonitor.pptx
+internal/docs/~$Introduction-AutopilotMonitor.pptx
 
-# Operator-local Azure setup helper — applies lifecycle policy + container
-# creation against a live storage account. Not portable across environments
-# (storage account name, resource group are operator-specific) so it stays
-# out of the repo. Each operator keeps their own copy.
-scripts/Backup/setup-backup-container.ps1
-docs/Introduction-AutopilotMonitor.pptx
-docs/~$Introduction-AutopilotMonitor.pptx
+# Playwright MCP browser artifacts (snapshots, screenshots, console logs)
+.playwright-mcp/
+
+# Web build stamp: generated by scripts/generate-version.js on every build (buildUtc
+# changes each run) and served at /version.json from the static export.
+src/Web/autopilot-monitor-web/public/version.json
+
+
+# Local IME installer scratch (MSI + extracted payload per version, for grepping
+# in binaries). Operator-only, never committed.
+ime-files/

.gitmodules

@@ -1,3 +1,9 @@
 [submodule ".claude/commands"]
 	path = .claude/commands
 	url = https://github.com/okieselbach/Autopilot-Monitor-dotclaude.git
+[submodule "docs"]
+	path = internal
+	url = https://github.com/okieselbach/Autopilot-Monitor-internal.git
+[submodule "infra"]
+	path = infra
+	url = https://github.com/okieselbach/Autopilot-Monitor-infra.git

.mcp.json

@@ -3,6 +3,10 @@
     "autopilot-monitor": {
       "type": "http",
       "url": "https://mcp.autopilotmonitor.com/mcp"
+    },
+    "playwright": {
+      "command": "cmd",
+      "args": ["/c", "npx", "@playwright/mcp@latest"]
     }
   }
 }

CODE_OF_CONDUCT.md

@@ -0,0 +1,19 @@
+# Code of Conduct
+
+This applies to all project spaces: issues, pull requests, discussions, and the documentation repository.
+
+## Expectations
+
+- Be respectful and constructive. Disagree with ideas, not with people.
+- Assume good intent. Most confusion is a documentation gap, not malice.
+- Keep discussions on topic and searchable: clear titles, reproducible steps, text instead of screenshots of text where possible.
+- Never post customer data, tenant IDs, device identifiers, tokens, or log excerpts containing personal data in public issues or discussions. Redact first.
+
+## Not acceptable
+
+Harassment, personal attacks, discriminatory language, publishing others' private information, and sustained disruption of discussions.
+
+## Enforcement
+
+The maintainers may edit, hide, or delete content and may block accounts that violate this code. To raise a concern, contact the maintainers privately through
+[GitHub](https://github.com/okieselbach) rather than in a public thread.

CONTRIBUTING.md

@@ -0,0 +1,17 @@
+# Feedback and Issues
+
+Autopilot Monitor is developed and operated by its maintainers. The source is published so that customers and security reviewers can see what runs on their devices and with their data. This page explains where feedback goes.
+
+| I want to… | Go to |
+|---|---|
+| Report a bug | [New issue → Bug report](https://github.com/okieselbach/AutopilotMonitor/issues/new/choose) |
+| Suggest a feature | [New issue → Feature request](https://github.com/okieselbach/AutopilotMonitor/issues/new/choose) |
+| Ask a question or discuss an idea | [Discussions](https://github.com/okieselbach/AutopilotMonitor/discussions) |
+| Report a security issue | [SECURITY.md](SECURITY.md) — privately, never as a public issue |
+| Read how the product works | [docs.autopilotmonitor.com](https://docs.autopilotmonitor.com) |
+
+## Reporting a problem in your own tenant
+
+For a failed or odd enrollment, the **Report Session** button in the portal is the fastest path. It hands the session context to support without exposing any of it publicly. Use a GitHub issue for problems that are reproducible and not tied to your data.
+
+Please redact tenant IDs, device names, serial numbers, and anything personal before posting in a public issue or discussion.

Directory.Build.props

@@ -0,0 +1,12 @@
+<Project>
+  <!-- Warning freeze (2026-08-13, backlog cleared to zero): every .NET build in this repo
+       must stay warning-free. Compiler, MSBuild and NuGet restore warnings are all fatal.
+       Exception: NuGet audit advisories (NU1901-NU1904) stay warnings — a CVE published
+       against an already-referenced package must not block an unrelated hotfix deploy;
+       advisories are handled by bumping the package, not by failing the build. -->
+  <PropertyGroup>
+    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
+    <MSBuildTreatWarningsAsErrors>true</MSBuildTreatWarningsAsErrors>
+    <WarningsNotAsErrors>NU1901;NU1902;NU1903;NU1904</WarningsNotAsErrors>
+  </PropertyGroup>
+</Project>

LICENSE

@@ -1,39 +1,673 @@
-Autopilot Monitor - Split License
+GNU AFFERO GENERAL PUBLIC LICENSE
+Version 3, 19 November 2007
 
-Copyright (c) 2026 Autopilot Monitor Contributors
+Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
 
-This project uses a split licensing model. Different components are
-licensed under different terms:
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
 
-## MIT License
+                            Preamble
 
-The following components are licensed under the MIT License:
+The GNU Affero General Public License is a free, copyleft license for
+software and other kinds of works, specifically designed to ensure
+cooperation with the community in the case of network server software.
 
-- src/Agent/    - The Autopilot Monitor Agent (deployed to devices)
-- src/Shared/   - Shared DTOs, enums, and constants
+The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+our General Public Licenses are intended to guarantee your freedom to
+share and change all versions of a program--to make sure it remains
+free software for all its users.
 
-See src/Agent/LICENSE and src/Shared/LICENSE for the full MIT license text.
+When we speak of free software, we are referring to freedom, not price.
+Our General Public Licenses are designed to make sure that you have the
+freedom to distribute copies of free software (and charge for them if
+you wish), that you receive source code or can get it if you want it,
+that you can change the software or use pieces of it in new free
+programs, and that you know you can do these things.
 
-## GNU Affero General Public License v3.0 (AGPL-3.0)
+Developers that use our General Public Licenses protect your rights
+with two steps: (1) assert copyright on the software, and (2) offer
+you this License which gives you legal permission to copy, distribute
+and/or modify the software.
 
-The following components are licensed under the AGPL-3.0:
+A secondary benefit of defending all users' freedom is that
+improvements made in alternate versions of the program, if they
+receive widespread use, become available for other developers to
+incorporate.  Many developers of free software are heartened and
+encouraged by the resulting cooperation.  However, in the case of
+software used on network servers, this result may fail to come about.
+The GNU General Public License permits making a modified version and
+letting the public access it on a server without ever releasing its
+source code to the public.
 
-- src/Backend/   - Azure Functions backend
-- src/Web/       - Next.js web frontend
-- src/McpServer/ - MCP Server
+The GNU Affero General Public License is designed specifically to
+ensure that, in such cases, the modified source code becomes available
+to the community.  It requires the operator of a network server to
+provide the source code of the modified version running there to the
+users of that server.  Therefore, public use of a modified version, on
+a publicly accessible server, gives the public access to the source
+code of the modified version.
 
-See src/Backend/LICENSE for the full AGPL-3.0 license text.
+An older license, called the Affero General Public License and
+published by Affero, was designed to accomplish similar goals.  This is
+a different license, not a version of the Affero GPL, but Affero has
+released a new version of the Affero GPL which permits relicensing
+under this license.
 
-## Why Split Licensing?
+The precise terms and conditions for copying, distribution and
+modification follow.
 
-The Agent runs on end-user devices and is licensed under MIT to allow
-unrestricted use, modification, and distribution without copyleft
-obligations.
+                       TERMS AND CONDITIONS
 
-The server-side components (Backend, Web, McpServer) are licensed under
-AGPL-3.0 to ensure that modifications to the server infrastructure
-remain open source, especially when deployed as a network service.
+0. Definitions.
 
-The Shared library is MIT-licensed because it is a dependency of the
-MIT-licensed Agent. Using AGPL for Shared would effectively make the
-Agent AGPL as well.
+"This License" refers to version 3 of the GNU Affero General Public
+License.
+
+"Copyright" also means copyright-like laws that apply to other kinds
+of works, such as semiconductor masks.
+
+"The Program" refers to any copyrightable work licensed under this
+License.  Each licensee is addressed as "you".  "Licensees" and
+"recipients" may be individuals or organizations.
+
+To "modify" a work means to copy from or adapt all or part of the work
+in a fashion requiring copyright permission, other than the making of
+an exact copy.  The resulting work is called a "modified version" of
+the earlier work or a work "based on" the earlier work.
+
+A "covered work" means either the unmodified Program or a work based
+on the Program.
+
+To "propagate" a work means to do anything with it that, without
+permission, would make you directly or secondarily liable for
+infringement under applicable copyright law, except executing it on a
+computer or modifying a private copy.  Propagation includes copying,
+distribution (with or without modification), making available to the
+public, and in some countries other activities as well.
+
+To "convey" a work means any kind of propagation that enables other
+parties to make or receive copies.  Mere interaction with a user
+through a computer network, with no transfer of a copy, is not
+conveying.
+
+An interactive user interface displays "Appropriate Legal Notices" to
+the extent that it includes a convenient and prominently visible
+feature that (1) displays an appropriate copyright notice, and (2)
+tells the user that there is no warranty for the work (except to the
+extent that warranties are provided), that licensees may convey the
+work under this License, and how to view a copy of this License.  If
+the interface presents a list of user commands or options, such as a
+menu, a prominent item in the list meets this criterion.
+
+1. Source Code.
+
+The "source code" for a work means the preferred form of the work for
+making modifications to it.  "Object code" means any non-source form
+of a work.
+
+A "Standard Interface" means an interface that either is an official
+standard defined by a recognized standards body, or, in the case of
+interfaces specified for a particular programming language, one that is
+widely used among developers working in that language.
+
+The "System Libraries" of an executable work include anything, other
+than the work as a whole, that (a) is included in the normal form of
+packaging a Major Component, but which is not part of that Major
+Component, and (b) serves only to enable use of the work with that
+Major Component, or to implement a Standard Interface for which an
+implementation is available to the public in source code form.  A
+"Major Component", in this context, means a major essential component
+(kernel, window system, and so on) of the specific operating system
+(if any) on which the executable work runs, or a compiler used to
+produce the work, or an object code interpreter used to run it.
+
+The "Corresponding Source" for a work in object code form means all
+the source code needed to generate, install, and (for an executable
+work) run the object code and to modify the work, including scripts to
+control those activities.  However, it does not include the work's
+System Libraries, or general-purpose tools or generally available free
+programs which are used unmodified in performing those activities but
+which are not part of the work.  For example, Corresponding Source
+includes interface definition files associated with source files for
+the work, and the source code for shared libraries and dynamically
+linked subprograms that the work is specifically designed to require,
+such as by intimate data communication or control flow between those
+subprograms and other parts of the work.
+
+The Corresponding Source need not include anything that users can
+regenerate automatically from other parts of the Corresponding Source.
+
+The Corresponding Source for a work in source code form is that same
+work.
+
+2. Basic Permissions.
+
+All rights granted under this License are granted for the term of
+copyright on the Program, and are irrevocable provided the stated
+conditions are met.  This License explicitly affirms your unlimited
+permission to run the unmodified Program.  The output from running a
+covered work is covered by this License only if the output, given its
+content, constitutes a covered work.  This License acknowledges your
+rights of fair use or other equivalent, as provided by copyright law.
+
+You may make, run and propagate covered works that you do not convey,
+without conditions so long as your license otherwise remains in force.
+You may convey covered works to others for the sole purpose of having
+them make modifications exclusively for you, or provide you with
+facilities for running those works, provided that you comply with the
+terms of this License in conveying all material for which you do not
+control copyright.  Those thus making or running the covered works for
+you must do so exclusively on your behalf, under your direction and
+control, on terms that prohibit them from making any copies of your
+copyrighted material outside their relationship with you.
+
+Conveying under any other circumstances is permitted solely under the
+conditions stated below.  Sublicensing is not allowed; section 10
+makes it unnecessary.
+
+3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+
+No covered work shall be deemed part of an effective technological
+measure under any applicable law fulfilling obligations under article
+11 of the WIPO copyright treaty adopted on 20 December 1996, or
+similar laws prohibiting or restricting circumvention of such measures.
+
+When you convey a covered work, you waive any legal power to forbid
+circumvention of technological measures to the extent such
+circumvention is effected by exercising rights under this License with
+respect to the covered work, and you disclaim any intention to limit
+operation or modification of the work as a means of enforcing, against
+the work's users, your or third parties' legal rights to forbid
+circumvention of technological measures.
+
+4. Conveying Verbatim Copies.
+
+You may convey verbatim copies of the Program's source code as you
+receive it, in any medium, provided that you conspicuously and
+appropriately publish on each copy an appropriate copyright notice;
+keep intact all notices stating that this License and any
+non-permissive terms added in accord with section 7 apply to the
+code; keep intact all notices of the absence of any warranty; and give
+all recipients a copy of this License along with the Program.
+
+You may charge any price or no price for each copy that you convey,
+and you may offer support or warranty protection for a fee.
+
+5. Conveying Modified Source Versions.
+
+You may convey a work based on the Program, or the modifications to
+produce it from the Program, in the form of source code under the
+terms of section 4, provided that you also meet all of these
+conditions:
+
+    a) The work must carry prominent notices stating that you modified
+    it, and giving a relevant date.
+
+    b) The work must carry prominent notices stating that it is
+    released under this License and any conditions added under
+    section 7.  This requirement modifies the requirement in section
+    4 to "keep intact all notices".
+
+    c) You must license the entire work, as a whole, under this
+    License to anyone who comes into possession of a copy.  This
+    License will therefore apply, along with any applicable section 7
+    additional terms, to the whole of the work, and all its parts,
+    regardless of how they are packaged.  This License gives no
+    permission to license the work in any other way, but it does not
+    invalidate such permission if you have separately received it.
+
+    d) If the work has interactive user interfaces, each must display
+    Appropriate Legal Notices; however, if the Program has interactive
+    interfaces that do not display Appropriate Legal Notices, your
+    work need not make them do so.
+
+A compilation of a covered work with other separate and independent
+works, which are not by their nature extensions of the covered work,
+and which are not combined with it such as to form a larger program,
+in or on a volume of a storage or distribution medium, is called an
+"aggregate" if the compilation and its resulting copyright are not used
+to limit the access or legal rights of the compilation's users beyond
+what the individual works permit.  Inclusion of a covered work in an
+aggregate does not cause this License to apply to the other parts of
+the aggregate.
+
+6. Conveying Non-Source Forms.
+
+You may convey a covered work in object code form under the terms of
+sections 4 and 5, provided that you also convey the machine-readable
+Corresponding Source under the terms of this License, in one of these
+ways:
+
+    a) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by the
+    Corresponding Source fixed on a durable physical medium
+    customarily used for software interchange.
+
+    b) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by a
+    written offer, valid for at least three years and valid for as
+    long as you offer spare parts or customer support for that product
+    model, to give anyone who possesses the object code either (1) a
+    copy of the Corresponding Source for all the software in the
+    product that is covered by this License, on a durable physical
+    medium customarily used for software interchange, for a price no
+    more than your reasonable cost of physically performing this
+    conveying of source, or (2) access to copy the Corresponding
+    Source from a network server at no charge.
+
+    c) Convey individual copies of the object code with a copy of the
+    written offer to provide the Corresponding Source.  This
+    alternative is allowed only occasionally and noncommercially, and
+    only if you received the object code with such an offer, in
+    accord with subsection 6b.
+
+    d) Convey the object code by offering access from a designated
+    place (gratis or for a charge), and offer equivalent access to
+    the Corresponding Source in the same way through the same place
+    at no further charge.  You need not require recipients to copy
+    the Corresponding Source along with the object code.  If the
+    place to copy the object code is a network server, the
+    Corresponding Source may be on a different server (operated by
+    you or a third party) that supports equivalent copying
+    facilities, provided you maintain clear directions next to the
+    object code saying where to find the Corresponding Source.
+    Regardless of what server hosts the Corresponding Source, you
+    remain obligated to ensure that it is available for as long as
+    needed to satisfy these requirements.
+
+    e) Convey the object code using peer-to-peer transmission,
+    provided you inform other peers where the object code and
+    Corresponding Source of the work are being offered to the general
+    public at no charge under subsection 6d.
+
+A separable portion of the object code, whose source code is excluded
+from the Corresponding Source as a System Library, need not be
+included in conveying the object code work.
+
+A "User Product" is either (1) a "consumer product", which means any
+tangible personal property which is normally used for personal, family,
+or household purposes, or (2) anything designed or sold for
+incorporation into a dwelling.  In determining whether a product is a
+consumer product, doubtful cases shall be resolved in favor of
+coverage.  For a particular product received by a particular user,
+"normally used" refers to a typical or common use of that class of
+product, regardless of the status of the particular user or of the way
+in which the particular user actually uses, or expects or is expected
+to use, the product.  A product is a consumer product regardless of
+whether the product has substantial commercial, industrial or
+non-consumer uses, unless such uses represent the only significant
+mode of use of the product.
+
+"Installation Information" for a User Product means any methods,
+procedures, authorization keys, or other information required to
+install and execute modified versions of a covered work in that User
+Product from a modified version of its Corresponding Source.  The
+information must suffice to ensure that the continued functioning of
+the modified object code is in no case prevented or interfered with
+solely because modification has been made.
+
+If you convey an object code work under this section in, or with, or
+specifically for use in, a User Product, and the conveying occurs as
+part of a transaction in which the right of possession and use of the
+User Product is transferred to the recipient in perpetuity or for a
+fixed term (regardless of how the transaction is characterized), the
+Corresponding Source conveyed under this section must be accompanied
+by the Installation Information.  But this requirement does not apply
+if neither you nor any third party retains the ability to install
+modified object code on the User Product (for example, the work has
+been installed in ROM).
+
+The requirement to provide Installation Information does not include a
+requirement to continue to provide support service, warranty, or
+updates for a work that has been modified or installed by the
+recipient, or for the User Product in which it has been modified or
+installed.  Access to a network may be denied when the modification
+itself materially and adversely affects the operation of the network
+or violates the rules and protocols for communication across the
+network.
+
+Corresponding Source conveyed, and Installation Information provided,
+in accord with this section must be in a format that is publicly
+documented (and with an implementation available to the public in
+source code form), and must require no special password or key for
+unpacking, reading or copying.
+
+7. Additional Terms.
+
+"Additional permissions" are terms that supplement the terms of this
+License by making exceptions from one or more of its conditions.
+Additional permissions that are applicable to the entire Program shall
+be treated as though they were included in this License, to the extent
+that they are valid under applicable law.  If additional permissions
+apply only to part of the Program, that part may be used separately
+under those permissions, but the entire Program remains governed by
+this License without regard to the additional permissions.
+
+When you convey a copy of a covered work, you may at your option
+remove any additional permissions from that copy, or from any part of
+it.  (Additional permissions may be written to require their own
+removal in certain cases when you modify the work.)  You may place
+additional permissions on material, added by you to a covered work,
+for which you have or can give appropriate copyright permission.
+
+Notwithstanding any other provision of this License, for material you
+add to a covered work, you may (if authorized by the copyright
+holders of that material) supplement the terms of this License with
+terms:
+
+    a) Disclaiming warranty or limiting liability differently from the
+    terms of sections 15 and 16 of this License; or
+
+    b) Requiring preservation of specified reasonable legal notices or
+    author attributions in that material or in the Appropriate Legal
+    Notices displayed by works containing it; or
+
+    c) Prohibiting misrepresentation of the origin of that material,
+    or requiring that modified versions of such material be marked in
+    reasonable ways as different from the original version; or
+
+    d) Limiting the use for publicity purposes of names of licensors
+    or authors of the material; or
+
+    e) Declining to grant rights under trademark law for use of some
+    trade names, trademarks, or service marks; or
+
+    f) Requiring indemnification of licensors and authors of that
+    material by anyone who conveys the material (or modified versions
+    of it) with contractual assumptions of liability to the recipient,
+    for any liability that these contractual assumptions directly
+    impose on those licensors and authors.
+
+All other non-permissive additional terms are considered "further
+restrictions" within the meaning of section 10.  If the Program as you
+received it, or any part of it, contains a notice stating that it is
+governed by this License along with a term that is a further
+restriction, you may remove that term.  If a license document contains
+a further restriction but permits relicensing or conveying under this
+License, you may add to a covered work material governed by the terms
+of that license document, provided that the further restriction does
+not survive such relicensing or conveying.
+
+If you add terms to a covered work in accord with this section, you
+must place, in the relevant source files, a statement of the
+additional terms that apply to those files, or a notice indicating
+where to find the applicable terms.
+
+Additional terms, permissive or non-permissive, may be stated in the
+form of a separately written license, or stated as exceptions; the
+above requirements apply either way.
+
+8. Termination.
+
+You may not propagate or modify a covered work except as expressly
+provided under this License.  Any attempt otherwise to propagate or
+modify it is void, and will automatically terminate your rights under
+this License (including any patent licenses granted under the third
+paragraph of section 11).
+
+However, if you cease all violation of this License, then your license
+from a particular copyright holder is reinstated (a) provisionally,
+unless and until the copyright holder explicitly and finally terminates
+your license, and (b) permanently, if the copyright holder fails to
+notify you of the violation by some reasonable means prior to 60 days
+after the cessation.
+
+Moreover, your license from a particular copyright holder is
+reinstated permanently if the copyright holder notifies you of the
+violation by some reasonable means, this is the first time you have
+received notice of violation of this License (for any work) from that
+copyright holder, and you cure the violation prior to 30 days after
+your receipt of the notice.
+
+Termination of your rights under this section does not terminate the
+licenses of parties who have received copies or rights from you under
+this License.  If your rights have been terminated and not permanently
+reinstated, you do not qualify to receive new licenses for the same
+material under section 10.
+
+9. Acceptance Not Required for Having Copies.
+
+You are not required to accept this License in order to receive or run
+a copy of the Program.  Ancillary propagation of a covered work
+occurring solely as a consequence of using peer-to-peer transmission
+to receive a copy likewise does not require acceptance.  However,
+nothing other than this License grants you permission to propagate or
+modify any covered work.  These actions infringe copyright if you do
+not accept this License.  Therefore, by modifying or propagating a
+covered work, you indicate your acceptance of this License to do so.
+
+10. Automatic Licensing of Downstream Recipients.
+
+Each time you convey a covered work, the recipient automatically
+receives a license from the original licensors, to run, modify and
+propagate that work, subject to this License.  You are not responsible
+for enforcing compliance by third parties with this License.
+
+An "entity transaction" is a transaction transferring control of an
+organization, or substantially all assets of one, or subdividing an
+organization, or merging organizations.  If propagation of a covered
+work results from an entity transaction, each party to that
+transaction who receives a copy of the work also receives whatever
+licenses to the work the party's predecessor in interest had or could
+give under the previous paragraph, plus a right to possession of the
+Corresponding Source of the work from the predecessor in interest, if
+the predecessor has it or can get it with reasonable efforts.
+
+You may not impose any further restrictions on the exercise of the
+rights granted or affirmed under this License.  For example, you may
+not impose a license fee, royalty, or other charge for exercise of
+rights granted under this License, and you may not initiate litigation
+(including a cross-claim or counterclaim in a lawsuit) alleging that
+any patent claim is infringed by making, using, selling, offering for
+sale, or importing the Program or any portion of it.
+
+11. Patents.
+
+A "contributor" is a copyright holder who authorizes use under this
+License of the Program or a work on which the Program is based.  The
+work thus licensed is called the contributor's "contributor version".
+
+A contributor's "essential patent claims" are all patent claims owned
+or controlled by the contributor, whether already acquired or
+hereafter acquired, that would be infringed by some manner, permitted
+by this License, of making, using, or selling its contributor version,
+but do not include claims that would be infringed only as a
+consequence of further modification of the contributor version.  For
+purposes of this definition, "control" includes the right to grant
+patent sublicenses in a manner consistent with the requirements of
+this License.
+
+Each contributor grants you a non-exclusive, worldwide, royalty-free
+patent license under the contributor's essential patent claims, to
+make, use, sell, offer for sale, import and otherwise run, modify and
+propagate the contents of its contributor version.
+
+In the following three paragraphs, a "patent license" is any express
+agreement or commitment, however denominated, not to enforce a patent
+(such as an express permission to practice a patent or covenant not to
+sue for patent infringement).  To "grant" such a patent license to a
+party means to make such an agreement or commitment not to enforce a
+patent against the party.
+
+If you convey a covered work, knowingly relying on a patent license,
+and the Corresponding Source of the work is not available for anyone
+to copy, free of charge and under the terms of this License, through a
+publicly available network server or other readily accessible means,
+then you must either (1) cause the Corresponding Source to be so
+available, or (2) arrange to deprive yourself of the benefit of the
+patent license for this particular work, or (3) arrange, in a manner
+consistent with the requirements of this License, to extend the
+patent license to downstream recipients.  "Knowingly relying" means
+you have actual knowledge that, but for the patent license, your
+conveying the covered work in a country, or your recipient's use of
+the covered work in a country, would infringe one or more identifiable
+patents in that country that you have reason to believe are valid.
+
+If, pursuant to or in connection with a single transaction or
+arrangement, you convey, or propagate by procuring conveyance of, a
+covered work, and grant a patent license to some of the parties
+receiving the covered work authorizing them to use, propagate, modify
+or convey a specific copy of the covered work, then the patent license
+you grant is automatically extended to all recipients of the covered
+work and works based on it.
+
+A patent license is "discriminatory" if it does not include within the
+scope of its coverage, prohibits the exercise of, or is conditioned on
+the non-exercise of one or more of the rights that are specifically
+granted under this License.  You may not convey a covered work if you
+are a party to an arrangement with a third party that is in the
+business of distributing software, under which you make payment to the
+third party based on the extent of your activity of conveying the
+work, and under which the third party grants, to any of the parties
+who would receive the covered work from you, a discriminatory patent
+license (a) in connection with copies of the covered work conveyed by
+you (or copies made from those copies), or (b) primarily for and in
+connection with specific products or compilations that contain the
+covered work, unless you entered into that arrangement, or that patent
+license was granted, prior to 28 March 2007.
+
+Nothing in this License shall be construed as excluding or limiting
+any implied license or other defenses to infringement that may
+otherwise be available to you under applicable patent law.
+
+12. No Surrender of Others' Freedom.
+
+If conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot convey
+a covered work so as to satisfy simultaneously your obligations under
+this License and any other pertinent obligations, then as a
+consequence you may not convey it at all.  For example, if you agree
+to terms that obligate you to collect a royalty for further conveying
+from those to whom you convey the Program, the only way you could
+satisfy both those terms and this License would be to refrain entirely
+from conveying the Program.
+
+13. Remote Network Interaction; Use with the GNU General Public
+License.
+
+Notwithstanding any other provision of this License, if you modify the
+Program, your modified version must prominently offer all users
+interacting with it remotely through a computer network (if your
+version supports such interaction) an opportunity to receive the
+Corresponding Source of your version by providing access to the
+Corresponding Source from a network server at no charge, through some
+standard or customary means of facilitating copying of software.  This
+Corresponding Source shall include the Corresponding Source for any
+work covered by version 3 of the GNU General Public License that is
+incorporated pursuant to the following paragraph.
+
+Notwithstanding any other provision of this License, you have
+permission to link or combine any covered work with a work licensed
+under version 3 of the GNU General Public License into a single
+combined work, and to convey the resulting work.  The terms of this
+License will continue to apply to the part which is the covered work,
+but the work with which it is combined will remain governed by version
+3 of the GNU General Public License.
+
+14. Revised Versions of this License.
+
+The Free Software Foundation may publish revised and/or new versions
+of the GNU Affero General Public License from time to time.  Such new
+versions will be similar in spirit to the present version, but may
+differ in detail to address new problems or concerns.
+
+Each version is given a distinguishing version number.  If the Program
+specifies that a certain numbered version of the GNU Affero General
+Public License "or any later version" applies to it, you have the
+option of following the terms and conditions either of that numbered
+version or of any later version published by the Free Software
+Foundation.  If the Program does not specify a version number of the
+GNU Affero General Public License, you may choose any version ever
+published by the Free Software Foundation.
+
+If the Program specifies that a proxy can decide which future versions
+of the GNU Affero General Public License can be used, that proxy's
+public statement of acceptance of a version permanently authorizes you
+to choose that version for the Program.
+
+Later license versions may give you additional or different
+permissions.  However, no additional obligations are imposed on any
+author or copyright holder as a result of your choosing to follow a
+later version.
+
+15. Disclaimer of Warranty.
+
+THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT
+WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND
+PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE PROGRAM PROVE
+DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR
+CORRECTION.
+
+16. Limitation of Liability.
+
+IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR
+CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES
+ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT
+NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR
+LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM
+TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER
+PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
+
+17. Interpretation of Sections 15 and 16.
+
+If the disclaimer of warranty and limitation of liability provided
+above cannot be given local legal effect according to their terms,
+reviewing courts shall apply local law that most closely approximates
+an absolute waiver of all civil liability in connection with the
+Program, unless a warranty or assumption of liability accompanies a
+copy of the Program in return for a fee.
+
+                 END OF TERMS AND CONDITIONS
+
+    How to Apply These Terms to Your New Programs
+
+If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these
+terms.
+
+To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+state the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This program is free software: you can redistribute it and/or modify
+    it under the terms of the GNU Affero General Public License as
+    published by the Free Software Foundation, either version 3 of the
+    License, or (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU Affero General Public License for more details.
+
+    You should have received a copy of the GNU Affero General Public
+    License along with this program.  If not, see
+    <https://www.gnu.org/licenses/>.
+
+Also add information on how to contact you by electronic and paper
+mail.
+
+If your software can interact with users remotely through a computer
+network, you should also make sure that it provides a way for users to
+get its source.  For example, if your program is a web application,
+its interface could display a "Source" link that leads users to an
+archive of the code.  There are many ways you could offer source, and
+different solutions will be better for different programs; see section
+13 for the specific requirements.
+
+You should also get your employer (if you work as a programmer) or
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary.  For more information on this, and how to apply and follow
+the GNU AGPL, see <https://www.gnu.org/licenses/>.

README.md

@@ -1,22 +1,22 @@
-# <img src="docs/images/logo.svg" height="28" alt="" /> AutopilotMonitor
+# <img src=".github/assets/logo.svg" height="28" alt="" /> Autopilot Monitor
 
-[![Status](https://img.shields.io/badge/status-Private%20Preview-orange)](https://www.autopilotmonitor.com)
+[![Status](https://img.shields.io/badge/status-live-brightgreen)](https://www.autopilotmonitor.com)
 [![License](https://img.shields.io/badge/license-MIT%20%2B%20AGPL--3.0-blue)](LICENSE)
 [![Website](https://img.shields.io/badge/website-autopilotmonitor.com-2ea44f)](https://www.autopilotmonitor.com)
 
 Advanced monitoring and troubleshooting solution for Windows Autopilot deployments. Gain full visibility into every enrollment session with a detailed event timeline, fleet health dashboards, and session reporting. Define custom analysis rules to automatically detect issues and gather rules to collect targeted evidence. Retrieve diagnostics packages on demand, configure agent settings like auto-reboot behavior and automatic timezone adjustment — all managed centrally from the web dashboard.
 
-## Private Preview
+## Availability
 
-Autopilot Monitor is currently running as a **Private Preview**. Visit **[autopilotmonitor.com](https://www.autopilotmonitor.com)** to request access and learn more.
+Autopilot Monitor is **publicly available** — the Community plan is free. Sign in with your work account at **[autopilotmonitor.com](https://www.autopilotmonitor.com)**; new organizations complete a short activation step after first sign-in.
 
 <p align="center">
-  <img src="docs/images/SessionList.png" width="45%" />
-  <img src="docs/images/FleetHealth.png" width="45%" />
+  <img src=".github/assets/SessionList.png" width="45%" />
+  <img src=".github/assets/FleetHealth.png" width="45%" />
 </p>
 <p align="center">
-  <img src="docs/images/SessionDetails.png" width="45%" />
-  <img src="docs/images/SessionTimeline.png" width="45%" />
+  <img src=".github/assets/SessionDetails.png" width="45%" />
+  <img src=".github/assets/SessionTimeline.png" width="45%" />
 </p>
 
 ## Overview
@@ -27,20 +27,31 @@ Autopilot Monitor provides real-time tracking, intelligent diagnostics, and auto
 - **Monitoring Agent** — Lightweight .NET application that collects telemetry and evidence during enrollment
 - **Backend API** — Azure Functions-based ingestion and processing pipeline
 - **Web Dashboard** — Next.js application for real-time monitoring and fleet analytics
+- **MCP Server** — Model Context Protocol server that lets AI assistants query and troubleshoot enrollments in natural language
 
-## Architecture
+## AI Integration (MCP)
 
-For detailed information about the system architecture, components, and data flow, see [Architecture Documentation](docs/architecture.md).
+Autopilot Monitor ships a hosted **[Model Context Protocol](https://modelcontextprotocol.io)** server. Connect Claude Desktop, VS Code, or any MCP client that speaks Streamable HTTP with OAuth, and ask questions like:
+
+- *"Show me all failed enrollments from the last 24 hours and group them by failure reason."*
+- *"Why did session X fail, and which app install caused the delay?"*
+- *"Which devices in my fleet are affected by CVE-2024-30078?"*
+
+Server URL: `https://mcp.autopilotmonitor.com/mcp` — sign-in runs through your existing work account, access is scoped to your tenant exactly like in the portal, and no credentials are stored. Setup guide: **[AI Integration (MCP)](https://docs.autopilotmonitor.com/integrations/ai-integration-mcp)**.
 
 ## Documentation
 
-Full documentation is available at **[autopilotmonitor.com/docs](https://www.autopilotmonitor.com/docs)**
+Full admin documentation is available at **[docs.autopilotmonitor.com](https://docs.autopilotmonitor.com)**
+
+## Feedback
+
+Bug reports and feature requests go through [Issues](https://github.com/okieselbach/AutopilotMonitor/issues/new/choose), questions and ideas through [Discussions](https://github.com/okieselbach/AutopilotMonitor/discussions). Security issues are reported privately, see [SECURITY.md](SECURITY.md). For a problem in your own tenant, the **Report Session** button in the portal is the fastest path.
 
 ## License
 
-This project uses a **split licensing model**:
+This project uses a **split licensing model**. The root [LICENSE](LICENSE) is AGPL-3.0, which covers the server-side components; the device-side components carry their own MIT license file:
 
-- **MIT License** — Agent (`src/Agent/`) and Shared library (`src/Shared/`) — unrestricted use on end-user devices
-- **AGPL-3.0** — Backend (`src/Backend/`), Web Dashboard (`src/Web/`), and MCP Server (`src/McpServer/`) — server-side components remain open source
+- **MIT License** — Agent ([`src/Agent/`](src/Agent/LICENSE)) and Shared library ([`src/Shared/`](src/Shared/LICENSE)) — unrestricted use on end-user devices, no copyleft obligations
+- **AGPL-3.0** — Backend ([`src/Backend/`](src/Backend/LICENSE)), Web Dashboard ([`src/Web/`](src/Web/LICENSE)), and MCP Server ([`src/McpServer/`](src/McpServer/LICENSE)) — modifications to server-side components remain open source, especially when deployed as a network service
 
-See [LICENSE](LICENSE) for full details.
+The Shared library is MIT because it is a dependency of the MIT-licensed Agent. The license file inside each component directory is authoritative for that component.

SECURITY.md

@@ -0,0 +1,37 @@
+# Security Policy
+
+## Reporting a vulnerability
+
+Please report security issues **privately** through
+[GitHub Security Advisories](https://github.com/okieselbach/AutopilotMonitor/security/advisories/new).
+Private vulnerability reporting is enabled, so a report reaches the maintainers without ever being public.
+
+Please do not open a public issue, post on social media, or send email for security findings.
+
+## What to expect
+
+- An acknowledgement and an initial severity assessment.
+- A fix or a mitigation plan, with a shared view of timing before anything is disclosed.
+- Credit in the advisory if you want it, and none if you prefer to stay anonymous.
+
+Reports are read by the maintainers directly. There is no guaranteed response time and no bug bounty.
+
+## Scope and rules of engagement
+
+Security research against the hosted service is welcome and is not a violation of the
+[Terms of Use](https://www.autopilotmonitor.com/terms). While testing, please:
+
+- do not access data of tenants you do not own,
+- do not degrade the service for others,
+- do not run automated scanners against production.
+
+## Supported versions
+
+The hosted service always runs the current `main`. For the on-device agent, only the
+[latest release](https://github.com/okieselbach/AutopilotMonitor/releases/latest) receives fixes.
+
+## More
+
+The [Security FAQ](https://docs.autopilotmonitor.com/trust-and-security/security-faq) and
+[Data Flows](https://docs.autopilotmonitor.com/trust-and-security/data-flows) pages describe the security model,
+data handling, and isolation in detail.

build.ps1

@@ -1,166 +0,0 @@
-<#
-.SYNOPSIS
-    Build script for Autopilot Monitor solution.
-
-.DESCRIPTION
-    Builds all .NET projects and optionally the web UI.
-    Run this after cloning or when you want to rebuild everything.
-
-.PARAMETER Configuration
-    Build configuration: Debug or Release (default: Debug)
-
-.PARAMETER IncludeWeb
-    Also build the web UI (requires Node.js)
-
-.PARAMETER Clean
-    Clean before building
-
-.EXAMPLE
-    .\build.ps1
-    Builds all .NET projects in Debug mode
-
-.EXAMPLE
-    .\build.ps1 -Configuration Release -IncludeWeb
-    Builds everything in Release mode including web UI
-#>
-
-[CmdletBinding()]
-param(
-    [ValidateSet("Debug", "Release")]
-    [string]$Configuration = "Debug",
-
-    [switch]$IncludeWeb,
-
-    [switch]$Clean
-)
-
-$ErrorActionPreference = "Stop"
-
-Write-Host "============================================" -ForegroundColor Cyan
-Write-Host " Autopilot Monitor Build Script" -ForegroundColor Cyan
-Write-Host "============================================" -ForegroundColor Cyan
-Write-Host ""
-
-$rootPath = $PSScriptRoot
-$slnPath = Join-Path $rootPath "AutopilotMonitor.sln"
-
-# Check prerequisites
-Write-Host "[1/4] Checking prerequisites..." -ForegroundColor Yellow
-
-# Check .NET SDK
-try {
-    $dotnetVersion = & dotnet --version
-    Write-Host "  ✓ .NET SDK version: $dotnetVersion" -ForegroundColor Green
-}
-catch {
-    Write-Host "  ✗ .NET SDK not found. Please install .NET 10 SDK." -ForegroundColor Red
-    exit 1
-}
-
-# Check Node.js if building web
-if ($IncludeWeb) {
-    try {
-        $nodeVersion = & node --version
-        Write-Host "  ✓ Node.js version: $nodeVersion" -ForegroundColor Green
-    }
-    catch {
-        Write-Host "  ✗ Node.js not found. Please install Node.js 18+." -ForegroundColor Red
-        exit 1
-    }
-}
-
-Write-Host ""
-
-# Clean if requested
-if ($Clean) {
-    Write-Host "[2/4] Cleaning solution..." -ForegroundColor Yellow
-    & dotnet clean $slnPath -c $Configuration
-    Write-Host "  ✓ Clean completed" -ForegroundColor Green
-    Write-Host ""
-}
-else {
-    Write-Host "[2/4] Skipping clean (use -Clean to clean first)" -ForegroundColor Gray
-    Write-Host ""
-}
-
-# Restore packages
-Write-Host "[3/4] Restoring NuGet packages..." -ForegroundColor Yellow
-& dotnet restore $slnPath
-
-if ($LASTEXITCODE -ne 0) {
-    Write-Host "  ✗ Restore failed" -ForegroundColor Red
-    exit 1
-}
-
-Write-Host "  ✓ Restore completed" -ForegroundColor Green
-Write-Host ""
-
-# Build solution
-Write-Host "[4/4] Building solution ($Configuration)..." -ForegroundColor Yellow
-& dotnet build $slnPath -c $Configuration --no-restore
-
-if ($LASTEXITCODE -ne 0) {
-    Write-Host "  ✗ Build failed" -ForegroundColor Red
-    exit 1
-}
-
-Write-Host "  ✓ Build completed" -ForegroundColor Green
-Write-Host ""
-
-# Build web if requested
-if ($IncludeWeb) {
-    Write-Host "[BONUS] Building web UI..." -ForegroundColor Yellow
-    $webPath = Join-Path $rootPath "src\Web\autopilot-monitor-web"
-
-    Push-Location $webPath
-    try {
-        Write-Host "  Installing npm packages..." -ForegroundColor Gray
-        & npm install --silent
-
-        if ($LASTEXITCODE -ne 0) {
-            Write-Host "  ✗ npm install failed" -ForegroundColor Red
-            exit 1
-        }
-
-        Write-Host "  Building Next.js app..." -ForegroundColor Gray
-        & npm run build
-
-        if ($LASTEXITCODE -ne 0) {
-            Write-Host "  ✗ Web build failed" -ForegroundColor Red
-            exit 1
-        }
-
-        Write-Host "  ✓ Web build completed" -ForegroundColor Green
-    }
-    finally {
-        Pop-Location
-    }
-    Write-Host ""
-}
-
-# Summary
-Write-Host "============================================" -ForegroundColor Cyan
-Write-Host " Build Completed Successfully!" -ForegroundColor Green
-Write-Host "============================================" -ForegroundColor Cyan
-Write-Host ""
-Write-Host "Output locations:" -ForegroundColor White
-Write-Host "  Agent:     src\Agent\AutopilotMonitor.Agent.V2\bin\$Configuration\net48\" -ForegroundColor Gray
-Write-Host "  Functions: src\Backend\AutopilotMonitor.Functions\bin\$Configuration\net10.0\" -ForegroundColor Gray
-
-if ($IncludeWeb) {
-    Write-Host "  Web UI:    src\Web\autopilot-monitor-web\.next\" -ForegroundColor Gray
-}
-
-Write-Host ""
-Write-Host "Next steps:" -ForegroundColor White
-Write-Host "  1. Start Azurite: azurite --silent --location c:\azurite" -ForegroundColor Gray
-Write-Host "  2. Start Functions: cd src\Backend\AutopilotMonitor.Functions && func start" -ForegroundColor Gray
-
-if ($IncludeWeb) {
-    Write-Host "  3. Start Web UI: cd src\Web\autopilot-monitor-web && npm run dev" -ForegroundColor Gray
-    Write-Host "  4. Test Agent: cd src\Agent\AutopilotMonitor.Agent.V2\bin\$Configuration\net48 && .\AutopilotMonitor.Agent.exe --console" -ForegroundColor Gray
-}
-else {
-    Write-Host "  3. Test Agent: cd src\Agent\AutopilotMonitor.Agent.V2\bin\$Configuration\net48 && .\AutopilotMonitor.Agent.exe --console" -ForegroundColor Gray
-}
-

docs/agent/autopilot-ztd-diagnostics.md

@@ -1,156 +0,0 @@
----
-type: Reference
-title: Autopilot ZTD Diagnostics — Event IDs, Registry Surfaces, Endpoints, Error Codes
-description: Windows' own diagnostic surfaces for the Autopilot profile-download (ZTD) flow and known deployment error codes — what the agent reads, what each identifier means, and where the knowledge comes from.
-resource: /src/Agent/AutopilotMonitor.Agent.V2.Core/Monitoring/Telemetry/DeviceInfo/ZtdEvidence.cs
-tags:
-  - agent
-  - autopilot
-  - ztd
-  - diagnostics
-  - event-log
-  - troubleshooting
-timestamp: 2026-07-16T00:00:00+02:00
----
-
-# Autopilot ZTD Diagnostics
-
-Windows documents its own diagnostic surfaces for the Autopilot profile-download flow
-(the Zero-Touch Deployment / "ZTD" service round-trip during OOBE). The agent consumes
-three of them to turn the `autopilot_profile_missing` warning from a guess into an
-evidence-backed verdict, and the backend rule engine uses the error-code map for
-known-issue enrichment.
-
-Consumers in this repo:
-
-* `ZtdEvidence.cs` (agent) — one-shot event-log query + `Diagnostics\Autopilot` registry
-  dump + deployment-service reachability probe on the profile-missing path.
-* `ModernDeploymentTracker.cs` (agent) — continuous watcher of the same channel,
-  Level ≤ 3 only (Warning/Error/Critical) plus targeted Info IDs.
-* Analyze rules (backend) — HRESULT/known-issue map (see [Error codes](#schema--error-codes)).
-
-# Schema — ModernDeployment Autopilot event channel
-
-Channel: `Microsoft-Windows-ModernDeployment-Diagnostics-Provider/Autopilot`
-(Event Viewer: Application and Services Logs → Microsoft → Windows →
-ModernDeployment-Diagnostics-Provider → Autopilot).
-
-| Event ID | Level | Meaning | Agent verdict mapping (`ztdVerdict`) |
-| --- | --- | --- | --- |
-| 100 | Warning | "Autopilot policy [name] not found" — temporary, device is waiting for the profile download. Windows can log hundreds of these per minute (harmless-rollup in `ModernDeploymentTracker`). | `waiting_for_profile_no_internet_confirmation` (when nothing else was logged) |
-| 101/103/109/111 | Info | Profile settings retrieval/processing details. | not queried |
-| 153 | Info | `ProfileState_Unknown → ProfileState_Available` — a profile was downloaded and is ready. | `profile_downloaded` |
-| 160 | Info | Profile settings acquisition beginning. | context only |
-| 161 | Info | Profile download succeeded. | `profile_downloaded` |
-| 163 | Info | Download not required — device already provisioned (typically after `Sysprep /Generalize`, i.e. Autopilot-for-existing-devices images). | `already_provisioned` |
-| 164 | Info | Internet available to attempt policy download — the authoritative witness that the ZTD round-trip could run at OOBE time. | with no 161: `download_attempted_no_profile_returned` (the assignment-gap signature, session 423b5360) |
-| 171 | Error | TPM identity confirmation failed (HRESULT in payload) — self-deploying/pre-prov attestation. | context only (`inconclusive` if alone) |
-| 172 | Error | Failed to set profile as available — usually follows 171. | context only |
-| 807 | Error | `ZtdDeviceIsNotRegistered` — hardware hash not registered in Autopilot. | `device_not_registered` |
-| 809 | Error | `ZtdDeviceHasNoAssignedProfile` — the assigned profile was deleted without cleanup. | `assigned_profile_deleted` |
-| 815 | Error | `ZtdDeviceHasNoAssignedProfile` — no profile assigned and no tenant default profile. | `no_profile_assigned` |
-| 908 | Error | `SerialNumberMismatch` / `ProductKeyIdMismatch` between Autopilot registration and physical hardware. | `serial_or_product_key_mismatch` |
-
-Verdict priority: error IDs are authoritative (807 → 908 → 809 → 815), then the Info-flow
-reconstruction (161/153 → 163 → 164 → 100). Implemented in
-`ZtdEvidence.ComputeZtdVerdict`, pinned by `ZtdEvidenceVerdictTests`.
-
-# Schema — Diagnostics registry key
-
-`HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot` — written by the ZTD client,
-dumped verbatim by the agent into the `autopilot_profile` event (`diagnosticsRegistry`):
-
-| Value | Meaning |
-| --- | --- |
-| `AadTenantId` | GUID of the tenant the user signed into. |
-| `CloudAssignedTenantDomain` | Tenant the device is registered with; **blank = not registered with Autopilot**. |
-| `CloudAssignedTenantId` | GUID matching `CloudAssignedTenantDomain`; blank when not registered. |
-| `IsAutopilotDisabled` | 1 = device not registered **or** profile download failed (network/firewall/timeout) — Microsoft's own catch-all indicator. **Casing caveat:** Windows actually writes `IsAutoPilotDisabled` (capital P; observed session e7dbac7a, 24H2) while the FAQ documents `IsAutopilotDisabled` — all agent lookups are case-insensitive for this reason. |
-| `TenantMatched` | 0 = user's tenant ≠ registration tenant → the "username belongs to another organization" OOBE error. |
-| `CloudAssignedOobeConfig` | Bitmap of configured OOBE settings (SkipCortanaOptIn=1, OobeUserNotLocalAdmin=2, SkipExpressSettings=4, SkipOemRegistration=8, SkipEula=16). |
-
-The profile cache itself lives in `HKLM\SOFTWARE\Microsoft\Provisioning\AutopilotPolicyCache`
-(`PolicyJsonCache`, `ProfileAvailable`) — `ProfileAvailable=0` plus an empty
-`ZeroTouchConfig` is the "blank profile cached" state the troubleshooting FAQ describes
-when no profile exists at check time. A reboot re-runs the download and can replace the
-blank cache.
-
-# Schema — Endpoints
-
-| Endpoint | Purpose | Agent behavior |
-| --- | --- | --- |
-| `https://ztd.dds.microsoft.com` | Autopilot Deployment Service — profile delivery during OOBE. | Reachability probe on profile-missing (any HTTP status = reachable). **Note:** several third-party blogs cite `ztd.ssd.microsoft.com`; the official requirements page says `ztd.dds.microsoft.com`. |
-| `https://login.live.com` | Second Deployment-Service URL; also needed by the Microsoft Sign-in Assistant (`wlidsvc`) — a policy that disables wlidsvc breaks profile download. | not probed |
-| `*.microsoftaik.azure.net` (+ per-vendor EK cert URLs) | TPM attestation for self-deploying/pre-provisioning. | not probed |
-| `lgmsapeweu.blob.core.windows.net` | Intune automatic diagnostics upload. | deliberately not probed (decision 2026-07-16: not mission-critical) |
-
-# Observability — when the agent can actually see these errors
-
-The agent's install timing bounds what the known-issue rules can ever observe. In the
-normal deployment model the agent is installed by an **Intune platform script via IME —
-i.e. only AFTER MDM enrollment succeeded**. Everything that happens before that point
-(profile download, TPM attestation in self-deploying/pre-provisioning, the MDM enrollment
-handshake itself) is over before our process exists.
-
-| Failure class | Normal flow (IME install) | Bootstrap token mode | Await-enrollment mode |
-| --- | --- | --- | --- |
-| Enrollment blocked (0x80180014/18, 0xC1036501, 0x801C03F3 → ANALYZE-ENRL-004) | **Invisible** — no enrollment ⇒ no agent, no session. | **Visible** — the bootstrap token exists precisely to report pre-MDM (as of 2026-07: one customer piloting). | **Invisible to the backend** — the agent binary is present but only polls for the MDM certificate; without the cert it cannot authenticate, and monitoring starts only after the cert appears. A hard blocker ends in the await timeout (default 480 min) with nothing uploaded. |
-| TPM attestation (ANALYZE-ENRL-003) | **Visible via error backfill** — attestation precedes enrollment, but the startup error backfill (below) replays Autopilot-channel Level 1-2 records from the last 4h, so retry-then-success attempts surface as `backfilled=true` events. | Visible. | Visible via error backfill once monitoring starts. |
-| Hybrid-join 0x80004005 (ANALYZE-ENRL-005) | **Visible** — the ODJ/hybrid phase runs during device ESP while the agent is active. | Visible. | Visible after cert arrival. |
-| Clock skew (ANALYZE-DEV-007) | **Always** — ntp_time_check is our own event. | Always. | Always. |
-
-The rules stay enabled despite the narrow normal-flow windows: they are evidence-gated
-(zero cost when the codes never appear) and they future-proof the bootstrap and
-await-enrollment paths.
-
-## Startup error backfill (ModernDeploymentTracker)
-
-At agent start (backfill enabled), the tracker replays Autopilot-channel **Level 1-2**
-records from the last **4 hours** through the normal emission pipeline — this is what makes
-pre-install errors (TPM attestation retries, ZTD errors 807/809/815/908) visible in the
-normal IME deployment flow. Spam containment, in order:
-
-1. **Errors only** — the Warning-level 100 heartbeat storm is excluded by the XPath.
-2. **Harmless-ID downgrade + burst rollup** still applies to backfilled records.
-3. **Cap** of 25 records per scan (newest first; the tail is logged, not emitted).
-4. **RecordId watermark** (`autopilot-error-backfill.json`, advanced by both the backfill
-   scan and the live watcher) — restarts never re-emit records a previous run forwarded.
-5. Backfilled events carry `backfilled: true` plus the original `timeCreated` in their
-   payload; the event's own timestamp is the emission time, so the session's `StartedAt`
-   (which the backend aligns to the earliest event) is not dragged backwards.
-
-# Schema — Error codes (backend known-issue map)
-
-Codes documented in the known-issues / troubleshooting-FAQ pages that appear in ESP/enrollment
-failures we can observe:
-
-| Code | Meaning / context | Actionable guidance |
-| --- | --- | --- |
-| `0x800705B4` | Timeout; in self-deploying mode usually "device is not TPM 2.0 capable" (e.g. a VM). | Don't use self-deploying on VMs / non-TPM-2.0 hardware. |
-| `0x801C03EA` | TPM attestation failed → Entra join with device token failed. | TPM/firmware issue; check attestation endpoints. |
-| `0x81039001` | `E_AUTOPILOT_CLIENT_TPM_MAX_ATTESTATION_RETRY_EXCEEDED` (intermittent, "Securing your hardware"). | Retry provisioning; persistent → firmware. |
-| `0x81039023` | TPM attestation failure on Windows 11 (pre-prov/self-deploy). | Fixed by KB5013943 (21H2) or later CU. |
-| `0x81039024` | TPM has known vulnerabilities → attestation refused. | Update TPM firmware from OEM. |
-| `0x80070490` | TPM attestation failure on AMD ASP fTPM platforms. | Update AMD firmware. |
-| `0xC1036501` | Automatic MDM enrollment impossible — multiple MDM configurations in Entra ID. | Consolidate MDM configs. |
-| `0x801C03F3` | Entra device object for the Autopilot device was deleted (logged in `Microsoft-Windows-User Device Registration/Admin`). | Deregister + re-register the device (recreates the object). |
-| `0x80180014` | Device-record reuse in self-deploying/pre-prov mode, or Windows MDM enrollment disabled ("Enrollment blocked for AP device by SDM One Time Limit Check"). | Intune → Autopilot device → **Unblock device**, or allow Windows (MDM) in enrollment restrictions. |
-| `0x80180018` | MDM enrollment refused — licensing (missing Intune/EMS license) or device cap. | Check user license + device limits. |
-| `0x80070774` | Hybrid-join ESP failure — domain mismatch between Intune Connector for AD and device targeting. | Install/configure the connector in the matching domain. |
-| `0x80004005` | Hybrid-join deployment timeout — **build-dependent known issue**, fixed in KB5065789 (25H2, ≥ 26200.6725), KB5065426 (24H2, ≥ 26100.6584), KB5070312 (23H2, ≥ 22631.6276). | Update the image / install the KB. |
-
-Related non-code known issues worth remembering: clock skew of minutes causes TPM
-attestation errors and ESP timeouts (`w32tm /resync /force`; the agent's `ntp_time_check`
-event carries the measured offset); multiple/unexpected OOBE reboots can delete kiosk
-autologon registry entries (fixed in 24H2 KB5058411); ESP does not support mixing LOB and
-Win32 apps ("Another installation is in progress").
-
-# Citations
-
-* [Windows Autopilot troubleshooting FAQ](https://learn.microsoft.com/en-us/autopilot/troubleshooting-faq) — event IDs, registry values, process flow. (Checked 2026-07-16.)
-* [Windows Autopilot known issues](https://learn.microsoft.com/en-us/autopilot/known-issues) — error codes, KB fixes. (Checked 2026-07-16.)
-* [Windows Autopilot requirements — Networking](https://learn.microsoft.com/en-us/autopilot/requirements?tabs=networking) — endpoint list incl. `ztd.dds.microsoft.com`. (Checked 2026-07-16.)
-* Re-check cadence: both Learn pages change regularly (known-issues carries an RSS feed:
-  `https://learn.microsoft.com/api/search/rss?search=%22Be+informed+about+known+issues+that+might+occur+during+Windows+Autopilot+deployment.%22&locale=en-us&%24filter=`).
-  When new event IDs / error codes appear, update `ZtdEvidence.cs`, the backend rule map,
-  and this document together.

docs/agent/build-counter-blob.md

@@ -1,68 +0,0 @@
----
-type: Concept
-title: Agent Build Numbers — Shared Counter Blob with ETag-CAS
-description: Why agent build numbers come from a public counter blob reserved before the build, how the compare-and-swap protocol works, and what the repo's buildcounter.txt still does.
-resource: /.github/workflows/build-agent.yml
-tags:
-  - agent
-  - build
-  - ci
-  - release
-  - versioning
-timestamp: 2026-07-17T00:00:00+02:00
----
-
-# Agent Build Numbers — Shared Counter Blob
-
-Agent (V2 line) build numbers — the `<n>` in `2.0.<n>` — are minted from a single
-shared counter blob so that **local builds (`scripts/Deployment/build.ps1`) and CI
-builds (`.github/workflows/build-agent.yml`) can never collide**. Both build paths
-stay first-class: local daily-ops builds remain possible, CI builds add provenance
-attestation on top.
-
-# Schema
-
-- **Counter blob**: `https://autopilotmonitor.blob.core.windows.net/agent/buildcounter-v{LINE}.txt`
-  (per release line, analogous to `version-v{LINE}.json`). Content: the **last used**
-  build number as plain text. Public-read like the rest of the container (the number
-  is visible in `version-v{LINE}.json` anyway); writes require the container SAS.
-- **Protocol — reserve before build, ETag-CAS**:
-  1. Anonymous `GET` the blob, capture value `N` and the `ETag`.
-  2. `PUT N+1` with `If-Match: <etag>` (quoted form — pwsh strips the quotes on read,
-     they must be re-added or the request is rejected client-side).
-  3. `412 Precondition Failed` → another build reserved concurrently → re-read, retry
-     (5 attempts, linear backoff).
-  4. Build with `BUILD_NUMBER=N+1` in the environment. The csproj honors
-     `BUILD_NUMBER` and then skips its `PersistBuildCounter` target, so the repo file
-     is not touched.
-- **Failed builds burn a number.** That is intentional: uniqueness matters, density
-  does not. Reserve-before-build is what makes concurrent minting impossible.
-- **CI manual override** (`build_number` input): numbers `<=` counter are re-builds
-  and leave the blob unchanged; numbers `>` counter advance it (monotonic guard).
-- **Seeding** (one-time per line): `PUT <last used number>` with `If-None-Match: *`
-  so an existing counter can never be clobbered. V2 was seeded with `1356` on
-  2026-07-17.
-
-# Consequences
-
-- `src/Agent/AutopilotMonitor.Agent.V2/buildcounter.txt` is now only an **offline
-  fallback** for `-SkipUpload` smoke builds and bare `dotnet build` (where the version
-  does not matter). It is never committed anymore; the CI step that pushed counter
-  bumps to `main` was removed.
-- `AdminConfiguration.LatestAgentV2*` (backend hash-oracle) is updated **only on
-  stable cutover** (`publish_as_stable` / default `build.ps1` run without
-  `-VersionedOnly`/`-Dev`) — it must never point at a build that is not actually in
-  the stable namespace.
-- CI builds additionally attest build provenance for the release ZIP via
-  `actions/attest-build-provenance` (Sigstore keyless, bound to the workflow OIDC
-  identity). The digest covers the identical bytes uploaded to blob, so one
-  attestation covers all copies. Verify:
-  `gh attestation verify <zip> --repo okieselbach/AutopilotMonitor`. Local builds
-  cannot produce this attestation — provenance is a CI-only property.
-
-# Citations
-
-- `.github/workflows/build-agent.yml` — "Reserve build number (counter blob CAS)" step
-- `scripts/Deployment/build.ps1` (gitignored, contains SAS) — `Request-BuildNumber`
-- `src/Agent/AutopilotMonitor.Agent.V2/AutopilotMonitor.Agent.V2.csproj` —
-  `BUILD_NUMBER` property + `PersistBuildCounter` target

docs/agent/decision-engine.md

@@ -1,187 +0,0 @@
----
-type: Reference
-title: V2 Agent — Decision Engine (DecisionCore)
-description: The pure-reducer state machine that decides enrollment completion/failure — signals, state, effects, the A/B/C completion arms, and its invariants.
-resource: /src/Shared/AutopilotMonitor.DecisionCore
-tags:
-  - agent
-  - decision-engine
-  - reducer
-  - completion
-timestamp: 2026-07-11T00:00:00+02:00
----
-
-# V2 Agent — Decision Engine (DecisionCore)
-
-DecisionCore (`src/Shared/AutopilotMonitor.DecisionCore`, netstandard2.0) is a **pure
-reducer**: a deterministic state machine with no I/O, no clock reads, no threads. The
-agent feeds it an ordered stream of *signals*; it returns a new immutable state plus a
-list of *effects* the host must execute. Because it is pure, the same persisted signal
-stream always reproduces the same journal and terminal outcome — that is what makes
-crash recovery a replay instead of a guess (determinism guarantee "L.5",
-`Engine/IDecisionEngine.cs`).
-
-# The reducer contract
-
-```
-DecisionStep step = engine.Reduce(DecisionState oldState, DecisionSignal signal)
-// DecisionStep = { NewState, Transition, Effects[] }
-```
-
-- `Reduce` never throws: a handler exception advances only bookkeeping and journals a
-  `reducer_exception` dead-end (fail-safe L.16).
-- Dispatch is a switch on `(signal.Kind, signal.KindSchemaVersion)`; unknown pairs
-  become journaled dead-ends, never crashes.
-- Every step yields a `DecisionTransition` journal record: `Taken` (state change vs
-  dead-end + reason), `StepIndex`, `FromStage/ToStage`, `Trigger`, `Guards`,
-  `ReducerVersion`.
-
-# State
-
-`DecisionState` (schema **v4**) is an immutable value object; "change" = builder copy.
-Key content:
-
-- Identity + progress: `SessionId`, `TenantId`, `Stage`, `Outcome`, `StepIndex`,
-  `LastAppliedSignalOrdinal`, `AgentBootUtc` (replay-safety anchor).
-- **Facts** as `SignalFact<T>` — value **plus** `SourceSignalOrdinal` provenance, e.g.
-  `AccountSetupEnteredUtc`, `EspFinalExitUtc`, `DesktopArrivedUtc`, `HelloResolvedUtc`,
-  `ImeUserSessionCompletedUtc`, `HelloPolicyEnabled`, `HelloOutcome`.
-- Aggregates: `AppInstallFacts`, `ScenarioProfile` + `ScenarioObservations`
-  (enrollment-scenario classification, monotonic), `ClassifierOutcomes`, `RealmJoinFacts`.
-- `Deadlines` — active timers the host has been asked to arm.
-
-Stages: `SessionStarted → EspDeviceSetup → EspAccountSetup → AwaitingHello →
-AwaitingDesktop → Finalizing → Completed` (plus `Failed`, `WhiteGloveCandidate/Sealed`,
-`AwaitingDeviceOnlyEsp` for self-deploying, and edge stages). Terminal =
-`Completed | Failed | WhiteGloveSealed`. `Finalizing` is deliberately non-terminal
-(grace window). Outcomes: `EnrollmentComplete`, `EnrollmentFailed`,
-`WhiteGlovePart1Sealed`, `Aborted`, `AdminPreempted`.
-
-# Signals
-
-`DecisionSignal` is the only input. Fields: `Kind` + `KindSchemaVersion` (dispatch key),
-`SessionSignalOrdinal` (monotonic, assigned **only** by the ingress worker — never by
-collectors), `OccurredAtUtc`, mandatory `Evidence` (classified `Raw | Derived |
-Synthetic` — a signal without evidence is a bug), `Payload` (string dict) and
-`TypedPayload` (structured sidecar).
-
-Signal kinds by family (`Signals/DecisionSignalKind.cs`):
-
-- **Raw observations**: `EspPhaseChanged`, `EspExiting`, `EspResumed`,
-  `EspTerminalFailure`, `DesktopArrived`, `HelloResolved`, `ImeUserSessionCompleted`,
-  `DeviceSetupProvisioningComplete`, `AccountSetupProvisioningComplete`,
-  `AppInstallCompleted/Failed`, `AadUserJoinedLate`, `SystemRebootObserved`,
-  `EspConfigDetected`, `HelloPolicyDetected`, WhiteGlove + RealmJoin kinds, …
-- **Synthetic**: `DeadlineFired` (scheduler timer), `ClassifierVerdictIssued`,
-  `EffectInfrastructureFailure`.
-- **Lifecycle**: `SessionStarted`, `SessionAborted`, `AdminPreemptionDetected`.
-- **`InformationalEvent`** — the single-rail pass-through: telemetry that must appear
-  on the Events timeline but never influences decisions.
-
-**Ordering is the ingest ordinal, never wall-clock.** Replayed IME/CMTrace lines carry
-backdated source timestamps; all before/after comparisons in the reducer therefore
-compare `SourceSignalOrdinal`s (e.g. "final exit after AccountSetup entry").
-
-# Effects — the only side-channel
-
-`DecisionEffect` kinds and how the host's `EffectRunner` treats failures:
-
-| Kind | Purpose | Failure class |
-| --- | --- | --- |
-| `ScheduleDeadline` / `CancelDeadline` | arm/cancel OS timers that come back as `DeadlineFired` | **critical** — failure aborts the session (a lost timer means silent parking) |
-| `EmitEventTimelineEntry` | timeline events incl. terminal `enrollment_complete` / `enrollment_failed` | transient — retried 100/400/1600 ms |
-| `PersistSnapshot` | hint to write the recovery snapshot | transient |
-| `RunClassifier` | scenario classification; verdict returns as a `ClassifierVerdictIssued` signal | optional — exception ⇒ Inconclusive, never aborts |
-
-Terminal and state-changing timeline effects carry a structured **audit trail** in
-`TypedPayload` (built by `DecisionAuditTrailBuilder`): `decisionSource`, `trigger`,
-`sessionStage`, `stepIndex`, `signalsSeen`, `signalEvidence`, `signalTimestamps`,
-`scenario` — so every completion/failure in the portal is explainable from its own
-event payload.
-
-# Completion logic
-
-## The A/B/C arms
-
-The arms are **not** three pipelines — they are three alternative sufficient conditions
-inside one guard, `ShouldTransitionToAwaitingHello`
-(`Engine/DecisionEngine.Shared.cs`), which gates promotion out of the ESP stages toward
-Hello/desktop completion:
-
-- **Arm A — registry-strong AccountSetup success**: `AccountSetupProvisioningSucceededUtc`
-  is set (the ESP registry reported `categorySucceeded`). Merely *entering* AccountSetup
-  is insufficient — Shell-Core 62407 fires at every ESP page transition.
-- **Arm B — SkipUser flow**: `ScenarioObservations.SkipUserEsp == true` — with no
-  User-ESP page, the first `esp_exiting` *is* the genuine final exit.
-- **Arm C — 4-fact eager completion** (all four mandatory):
-  1. AccountSetup was entered, and
-  2. a post-AccountSetup ESP final exit occurred (ordinal-ordered), and
-  3. a *genuine* IME user-session completion (at-or-after the AccountSetup anchor —
-     guards against the `defaultuser0` ghost), and
-  4. a DAD-validated real-user desktop arrival.
-  Arm C applies eagerly the same conjunction the 30-minute `AdvisoryCompletion`
-  backstop would eventually trust.
-
-**Layering note:** Arm C's app-install hardening lives in the **adapter**, not the
-reducer. `ImeLogTrackerAdapter` defers posting `ImeUserSessionCompleted` while required
-user-ESP Install-intent apps are still pending (IME logs "Completed user session" per
-*pass*, not once per session — sessions 14690fc2/6cb01530). The reducer stays free of
-app-pending guards; adapters sanitize evidence before it becomes a signal.
-
-## Completion attempt sites and sequence
-
-Completion can be attempted from whichever fact arrives last: `HelloResolved`,
-`DesktopArrived` (including the Hello-disabled fast-path when `HelloPolicyEnabled ==
-false` and an arm holds), `EspExiting`, `ImeUserSessionCompleted`,
-`AccountSetupProvisioningComplete`, the Hello safety deadline, or the 30-minute
-advisory backstop. All routes converge on `CompleteThroughFinalizingOrDefer`:
-
-1. **Completion gates** (currently only the RealmJoin AND-gate): if RealmJoin was
-   detected and is neither resolved nor timed-out (hard 60-min timeout), completion is
-   *deferred* — the session stays in stage and emits `completion_waiting`.
-2. `Finalizing` stage + ~5 s `FinalizingGrace` deadline.
-3. Grace fires → `Completed`, `EnrollmentComplete` outcome, `enrollment_complete`
-   timeline event with full audit payload.
-
-**Self-deploying/kiosk** is a separate rail: no Hello, no user desktop —
-`AwaitingDeviceOnlyEsp` with a detection deadline as the sole terminal entry, protected
-by stale-fire and race guards. A registry-confirmed self-deploying profile also waives
-IME false-positive AccountSetup entries.
-
-# Invariants (violating any of these is a bug)
-
-- **Post-terminal dispatch guard**: after `Completed`/`Failed`, every signal is a
-  bookkept dead-end — **except `InformationalEvent`** (single-rail pass-through must
-  keep flowing). `WhiteGloveSealed` is unguarded on purpose (Part 2 resumes fresh).
-- **`InformationalEvent` never mutates decision state** — exactly one pass-through
-  timeline effect, payload copied 1:1.
-- **`AadUserJoinedLate` is observation-only** — never completion evidence.
-- **Hello policy is orthogonal to completion** — `HelloPolicyEnabled` tunes wait
-  cadence, never gates the outcome.
-- **Raw IME "Completed user session" is weak evidence** — can run under `defaultuser0`;
-  only meaningful with a real-user desktop and the AccountSetup anchor (Arm C).
-- **Deadline bases are floored at `AgentBootUtc`** — replayed backdated signals must
-  not arm past-due timers at boot.
-- **Reducer-side deadline cancels need an explicit `CancelDeadline` effect** — a
-  builder-only removal leaves the OS timer live.
-- **No silent parking**: a non-terminal post-AccountSetup session must always hold a
-  resolution-capable deadline; a 10-min dwell tripwire emits
-  `session_parked_without_deadline`.
-
-# Hosting & threading (inside the agent)
-
-Wired by `EnrollmentOrchestrator.Start` (`src/Agent/AutopilotMonitor.Agent.V2.Core/Orchestration/`):
-
-- `SignalIngress` — bounded queue (256, back-pressure) + **one** worker thread. Per
-  signal, in order: assign ordinals → `SignalLog.Append` (durable, *before* reducing;
-  append failure ⇒ reducer does not run, no ordinal gap) → `engine.Reduce` →
-  `DecisionStepProcessor.ApplyStep`.
-- `DecisionStepProcessor.ApplyStep` (same thread, no locks): journal append (the only
-  hard-throwing path; 3 consecutive failures escalate to quarantine) → effects run
-  synchronously via `EffectRunner` → best-effort snapshot → advance `CurrentState` →
-  one-shot terminal-stage hook (raises the agent's `Terminated` event off-thread).
-- The `DeadlineScheduler`'s `Fired` event loops back in as synthetic `DeadlineFired`
-  signals.
-- On restart, `RecoveryCoordinator` folds the persisted signal log through a transient
-  `new DecisionEngine()` before the live pipeline starts — see
-  [logs & persistence](logs-and-persistence.md).

docs/agent/endpoint-migration.md

@@ -1,88 +0,0 @@
----
-type: Concept
-title: Agent Endpoint Migration — Config-Channel Re-Home
-description: How the backend re-homes agents to a new API base URL (backend move or per-tenant region move) via MigrateToApiBaseUrl on the agent config response, and why HTTP redirects were rejected.
-resource: /src/Agent/AutopilotMonitor.Agent.V2.Core/Configuration/EndpointMigration.cs
-tags:
-  - agent
-  - backend
-  - config
-  - migration
-  - security
-timestamp: 2026-07-18T00:00:00+02:00
----
-
-# Problem
-
-The agent's API base URL is compiled into the binary (`Constants.ApiBaseUrl`). No DNS/domain
-indirection is possible in front of the API: mTLS client-cert auth does not survive a reverse
-proxy (Front Door), and Flex Consumption custom-domain TLS is broken. A backend move (like the
-2026-07-18 WEU→GWC subscription migration) therefore hard-cuts every deployed agent still
-pointing at the old hostname. In-flight agents self-terminate safely (local MaxLifetime watchdog
-+ CleanupService), but their sessions are lost and a per-tenant region move (EU→US) has no
-mechanism at all.
-
-# Mechanism
-
-`AgentConfigResponse.MigrateToApiBaseUrl` — served on `GET /api/agent/config` (incl. the
-bootstrap wrapper), the same control channel as the kill switch, fetched at every agent
-process start.
-
-Agent flow (`Program.RunAgent`, Phase 4):
-
-1. Config fetched from the compiled-in (old) base URL.
-2. Kill-switch check runs FIRST — **kill wins over migrate**.
-3. `AgentRuntimeConfig.Resolve` detects the migration signal directly after the fetch and
-   returns early, BEFORE merge / binary-integrity / bootstrap-cleanup — none of those side
-   effects may run against a config from the backend being abandoned (a migration stub may
-   advertise stale agent hashes; a spurious `IntegrityCheckFailed` + force-update would be
-   harmful).
-4. `Program.RunAgent` swaps `AgentConfiguration.ApiBaseUrl`, disposes the old client stack,
-   rebuilds Phase 3 (auth clients) and re-runs Phase 4 against the new URL —
-   `allowEndpointMigration: false`, so the new backend's config **cannot chain a second hop**.
-5. Kill-switch check runs again on the NEW backend's config; startup continues normally
-   (Phase 5+ builds mTLS/telemetry clients from the updated base URL).
-
-# Hardening (mirrors the kill switch)
-
-* **Live fetch only** — the on-disk config cache strips `MigrateToApiBaseUrl` on write AND
-  read (`RemoteConfigService.CacheConfig` / `LoadCachedConfig`); `EndpointMigration.ResolveTarget`
-  re-checks `LastFetchOutcome == Succeeded` as defence-in-depth. A planted cache file can
-  never re-home an agent.
-* **Allowlist validated on BOTH sides** — `AgentEndpointMigrationRules` (Shared, single
-  source): https only, host must end in `.azurewebsites.net` on a label boundary, no
-  path/query/userinfo/port. The backend refuses to serve an invalid admin value
-  (`AgentMigrateRejected` warning); the agent refuses to honour one even if the backend was
-  compromised.
-* **One hop, no loops** — second Resolve pass never migrates; a target equal to the current
-  base URL is a no-op (steady state during the migration window).
-
-# Operation
-
-Global admin settings (`AdminConfiguration`, admin portal → Global Settings):
-
-* `AgentMigrateApiBaseUrl` — global target, set on the backend being **abandoned**; clear it
-  after the migration window.
-* `AgentMigrateTenantOverridesJson` — JSON object `tenantId → URL` for per-tenant moves.
-  An entry with an **empty string** pins that tenant against the global target (staged rollout).
-  Overrides win over the global value.
-
-Delivery evidence: every served target logs `AgentMigrateServed` (Warning — reaches App
-Insights) with tenant, serial, agent version and target. Agent-side, the re-home is logged as
-`Endpoint migration: backend re-homed this agent from … to …`.
-
-Reach limitation: agents that cannot complete an authenticated config fetch (e.g. cert-broken
-devices) never see the signal — they fall back to the local MaxLifetime/emergency-break
-lifecycle. During a migration window the old backend must keep running as a serving stub;
-keeping the old `*.azurewebsites.net` name parked afterwards also prevents hostname
-re-registration by third parties while stragglers drain.
-
-# Citations
-
-* `src/Shared/AutopilotMonitor.Shared/Services/AgentEndpointMigrationRules.cs` — shared validation rules
-* `src/Shared/AutopilotMonitor.Shared/Models/Config/AgentConfigResponse.cs` — wire field
-* `src/Backend/AutopilotMonitor.Functions/Functions/Config/GetAgentConfigFunction.cs` — `ResolveMigrateTarget` + serving (ConfigVersion 33)
-* `src/Agent/AutopilotMonitor.Agent.V2.Core/Configuration/EndpointMigration.cs` — agent-side evaluation
-* `src/Agent/AutopilotMonitor.Agent.V2/Runtime/AgentRuntimeConfig.cs` — early return before merge/integrity
-* `src/Agent/AutopilotMonitor.Agent.V2/Program.cs` — one-hop rebuild in `RunAgent`
-* Tests: `AgentEndpointMigrationTests` (backend), `EndpointMigrationTests` + `RemoteConfigServiceCacheHardeningTests` (agent)

docs/agent/hello-wizard-unskip.md

@@ -1,108 +0,0 @@
----
-type: Concept
-title: Hello Wizard Un-Skip — vetoing the policy-disabled Hello shortcut
-description: Why a single "WHfB disabled" policy read is not trusted for completion decisions — the HelloWizardStarted signal (prevention + cure) and the HelloTracker confirmation second read.
-resource: /src/Shared/AutopilotMonitor.DecisionCore
-tags:
-  - agent
-  - decision-engine
-  - hello
-  - completion
-  - whfb
-timestamp: 2026-07-13T00:00:00+02:00
----
-
-# Hello Wizard Un-Skip
-
-Session `772fe502` (2026-07-13) completed as *Succeeded* while the user was inside the
-Windows Hello wizard. Cause: the user-scoped WHfB CSP value
-(`HKLM\SOFTWARE\Microsoft\Policies\PassportForWork\{tenant}\{scope}\Policies\UsePassportForWork`)
-**flip-flops** during User-ESP while Intune policy sync is still writing. A single read
-caught "disabled", the engine set `HelloPolicyEnabled=false` (set-once, poll stops), and
-the arm-C completion synthesized `HelloOutcome="Skipped"` → 5 s `finalizing_grace` →
-`enrollment_complete` — 230 ms *after* Shell-Core event 62404 (CXID `AADHello`) proved
-the wizard had launched. The wizard-start was previously an `InformationalEvent` only
-(timeline pass-through, no state mutation).
-
-Two independent defense layers fix this:
-
-# Layer 1 — `DecisionSignalKind.HelloWizardStarted` (engine)
-
-Shell-Core 62404 with CXID `AADHello`/`NGC` is a **genuine wizard-lifecycle observation**
-(unlike the unreliable `hello_provisioning_willlaunch` registry snapshot). It is now a
-dedicated signal: `ShellCoreTracker.HelloWizardStarted` event → coordinator forward
-(`EspAndHelloTracker`, timestamp mirror) → `EspAndHelloTrackerAdapter` (fire-once) →
-reducer. The startup backfill also replays 62404 (5-min lookback), so an agent restart
-mid-wizard does not lose the observation. The reducer records the set-once fact
-`DecisionState.HelloWizardStartedUtc`.
-
-**Prevention** — every "may policy-disabled stand in for a Hello resolution?" decision
-routes through one predicate (`DecisionEngine.Completion.cs`):
-
-```
-HelloPolicyDisabledWithoutWizard = HelloPolicyEnabled == false && HelloWizardStartedUtc == null
-HelloSatisfiedForCompletion     = HelloResolvedUtc != null || HelloPolicyDisabledWithoutWizard
-```
-
-Once a wizard start is on record, the policy-disabled shortcut is vetoed at all five
-Skipped-synthesis sites (EspExiting DeferredCompletion, DesktopArrived fast-path,
-ImeUserSessionCompleted arm-C, AdvisoryCompletion deadline, AccountSetupProvisioningComplete
-DeferredCompletion) *and* in the `completion_waiting` missing-prerequisites computation.
-Sessions then take their pessimistic path: promote to `AwaitingHello` + arm HelloSafety
-(300 s). The AdvisoryCompletion handler needed a dedicated
-`HelloWizardObservedPromote` branch — its fallthrough is re-arm-or-**fail**, and
-prevention alone would have failed a live-wizard session there.
-
-**Cure** — `HandleHelloWizardStartedV1` (`DecisionEngine.Classic.cs`): when the state
-already carries the engine-synthesized skip, the handler retracts it — cancel
-`finalizing_grace` (if armed), null `HelloResolvedUtc`/`HelloOutcome`, back to
-`AwaitingHello`, arm HelloSafety, emit `completion_waiting` (trigger
-`HelloWizardStarted:UnSkip`). A real `HelloResolved` — or the HelloSafety timeout —
-then decides the session.
-
-Two deliberate design points:
-
-1. **Synthetic-outcome discriminator.** The engine's synthesized outcomes are exact-case
-   `"Skipped"` / `"Timeout"` (constants `SyntheticHelloOutcomeSkipped`/`...Timeout`);
-   the tracker vocabulary is all-lowercase (`completed`, `skipped`, `not_configured`,
-   `timeout`, `wizard_not_started`). The cure only ever retracts the exact-case
-   `"Skipped"` — tracker-posted resolutions and the deliberate HelloSafety `"Timeout"`
-   are never touched.
-2. **First fact-nulling reducer.** DecisionState facts are otherwise set-once/monotonic.
-   The retraction is legal exactly here because the fact is provably engine-synthesized
-   and provably wrong (the wizard it claimed would never appear is running). The cure is
-   **stage-agnostic** (guarded by the synthetic outcome, not by `Stage==Finalizing`):
-   a synthetic skip can also sit parked behind a closed RealmJoin completion gate, whose
-   release path completes on `HelloResolvedUtc != null` — the same bug through another
-   door.
-
-# Layer 2 — confirmation second read (HelloTracker)
-
-`HelloTracker.ApplyPolicyRead` (extracted state machine, `HelloTracker.cs`):
-
-| Read | Effect |
-|------|--------|
-| `enabled` (first) | commit immediately (pessimistic direction; `confirmedReads=1`) |
-| `disabled` (first) | mark pending only; 10 s poll timer stays alive |
-| `disabled` while pending | commit disabled (`confirmedReads=2`) |
-| `enabled` while pending | commit enabled + `flipFlopDetected=true` (the 772fe502 catch) |
-| `null` while pending | clear pending, keep polling (a vanished value is flip-flop evidence) |
-
-While pending, `_isPolicyConfigured` stays false, so the Hello wait timers use the
-longer policy-unknown cadence — the safe direction. The confirmation audit fields ride
-on the `hello_policy_detected` event `Data`.
-
-# Residual risk
-
-A wizard that starts only *after* `Completed` (agent already terminal + shut down) is
-still not catchable — the dispatch guard dead-ends post-terminal signals by design. The
-confirmation read shrinks the window for the stale-disabled commit; the wizard signal
-closes it for every ordering where 62404 fires before the 5 s grace elapses.
-
-# Citations
-
-- Reducer handler + prevention predicate: `src/Shared/AutopilotMonitor.DecisionCore/Engine/DecisionEngine.Classic.cs` (`HandleHelloWizardStartedV1`), `.../DecisionEngine.Completion.cs` (`HelloSatisfiedForCompletion`), `.../DecisionEngine.Edge.cs` (`HelloWizardObservedPromote`)
-- Agent signal path: `src/Agent/AutopilotMonitor.Agent.V2.Core/Monitoring/Enrollment/SystemSignals/ShellCoreTracker.cs` (62404 + backfill), `EspAndHelloTracker.cs`, `SignalAdapters/EspAndHelloTrackerAdapter.cs`
-- Confirmation read: `src/Agent/AutopilotMonitor.Agent.V2.Core/Monitoring/Enrollment/SystemSignals/HelloTracker.cs` (`ApplyPolicyRead`)
-- Fixtures: `tests/fixtures/signal-kinds/hello-wizard-started-v1.json`, `tests/fixtures/enrollment-sessions/userdriven-hello-wizard-unskip-v1.jsonl`
-- Related: [Decision Engine](decision-engine.md)

docs/agent/index.md

@@ -1,11 +0,0 @@
-# V2 Agent
-
-How the on-device agent works:
-
-* [Runtime Overview](overview.md) - lifecycle (install → boot guards → runtime → termination), collector hosts, the single-rail event pipeline to the backend, config & kill switch, on-disk layout.
-* [Decision Engine](decision-engine.md) - the pure-reducer state machine (DecisionCore): signals, state, effects, the A/B/C completion arms, invariants, threading.
-* [Logs, Persistence & Crash Recovery](logs-and-persistence.md) - every persisted file and why it exists; signal log vs spool; snapshot/journal; the replay-based recovery flow and quarantine.
-* [Hello Wizard Un-Skip](hello-wizard-unskip.md) - why a single "WHfB disabled" policy read never decides completion: the HelloWizardStarted signal (prevention + cure) and the HelloTracker confirmation second read.
-* [Autopilot ZTD Diagnostics](autopilot-ztd-diagnostics.md) - Windows' own diagnostic surfaces for the profile-download flow: ModernDeployment event IDs (807/815/164/...), the Diagnostics\Autopilot registry key, deployment-service endpoints, and the known-issue error-code map.
-
-Reading order for newcomers: overview → decision engine → persistence.

docs/agent/logs-and-persistence.md

@@ -1,141 +0,0 @@
----
-type: Reference
-title: V2 Agent — Logs, Persistence & Crash Recovery
-description: Every file the agent persists under %ProgramData%\AutopilotMonitor, why each exists (especially the signal log), and the exact recovery/replay flow after a crash or reboot.
-resource: /src/Agent/AutopilotMonitor.Agent.V2.Core/Orchestration/RecoveryCoordinator.cs
-tags:
-  - agent
-  - persistence
-  - signal-log
-  - recovery
-  - durability
-timestamp: 2026-07-11T00:00:00+02:00
----
-
-# V2 Agent — Logs, Persistence & Crash Recovery
-
-An enrollment spans multiple reboots and can be killed at any moment (app-forced
-restart, self-update, crash, power loss). The agent therefore persists three distinct
-tiers of state — each answers a different question:
-
-1. **Decision truth** (`State\`): *what did the decision engine see and decide?*
-   Signal log + journal + snapshot. Must be deterministic and replayable.
-2. **Transport** (`Spool\`): *what telemetry still has to reach the backend?*
-   Durable upload queue + cursor. Best-effort; the backend dedups.
-3. **Diagnostics** (`Logs\`, `Crashes\`): *what happened, for humans?* Trace log and
-   crash dumps. Never allowed to affect decisions.
-
-Plus small markers (session identity, completion, quarantine) that steer the next
-process start.
-
-# Why a signal log AND an event spool?
-
-They look similar (both JSONL) but serve opposite masters:
-
-- The **signal log** is the *input* truth of the decision engine. Recovery rebuilds
-  decision state by replaying it; the snapshot is only a cache. An append failure here
-  **blocks the reducer** — a signal that was never durably logged must not change state,
-  or a post-crash replay would diverge from what the live run decided (determinism L.1/L.5).
-- The **spool** is a *projection* for upload. Writing it is best-effort — a spool
-  failure must never break ingress, and a lost non-critical item is acceptable because
-  the backend dedups on `(PartitionKey, RowKey)`.
-
-Same data, two files, because durability requirements differ: the signal log fsyncs
-every line; the spool fsyncs only items flagged `RequiresImmediateFlush`.
-
-# Artifact inventory
-
-| Artifact | Path | Format | fsync | Rotation/cap |
-| --- | --- | --- | --- | --- |
-| Signal log | `State\signal-log.jsonl` | JSONL (`DecisionSignal`/line) | every append (WriteThrough + Flush, bufferSize=1) | none (per-enrollment lifecycle) |
-| Journal | `State\journal.jsonl` | JSONL (`DecisionTransition`/line) | every append | atomic truncate only (phantom tail) |
-| Snapshot | `State\snapshot.json` | JSON + SHA-256 checksum envelope | temp-write + `File.Replace` | single file |
-| Event sequence | `State\event-sequence.json` | `{ LastAssignedSequence }` | atomic | none; survives WhiteGlove Part-2 resume |
-| Spool | `Spool\spool.jsonl` | JSONL (`TelemetryItem`/line) | only `RequiresImmediateFlush` items | none — never truncated, cursor skips uploaded items |
-| Upload cursor | `Spool\upload-cursor.json` | `{ LastUploadedItemId }` | atomic | idempotent, never regresses |
-| Agent trace log | `Logs\agent_YYYYMMDD[_NNN].log` | text `[utc] [LEVEL] msg` | no | 50 MB → suffix rotation; consumed by `/diag-agent-log` |
-| Crash dump + record | `Crashes\<stem>.dmp` + `.json` | MiniDump + JSON | n/a (process dying) | 5 files / 7 days |
-| Startup-event gate | `State\startup-event-state.json` | JSON dict | no (atomic) | cross-reboot dedup of one-shot probes |
-| Bandwidth state | `State\bandwidth-state.json` | JSON samples/counters | no (atomic) | reboot-survivor for the DO bandwidth estimate |
-| Session identity | `session.id`, `session.created`, `whiteglove.complete` (root) | text | no | drives emergency-break age check + WG resume |
-| Markers | `clean-exit.marker` (root), `enrollment-complete.marker` (State), `quarantine-requested.marker` (State) | text | no | consumed at next start |
-| Config cache | `Config\remote-config.json` | JSON | no | security-sensitive fields stripped |
-
-Per-collector state files (`OfficeInstallStatePersistence`, IME tracker state, script
-execution state, log-file positions) follow the same fail-soft atomic-replace pattern.
-Cleanup (`CleanupService`) removes the agent dirs on self-destruct but **keeps `Logs\`**
-for forensics.
-
-# The decision-truth triad
-
-## Signal log — authoritative input
-
-- Written by the single ingress worker, one line per accepted signal, **before** the
-  reducer runs. Monotonic-ordinal guard on append.
-- `bufferSize: 1` is load-bearing: session `b9b92d89` (2026-07-09) was killed mid-append
-  by a self-update `Environment.Exit`; the default 4096-byte buffer flushed the same
-  buffered line twice → byte-identical duplicate → non-monotonic ordinal → **recovery
-  crash-loop**. Fixes (commits `57e4334b` + `a0238a4b`):
-  - unbuffered append (nothing left for `Dispose` to re-flush),
-  - read-side tolerance: a byte-identical *consecutive* duplicate line is skipped as a
-    known crash artifact,
-  - self-update restarts now route through graceful shutdown (full drain, bounded 15 s
-    hard-exit fallback) instead of `Environment.Exit`,
-  - poison-replay quarantine (below) so a corrupt log can never loop the agent again.
-- Corrupt-tail rule: readers stop at the first unparsable line (a torn final write is
-  expected, not fatal).
-
-## Journal — authoritative applied-transition record
-
-One `DecisionTransition` per reducer step, appended in `ApplyStep` step 1 — the **only**
-persistence path that hard-throws. Three consecutive append failures escalate to a
-quarantine request. Used during recovery to detect BEHIND/AHEAD crash windows against
-the snapshot; AHEAD phantom entries are truncated to `.quarantine\<ts>\journal-phantom-tail.jsonl`.
-
-## Snapshot — recovery cache, never truth
-
-Full `DecisionState` (schema **v4**) in a checksum envelope, written best-effort after
-meaningful steps (stage transition / non-telemetry effect) or every 100 pass-through
-steps. Atomic temp-write + `File.Replace`; a crash mid-save leaves the old file intact.
-Load returns `null` on any doubt (missing, IO error, checksum mismatch) — recovery then
-falls back to full signal-log replay. Aborted/phantom states are never snapshotted.
-
-# Recovery flow on restart
-
-`RecoveryCoordinator.Recover` runs before the live pipeline; order is load-bearing:
-
-1. **Death-rattle peek**: if the previous exit was unclean, read the prior snapshot
-   *non-mutatingly* (`TryReadRaw`) for the `previous_crash_detected` context — before
-   the pipeline may quarantine it.
-2. **Quarantine marker** (`quarantine-requested.marker`, written mid-run when the
-   journal became unappendable): quarantine all segments + snapshot *now*, at a moment
-   when no writer holds them. Marker is deleted only on full success.
-3. **WhiteGlove Part-2 resume**: prior stage `WhiteGloveSealed` → archive the reducer
-   segments to `.part1-<ts>\` but **preserve `event-sequence.json`** (the Web UI splits
-   Part 1/2 on the sequence).
-4. **Open writers** — each scans its file for the last ordinal/step, stopping at the
-   first unparsable line.
-5. **Pick seed + replay stream**:
-   - snapshot loads → seed from it, re-stamp `AgentBootUtc` to *now* (replayed signals
-     must not arm past-due deadlines), replay only the signal-log **tail**
-     (`ordinal > snapshot.LastAppliedSignalOrdinal`);
-   - snapshot corrupt → quarantine snapshot only, replay the full signal log;
-   - log head-corrupt → total-loss quarantine of everything, fresh Initial seed.
-6. **Journal alignment**: truncate AHEAD phantoms to the seed's `StepIndex`.
-7. **Replay + backfill**: fold the stream through a transient `DecisionEngine`,
-   re-appending any missing journal entries (closes the BEHIND window).
-8. **Poison guard**: if replay itself throws, quarantine snapshot + all segments and
-   reseed Initial — the agent keeps running with fresh state instead of crash-looping.
-
-**Duplicate avoidance, end to end**: monotonic append guards (signal log + journal) →
-consecutive-duplicate skip on read → tail-replay past the snapshot ordinal → AHEAD
-truncation → backend `(PartitionKey, RowKey)` dedup for re-uploaded spool items.
-
-**Quarantine semantics**: files are *moved*, never deleted, into
-`State\.quarantine\<utc-ts>\` with a `reason.txt` sidecar — evidence survives for
-diagnostics ZIPs while the agent restarts from clean state.
-
-# Related
-
-- Pipeline that produces these files: [runtime overview](overview.md)
-- What replay must reproduce deterministically: [decision engine](decision-engine.md)

docs/agent/overview.md

@@ -1,153 +0,0 @@
----
-type: Component Overview
-title: V2 Agent — Runtime Overview
-description: How the V2 agent boots during Autopilot enrollment, which collectors it runs, how telemetry flows to the backend, and how it decides to stop.
-resource: /src/Agent/AutopilotMonitor.Agent.V2/Program.cs
-tags:
-  - agent
-  - runtime
-  - collectors
-  - telemetry
-timestamp: 2026-07-11T00:00:00+02:00
----
-
-# V2 Agent — Runtime Overview
-
-The agent is a .NET Framework 4.8 executable (`AutopilotMonitor.Agent.exe`) that runs as
-SYSTEM on Windows devices during Autopilot enrollment. It observes the enrollment
-(ESP phases, IME app installs, Hello, desktop arrival, …), streams telemetry to the
-backend, and decides locally — via the [decision engine](decision-engine.md) —
-when the enrollment is complete or failed. When it reaches a terminal decision it shows
-the optional summary dialog, uploads diagnostics, and removes itself.
-
-Projects: `src/Agent/AutopilotMonitor.Agent.V2` (exe) + `AutopilotMonitor.Agent.V2.Core`
-(library) + `src/Shared/AutopilotMonitor.DecisionCore` (portable decision engine).
-
-# Lifecycle
-
-## Install (bootstrap during OOBE)
-
-`AutopilotMonitor.Agent.exe --install` is invoked by the Intune Platform Script
-(bootstrap) and never runs the monitoring runtime
-(`src/Agent/AutopilotMonitor.Agent.V2/Program.InstallMode.cs`):
-
-1. Copy payload to `%ProgramData%\AutopilotMonitor\Agent\`.
-2. Persist `bootstrap-config.json` (bootstrap token, tenant id) and `await-enrollment.json`.
-3. Register the `AutopilotMonitor-Agent` scheduled task (BootTrigger, SYSTEM,
-   `ExecutionTimeLimit=PT0S`, survives battery conditions).
-4. Immediate runtime handoff: WMI `Win32_Process.Create` → `schtasks /Run` fallback →
-   defer to BootTrigger on next reboot. `--install` exits 0 even if both immediate
-   launches fail (fail-soft; the BootTrigger is the net).
-5. Write `HKLM\SOFTWARE\AutopilotMonitor\Deployed` = UTC timestamp — the **bootstrap
-   re-entry lock** read by the install script. Never consulted by the agent itself;
-   intentionally preserved across cleanup.
-
-## Runtime start (each process start / boot)
-
-`Program.Main` → `RunAgent` runs numbered phases (V1-parity exit codes 0–7):
-
-1. **Guards & bootstrap** (`AgentBootstrap.Run`): classify previous exit
-   (`clean` / `exception_crash` / `hard_kill` / `reboot_kill` via `clean-exit.marker`,
-   crash logs, boot event 6009); ghost-restart guard (`enrollment-complete.marker`
-   → cleanup + exit 0); absolute session-age emergency break; optional waits
-   (`--await-enrollment` MDM cert poll, `--tenant-id-wait` registry wait); resolve
-   TenantId from `HKLM:\SOFTWARE\Microsoft\Enrollments`; get-or-create SessionId.
-2. **Auth clients** (mTLS with the Intune MDM device client certificate).
-3. **Remote config** (`GET /api/agent/config`): live fetch → cached
-   `Config\remote-config.json` → built-in defaults. Config-channel **kill switch**
-   checked here, honoured only from a *live* fetch (cache strips all security-sensitive
-   fields).
-4. **Telemetry clients**, **backend session registration**.
-5. **`AgentRuntimeHost.Run`**: builds the `EnrollmentOrchestrator`, starts collector
-   hosts, decision pipeline and upload drain loop, then blocks until shutdown.
-
-## Stop triggers
-
-- **Terminal decision** of the engine (Completed / Failed / WhiteGloveSealed) — the normal path.
-- **Max-lifetime watchdog**: `AgentMaxLifetimeMinutes` (default 360) — hard cap per session.
-- Backend **kill switch** (config channel at start; telemetry channel via upload responses
-  → synthesized `terminate_session` action).
-- Auth-failure threshold, self-update restart, Ctrl+C / ProcessExit.
-
-Distinct from agent lifetime: `CollectorIdleTimeoutMinutes` (default 15) stops only the
-periodic collectors (Performance, AgentSelfMetrics) when nothing "real" happens; they
-restart on new activity.
-
-## Termination sequence
-
-On terminal decision (`EnrollmentTerminationHandler`): stop collectors → build
-`FinalStatus` → write `final-status.json` + launch `SummaryDialog` (separate WPF exe in
-the user session, opt-in) → 2 s late-event grace → diagnostics ZIP upload →
-write `enrollment-complete.marker` → optional reboot → self-destruct cleanup
-(skipped for WhiteGlove Part 1, which instead writes the `whiteglove.complete` marker
-and leaves state for Part 2).
-
-# Collector model
-
-Collectors are wrapped in **collector hosts** (`ICollectorHost`, built by
-`DefaultComponentFactory.CreateCollectorHosts`). Each host owns collector/tracker
-classes plus a **signal adapter** that translates raw callbacks into decision signals.
-Main hosts (gating in parentheses; several more are opt-in via remote config):
-
-| Host | Watches |
-| --- | --- |
-| EspAndHelloHost | ESP phases, Shell-Core events, provisioning status, Hello (always) |
-| ImeLogHost | IME log tailer (CMTrace) + IME process watcher — app installs (always) |
-| DesktopArrivalHost | real-user desktop arrival (always) |
-| AadJoinHost | AAD join events + hybrid login pending (always) |
-| DeviceInfoHost | one-shot hardware/OS/network inventory (always) |
-| StallProbeHost | idle/stall probes (config) |
-| WindowsUpdateWatcherHost / OsBuildChangeHost | WU during OOBE, build changes (config / always) |
-| DeliveryOptimizationHost | DO counters for bandwidth estimate (config, dormant until installs run) |
-| OfficeInstallDetectorHost, ConsoleBypassHost, ProvisioningPackageHost, NetworkChangeHost, RealmJoinHost, GatherRuleExecutorHost, … | feature-specific (mixed gating) |
-
-# Event pipeline (single rail)
-
-Everything a collector observes flows through **one** path — no collector emits
-telemetry directly:
-
-```
-Collector callback
-  → SignalAdapter (dual emission: decision signal + InformationalEvent)
-    → SignalIngress.Post()            (bounded queue 256, back-pressure blocks producer)
-      → single worker thread:
-          assign ordinals → SignalLog.Append (durable)   ← source of truth
-          → DecisionEngine.Reduce → apply step/effects
-          → telemetry projection (best-effort)
-            → TelemetrySpool → batch (≤100) → gzip → POST /api/agent/telemetry
-```
-
-- Wire model: `EnrollmentEvent` (`EventType` from `Constants.EventTypes`, monotonic
-  `Sequence` = canonical order, `Phase`, `ImmediateUpload` for lifecycle-critical items),
-  wrapped in `TelemetryItem` (Kind = Event / Signal / DecisionTransition, monotonic
-  `TelemetryItemId` as upload cursor).
-- Auth per request: client-cert mTLS + hardware headers (`X-Tenant-Id`,
-  `X-Device-Manufacturer/-Model/-SerialNumber`, `X-Bootstrap-Token` pre-MDM-cert,
-  `X-Agent-Version`).
-- Retry: 100/400/1600 ms for transient (408/429/5xx); 413 → split batch and halve batch
-  size; unknown 4xx → items retained (cursor holds) unless the backend flags explicit
-  poison row keys; offline → spool keeps everything, backend dedups on re-upload;
-  `DeviceBlocked` pauses the drain until `UnblockAt`.
-
-# Decision integration
-
-Adapters post `DecisionSignal`s; the engine's terminal stage fires
-`Terminated` (off the worker thread) → termination sequence above. Engine *effects*
-(timeline events like `enrollment_complete`, deadline scheduling, classifier runs,
-snapshots) are executed by the `EffectRunner` — the reducer itself is pure. Details:
-[decision engine](decision-engine.md); durability and replay:
-[logs & persistence](logs-and-persistence.md).
-
-# On-disk layout (`%ProgramData%\AutopilotMonitor\`)
-
-| Path | Contents |
-| --- | --- |
-| `\` | `bootstrap-config.json`, `await-enrollment.json`, `clean-exit.marker`, session-id persistence |
-| `\Agent\` | deployed binaries |
-| `\State\` | decision persistence (SignalLog, Journal, Snapshot), `enrollment-complete.marker`, `final-status.json`, self-update state, `.quarantine/`, `.part1-<ts>/` |
-| `\Spool\` | telemetry spool (offline queue) |
-| `\Logs\` | agent trace log, `crash_*.log`, `ime_pattern_matches.log` |
-| `\Config\` | `remote-config.json` cache |
-| `\Agent-Update\`, `\Updates\` | self-update staging/download |
-
-Per-file details and the recovery flow: [logs & persistence](logs-and-persistence.md).

docs/architecture.md

@@ -1,135 +0,0 @@
----
-type: Architecture Guide
-title: Autopilot Monitor – Architecture Guide
-description: High-level architecture overview and solution layout for contributors.
-tags:
-  - architecture
-  - agent
-  - backend
-  - web
-  - mcp
-timestamp: 2026-07-06T21:39:29+02:00
----
-
-# Autopilot Monitor – Architecture Guide
-
-> High-level architecture overview and solution layout for contributors.
-> Full product documentation lives at https://docs.autopilotmonitor.com.
-
----
-
-## High-Level Overview
-
-```text
-+----------------------------------------------------------------------------------+
-|                         Autopilot Monitor - Architecture                         |
-+----------------------------------------------------------------------------------+
-
- [Admin/User Browser]
-          |
-          | HTTPS
-          v
-+-----------------------------+      OIDC        +-------------------------------+
-| Web App (Next.js)           |<---------------->| Microsoft Identity (Entra ID) |
-| Dashboard / Progress        |                  | Auth / Authorization          |
-+-----------------------------+                  +-------------------------------+
-          ^    ^
-          |    |
-          |    | Live updates
-          |    |
-          |    |                         +---------------------------+
-          |    +-------------------------| SignalR Hub               |
-          |                              | Real-time event stream    |
-          |                              +---------------------------+
-          |                                          ^
-          | REST / API                               |
-          v                                          | events
-+---------------------------+        Data &          |
-| Azure Functions Backend   |------> Integrations ---+
-| APIs / Ingestion / Rules  |               \
-+---------------------------+                \       +---------------------------+
-          ^                                   +----->| Storage Tables            |
-          | mTLS                                     | Sessions / Events / Rules |
-          | telemetry / events                       +---------------------------+
-          |                                          +---------------------------+
-+---------------------------+                        | Notifications             |
-| Agent on Windows Devices  |                        | Teams / Slack / Webhooks  |
-| Enrollment + app progress |                        +---------------------------+
-+---------------------------+
-                                                     +---------------------------+
-                                                     | MCP Server                |
-                                                     | Azure Container App       |
-                                                     +---------------------------+
-```
-
-**Core Data Flow:**
-```
-Device (Agent) ──JSON telemetry+gzip──► Azure Functions ──► Azure Table Storage
-                                      │                     │
-                                      ├── SignalR ─────────►│
-                                      │                     │
-                              Web Dashboard ◄── REST API ◄──┘
-```
-
-| Component | Technology | Purpose |
-|-----------|------------|---------|
-| **Agent** | .NET Framework 4.8 (Windows) | Runs on devices during enrollment, collects telemetry |
-| **SummaryDialog** | .NET Framework 4.8 (WPF) | Post-enrollment summary UI (outcome, app timeline, auto-close) |
-| **Backend** | Azure Functions .NET 8 (Isolated Worker) | REST API, event processing, rule engine, storage |
-| **Web** | Next.js 15 + TypeScript + React 18 | Dashboard, settings, analytics, real-time UI |
-| **Shared** | .NET Standard 2.0 | DTOs, models, enums, constants shared between Agent & Backend |
-| **MCP Server** | Azure Container App | Model Context Protocol server for AI-assisted analysis |
-
----
-
-## Solution Structure
-
-```
-AutopilotMonitor.sln
-├── src/
-│   ├── Shared/
-│   │   ├── AutopilotMonitor.Shared/             (netstandard2.0 – DTOs, models, enums, constants)
-│   │   └── AutopilotMonitor.DecisionCore/       (netstandard2.0 – completion decision engine)
-│   ├── Agent/
-│   │   ├── AutopilotMonitor.Agent.V2/           (net48, Exe – entry point; output named AutopilotMonitor.Agent.exe)
-│   │   ├── AutopilotMonitor.Agent.V2.Core/      (net48, Lib – core logic)
-│   │   ├── AutopilotMonitor.Agent.V2.Core.Tests/ (net48, xUnit – agent unit tests)
-│   │   ├── AutopilotMonitor.DecisionCore.Tests/ (net48, xUnit – decision engine tests)
-│   │   ├── AutopilotMonitor.SummaryDialog/      (net48, WPF – enrollment summary UI)
-│   │   └── AutopilotMonitor.SummaryDialog.Tests/ (net48, xUnit)
-│   ├── Backend/
-│   │   ├── AutopilotMonitor.Functions/          (net8.0, Azure Functions v4)
-│   │   └── AutopilotMonitor.Functions.Tests/    (net8.0, xUnit)
-│   ├── McpServer/
-│   │   └── autopilot-monitor-mcp/               (TypeScript/Node – MCP server; deployed as Azure Container App)
-│   └── Web/
-│       └── autopilot-monitor-web/               (Next.js 15, TypeScript)
-├── rules/
-│   ├── gather/                                   Individual gather rule JSONs
-│   ├── analyze/                                  Individual analyze rule JSONs
-│   ├── ime-log-patterns/                         IME regex pattern JSONs
-│   ├── schema/                                   JSON Schema definitions
-│   ├── guardrails.json                           Gather-rule guardrail allow-lists (source)
-│   ├── scripts/                                  combine.js
-│   └── dist/                                     Combined output (embedded in Functions)
-├── infra/                                        Bicep templates (MCP server)
-├── scripts/
-│   ├── Backup/                                   Table backup/restore tooling
-│   ├── Bootstrap/                                Intune deployment scripts
-│   ├── CustomerSetup/                            Customer onboarding helpers
-│   └── Deployment/                               CI/CD build scripts
-└── .github/workflows/                            CI/CD pipelines
-```
-
-**Project References:**
-```
-Shared + DecisionCore ◄── Agent.V2.Core ◄── Agent.V2
-                                          ◄── Agent.V2.Core.Tests
-Shared + DecisionCore ◄── DecisionCore.Tests
-Shared + DecisionCore ◄── Functions ◄── Functions.Tests
-SummaryDialog ◄── SummaryDialog.Tests   (standalone; compiled alongside the agent build)
-Web (independent – communicates via REST + SignalR)
-McpServer (independent – talks to the backend REST API)
-```
-
----

docs/index.md

@@ -1,35 +0,0 @@
----
-okf_version: "0.1"
----
-
-# Autopilot Monitor — Technical Knowledge Bundle
-
-Contributor-facing technical documentation for Autopilot Monitor, organized as an
-[Open Knowledge Format (OKF)](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md)
-knowledge bundle. Customer-facing product documentation lives at
-https://docs.autopilotmonitor.com (separate repository).
-
-# Architecture
-
-* [Architecture Guide](architecture.md) - High-level architecture overview and solution layout for contributors.
-
-# Agent
-
-* [V2 Agent](agent/index.md) - How the on-device agent works: [runtime overview](agent/overview.md), [decision engine](agent/decision-engine.md) (reducer, signals, completion arms), [logs & persistence](agent/logs-and-persistence.md) (signal log, snapshot, crash recovery), [Hello wizard un-skip](agent/hello-wizard-unskip.md) (why a single "WHfB disabled" read never decides completion), [Autopilot ZTD diagnostics](agent/autopilot-ztd-diagnostics.md) (event IDs, diagnostic registry, endpoints, error-code map).
-* [Build Counter Blob](agent/build-counter-blob.md) - How agent build numbers are minted: shared counter blob with ETag-CAS so local and CI builds never collide; CI additionally attests build provenance (Sigstore).
-* [Agent Endpoint Migration](agent/endpoint-migration.md) - How the backend re-homes agents to a new API base URL via the config channel (backend move or per-tenant region move): live-fetch-only, allowlist-validated on both sides, one hop, kill wins.
-
-# Rules
-
-* [Gather Rule Phase Scoping & Emit-on-Change](rules/gather-rule-phase-scoping.md) - Restricting gather rules to enrollment phases (activePhases / activeFromPhase sticky latch) and emitMode "on_change" result-dedup — the anti-spam pair for interval rules.
-
-# Security & Identity
-
-* [MCP OAuth Flow](mcp-oauth-flow.md) - Who authenticates where when connecting an AI client to the MCP server; two identities, three parties plus Entra ID.
-
-# Conventions for this bundle
-
-* Every concept document is a markdown file with YAML frontmatter; `type` is mandatory, `title`, `description`, `resource`, `tags`, and `timestamp` are recommended.
-* Use standard **relative** markdown links between documents (e.g. `agent/overview.md`, `../architecture.md`). Do NOT use the spec's `/`-prefixed bundle-absolute form — GitHub resolves those against the repo root (missing `/docs`) and navigation breaks.
-* Record notable additions and changes in [log.md](log.md).
-* `index.md` and `log.md` are reserved names — never use them for concept documents.

docs/log.md

@@ -1,29 +0,0 @@
-# Log
-
-## 2026-07-20
-
-* **Creation**: Added `rules/gather-rule-phase-scoping.md` (new `rules/` section) — gather rules gain `activePhases` (run only during listed phases), `activeFromPhase` (sticky latch from a phase onwards, never via Failed) and `emitMode: "on_change"` (canonical-hash result dedup with `suppressedPolls` observability), ConfigVersion 34. Includes the prerequisite backend fix: the custom-rule toggle PUT no longer wipes the stored rule definition (partial-merge in `GatherRuleService.UpdateRuleAsync`).
-
-## 2026-07-18
-
-* **Creation**: Added `agent/endpoint-migration.md` — config-channel agent re-home (`MigrateToApiBaseUrl` on `GET agent/config`, ConfigVersion 33): backend or per-tenant API-URL moves without DNS indirection (impossible due to mTLS/Flex-TLS). Live-fetch-only with cache strip, `AgentEndpointMigrationRules` allowlist validated on both sides, one hop, kill-switch wins. Built as the lesson from the 2026-07-18 WEU→GWC cutover, which hard-cut all in-flight agents.
-
-## 2026-07-17
-
-* **Creation**: Added `agent/build-counter-blob.md` — agent build numbers now come from a shared public counter blob (`buildcounter-v{N}.txt`, reserve-before-build with ETag-CAS) so local `build.ps1` and CI `build-agent.yml` builds can never mint the same number. Documents the CI parity fixes (SummaryDialog.exe.config in the ZIP, EXE-vs-manifest version check, hash-oracle update gated on stable cutover) and the Sigstore provenance attestation on CI-built ZIPs.
-
-## 2026-07-16
-
-* **Creation**: Added `agent/autopilot-ztd-diagnostics.md` — reference for Windows' own ZTD diagnostic surfaces (ModernDeployment Autopilot event IDs incl. 807/809/815/908, the `Diagnostics\Autopilot` registry key, deployment-service endpoints, known-issue error-code map with KB fixes). Backs the agent's `ZtdEvidence` collector (`ztdVerdict` on `autopilot_profile_missing`) and the backend known-issue rules; sources carry a re-check RSS feed.
-
-## 2026-07-13
-
-* **Removal**: Moved `customer-graph-add-on-permissions.md` out of this contributor bundle into the customer documentation repository (`reference/optional-graph-permissions.md`). It was customer-facing product content and did not belong in the tech-docs bundle; removed the entry from `index.md`.
-
-* **Creation**: Added `agent/hello-wizard-unskip.md` — session 772fe502 fix: the `HelloWizardStarted` decision signal (prevention veto + un-skip cure for the policy-disabled Hello shortcut) and the HelloTracker confirmation second read against flip-flopping WHfB CSP values.
-
-## 2026-07-11
-
-* **Creation**: Added the `agent/` section — three concept documents on the V2 agent: `agent/overview.md` (runtime, collectors, telemetry pipeline), `agent/decision-engine.md` (DecisionCore reducer, signals, A/B/C completion arms, invariants), `agent/logs-and-persistence.md` (persisted artifacts, signal log vs spool, recovery/replay flow) plus `agent/index.md`.
-
-* **Creation**: Converted `docs/` into an OKF v0.1 knowledge bundle — added YAML frontmatter to `architecture.md`, `mcp-oauth-flow.md`, and `customer-graph-add-on-permissions.md`; created `index.md` and this log.

docs/mcp-oauth-flow.md

@@ -1,126 +0,0 @@
----
-type: Reference
-title: MCP OAuth Flow — Who Authenticates Where
-description: How the two unrelated identities (AI-product account vs. Entra ID work account) and three parties interact when connecting an AI client to the Autopilot Monitor MCP server.
-resource: /src/McpServer/autopilot-monitor-mcp/src/oauth.ts
-tags:
-  - mcp
-  - oauth
-  - entra-id
-  - security
-timestamp: 2026-07-11T10:59:31+02:00
----
-
-# MCP OAuth Flow — Who Authenticates Where
-
-**Status:** Reference · **Owner:** MCP Server · **Code:** [`src/McpServer/autopilot-monitor-mcp/src/oauth.ts`](../../src/McpServer/autopilot-monitor-mcp/src/oauth.ts)
-
-## Why this document exists
-
-Connecting an AI client (Claude Desktop, claude.ai, VS Code, ChatGPT) to the
-Autopilot Monitor MCP server involves **two unrelated identities** and **three
-parties plus Entra ID**. This regularly confuses users during setup, because
-the account signed in to the AI product and the account used for Autopilot
-Monitor are usually different people-in-one: e.g. **Luke** uses his normal
-account `luke` for his Claude subscription, but his admin account `adm.luke`
-for Autopilot Monitor.
-
-The two identities never mix:
-
-* **`luke` (AI-product account)** — only authenticates Luke against Claude
-  itself. Anthropic needs it to associate the OAuth callback with the right
-  Claude user and connector. The MCP server never sees this identity.
-* **`adm.luke` (Entra ID work account)** — the identity *inside* the token.
-  Every MCP tool call is authorized as `adm.luke`; roles and tenant scope
-  derive from it. Anthropic never sees this password, only the issued tokens.
-
-## The parties
-
-1. **AI client + its backend** (e.g. Claude Desktop + claude.ai) — the OAuth
-   *client*. For hosted surfaces the token exchange and token storage happen
-   in the vendor's backend, not on the user's machine.
-2. **MCP server** (Container App) — acts as a stateless **OAuth proxy /
-   authorization-server façade** in front of Entra ID. It is *not* an IdP:
-   it registers clients dynamically (RFC 7591, HMAC-signed stateless
-   `client_id`), enforces the redirect-URI allowlist and PKCE, and exchanges
-   codes at Entra using its confidential client secret.
-3. **Entra ID** — the real identity provider. This is where `adm.luke` lives.
-
-## Full sequence
-
-```
-Claude Desktop        Browser (user's           MCP server              Entra ID
-+ claude.ai backend   DEFAULT browser!)         (OAuth proxy)
-     │                      │                        │                      │
- 1.  │─ POST /mcp ──────────┼───────────────────────▶│ 401 + WWW-Auth       │
- 2.  │─ Discovery ──────────┼───────────────────────▶│ RFC 9728/8414 docs   │
- 3.  │─ POST /oauth/register┼───────────────────────▶│ client_id (HMAC-     │
-     │                      │                        │ signed, embeds the   │
-     │                      │                        │ registered callback) │
-     │                      │                        │                      │
- 4.  │─ opens browser ─────▶│─ GET /oauth/authorize ▶│─ 302 to Entra ──────▶│
-     │                      │  (PKCE challenge)      │  app-reg client_id,  │
-     │                      │                        │  prompt=select_acct  │
-     │                      │                        │                      │
- 5.  │                      │◀── Microsoft sign-in: account picker ────────│
-     │                      │    ➜ user picks adm.luke HERE                │
-     │                      │                        │                      │
- 6.  │                      │◀─ 302 /oauth/callback?code=... ──────────────│
-     │                      │─ code ────────────────▶│ verifies HMAC state, │
-     │                      │                        │ re-checks allowlist  │
-     │                      │◀─ 302 claude.ai/api/mcp/auth_callback?code=..│
-     │                      │                        │                      │
-     │◀═ browser hits claude.ai ═════╗               │                      │
-     │   ➜ the browser MUST have an  │               │                      │
-     │     active claude.ai session  │               │                      │
-     │     as luke — otherwise       │               │                      │
-     │     Anthropic cannot map the  │               │                      │
-     │     code to a user/connector  │               │                      │
-     │     and the connect fails ════╝               │                      │
-     │                      │                        │                      │
- 7.  │─ Anthropic backend: POST /oauth/token ───────▶│─ + client_secret ───▶│
-     │   (code + PKCE verifier)                      │◀─ access + refresh ──│
-     │◀─ tokens (stored server-side at Anthropic, per connector)            │
-     │                      │                        │                      │
- 8.  │─ POST /mcp + Bearer ─┼───────────────────────▶│ validates Entra JWT  │
-     │                      │                        │ ➜ acts as adm.luke   │
-```
-
-## Key properties
-
-* **Step 5 vs. step 6 is the double sign-in.** The whole browser leg runs in
-  the user's *default* browser. That one browser profile needs **both** an
-  active session at the AI product (`luke` at claude.ai — same account as in
-  the desktop app) *and* the Entra sign-in as `adm.luke`. `prompt=
-  select_account` forces the Entra account picker so an existing SSO session
-  for the wrong account cannot be silently reused.
-* **Step 6 is authenticated at the vendor.** `claude.ai/api/mcp/auth_callback`
-  is an authenticated Anthropic endpoint; the authorization code is bound to
-  the Claude user via the browser's claude.ai session cookies. No claude.ai
-  session (or a different browser profile) → the code lands on a login page
-  and the connect stalls, even though the Entra half succeeded. This is the
-  single most common setup failure.
-* **The MCP server is a pure intermediary.** Its client secret never leaves
-  the server; the AI client never talks to Entra directly. The redirect
-  target is checked twice (authorize + callback) against a strict allowlist
-  of exact vendor callback URIs, and the proxy state that transits the
-  user-agent is HMAC-signed with a 10-minute lifetime.
-* **PKCE is end-to-end.** The AI client generates the verifier; the proxy
-  forwards the challenge (step 4) and the verifier (step 7) untouched, and
-  Entra validates the pair. The proxy additionally *requires* S256 PKCE and
-  rejects downgrades.
-* **Tokens are Entra tokens for `adm.luke`** with audience
-  `api://<client_id>/access_as_user`. For hosted surfaces they are stored in
-  the vendor's backend per connector (which is why the connector then works
-  across desktop, web and mobile). Renewal is a silent `refresh_token` grant
-  through the same `/oauth/token` proxy — no account picker again.
-* **Native CLIs skip step 6's hosted callback.** Claude Code, Gemini CLI and
-  VS Code's loopback flow use RFC 8252 `http://localhost:<port>` /
-  `http://127.0.0.1:<port>` redirects instead; there the token exchange runs
-  on the user's machine and no vendor-side session is involved.
-
-## One-line summary
-
-`luke` authenticates the *return path* of the authorization code to the AI
-vendor (step 6); `adm.luke` is the identity *inside* the token that the MCP
-server authorizes on every tool call (step 8).

docs/rules/gather-rule-phase-scoping.md

@@ -1,97 +0,0 @@
----
-type: Concept
-title: Gather Rule Phase Scoping & Emit-on-Change
-description: How gather rules are restricted to enrollment phases (activePhases / activeFromPhase) and how emitMode "on_change" suppresses repeated identical results — the anti-spam pair for interval rules.
-resource: /src/Agent/AutopilotMonitor.Agent.V2.Core/Monitoring/Telemetry/Gather/GatherRuleExecutor.cs
-tags:
-  - agent
-  - backend
-  - gather-rules
-  - config
-timestamp: 2026-07-20T00:00:00+02:00
----
-
-# Problem
-
-Interval gather rules (e.g. a registry poll every 60 s) ran during **all** enrollment phases
-and emitted an event on **every** tick — including `exists=false` events while the target key
-did not exist yet. A rule needed only from Account Setup onwards produced hundreds of
-identical noise events per session and wasted collector runs.
-
-# Schema
-
-Three opt-in fields on `GatherRule` (Shared model, `rules/schema/gather-rule.schema.json`,
-delivered to the agent via `GET agent/config`; ConfigVersion 34). Absent fields = legacy
-behavior — full back-compat.
-
-| Field | Type | Semantics |
-|---|---|---|
-| `activePhases` | `string[]` \| null | Rule runs only while the current phase is in the list. Null/empty = unrestricted. |
-| `activeFromPhase` | `string` \| null | Sticky latch: activates when the phase first reaches the threshold, then stays active for the rest of the session — including through `Failed`. Null = unrestricted. |
-| `emitMode` | `"always"` \| `"on_change"` \| null | `on_change`: poll on the trigger cadence, emit only when the collected result changes. Null/`always` = emit every collection (legacy). |
-
-Canonical phase tokens are the `EnrollmentPhase` enum **names** `Start`(0) …`Complete`(7).
-Backend validation (`GatherRulesFunction.ValidateScopeAndEmitMode`) rejects `Unknown`/`Failed`,
-numeric tokens, unknown emit modes, and both scope fields set at once (400). The agent
-defensively prefers `activePhases` if both arrive anyway.
-
-# Scope semantics (agent, `GatherRuleExecutor`)
-
-* Scope applies to **all trigger types**:
-  * `interval` — timers keep running; an out-of-scope tick is a free early-return (no
-    start/stop lifecycle races on phase transitions).
-  * `startup` — a scoped startup rule not yet in scope at `UpdateRules` is **deferred**: it
-    runs exactly once from `OnPhaseChanged` when its scope activates (same
-    `_startupRulesExecuted` dedup; it is not part of the `WaitForStartupRules` latch).
-  * `phase_change` — evaluated against the **new** phase; the scope gate runs before the
-    per-(rule, phase) dedup so an out-of-scope pass does not consume the execution slot.
-  * `on_event` — gated by the current phase.
-* **Before the first phase signal** of a session (`_currentPhase == Unknown`) scoped rules are
-  inactive. Sessions that never produce phase signals never run them (documented behavior).
-* **From-phase latch**: activates when `phase != Unknown && phase != Failed && (int)phase >=
-  (int)fromPhase`. `Failed=99` would ordinal-satisfy every threshold, hence the explicit
-  exclusion — but once latched, a rule stays active through `Failed`. A config refresh that
-  delivers a from-phase rule after its threshold passed latches it immediately.
-* `--run-gather-rules` (diagnostic CLI) sets `IgnorePhaseScope = true` — no phase context
-  exists there, scoped rules execute unconditionally (log line marks the bypass).
-
-# Emit-on-change semantics
-
-* The collector result dict is canonically hashed (keys ordinal-sorted at every nesting
-  level, invariant value formatting, SHA-256) **before** `ruleId`/`ruleTitle` injection.
-* First in-scope non-empty result always emits — on an absent registry key that first
-  `exists=false` event *is* the visible "we're polling now" indicator.
-* Unchanged results increment a per-rule suppression counter; the next emitted event carries
-  `suppressedPolls` + `suppressedSinceUtc` in its `Data` so the gap is observable.
-* Composition with `emitOnlyIfExists=true` (collector-level): a miss returns an empty dict —
-  no emit AND no hash update. Result: zero noise while absent, one event on appearance, then
-  only on change.
-* State is in-memory and survives `UpdateRules` config refreshes; an agent restart causes at
-  most one re-emit per rule (acceptable under the per-enrollment lifecycle).
-* Volatile collectors (eventlog timestamps, logparser positions) degrade `on_change` to
-  `always` — every poll hashes differently. The option stays visible for them since some
-  outputs are stable; this is documented, not hidden.
-
-# Portal & delivery
-
-* Create form defaults new rules to `emitMode: "on_change"`; existing rules load as
-  `always`. The scope UI is a three-way mode (always / during phases / from phase) backed by
-  a canonical `GATHER_PHASES` list — the same list replaced the free-text `triggerPhase`
-  input, whose placeholder used to suggest invalid tokens.
-* The custom-rule toggle PUT (`{enabled, isBuiltIn, isCommunity}`) previously full-replaced
-  the stored rule and wiped Title/Target/Trigger — `GatherRuleService.UpdateRuleAsync` now
-  merges toggle-style partials (empty Title/CollectorType/Target) into the existing row and
-  preserves `CreatedAt` on full edits. This fix is a prerequisite: without it every toggle
-  would silently clear the new fields.
-* Old agents (Newtonsoft) ignore unknown config properties: scoped rules run everywhere,
-  `emitMode` is ignored — graceful degradation until the fleet rolls forward.
-* `ContentEquivalent` treats null and empty `activePhases` as equal, so pre-existing DB rows
-  (absent columns → null) never diff against seeds — no reseed churn.
-
-# Citations
-
-* `src/Agent/AutopilotMonitor.Agent.V2.Core/Monitoring/Telemetry/Gather/GatherRuleExecutor.cs` — scope gates, latch, canonical hash
-* `src/Backend/AutopilotMonitor.Functions/Functions/Rules/GatherRulesFunction.cs` — `ValidateScopeAndEmitMode`
-* `src/Backend/AutopilotMonitor.Functions/Services/GatherRuleService.cs` — partial-PUT merge, `ContentEquivalent`
-* `src/Shared/AutopilotMonitor.Shared/Models/Rules/GatherRule.cs` — field contracts
-* Tests: `GatherRuleExecutorPhaseScopeTests`, `GatherRuleExecutorEmitModeTests` (agent); `GatherRuleUpdatePartialMergeTests`, `GatherRuleScopeFieldsTests` (backend)

rules/analyze/ANALYZE-APP-001.json

@@ -5,8 +5,12 @@
   "description": "Detects when a Win32 app detection script fails or returns unexpected results.",
   "severity": "warning",
   "category": "apps",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "baseConfidence": 60,
   "conditions": [
     {
@@ -34,5 +38,9 @@
       ]
     }
   ],
-  "tags": ["apps", "detection", "win32"]
+  "tags": [
+    "apps",
+    "detection",
+    "win32"
+  ]
 }

rules/analyze/ANALYZE-APP-002.json

@@ -5,8 +5,13 @@
   "description": "Detects app installation failures with specific exit codes or HRESULT error codes and suggests fixes.",
   "severity": "high",
   "category": "apps",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed",
+    "on_event:app_install_failed"
+  ],
   "baseConfidence": 80,
   "conditions": [
     {
@@ -36,5 +41,9 @@
       ]
     }
   ],
-  "tags": ["apps", "msi", "error-code"]
+  "tags": [
+    "apps",
+    "msi",
+    "error-code"
+  ]
 }

rules/analyze/ANALYZE-APP-003.json

@@ -6,6 +6,10 @@
   "severity": "high",
   "category": "apps",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "baseConfidence": 70,
   "conditions": [
     {
@@ -29,5 +33,9 @@
       ]
     }
   ],
-  "tags": ["apps", "dependency"]
+  "tags": [
+    "apps",
+    "dependency"
+  ],
+  "version": "1.1.0"
 }

rules/analyze/ANALYZE-APP-004.json

@@ -5,8 +5,13 @@
   "description": "Detects when disk space is critically low during enrollment, which can cause app installation failures. Confidence increases when app installations actually failed while disk space was low.",
   "severity": "critical",
   "category": "apps",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed",
+    "on_event:app_install_failed"
+  ],
   "baseConfidence": 75,
   "conditions": [
     {
@@ -36,8 +41,16 @@
     }
   ],
   "confidenceFactors": [
-    { "signal": "app_failed", "condition": "exists", "weight": 15 },
-    { "signal": "enrollment_failed", "condition": "exists", "weight": 10 }
+    {
+      "signal": "app_failed",
+      "condition": "exists",
+      "weight": 15
+    },
+    {
+      "signal": "enrollment_failed",
+      "condition": "exists",
+      "weight": 10
+    }
   ],
   "explanation": "Performance monitoring shows disk free space dropped below 5 GB during enrollment. This can cause app installation failures, especially for large Win32 apps.\n\nIf app installations failed in the same session while free space was low, treat storage exhaustion as the likely contributing cause — the confidence score of this finding is raised accordingly. Verify the individual app failures for their concrete error codes before concluding storage was the only cause.",
   "remediation": [
@@ -58,5 +71,9 @@
       ]
     }
   ],
-  "tags": ["apps", "disk-space", "critical"]
+  "tags": [
+    "apps",
+    "disk-space",
+    "critical"
+  ]
 }

rules/analyze/ANALYZE-APP-005.json

@@ -6,6 +6,10 @@
   "severity": "high",
   "category": "apps",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "baseConfidence": 70,
   "conditions": [
     {
@@ -29,5 +33,10 @@
       ]
     }
   ],
-  "tags": ["apps", "download", "timeout"]
+  "tags": [
+    "apps",
+    "download",
+    "timeout"
+  ],
+  "version": "1.1.0"
 }

rules/analyze/ANALYZE-APP-006.json

@@ -5,8 +5,12 @@
   "description": "Detects when the same app installation is attempted 3 or more times during one enrollment — a retry loop caused by unhonored reboot requests, repeated failures, or detection mismatches.",
   "severity": "high",
   "category": "apps",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "baseConfidence": 70,
   "conditions": [
     {
@@ -31,5 +35,10 @@
       ]
     }
   ],
-  "tags": ["apps", "reboot", "retry", "loop"]
+  "tags": [
+    "apps",
+    "reboot",
+    "retry",
+    "loop"
+  ]
 }

rules/analyze/ANALYZE-APP-007.json

@@ -5,7 +5,13 @@
   "description": "Detects when the app tracking summary reports multiple failed app installations.",
   "severity": "high",
   "category": "apps",
+  "version": "1.2.0",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed",
+    "on_event:app_install_failed"
+  ],
   "baseConfidence": 75,
   "conditions": [
     {
@@ -16,10 +22,22 @@
       "operator": "gte",
       "value": "2",
       "required": true
+    },
+    {
+      "signal": "enrollment_failed",
+      "source": "event_type",
+      "eventType": "enrollment_failed",
+      "operator": "exists",
+      "value": "",
+      "required": false
     }
   ],
   "confidenceFactors": [
-    { "signal": "enrollment_failed", "condition": "exists", "weight": 15 }
+    {
+      "signal": "enrollment_failed",
+      "condition": "exists",
+      "weight": 15
+    }
   ],
   "explanation": "The app tracking summary reports 2 or more failed app installations during enrollment. This suggests a systemic issue rather than an isolated app failure.",
   "remediation": [
@@ -32,5 +50,9 @@
       ]
     }
   ],
-  "tags": ["apps", "summary", "multiple-failures"]
+  "tags": [
+    "apps",
+    "summary",
+    "multiple-failures"
+  ]
 }

rules/analyze/ANALYZE-APP-008.json

@@ -6,6 +6,10 @@
   "severity": "warning",
   "category": "apps",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "baseConfidence": 70,
   "conditions": [
     {
@@ -28,5 +32,11 @@
       ]
     }
   ],
-  "tags": ["apps", "performance", "slow-install", "warning"]
+  "tags": [
+    "apps",
+    "performance",
+    "slow-install",
+    "warning"
+  ],
+  "version": "1.1.0"
 }

rules/analyze/ANALYZE-APP-012.json

@@ -6,6 +6,10 @@
   "severity": "warning",
   "category": "apps",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "trigger": "correlation",
   "baseConfidence": 80,
   "conditions": [
@@ -34,7 +38,17 @@
     }
   ],
   "relatedDocs": [
-    { "title": "Win32 app return codes in Intune", "url": "https://learn.microsoft.com/en-us/mem/intune/apps/apps-win32-app-management#step-4-return-codes" }
+    {
+      "title": "Win32 app return codes in Intune",
+      "url": "https://learn.microsoft.com/en-us/mem/intune/apps/apps-win32-app-management#step-4-return-codes"
+    }
   ],
-  "tags": ["apps", "enforcement", "exit-code", "unmapped", "resolved"]
+  "tags": [
+    "apps",
+    "enforcement",
+    "exit-code",
+    "unmapped",
+    "resolved"
+  ],
+  "version": "1.1.0"
 }

rules/analyze/ANALYZE-APP-013.json

@@ -5,8 +5,12 @@
   "description": "Detects when the Enrollment Status Page failed because Intune could not verify an app was installed (HRESULT 0x87D1041C). The installer ran but the detection rule did not match afterwards.",
   "severity": "critical",
   "category": "apps",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "baseConfidence": 90,
   "preconditions": [
     {
@@ -69,8 +73,20 @@
     }
   ],
   "relatedDocs": [
-    { "title": "Microsoft Learn: Troubleshoot Windows Autopilot ESP error codes", "url": "https://learn.microsoft.com/en-us/autopilot/troubleshoot-tsg" },
-    { "title": "Win32 app detection rules in Intune", "url": "https://learn.microsoft.com/en-us/mem/intune/apps/apps-win32-add#step-4-detection-rules" }
+    {
+      "title": "Microsoft Learn: Troubleshoot Windows Autopilot ESP error codes",
+      "url": "https://learn.microsoft.com/en-us/autopilot/troubleshoot-tsg"
+    },
+    {
+      "title": "Win32 app detection rules in Intune",
+      "url": "https://learn.microsoft.com/en-us/mem/intune/apps/apps-win32-add#step-4-detection-rules"
+    }
   ],
-  "tags": ["apps", "detection", "esp", "0x87d1041c", "intune"]
+  "tags": [
+    "apps",
+    "detection",
+    "esp",
+    "0x87d1041c",
+    "intune"
+  ]
 }

rules/analyze/ANALYZE-APP-014.json

@@ -5,8 +5,12 @@
   "description": "Detects when the Enrollment Status Page failed on the Apps subcategory and the agent's AppX deployment log scan identified a suspected MSIX/Store package. Store/MSIX apps install outside the Win32 pipeline, so the regular per-app tracking sees nothing — this correlation names the likely culprit.",
   "severity": "warning",
   "category": "apps",
-  "version": "1.0.0",
+  "version": "1.2.0",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "baseConfidence": 75,
   "preconditions": [
     {
@@ -35,6 +39,51 @@
       "operator": "regex",
       "value": "^0x80073[cd]",
       "required": false
+    },
+    {
+      "signal": "appx_esp_category",
+      "source": "event_data",
+      "eventType": "esp_appx_failure_analysis",
+      "dataField": "espCategory",
+      "operator": "exists",
+      "value": "",
+      "required": false
+    },
+    {
+      "signal": "appx_esp_errorcode",
+      "source": "event_data",
+      "eventType": "esp_appx_failure_analysis",
+      "dataField": "espErrorCode",
+      "operator": "exists",
+      "value": "",
+      "required": false
+    },
+    {
+      "signal": "appx_top_candidate_package",
+      "source": "event_data",
+      "eventType": "esp_appx_failure_analysis",
+      "dataField": "topCandidatePackage",
+      "operator": "exists",
+      "value": "",
+      "required": false
+    },
+    {
+      "signal": "appx_candidate_count",
+      "source": "event_data",
+      "eventType": "esp_appx_failure_analysis",
+      "dataField": "candidateCount",
+      "operator": "exists",
+      "value": "",
+      "required": false
+    },
+    {
+      "signal": "appx_scan_confidence",
+      "source": "event_data",
+      "eventType": "esp_appx_failure_analysis",
+      "dataField": "confidence",
+      "operator": "exists",
+      "value": "",
+      "required": false
     }
   ],
   "explanation": "The ESP **{{espCategory}}/Apps** subcategory failed with HRESULT **{{espErrorCode}}** — an error from the AppX/MSIX deployment stack, i.e. a **Microsoft Store / MSIX app**, not a Win32 app. These apps install via the EnterpriseModernAppManagement CSP and never appear in the IME Win32 sidecar logs, which is why all tracked Win32/WinGet apps in this session can look green while ESP still reports an Apps failure.\n\nThe agent scanned the AppXDeploymentServer event log during the failure settle window and identified **{{topCandidatePackageName}}** (package `{{topCandidatePackage}}`) as the most likely culprit — its deployment error matches the ESP failure code ({{candidateCount}} candidate(s) total, confidence: {{confidence}}).\n\n**This is a correlation-based assessment, not a confirmed root cause** — validate against the AppXDeploymentServer/Operational event log on the device or in the diagnostics archive before acting.",
@@ -65,8 +114,21 @@
     }
   ],
   "relatedDocs": [
-    { "title": "Microsoft Learn: Troubleshoot Windows Autopilot ESP error codes", "url": "https://learn.microsoft.com/en-us/autopilot/troubleshoot-tsg" },
-    { "title": "Add Microsoft Store apps to Intune", "url": "https://learn.microsoft.com/en-us/mem/intune/apps/store-apps-microsoft" }
+    {
+      "title": "Microsoft Learn: Troubleshoot Windows Autopilot ESP error codes",
+      "url": "https://learn.microsoft.com/en-us/autopilot/troubleshoot-tsg"
+    },
+    {
+      "title": "Add Microsoft Store apps to Intune",
+      "url": "https://learn.microsoft.com/en-us/mem/intune/apps/store-apps-microsoft"
+    }
   ],
-  "tags": ["apps", "appx", "msix", "store", "esp", "0x80073cf9"]
+  "tags": [
+    "apps",
+    "appx",
+    "msix",
+    "store",
+    "esp",
+    "0x80073cf9"
+  ]
 }

rules/analyze/ANALYZE-APP-015.json

@@ -0,0 +1,80 @@
+{
+  "$schema": "../schema/analyze-rule.schema.json",
+  "ruleId": "ANALYZE-APP-015",
+  "title": "Required App Never Settled — ESP Completion Deferred",
+  "description": "The IME reported its user-session completion line, but at least one required app stayed pending — without ever failing or even starting to install — so the agent kept deferring the enrollment completion signal. Typically an assignment/requirement problem (requirement rules never met, dependency never satisfied, or the app needs a context that is not available during ESP, e.g. a VPN client waiting for user sign-in to a portal).",
+  "severity": "high",
+  "category": "apps",
+  "version": "1.0.0",
+  "author": "Autopilot Monitor",
+  "enabled": true,
+  "trigger": "correlation",
+  "baseConfidence": 60,
+  "confidenceThreshold": 55,
+  "preconditions": [
+    {
+      "source": "event_data",
+      "eventType": "enrollment_complete",
+      "operator": "not_exists",
+      "description": "Suppress when the pending app eventually settled and the enrollment completed — a transient deferral is normal."
+    },
+    {
+      "source": "event_data",
+      "eventType": "enrollment_failed",
+      "operator": "not_exists",
+      "description": "Suppress when the session failed explicitly — the app/ESP failure rules already cover that path; this rule targets the never-finishing case."
+    }
+  ],
+  "conditions": [
+    {
+      "signal": "completion_deferred",
+      "source": "event_type",
+      "eventType": "agent_trace",
+      "dataField": "message",
+      "operator": "contains",
+      "value": "completion signal deferred",
+      "required": true
+    },
+    {
+      "signal": "apps_pending",
+      "source": "event_data",
+      "eventType": "app_tracking_summary",
+      "dataField": "pending",
+      "operator": "gte",
+      "value": "1",
+      "required": true
+    },
+    {
+      "signal": "pending_app_names",
+      "source": "event_data",
+      "eventType": "app_tracking_summary",
+      "dataField": "pendingNames",
+      "operator": "exists",
+      "value": "",
+      "required": false
+    }
+  ],
+  "confidenceFactors": [
+    { "signal": "pending_app_names", "condition": "exists", "weight": 5 }
+  ],
+  "explanation": "The Intune Management Extension wrote its user-session completion line, but the agent observed `{{pending}}` required app(s) still pending (`{{pendingNames}}`) and therefore **deferred the enrollment completion signal** — repeatedly, if this happened across several logons or reboots.\n\nA pending app that never transitions to downloading/installing and never fails is almost always an **assignment or requirement problem**, not an install error:\n\n- requirement rules that are never met on this device (OS/architecture/registry/script checks),\n- an unsatisfied dependency or supersedence chain,\n- an app targeted as *required* for the user ESP that needs something unavailable during provisioning (e.g. a VPN client whose portal sign-in only happens after first logon),\n- user-targeted apps on a device where the user identity never fully registered (see the hybrid user-affinity rule if it also fired).",
+  "remediation": [
+    {
+      "title": "Identify and unblock the pending app",
+      "steps": [
+        "Check the app names listed in this finding's evidence (pendingNames) — these are the apps the ESP is waiting for.",
+        "In Intune, review the app's requirement rules and dependencies; test them on the device (IntuneManagementExtension.log logs each requirement evaluation).",
+        "Decide whether the app really must block the ESP: removing it from the ESP's 'blocking apps' list (or making it not-required during enrollment) unblocks completion immediately.",
+        "If the app is user-targeted on a hybrid-joined device, verify the user's Entra affinity first — without a signed-in Entra user, user-targeted policy never applies."
+      ]
+    }
+  ],
+  "relatedDocs": [
+    {
+      "title": "Microsoft Learn: Enrollment Status Page — blocking apps",
+      "url": "https://learn.microsoft.com/en-us/intune/intune-service/enrollment/windows-enrollment-status"
+    }
+  ],
+  "markSessionAsFailedDefault": false,
+  "tags": ["apps", "esp", "completion", "assignment", "pending"]
+}

rules/analyze/ANALYZE-APP-016.json

@@ -0,0 +1,113 @@
+{
+  "$schema": "../schema/analyze-rule.schema.json",
+  "ruleId": "ANALYZE-APP-016",
+  "title": "Required Apps Never Started — ESP Apps Gate Starved",
+  "description": "One or more required user-ESP apps never started installing while the ESP AccountSetup apps gate waited on them — the agent observed the ESP page exit with those apps still in a non-terminal, never-started state. Unlike ANALYZE-APP-015 (which reports that completion was DEFERRED because of a pending app, and stays silent once the session reaches a terminal verdict) this rule reports the delivery gap itself and fires regardless of the final outcome: an enrollment that Windows called done while required apps never ran is a successful enrollment with missing software, and the operator must see it.",
+  "severity": "warning",
+  "category": "apps",
+  "version": "1.0.0",
+  "author": "Autopilot Monitor",
+  "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed",
+    "on_event:session_stalled"
+  ],
+  "trigger": "single",
+  "baseConfidence": 75,
+  "confidenceThreshold": 70,
+  "conditions": [
+    {
+      "signal": "starved_apps_present",
+      "source": "event_count",
+      "eventType": "app_install_starved",
+      "operator": "count_gte",
+      "value": "1",
+      "required": true
+    },
+    {
+      "signal": "many_starved_apps",
+      "source": "event_count",
+      "eventType": "app_install_starved",
+      "operator": "count_gte",
+      "value": "5",
+      "required": false
+    },
+    {
+      "signal": "appName",
+      "source": "event_type",
+      "eventType": "app_install_starved",
+      "dataField": "appName",
+      "operator": "exists",
+      "value": "",
+      "required": false
+    },
+    {
+      "signal": "state",
+      "source": "event_type",
+      "eventType": "app_install_starved",
+      "dataField": "state",
+      "operator": "exists",
+      "value": "",
+      "required": false
+    }
+  ],
+  "confidenceFactors": [
+    {
+      "signal": "many_starved_apps",
+      "condition": "exists",
+      "weight": 15
+    },
+    {
+      "signal": "appName",
+      "condition": "exists",
+      "weight": 10
+    }
+  ],
+  "explanation": "At least one **required** app assigned to the user ESP never started installing. The Intune Management Extension never moved it out of its initial state (`{{state}}`) — it did not download, did not install, and did not fail — while the ESP AccountSetup apps gate was waiting on it. First app observed: `{{appName}}`.\n\nEvery starved app has its own `app_install_starved` timeline event carrying `appId`, `appName` and `state` — open the timeline and filter on that event type for the complete list.\n\nThis is a **delivery** problem, not an install error, and it is invisible in the Intune console: the app simply never appears. Typical causes:\n\n- far more required apps targeted at the ESP than the gate can service in the available window,\n- requirement rules that are never met on this device (OS / architecture / registry / script checks),\n- an unsatisfied dependency or supersedence chain,\n- an app that needs a context unavailable during provisioning (e.g. a VPN client waiting on a portal sign-in),\n- a mid-ESP reboot that cut the gate short — check whether the mid-ESP reboot advisory also fired for this session.\n\nNote that this finding is independent of the session verdict. A session can be marked **Succeeded** and still be missing every app listed here.",
+  "remediation": [
+    {
+      "title": "Shrink the ESP blocking set",
+      "steps": [
+        "Open the Enrollment Status Page profile and review the blocking app list — every required app there must finish before the user reaches the desktop.",
+        "Move apps that do not have to be present at first logon from *required* to *available*, or remove them from the ESP's blocking apps selection.",
+        "Prefer a small, deliberately chosen blocking set (security agent, VPN, management tooling) over the full application catalogue."
+      ]
+    },
+    {
+      "title": "Unblock the individual apps",
+      "steps": [
+        "Collect the app names from the `app_install_starved` timeline events in this session.",
+        "For each app, review its requirement rules and dependencies in Intune — IntuneManagementExtension.log records every requirement evaluation.",
+        "Verify the assignment actually targets the signed-in user (user-targeted apps need an established Entra user affinity; check the hybrid user-affinity finding if it also fired).",
+        "Re-run an enrollment and confirm the apps now reach a terminal state before the ESP exits."
+      ]
+    },
+    {
+      "title": "Rule out a truncated gate",
+      "steps": [
+        "Check whether a mid-ESP reboot was observed for this session — a forced restart during AccountSetup cuts the apps gate short and can starve everything still queued.",
+        "If so, reassign the reboot-forcing device policies to user groups so the restart lands after AccountSetup."
+      ]
+    }
+  ],
+  "relatedDocs": [
+    {
+      "title": "Microsoft Learn: Enrollment Status Page — blocking apps",
+      "url": "https://learn.microsoft.com/en-us/intune/intune-service/enrollment/windows-enrollment-status"
+    },
+    {
+      "title": "Microsoft Learn: Win32 app requirement rules",
+      "url": "https://learn.microsoft.com/en-us/intune/intune-service/apps/apps-win32-add"
+    }
+  ],
+  "markSessionAsFailedDefault": false,
+  "tags": [
+    "apps",
+    "esp",
+    "starvation",
+    "assignment",
+    "blocking",
+    "delivery-gap"
+  ]
+}

rules/analyze/ANALYZE-APP-017.json

@@ -0,0 +1,92 @@
+{
+  "$schema": "../schema/analyze-rule.schema.json",
+  "ruleId": "ANALYZE-APP-017",
+  "title": "App Install Blocked by Another Installer (0x80070652)",
+  "description": "Detects Win32 app installs that failed because the Windows Installer was busy with another installation (HRESULT 0x80070652 / MSI exit code 1618, ERROR_INSTALL_ALREADY_RUNNING). The IME retries on a fixed budget (~15-17 minutes across several attempts) and then reports the app as failed; when the app is ESP-blocking, the Device Setup Apps subcategory terminates with it.",
+  "severity": "high",
+  "category": "apps",
+  "version": "1.0.0",
+  "author": "Autopilot Monitor",
+  "enabled": true,
+  "baseConfidence": 70,
+  "conditions": [
+    {
+      "signal": "mutex_blocked_install",
+      "source": "event_type",
+      "eventType": "app_install_failed",
+      "dataField": "hresultFromWin32",
+      "operator": "equals",
+      "value": "-2147023278",
+      "required": true
+    },
+    {
+      "signal": "installer_exit_1618",
+      "source": "event_data",
+      "eventType": "app_install_failed",
+      "dataField": "exitCode",
+      "operator": "equals",
+      "value": "1618",
+      "required": false
+    },
+    {
+      "signal": "esp_failed_with_mutex_code",
+      "source": "event_data",
+      "eventType": "esp_failure_settle_started",
+      "dataField": "errorCode",
+      "operator": "equals",
+      "value": "0x80070652",
+      "required": false
+    }
+  ],
+  "confidenceFactors": [
+    {
+      "signal": "installer_exit_1618",
+      "condition": "exists",
+      "weight": 10
+    },
+    {
+      "signal": "esp_failed_with_mutex_code",
+      "condition": "exists",
+      "weight": 20
+    }
+  ],
+  "confidenceThreshold": 65,
+  "explanation": "App **{{appName}}** failed to install because the Windows Installer service was already busy with another installation — HRESULT **0x80070652** / MSI exit code **1618** (`ERROR_INSTALL_ALREADY_RUNNING`). Only one Windows Installer transaction can run at a time; the Intune Management Extension retried on its fixed budget (typically ~15-17 minutes across several attempts) and then reported the app as failed. If this app is required in the Enrollment Status Page, the Device Setup Apps subcategory fails with it and the enrollment terminates.\n\nThis failure is **deterministic per attempt**: as long as the competing installer keeps winning the race, a plain re-enrollment fails again at roughly the same minute mark — retrying without fixing the collision only churns devices.\n\nCommon sources of the competing installation:\n\n- The **preceding Win32 app in the install order**: its installer exits 0 (so IME moves on) but leaves a child `msiexec` transaction or post-install MSI work running. Security agents and proxy clients that chain multiple MSIs are frequent offenders.\n- **OEM factory software** installing on first boot (factory-image provisioning packages, vendor updaters) — typical on brand-new hardware batches.\n- **Microsoft 365 Apps (C2R), driver updaters or Windows servicing** running installations in parallel outside IME's control.",
+  "remediation": [
+    {
+      "title": "Identify the competing installer",
+      "steps": [
+        "In this session's timeline, note which app finished installing immediately before {{appName}} started — its installer is the prime suspect for holding the Windows Installer mutex",
+        "On a reproduction device, when the failure window is active, check for running installers: Get-Process msiexec | Select-Object Id,StartTime and the in-progress marker key HKLM\\SOFTWARE\\Microsoft\\Windows\\Installer\\InProgress",
+        "Check the Application event log for MsiInstaller events around the failure timestamp to see which product held the transaction",
+        "On factory-fresh hardware, also look for OEM first-boot installers (vendor updater services, factory provisioning packages) that run outside Intune"
+      ]
+    },
+    {
+      "title": "Serialize the install chain",
+      "steps": [
+        "Add an Intune Win32 dependency so {{appName}} depends on the app whose installer causes the collision — IME then orders them explicitly instead of racing",
+        "Alternatively, wrap the offending predecessor so its install script waits until msiexec has fully finished (poll the InProgress registry key or the _MSIExecute mutex with a bounded timeout) before exiting",
+        "If the app does not have to gate the ESP, remove it from the blocking-app list so a transient 1618 no longer terminates the enrollment; Intune retries it after the desktop"
+      ]
+    }
+  ],
+  "relatedDocs": [
+    {
+      "title": "Microsoft Learn: MsiExec.exe error messages (1618 = another installation is in progress)",
+      "url": "https://learn.microsoft.com/en-us/windows/win32/msi/error-codes"
+    },
+    {
+      "title": "Microsoft Learn: Troubleshoot Win32 app installations in Intune",
+      "url": "https://learn.microsoft.com/en-us/troubleshoot/mem/intune/app-management/troubleshoot-win32-app-install"
+    }
+  ],
+  "tags": [
+    "apps",
+    "msiexec",
+    "mutex",
+    "0x80070652",
+    "1618",
+    "esp"
+  ]
+}

rules/analyze/ANALYZE-CORR-003.json

@@ -5,8 +5,13 @@
   "description": "Correlates an active proxy configuration with app content download failures (Delivery Optimization timeout or download error), suggesting the proxy is blocking or throttling Intune content delivery.",
   "severity": "high",
   "category": "apps",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed",
+    "on_event:app_install_failed"
+  ],
   "trigger": "correlation",
   "baseConfidence": 60,
   "conditions": [
@@ -30,8 +35,16 @@
     }
   ],
   "confidenceFactors": [
-    { "signal": "app_install_failed", "condition": "count >= 2", "weight": 15 },
-    { "signal": "enrollment_failed", "condition": "count >= 1", "weight": 10 }
+    {
+      "signal": "app_install_failed",
+      "condition": "count >= 2",
+      "weight": 15
+    },
+    {
+      "signal": "enrollment_failed",
+      "condition": "count >= 1",
+      "weight": 10
+    }
   ],
   "confidenceThreshold": 50,
   "explanation": "A proxy (explicit or PAC-based) is configured on this device and app content downloads failed (Delivery Optimization timeout or download content error). Proxies can block or throttle downloads from *.delivery.mp.microsoft.com and other Intune CDN endpoints.\n\nThis is a common root cause when app downloads fail consistently on proxy-connected corporate networks. Note this rule only fires when the failure is download-related — generic app install errors behind a proxy do not trigger it.",
@@ -54,5 +67,12 @@
       ]
     }
   ],
-  "tags": ["correlation", "apps", "proxy", "network", "download", "root-cause"]
+  "tags": [
+    "correlation",
+    "apps",
+    "proxy",
+    "network",
+    "download",
+    "root-cause"
+  ]
 }

rules/analyze/ANALYZE-DEV-002.json

@@ -5,8 +5,12 @@
   "description": "Detects when memory usage stays above 90% across at least 3 performance snapshots during enrollment, indicating sustained memory pressure that can cause app installation failures or system instability.",
   "severity": "warning",
   "category": "device",
-  "version": "2.0.0",
+  "version": "2.1.0",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "baseConfidence": 55,
   "conditions": [
     {
@@ -38,8 +42,16 @@
     }
   ],
   "confidenceFactors": [
-    { "signal": "app_failed", "condition": "exists", "weight": 20 },
-    { "signal": "enrollment_failed", "condition": "exists", "weight": 15 }
+    {
+      "signal": "app_failed",
+      "condition": "exists",
+      "weight": 20
+    },
+    {
+      "signal": "enrollment_failed",
+      "condition": "exists",
+      "weight": 15
+    }
   ],
   "explanation": "Memory usage exceeded 90% in at least 3 performance snapshots during this enrollment — sustained pressure, not a single transient spike. Persistent high memory usage can cause app installation failures, system slowdowns, and ESP timeouts, especially on devices with 8 GB RAM installing several apps concurrently.",
   "remediation": [
@@ -53,5 +65,9 @@
       ]
     }
   ],
-  "tags": ["device", "memory", "performance"]
+  "tags": [
+    "device",
+    "memory",
+    "performance"
+  ]
 }

rules/analyze/ANALYZE-DEV-003.json

@@ -5,8 +5,12 @@
   "description": "Detects devices enrolling with an OS build that has reached end of support: Windows 11 22H2 (build 22621) or older, which includes every Windows 10 build. Maintenance note: raise the build cutoff to 22631 after Windows 11 23H2 reaches end of support on 2026-11-10.",
   "severity": "warning",
   "category": "device",
-  "version": "2.0.0",
+  "version": "2.1.0",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "baseConfidence": 90,
   "conditions": [
     {
@@ -52,5 +56,11 @@
       "url": "https://learn.microsoft.com/en-us/lifecycle/products/windows-11-home-and-pro"
     }
   ],
-  "tags": ["device", "os-version", "end-of-support", "windows-11", "windows-10"]
+  "tags": [
+    "device",
+    "os-version",
+    "end-of-support",
+    "windows-11",
+    "windows-10"
+  ]
 }

rules/analyze/ANALYZE-DEV-004.json

@@ -5,8 +5,13 @@
   "description": "Detects a Windows quality/cumulative update that FAILED to install during the OOBE / ESP enrollment window (WindowsUpdateClient EventID 20). A cumulative update failing mid-OOBE is a known cause of enrollment errors and is otherwise invisible in the Intune console.",
   "severity": "high",
   "category": "device",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed",
+    "on_event:windows_update_failed"
+  ],
   "trigger": "single",
   "baseConfidence": 70,
   "confidenceThreshold": 60,
@@ -65,8 +70,16 @@
     }
   ],
   "confidenceFactors": [
-    { "signal": "enrollment_failed", "condition": "exists", "weight": 20 },
-    { "signal": "reboot_pending", "condition": "exists", "weight": 10 }
+    {
+      "signal": "enrollment_failed",
+      "condition": "exists",
+      "weight": 20
+    },
+    {
+      "signal": "reboot_pending",
+      "condition": "exists",
+      "weight": 10
+    }
   ],
   "explanation": "A Windows Update failed to install during enrollment: **{{updateTitle}}** (error {{hresult}} {{hresultSymbol}}). Windows can install quality/cumulative updates during OOBE (the \"Getting updates\" screen and the ESP \"Install Windows quality updates during OOBE\" option). When one of these fails mid-enrollment it can leave the device in an inconsistent state, force an unexpected reboot, or block the Enrollment Status Page — a failure mode that is otherwise only discoverable by deep manual digging on the device.",
   "remediation": [
@@ -87,5 +100,10 @@
     }
   ],
   "markSessionAsFailedDefault": false,
-  "tags": ["device", "windows-update", "oobe", "servicing"]
+  "tags": [
+    "device",
+    "windows-update",
+    "oobe",
+    "servicing"
+  ]
 }

rules/analyze/ANALYZE-DEV-005.json

@@ -5,8 +5,12 @@
   "description": "Informational: a Windows quality/cumulative update installed during the OOBE / ESP enrollment window (WindowsUpdateClient EventID 19). Surfaces updates applied mid-enrollment — useful context when correlating enrollment duration, reboots, or later issues with a specific KB.",
   "severity": "info",
   "category": "device",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "trigger": "single",
   "baseConfidence": 60,
   "confidenceThreshold": 50,
@@ -39,7 +43,11 @@
     }
   ],
   "confidenceFactors": [
-    { "signal": "reboot_pending", "condition": "exists", "weight": 15 }
+    {
+      "signal": "reboot_pending",
+      "condition": "exists",
+      "weight": 15
+    }
   ],
   "explanation": "One or more Windows updates installed during enrollment (e.g. **{{updateTitle}}**). This is normal when Windows Update runs during OOBE, but it extends enrollment time and can trigger a reboot mid-ESP. Track it when correlating enrollment duration or reboot count with a specific cumulative update, or when a device behaves differently after a particular KB landed during provisioning.",
   "remediation": [
@@ -53,5 +61,9 @@
     }
   ],
   "markSessionAsFailedDefault": false,
-  "tags": ["device", "windows-update", "oobe"]
+  "tags": [
+    "device",
+    "windows-update",
+    "oobe"
+  ]
 }

rules/analyze/ANALYZE-DEV-006.json

@@ -5,8 +5,12 @@
   "description": "Informational: the OS build (CurrentBuild.UBR) changed across a reboot during enrollment — an update was installed, regardless of which servicing path delivered it. Deterministic corroboration that works even when the Windows Update event channel shows nothing (registry comparison across restart cannot be lost to timing or logging-path differences).",
   "severity": "info",
   "category": "device",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "trigger": "single",
   "baseConfidence": 70,
   "confidenceThreshold": 50,
@@ -47,7 +51,11 @@
     }
   ],
   "confidenceFactors": [
-    { "signal": "wu_channel_blind", "condition": "exists", "weight": 10 }
+    {
+      "signal": "wu_channel_blind",
+      "condition": "exists",
+      "weight": 10
+    }
   ],
   "explanation": "The OS build changed from **{{previousBuild}}** to **{{currentBuild}}** across a reboot during enrollment — a Windows update was installed mid-provisioning. This is normal when quality updates run during OOBE, but it adds a reboot and extends enrollment time. If a windows_update_channel_census event is also present, the update installed via a servicing path the Windows Update watcher does not capture yet — its EventID histogram tells which IDs to enable.",
   "remediation": [
@@ -61,5 +69,10 @@
     }
   ],
   "markSessionAsFailedDefault": false,
-  "tags": ["device", "windows-update", "oobe", "reboot"]
+  "tags": [
+    "device",
+    "windows-update",
+    "oobe",
+    "reboot"
+  ]
 }

rules/analyze/ANALYZE-DEV-007.json

@@ -2,12 +2,16 @@
   "$schema": "../schema/analyze-rule.schema.json",
   "ruleId": "ANALYZE-DEV-007",
   "title": "System Clock Skew — TPM Attestation and ESP Timeout Risk",
-  "description": "The device's real-time clock deviates from NTP by more than two minutes. Microsoft documents that a clock off by several minutes causes TPM attestation errors (self-deploying/pre-provisioning) and ESP timeouts. Knowledge source: docs/agent/autopilot-ztd-diagnostics.md.",
+  "description": "The device's real-time clock deviates from NTP by more than two minutes. Microsoft documents that a clock off by several minutes causes TPM attestation errors (self-deploying/pre-provisioning) and ESP timeouts.",
   "severity": "warning",
   "category": "device",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "author": "Autopilot Monitor",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "trigger": "single",
   "baseConfidence": 55,
   "confidenceThreshold": 50,
@@ -55,5 +59,12 @@
     }
   ],
   "markSessionAsFailedDefault": false,
-  "tags": ["device", "ntp", "clock-skew", "tpm", "esp", "known-issue"]
+  "tags": [
+    "device",
+    "ntp",
+    "clock-skew",
+    "tpm",
+    "esp",
+    "known-issue"
+  ]
 }

rules/analyze/ANALYZE-DEV-008.json

@@ -0,0 +1,69 @@
+{
+  "$schema": "../schema/analyze-rule.schema.json",
+  "ruleId": "ANALYZE-DEV-008",
+  "title": "Device Clock Wrong During Enrollment — Jump or Sustained Offset",
+  "description": "The device's clock changed by five or more minutes mid-session (clock jump) or ran five or more minutes off server time for the whole session (sustained offset), measured against the server receive frame of every uploaded event. Complements ANALYZE-DEV-007, which is a one-shot NTP check at agent startup and misses devices where NTP was unreachable or the clock changed later. IME-log-derived events are excluded from the measurement.",
+  "severity": "warning",
+  "category": "device",
+  "version": "1.0.0",
+  "author": "Autopilot Monitor",
+  "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
+  "trigger": "single",
+  "baseConfidence": 60,
+  "confidenceThreshold": 50,
+  "conditions": [
+    {
+      "signal": "clock_jump",
+      "source": "clock_skew",
+      "skewMetric": "clock_jump",
+      "operator": "gte",
+      "value": "300",
+      "required": false
+    },
+    {
+      "signal": "sustained_offset",
+      "source": "clock_skew",
+      "skewMetric": "sustained_offset",
+      "operator": "gte",
+      "value": "300",
+      "required": false
+    }
+  ],
+  "confidenceFactors": [],
+  "explanation": "This device's {{skewSummary}} (five-minute threshold). A clock that is off by five or more minutes breaks time-sensitive enrollment mechanisms: Kerberos tolerates at most 5 minutes of skew (Hybrid Join), Entra ID token validation allows about 5 minutes on token lifetimes, and freshly issued SCEP/PKCS certificates can be rejected as \"not yet valid\" when the clock is more than ~10 minutes behind the CA.\n\nUnlike ANALYZE-DEV-007 (a one-shot NTP comparison at agent startup), this finding is measured across the whole session against the server's receive time — it also catches devices where the NTP check could not run (UDP 123 blocked) or where the clock changed after startup (time sync correcting a wrong RTC, Windows auto-timezone, manual change).",
+  "remediation": [
+    {
+      "title": "Fix the device clock and time source",
+      "steps": [
+        "Check the BIOS/RTC clock and the CMOS battery if the wrong time recurs on the same hardware.",
+        "At OOBE, run 'w32tm /resync /force' (Shift+F10 command prompt) to sync with time.windows.com.",
+        "Ensure UDP port 123 to time.windows.com is open in the deployment network.",
+        "Review 'Set time automatically' and 'Set time zone automatically' behavior on the deployment image — automatic timezone changes mid-enrollment show up as clock jumps."
+      ]
+    }
+  ],
+  "relatedDocs": [
+    {
+      "title": "Microsoft Learn: Windows Autopilot known issues — device provisioning can fail (clock skew)",
+      "url": "https://learn.microsoft.com/en-us/autopilot/known-issues"
+    },
+    {
+      "title": "Microsoft Learn: Windows Autopilot requirements — Networking (NTP)",
+      "url": "https://learn.microsoft.com/en-us/autopilot/requirements?tabs=networking"
+    }
+  ],
+  "markSessionAsFailedDefault": false,
+  "tags": [
+    "device",
+    "clock-skew",
+    "clock-jump",
+    "time-sync",
+    "kerberos",
+    "certificates",
+    "known-issue"
+  ]
+}

rules/analyze/ANALYZE-DEV-009.json

@@ -0,0 +1,48 @@
+{
+  "$schema": "../schema/analyze-rule.schema.json",
+  "ruleId": "ANALYZE-DEV-009",
+  "title": "Battery Critically Low During Enrollment",
+  "description": "Detects that the device's battery dropped to 15% or less while enrolling on battery power (power_state_change threshold event from the agent's live power watcher). A device dying mid-enrollment leaves a half-provisioned state that typically needs a full reset; this rule surfaces the risk while there is still time to plug the device in. Uses a single required condition on the agent-stamped thresholdPercent field (the data field 'transition' on the event is unrelated to this rule's 'trigger' property).",
+  "severity": "high",
+  "category": "device",
+  "version": "1.0.0",
+  "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed",
+    "on_event:power_state_change"
+  ],
+  "trigger": "single",
+  "baseConfidence": 90,
+  "confidenceThreshold": 60,
+  "conditions": [
+    {
+      "signal": "battery_threshold_15",
+      "source": "event_data",
+      "eventType": "power_state_change",
+      "dataField": "thresholdPercent",
+      "operator": "equals",
+      "value": "15",
+      "required": true
+    }
+  ],
+  "explanation": "The device's battery fell below **{{thresholdPercent}}%** while the enrollment was running on battery power. If the battery drains completely mid-enrollment, the device is left in a half-provisioned state — apps, policies, or the user profile may be incomplete, and in most cases the device has to be reset and re-enrolled. The agent detected the threshold crossing live via a Windows power-status notification; the exact percentage at that moment is recorded on the matched power_state_change event in the session timeline.",
+  "remediation": [
+    {
+      "title": "Secure power for the running enrollment",
+      "steps": [
+        "Connect the device to AC power immediately — the enrollment continues normally once power is stable.",
+        "If the device shut down before completing, check whether the session reached the desktop; if not, reset the device (Autopilot reset or reimage) and re-enroll it plugged in.",
+        "For technician/White Glove flows, make AC power part of the bench checklist — pre-provisioning on battery is the most common source of this alert.",
+        "If this fires across many devices of one model, review that model's battery health (the hardware_spec event carries design vs. full-charge capacity)."
+      ]
+    }
+  ],
+  "markSessionAsFailedDefault": false,
+  "tags": [
+    "device",
+    "power",
+    "battery",
+    "environment"
+  ]
+}

rules/analyze/ANALYZE-DEV-010.json

@@ -0,0 +1,48 @@
+{
+  "$schema": "../schema/analyze-rule.schema.json",
+  "ruleId": "ANALYZE-DEV-010",
+  "title": "Enrollment Switched From AC to Battery Power",
+  "description": "Detects that the device lost AC power and switched to battery while the enrollment was running (power_state_change event with transition ac_to_battery from the agent's live power watcher). Uses a single required condition so the match is pinned to one event instance; the event payload carries the battery percentage at the moment of the switch. The agent debounces power flapping (5s) so a brief unplug/replug does not produce this event.",
+  "severity": "warning",
+  "category": "device",
+  "version": "1.0.0",
+  "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed",
+    "on_event:power_state_change"
+  ],
+  "trigger": "single",
+  "baseConfidence": 85,
+  "confidenceThreshold": 60,
+  "conditions": [
+    {
+      "signal": "switched_to_battery",
+      "source": "event_data",
+      "eventType": "power_state_change",
+      "dataField": "transition",
+      "operator": "equals",
+      "value": "ac_to_battery",
+      "required": true
+    }
+  ],
+  "explanation": "The device switched from AC to battery power mid-enrollment. Enrollments are power-hungry — app downloads, Windows Update and disk encryption drain a battery quickly, and Windows may also throttle CPU and network on battery, slowing the enrollment down. The battery percentage at the moment of the switch is recorded on the matched power_state_change event in the session timeline; if the device stayed on battery, look there for subsequent threshold events (50/30/15%) — a later battery_to_ac event means power was restored.",
+  "remediation": [
+    {
+      "title": "Restore AC power",
+      "steps": [
+        "Reconnect the device to AC power; the enrollment continues normally.",
+        "Check the session timeline for a subsequent battery_to_ac event (power restored) or threshold_crossed events (battery draining) to judge urgency.",
+        "If this alert is frequent in a deployment area, check docking stations/USB-C hubs for loose power delivery — a flapping dock is a common cause.",
+        "Make 'plugged in during setup' part of the end-user/technician enrollment instructions."
+      ]
+    }
+  ],
+  "markSessionAsFailedDefault": false,
+  "tags": [
+    "device",
+    "power",
+    "battery",
+    "environment"
+  ]
+}

rules/analyze/ANALYZE-DEV-012.json

@@ -0,0 +1,49 @@
+{
+  "$schema": "../schema/analyze-rule.schema.json",
+  "ruleId": "ANALYZE-DEV-012",
+  "title": "Device Entered Standby During Enrollment",
+  "description": "Detects that the device completed a sleep, hibernate or Modern Standby episode of at least 5 minutes while the enrollment was running (system_sleep_episode event from the agent's system timeline watcher, recorded retroactively at wake from the Windows event log — pre-agent episodes are backfilled). Uses a single required condition on the episode's durationSeconds so the match is pinned to one event instance and the interpolated duration is the matched value. Short Modern Standby screen-off scenarios (under 60 s of real sleep) never emit the event, and this rule adds a 5-minute floor so brief lid-close moments do not fire it.",
+  "severity": "info",
+  "category": "device",
+  "version": "1.0.0",
+  "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed",
+    "on_event:system_sleep_episode"
+  ],
+  "trigger": "single",
+  "baseConfidence": 90,
+  "confidenceThreshold": 60,
+  "conditions": [
+    {
+      "signal": "slept_during_enrollment",
+      "source": "event_data",
+      "eventType": "system_sleep_episode",
+      "dataField": "durationSeconds",
+      "operator": "gte",
+      "value": "300",
+      "required": true
+    }
+  ],
+  "explanation": "The device was asleep for {{durationSeconds}} seconds during the enrollment window. Nothing progresses while the device sleeps — downloads pause, the IME stops processing and the ESP simply waits — so the wall-clock enrollment duration includes this pause and can look much slower than the enrollment actually was. The matched system_sleep_episode event in the session timeline carries the exact enter/exit times, the episode kind (sleep, hibernate or Modern Standby) and, for Modern Standby, whether the device was on AC power. A long unexplained gap in the timeline right before that event is this pause, not missing telemetry.",
+  "remediation": [
+    {
+      "title": "Keep the device awake during enrollment",
+      "steps": [
+        "Check the matched system_sleep_episode event in the timeline for the episode bounds and kind — the enrollment duration minus the episode duration is the real active time.",
+        "If the device slept on battery, connect AC power during setup; Windows sleeps far more aggressively on battery.",
+        "Instruct users/technicians to keep the lid open and the device powered until the enrollment finishes.",
+        "For recurring cases, review the power plan applied during OOBE/ESP (e.g. via provisioning or Intune policy) — consider disabling sleep on AC for the enrollment window."
+      ]
+    }
+  ],
+  "markSessionAsFailedDefault": false,
+  "tags": [
+    "device",
+    "power",
+    "standby",
+    "sleep",
+    "environment"
+  ]
+}

rules/analyze/ANALYZE-ENRL-002.json

@@ -5,7 +5,7 @@
   "description": "Detects when the enrollment session was force-failed by the server-side inactivity timeout (no agent telemetry for the configured SessionTimeoutHours window) without ever completing or explicitly failing.",
   "severity": "high",
   "category": "enrollment",
-  "version": "1.0.0",
+  "version": "1.2.0",
   "enabled": true,
   "baseConfidence": 80,
   "preconditions": [
@@ -30,9 +30,35 @@
       "operator": "exists",
       "value": "",
       "required": true
+    },
+    {
+      "signal": "timeoutHours",
+      "source": "event_data",
+      "eventType": "session_timeout",
+      "dataField": "timeoutHours",
+      "operator": "exists",
+      "value": "",
+      "required": false
+    },
+    {
+      "signal": "desktop_was_reached",
+      "source": "event_type",
+      "eventType": "desktop_arrived",
+      "operator": "exists",
+      "value": "",
+      "required": false
+    },
+    {
+      "signal": "all_tracked_apps_completed",
+      "source": "event_data",
+      "eventType": "app_tracking_summary",
+      "dataField": "isAllCompleted",
+      "operator": "equals",
+      "value": "true",
+      "required": false
     }
   ],
-  "explanation": "The enrollment session was force-failed by the server-side maintenance sweep after `{{timeoutHours}}` hour(s) of agent inactivity — the device stopped sending telemetry and never reported completion or an explicit failure.\n\nThis usually means the agent process died or the device went offline mid-enrollment (power off, network loss, bluescreen, reimage) rather than a clean enrollment failure. Because there is no terminal `enrollment_failed` event, the more specific app/ESP rules cannot pinpoint a cause — the evidence simply stops at the last event before the gap.",
+  "explanation": "The enrollment session was force-failed by the server-side maintenance sweep after `{{timeoutHours}}` hour(s) of agent inactivity — the device stopped sending telemetry and never reported completion or an explicit failure.\n\nThis usually means the agent process died or the device went offline mid-enrollment (power off, network loss, bluescreen, reimage) rather than a clean enrollment failure. Because there is no terminal `enrollment_failed` event, the more specific app/ESP rules cannot pinpoint a cause — the evidence simply stops at the last event before the gap.\n\n**If the evidence shows the user desktop was reached and all tracked apps completed**, the device most likely got all its content but the ESP never signaled completion — on hybrid-joined devices the usual culprit is the user session never establishing Entra affinity (Account Setup re-running on every logon). Check whether the hybrid user-affinity finding also fired for this session.",
   "remediation": [
     {
       "title": "Investigate the silent session",
@@ -43,6 +69,13 @@
         "If the device is reachable, collect the agent + IME logs and re-run enrollment, correlating with the timeout timestamp",
         "If many sessions time out in the same window, check for a tenant-wide network/connectivity issue or an Intune service incident"
       ]
+    },
+    {
+      "title": "Desktop reached and apps done, but no completion",
+      "steps": [
+        "Sign in as the affected user and run dsregcmd /status — 'SSO State: AzureAdPrt' must be YES; NO means the user never registered with Entra and the Account Setup ESP will loop",
+        "Verify Entra Connect syncs both the computer object (userCertificate) and the signing-in user, and that the user's UPN suffix is a verified Entra domain"
+      ]
     }
   ],
   "tags": ["enrollment", "timeout", "stalled"]

rules/analyze/ANALYZE-ENRL-003.json

@@ -2,12 +2,17 @@
   "$schema": "../schema/analyze-rule.schema.json",
   "ruleId": "ANALYZE-ENRL-003",
   "title": "TPM Attestation Failure — Known Error Code",
-  "description": "A TPM-attestation-related error code documented in the Microsoft Autopilot known-issues list was observed (0x800705B4, 0x801C03EA, 0x81039001, 0x81039023, 0x81039024, 0x80070490). These block self-deploying and pre-provisioning deployments during 'Securing your hardware'. Observability: attestation precedes MDM enrollment, so in the normal deployment model (agent installed via IME after enrollment) these codes are rarely visible — the rule primarily serves bootstrap-token deployments. See docs/agent/autopilot-ztd-diagnostics.md (Observability section).",
+  "description": "A TPM-attestation-related error code documented in the Microsoft Autopilot known-issues list was observed (0x800705B4, 0x801C03EA, 0x81039001, 0x81039023, 0x81039024, 0x80070490). These block self-deploying and pre-provisioning deployments during 'Securing your hardware'. Observability: attestation precedes MDM enrollment, so in the normal deployment model (agent installed via IME after enrollment) these codes are rarely visible — the rule primarily serves bootstrap-token deployments.",
   "severity": "high",
   "category": "enrollment",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "author": "Autopilot Monitor",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed",
+    "on_event:modern_deployment_error"
+  ],
   "trigger": "single",
   "baseConfidence": 60,
   "confidenceThreshold": 55,
@@ -75,5 +80,12 @@
     }
   ],
   "markSessionAsFailedDefault": false,
-  "tags": ["enrollment", "tpm", "attestation", "self-deploying", "pre-provisioning", "known-issue"]
+  "tags": [
+    "enrollment",
+    "tpm",
+    "attestation",
+    "self-deploying",
+    "pre-provisioning",
+    "known-issue"
+  ]
 }

rules/analyze/ANALYZE-ENRL-004.json

@@ -2,12 +2,16 @@
   "$schema": "../schema/analyze-rule.schema.json",
   "ruleId": "ANALYZE-ENRL-004",
   "title": "MDM Enrollment Blocked — Known Error Code",
-  "description": "An enrollment-blocking error code documented in the Microsoft Autopilot known-issues/troubleshooting pages was observed (0x80180014, 0x80180018, 0xC1036501, 0x801C03F3, 0x80070774). Each has a specific, documented cause and fix. Observability: a blocked MDM enrollment normally means no agent gets installed at all (IME install happens after enrollment) — this rule can realistically only fire for bootstrap-token deployments (pre-MDM reporting) or mixed retry scenarios. See docs/agent/autopilot-ztd-diagnostics.md (Observability section).",
+  "description": "An enrollment-blocking error code documented in the Microsoft Autopilot known-issues/troubleshooting pages was observed (0x80180014, 0x80180018, 0xC1036501, 0x801C03F3, 0x80070774). Each has a specific, documented cause and fix. Observability: a blocked MDM enrollment normally means no agent gets installed at all (IME install happens after enrollment) — this rule can realistically only fire for bootstrap-token deployments (pre-MDM reporting) or mixed retry scenarios.",
   "severity": "high",
   "category": "enrollment",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "author": "Autopilot Monitor",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "trigger": "single",
   "baseConfidence": 60,
   "confidenceThreshold": 55,
@@ -74,5 +78,11 @@
     }
   ],
   "markSessionAsFailedDefault": false,
-  "tags": ["enrollment", "mdm", "known-issue", "entra-id", "hybrid-join"]
+  "tags": [
+    "enrollment",
+    "mdm",
+    "known-issue",
+    "entra-id",
+    "hybrid-join"
+  ]
 }

rules/analyze/ANALYZE-ENRL-005.json

@@ -2,12 +2,16 @@
   "$schema": "../schema/analyze-rule.schema.json",
   "ruleId": "ANALYZE-ENRL-005",
   "title": "Hybrid Join Timeout 0x80004005 — Fixed by Windows Update",
-  "description": "A Microsoft Entra hybrid join Autopilot deployment hit error 0x80004005 — a documented build-dependent known issue, resolved by KB5065789 (25H2, build >= 26200.6725), KB5065426 (24H2, build >= 26100.6584), and KB5070312 (23H2, build >= 22631.6276). Knowledge source: docs/agent/autopilot-ztd-diagnostics.md (error-code map).",
+  "description": "A Microsoft Entra hybrid join Autopilot deployment hit error 0x80004005 — a documented build-dependent known issue, resolved by KB5065789 (25H2, build >= 26200.6725), KB5065426 (24H2, build >= 26100.6584), and KB5070312 (23H2, build >= 22631.6276).",
   "severity": "high",
   "category": "enrollment",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "author": "Autopilot Monitor",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "trigger": "correlation",
   "baseConfidence": 25,
   "confidenceThreshold": 60,
@@ -59,10 +63,26 @@
     }
   ],
   "confidenceFactors": [
-    { "signal": "e_fail_esp_failure", "condition": "exists", "weight": 40 },
-    { "signal": "e_fail_esp_advisory", "condition": "exists", "weight": 35 },
-    { "signal": "e_fail_modern_deployment", "condition": "exists", "weight": 40 },
-    { "signal": "e_fail_error_detected", "condition": "exists", "weight": 35 }
+    {
+      "signal": "e_fail_esp_failure",
+      "condition": "exists",
+      "weight": 40
+    },
+    {
+      "signal": "e_fail_esp_advisory",
+      "condition": "exists",
+      "weight": 35
+    },
+    {
+      "signal": "e_fail_modern_deployment",
+      "condition": "exists",
+      "weight": 40
+    },
+    {
+      "signal": "e_fail_error_detected",
+      "condition": "exists",
+      "weight": 35
+    }
   ],
   "explanation": "This is a **Microsoft Entra hybrid join** deployment that hit error **0x80004005** — a documented, build-dependent Autopilot known issue where hybrid deployments time out.\n\nThe issue is fixed by Windows cumulative updates:\n\n- Windows 11 **25H2**: KB5065789 — fixed from build **26200.6725**\n- Windows 11 **24H2**: KB5065426 — fixed from build **26100.6584**\n- Windows 11 **23H2**: KB5070312 — fixed from build **22631.6276**\n\nCompare this session's OS build (see the Session Info card / os_info event) against the fixed-build threshold for its version. If the device booted with an older build, updating the deployment image (or installing quality updates during OOBE) resolves the timeout. Note that 0x80004005 is a generic failure code (E_FAIL) — if the build is already at or above the fixed threshold, investigate the Intune Connector for Active Directory and domain-controller connectivity instead.",
   "remediation": [
@@ -83,5 +103,11 @@
     }
   ],
   "markSessionAsFailedDefault": false,
-  "tags": ["enrollment", "hybrid-join", "known-issue", "windows-update", "esp"]
+  "tags": [
+    "enrollment",
+    "hybrid-join",
+    "known-issue",
+    "windows-update",
+    "esp"
+  ]
 }

rules/analyze/ANALYZE-ESP-001.json

@@ -5,8 +5,12 @@
   "description": "Detects when the DeviceSetup phase of the ESP took longer than 30 minutes, indicating a stuck or very slow blocking app. Confidence increases when the phase exceeds 60 minutes.",
   "severity": "high",
   "category": "esp",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "baseConfidence": 50,
   "conditions": [
     {
@@ -20,8 +24,16 @@
     }
   ],
   "confidenceFactors": [
-    { "signal": "long_esp", "condition": "phase_duration > 1800", "weight": 40 },
-    { "signal": "very_long_esp", "condition": "phase_duration > 3600", "weight": 15 }
+    {
+      "signal": "long_esp",
+      "condition": "phase_duration > 1800",
+      "weight": 40
+    },
+    {
+      "signal": "very_long_esp",
+      "condition": "phase_duration > 3600",
+      "weight": 15
+    }
   ],
   "confidenceThreshold": 70,
   "explanation": "The ESP DeviceSetup phase took more than 30 minutes. This indicates a blocking app is stuck installing, downloading very slowly, or has entered a retry loop. A duration beyond 60 minutes raises the confidence further — at that point the enrollment is almost certainly held by a single stuck blocking item rather than ordinary slowness.",
@@ -35,5 +47,10 @@
       ]
     }
   ],
-  "tags": ["esp", "blocking", "timeout", "duration"]
+  "tags": [
+    "esp",
+    "blocking",
+    "timeout",
+    "duration"
+  ]
 }

rules/analyze/ANALYZE-ESP-002.json

@@ -5,9 +5,13 @@
   "description": "Detects when the Certificates subcategory of the Enrollment Status Page reported a failure, even if the enrollment later appears to have succeeded. Users can click 'Continue anyway' on an ESP error, which masks the underlying certificate provisioning failure — this rule surfaces the transition so it stays visible.",
   "severity": "high",
   "category": "esp",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "author": "Autopilot Monitor",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "trigger": "single",
   "baseConfidence": 80,
   "conditions": [
@@ -54,5 +58,10 @@
     }
   ],
   "markSessionAsFailedDefault": false,
-  "tags": ["esp", "certificates", "subcategory", "silent-failure"]
+  "tags": [
+    "esp",
+    "certificates",
+    "subcategory",
+    "silent-failure"
+  ]
 }

rules/analyze/ANALYZE-ESP-005.json

@@ -0,0 +1,105 @@
+{
+  "$schema": "../schema/analyze-rule.schema.json",
+  "ruleId": "ANALYZE-ESP-005",
+  "title": "MDM Policy Forced a Mid-ESP Reboot (Second Sign-In)",
+  "description": "Attributes an observed enrollment reboot to device-assigned MDM policies that Windows flagged as reboot-required. Fires ONLY when both facts are present in the session: at least one actually-observed reboot (system_reboot_detected) AND reboot-required policy flags (mdm_policy_reboot_required). Policy flags alone — e.g. from a user-policy sync during AccountSetup — force no reboot and stay advisory-silent.",
+  "severity": "warning",
+  "category": "esp",
+  "version": "1.3.0",
+  "author": "Autopilot Monitor",
+  "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed",
+    "on_event:session_stalled"
+  ],
+  "trigger": "single",
+  "baseConfidence": 70,
+  "conditions": [
+    {
+      "signal": "reboot_forcing_policy_uri",
+      "source": "event_data",
+      "eventType": "mdm_policy_reboot_required",
+      "dataField": "firstRebootUri",
+      "operator": "exists",
+      "required": true
+    },
+    {
+      "signal": "reboot_observed",
+      "source": "event_count",
+      "eventType": "system_reboot_detected",
+      "operator": "count_gte",
+      "value": "1",
+      "required": true
+    },
+    {
+      "signal": "multiple_reboot_uris",
+      "source": "event_data",
+      "eventType": "mdm_policy_reboot_required",
+      "dataField": "uriCount",
+      "operator": "gte",
+      "value": "2",
+      "required": false
+    },
+    {
+      "signal": "omadm_reboot_flag_set",
+      "source": "event_data",
+      "eventType": "mdm_policy_reboot_required",
+      "dataField": "omadmRebootRequiredFlag",
+      "operator": "equals",
+      "value": "true",
+      "required": false
+    }
+  ],
+  "confidenceFactors": [
+    {
+      "signal": "multiple_reboot_uris",
+      "condition": "exists",
+      "weight": 10
+    },
+    {
+      "signal": "omadm_reboot_flag_set",
+      "condition": "exists",
+      "weight": 15
+    }
+  ],
+  "confidenceThreshold": 70,
+  "explanation": "This session **rebooted during enrollment**, and Windows flagged one or more device-assigned MDM policies as **reboot-required** — the classic cause of the coalesced mid-ESP restart and the unexpected **second sign-in screen** before AccountSetup.\n\nFirst reboot-forcing policy URI: `{{firstRebootUri}}`\n\nThe complete URI list is in the `mdm_policy_reboot_required` timeline event (`rebootUris`). Policies applied DURING ESP DeviceSetup are coalesced into one forced restart at the end of DeviceSetup; the same flags raised later (e.g. user-policy sync in AccountSetup) have no immediate effect — this advisory only fires when a reboot was actually observed.\n\nThis is expected OS behavior, not a failure — but it degrades the enrollment experience, confuses users, and is invisible in the Intune console.",
+  "remediation": [
+    {
+      "title": "Reassign the reboot-forcing policies to user groups",
+      "steps": [
+        "Open the `mdm_policy_reboot_required` timeline event and note the CSP URIs in `rebootUris` (e.g. `./Device/Vendor/MSFT/...`)",
+        "Map each URI to its Intune profile (Settings Catalog / configuration profile) — the URI path names the CSP area",
+        "Reassign those profiles from device groups to user groups so they apply during/after AccountSetup instead of DeviceSetup",
+        "Alternatively, exclude the Autopilot device group from the profile and deliver the setting post-enrollment"
+      ]
+    },
+    {
+      "title": "Or accept the reboot and set expectations",
+      "steps": [
+        "If the policy must be device-assigned (e.g. a security baseline), keep it and document the expected mid-ESP restart",
+        "Communicate to users that a restart and second sign-in during provisioning is expected for these deployments"
+      ]
+    }
+  ],
+  "relatedDocs": [
+    {
+      "title": "Patch My PC: Avoid the second sign-in screen after Autopilot",
+      "url": "https://patchmypc.com/blog/autopilot-unexpected-reboot-autopilot-second-login-screen/"
+    },
+    {
+      "title": "Microsoft Learn: Enrollment Status Page tracking",
+      "url": "https://learn.microsoft.com/en-us/autopilot/enrollment-status"
+    }
+  ],
+  "markSessionAsFailedDefault": false,
+  "tags": [
+    "esp",
+    "reboot",
+    "coalescing",
+    "second-sign-in",
+    "policy-attribution",
+    "user-experience"
+  ]
+}

rules/analyze/ANALYZE-ESP-006.json

@@ -0,0 +1,109 @@
+{
+  "$schema": "../schema/analyze-rule.schema.json",
+  "ruleId": "ANALYZE-ESP-006",
+  "title": "ESP Failure Recovered After User Retry",
+  "description": "Detects the recovery story: the ESP reported a terminal failure (typically DeviceSetup/Apps), the user most likely pressed 'Try again' on the failure page, the failed step re-ran and completed successfully. The earlier failure did not stick — the enrollment continued past it.",
+  "severity": "info",
+  "category": "esp",
+  "version": "1.1.0",
+  "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
+  "baseConfidence": 85,
+  "conditions": [
+    {
+      "signal": "advisory",
+      "source": "event_type",
+      "eventType": "esp_failure_advisory",
+      "operator": "exists",
+      "value": "",
+      "required": true
+    },
+    {
+      "signal": "recovered",
+      "source": "event_type",
+      "eventType": "esp_failure_recovered",
+      "operator": "exists",
+      "value": "",
+      "required": true
+    },
+    {
+      "signal": "retry",
+      "source": "event_type",
+      "eventType": "esp_failure_retry_detected",
+      "operator": "exists",
+      "value": "",
+      "required": false
+    },
+    {
+      "signal": "category",
+      "source": "event_type",
+      "eventType": "esp_failure_recovered",
+      "dataField": "category",
+      "operator": "exists",
+      "value": "",
+      "required": false
+    },
+    {
+      "signal": "failedSubcategory",
+      "source": "event_type",
+      "eventType": "esp_failure_recovered",
+      "dataField": "failedSubcategory",
+      "operator": "exists",
+      "value": "",
+      "required": false
+    },
+    {
+      "signal": "likelyCulpritApps",
+      "source": "event_type",
+      "eventType": "esp_failure_advisory",
+      "dataField": "likelyCulpritApps",
+      "operator": "exists",
+      "value": "",
+      "required": false
+    },
+    {
+      "signal": "minutesSinceFailure",
+      "source": "event_type",
+      "eventType": "esp_failure_recovered",
+      "dataField": "minutesSinceFailure",
+      "operator": "exists",
+      "value": "",
+      "required": false
+    }
+  ],
+  "confidenceFactors": [
+    {
+      "signal": "retry",
+      "condition": "exists",
+      "weight": 10
+    },
+    {
+      "signal": "likelyCulpritApps",
+      "condition": "exists",
+      "weight": 5
+    }
+  ],
+  "explanation": "The Enrollment Status Page reported a **failure** in the `{{category}}` phase (`{{failedSubcategory}}` subcategory, most likely app(s): `{{likelyCulpritApps}}`) — and then **recovered**: the failed step left its failed state and completed successfully about `{{minutesSinceFailure}}` min later.\n\nThat pattern is consistent with the user pressing **'Try again'** on the ESP failure page (the profile allows failure-page actions; the agent cannot observe the click itself). The failure the user saw was real, but it did not stick — the ESP re-ran the step, it succeeded, and the enrollment continued.\n\nRead the session timeline as one arc: `esp_failure_advisory` (the failure, with the likely culprit app) → `esp_failure_retry_detected` (the retry) → `esp_failure_recovered` (the recovery). If this pattern repeats across devices for the same app, that app's install is flaky on first attempt — fix the app rather than the devices. Any literal `{{…}}` placeholder means that detail was not recorded for this session.",
+  "remediation": [
+    {
+      "title": "Make the first install attempt stick",
+      "steps": [
+        "Check the likely culprit app(s) (`{{likelyCulpritApps}}`) in Intune: an app that fails on the first ESP pass but succeeds on retry usually has a dependency/ordering or detection-timing problem.",
+        "If the app shows 'never started installing' in esp_failure_settle_started, verify its assignment and applicability rules — ESP counted it as required, but IME never processed it.",
+        "If the pattern repeats across the tenant, consider removing the app from the ESP blocking list until the first-attempt install is reliable — users are seeing an avoidable failure screen.",
+        "No device-side action is needed for this session: the failure recovered and the enrollment continued."
+      ]
+    }
+  ],
+  "tags": [
+    "esp",
+    "recovery",
+    "try-again",
+    "retry",
+    "continue-anyway",
+    "enrollment"
+  ]
+}

rules/analyze/ANALYZE-ID-001.json

@@ -7,7 +7,11 @@
   "category": "identity",
   "isCommunity": true,
   "enabled": false,
-  "version": "1.2.0",
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
+  "version": "1.3.0",
   "baseConfidence": 75,
   "conditions": [
     {
@@ -50,7 +54,12 @@
       ]
     }
   ],
-  "tags": ["identity", "certificates", "machine-store", "subject-check"],
+  "tags": [
+    "identity",
+    "certificates",
+    "machine-store",
+    "subject-check"
+  ],
   "templateVariables": [
     {
       "name": "cert_subject",

rules/analyze/ANALYZE-ID-002.json

@@ -5,9 +5,13 @@
   "description": "Detects when the LocalAdminAnalyzer flags unexpected local user accounts or profile directories on the device. This is a known Autopilot bypass technique where admin accounts are created before or during enrollment to gain persistent local admin access.",
   "severity": "high",
   "category": "identity",
-  "version": "1.0.0",
+  "version": "1.3.0",
   "author": "Autopilot Monitor",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "trigger": "single",
   "baseConfidence": 60,
   "conditions": [
@@ -52,7 +56,7 @@
     }
   ],
   "confidenceThreshold": 50,
-  "explanation": "The agent detected unexpected local user accounts or profile directories on this device that are not in the built-in or tenant-configured allowed list.\n\nThis is a security-relevant finding. Creating local admin accounts before or during Autopilot enrollment is a known bypass technique (e.g. via BypassNRO or Shift+F10 during OOBE) that grants persistent local administrator access.\n\nClick the event link below to jump to the local_admin_analysis event and check: unexpected_accounts (local user accounts not on the allowed list), unexpected_profiles (C:\\Users profile directories not on the allowed list), bypass_nro (whether the BypassNRO registry flag was set), and confidence_score (the agent's confidence in the finding, 0-100).\n\nIf these accounts are expected for your environment (e.g. a service account or helpdesk account), add them to the allowed list in Tenant Settings.",
+  "explanation": "The agent detected unexpected local user accounts or profile directories on this device that are not in the built-in or tenant-configured allowed list.\n\nThis is a security-relevant finding. Creating local admin accounts before or during Autopilot enrollment is a known bypass technique (e.g. via BypassNRO or Shift+F10 during OOBE) that grants persistent local administrator access.\n\nClick the event link below to jump to the local_admin_analysis event and check: unexpected_accounts (local user accounts not on the allowed list — disabled accounts included, a dormant account can be re-enabled later), unexpected_admin_members (unexpected accounts that are members of the local Administrators group — the actual backdoor), account_details (per account: disabled state and Administrators membership), unexpected_profiles (C:\\Users profile directories not on the allowed list), logged_in_local_accounts (local accounts that were signed in when the shutdown scan ran — a signed-in local account is never exempted, only Entra/domain users are), bypass_nro (whether the BypassNRO registry flag was set), and confidence_score (the agent's confidence in the finding, 0-100).\n\nIf these accounts are expected for your environment (e.g. a service account or helpdesk account), add them to the allowed list in Tenant Settings.",
   "remediation": [
     {
       "title": "Review the unexpected accounts",
@@ -75,11 +79,16 @@
       "steps": [
         "Check if the BypassNRO registry flag was set (indicates OOBE was bypassed)",
         "Review the enrollment timeline for Shift+F10 or other OOBE escape indicators",
-        "Check whether the unexpected account has admin group membership",
+        "Check 'unexpected_admin_members' and 'account_details' — an unexpected account with Administrators membership is a backdoor even while it is disabled (it can be re-enabled by a scheduled task after enrollment)",
         "Consider re-imaging the device if unauthorized admin access is confirmed"
       ]
     }
   ],
   "relatedDocs": [],
-  "tags": ["identity", "security", "local-admin", "bypass-detection"]
+  "tags": [
+    "identity",
+    "security",
+    "local-admin",
+    "bypass-detection"
+  ]
 }

rules/analyze/ANALYZE-ID-003.json

@@ -5,9 +5,13 @@
   "description": "Fires when the vulnerability correlation finds critical-severity CVEs or CISA KEV entries in installed software. This indicates the device has software with known, actively exploited vulnerabilities.",
   "severity": "critical",
   "category": "security",
-  "version": "1.0.1",
+  "version": "1.1.0",
   "author": "Autopilot Monitor",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "trigger": "single",
   "baseConfidence": 90,
   "conditions": [
@@ -31,7 +35,11 @@
     }
   ],
   "confidenceFactors": [
-    { "signal": "kev_matches", "condition": "exists", "weight": 10 }
+    {
+      "signal": "kev_matches",
+      "condition": "exists",
+      "weight": 10
+    }
   ],
   "confidenceThreshold": 80,
   "explanation": "The device has installed software with critical vulnerabilities. Software with CVEs rated CRITICAL (CVSS >= 9.0) or listed in the CISA Known Exploited Vulnerabilities catalog was detected. These vulnerabilities are actively targeted by attackers and should be remediated immediately.",
@@ -64,5 +72,11 @@
       "url": "https://nvd.nist.gov/"
     }
   ],
-  "tags": ["vulnerability", "cve", "kev", "critical", "security"]
+  "tags": [
+    "vulnerability",
+    "cve",
+    "kev",
+    "critical",
+    "security"
+  ]
 }

rules/analyze/ANALYZE-ID-004.json

@@ -0,0 +1,101 @@
+{
+  "$schema": "../schema/analyze-rule.schema.json",
+  "ruleId": "ANALYZE-ID-004",
+  "title": "Hybrid Sign-In Never Establishes Entra User Affinity",
+  "description": "On a hybrid-joined device the real user reached the desktop, but the Autopilot provisioning placeholder stayed active in JoinInfo and the agent repeatedly reported the hybrid sign-in as overdue. The user session never establishes Entra user affinity (no PRT), so the Account Setup ESP re-runs on every logon and the enrollment never completes.",
+  "severity": "high",
+  "category": "identity",
+  "version": "1.2.0",
+  "author": "Autopilot Monitor",
+  "enabled": true,
+  "trigger": "correlation",
+  "evaluateOn": ["enrollment_end", "on_event:hybrid_login_pending"],
+  "baseConfidence": 60,
+  "confidenceThreshold": 75,
+  "preconditions": [
+    {
+      "source": "event_data",
+      "eventType": "enrollment_complete",
+      "operator": "not_exists",
+      "description": "Suppress when the session eventually completed — a single overdue-login warning followed by a successful sign-in is normal hybrid latency, not a broken affinity."
+    }
+  ],
+  "conditions": [
+    {
+      "signal": "hybrid_login_overdue",
+      "source": "event_type",
+      "eventType": "hybrid_login_pending",
+      "operator": "exists",
+      "value": "",
+      "required": true
+    },
+    {
+      "signal": "user_desktop_reached",
+      "source": "event_type",
+      "eventType": "desktop_arrived",
+      "operator": "exists",
+      "value": "",
+      "required": true
+    },
+    {
+      "signal": "placeholder_still_active",
+      "source": "event_type",
+      "eventType": "aad_placeholder_user_detected",
+      "operator": "exists",
+      "value": "",
+      "required": false
+    }
+  ],
+  "confidenceFactors": [
+    { "signal": "hybrid_login_pending", "condition": "count >= 2", "weight": 20 },
+    { "signal": "hybrid_login_pending", "condition": "count >= 3", "weight": 10 },
+    { "signal": "aad_placeholder_user_detected", "condition": "count >= 3", "weight": 10 }
+  ],
+  "explanation": "A real user signed in and reached the desktop, but the device kept reporting the **Autopilot provisioning placeholder** as the active identity in JoinInfo and the hybrid sign-in as **overdue** — across multiple reboots. This means the signed-in user never established **Microsoft Entra user affinity** (no Primary Refresh Token), so:\n\n- the Account Setup ESP page re-appears on every logon,\n- user-targeted required apps and policies cannot settle,\n- the enrollment never reaches completion.\n\nAfter this many hours this is not normal Entra Connect sync latency — something is structurally preventing the user (or the computer object) from registering:\n\n- the computer object's `userCertificate` attribute is not syncing to Entra ID (sync scope / OU filtering),\n- the signing-in user is not synced, or their UPN does not match a verified Entra domain,\n- the device has no line of sight to a domain controller **at logon time**, so the hybrid PRT flow cannot finish,\n- time skew or a proxy blocking `login.microsoftonline.com` / `enterpriseregistration.windows.net` from the user context.\n\nA frequent variant: the user's **first sign-in happens without domain-controller reachability** — for example when a pre-logon VPN tunnel (GlobalProtect, Always On VPN, Zscaler ZPA) is not established yet at the logon screen. Windows falls back to cached credentials, the hybrid PRT flow silently never runs, and later reboots do not fix it — sessions in this state typically show repeated reboots and network flapping while the placeholder identity stays active.\n\nA visible side effect: **the Windows Hello for Business wizard never appears**, because Hello provisioning requires an Entra user token (PRT). Hello is a downstream symptom here, not the cause.",
+  "remediation": [
+    {
+      "title": "Verify user affinity on the device",
+      "steps": [
+        "Sign in as the affected user and run: dsregcmd /status — under 'SSO State' the value AzureAdPrt must be YES. NO means the user has no Entra token and this diagnosis is confirmed.",
+        "Also check 'Device State': AzureAdJoined = YES and DomainJoined = YES are expected for hybrid join.",
+        "Check Event Viewer: Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin for PRT / registration errors (e.g. event 304/305/362).",
+        "Enable the gather rules 'Collect dsregcmd join status' so future sessions capture this state automatically."
+      ]
+    },
+    {
+      "title": "Fix the identity pipeline",
+      "steps": [
+        "Entra Connect: confirm BOTH the computer OU and the user OU are in the sync scope, and the computer object's userCertificate attribute is being exported.",
+        "Verify the user's UPN suffix is a verified domain in Entra ID (no .local / mismatched suffix).",
+        "Ensure domain-controller line of sight at logon from the provisioning network/VLAN (hybrid PRT requires a reachable DC).",
+        "Check proxy/firewall rules for login.microsoftonline.com, device.login.microsoftonline.com and enterpriseregistration.windows.net from the user context."
+      ]
+    },
+    {
+      "title": "Address VPN and Windows Hello dependencies",
+      "steps": [
+        "If a VPN is required to reach a domain controller, it must be established before or at the logon screen (machine tunnel / pre-logon tunnel). A user-context tunnel that starts after sign-in is too late for the hybrid PRT flow.",
+        "If you deploy Windows Hello for Business to hybrid-joined devices, use cloud Kerberos trust — it removes the on-premises certificate/key-trust dependencies that commonly stall Hello on hybrid devices.",
+        "If you do not use Windows Hello, disable it explicitly via a device-scoped Intune policy instead of leaving it unconfigured — the enrollment then resolves the Hello step deterministically instead of waiting for a wizard that never comes.",
+        "Avoid feature/quality updates mid-enrollment where possible — an OS update with forced reboots during enrollment aggravates this pattern. Consider a short Windows Update deferral covering the enrollment window.",
+        "For hybrid deployments, pre-provisioning (White Glove) materially shrinks the user-facing phase: the device phase runs on a known-good technician network, and the user phase reduces to sign-in, user ESP, and Hello."
+      ]
+    }
+  ],
+  "relatedDocs": [
+    {
+      "title": "Autopilot Monitor: Hybrid join — stuck in Account Setup (no user affinity)",
+      "url": "https://docs.autopilotmonitor.com/troubleshooting/hybrid-join-stuck-in-account-setup"
+    },
+    {
+      "title": "Autopilot Monitor: Hybrid join — late device registration",
+      "url": "https://docs.autopilotmonitor.com/troubleshooting/hybrid-join-late-device-registration"
+    },
+    {
+      "title": "Microsoft Learn: Troubleshoot hybrid-joined devices",
+      "url": "https://learn.microsoft.com/en-us/entra/identity/devices/troubleshoot-hybrid-join-windows-current"
+    }
+  ],
+  "markSessionAsFailedDefault": false,
+  "tags": ["identity", "hybrid-join", "entra-id", "user-affinity", "esp"]
+}

rules/analyze/ANALYZE-NET-001.json

@@ -0,0 +1,81 @@
+{
+  "$schema": "../schema/analyze-rule.schema.json",
+  "ruleId": "ANALYZE-NET-001",
+  "title": "Diagnostics Upload Blocked by Web Security Gateway",
+  "description": "Detects diagnostics package uploads that were answered by a security appliance's HTML block page instead of the Autopilot Monitor backend. A forward proxy / secure web gateway (SWG) with SSL inspection is intercepting the upload endpoint, so exactly the sessions where diagnostics matter most (OnFailure uploads) are the ones losing them.",
+  "severity": "warning",
+  "category": "network",
+  "version": "1.0.0",
+  "author": "Autopilot Monitor",
+  "enabled": true,
+  "baseConfidence": 75,
+  "conditions": [
+    {
+      "signal": "foreign_html_response",
+      "source": "event_data",
+      "eventType": "diagnostics_upload_failed",
+      "dataField": "errorCode",
+      "operator": "contains",
+      "value": "HTML platform error page",
+      "required": true
+    },
+    {
+      "signal": "security_gateway_marker",
+      "source": "event_data",
+      "eventType": "diagnostics_upload_failed",
+      "dataField": "errorCode",
+      "operator": "regex",
+      "value": "mcafee|skyhigh|zscaler|netskope|blue ?coat|proxysg|forcepoint|websense|palo ?alto|fortigate|fortiguard|sophos|watchguard|barracuda|iboss|umbrella|lightspeed|smoothwall|contentkeeper|web ?gateway|web ?filter|content ?filter|secure ?gateway",
+      "required": true
+    },
+    {
+      "signal": "http_403_block",
+      "source": "event_data",
+      "eventType": "diagnostics_upload_failed",
+      "dataField": "errorCode",
+      "operator": "contains",
+      "value": "403",
+      "required": false
+    }
+  ],
+  "confidenceFactors": [
+    {
+      "signal": "http_403_block",
+      "condition": "exists",
+      "weight": 15
+    }
+  ],
+  "confidenceThreshold": 70,
+  "explanation": "The agent collected a diagnostics package but the upload was answered with an **HTML block page from a web security gateway** instead of a response from the Autopilot Monitor backend — the event message names the product that served the page. A forward proxy / SWG with SSL inspection is intercepting HTTPS traffic from the enrollment network and blocking the upload endpoint.\n\nThe consequence is quietly painful: diagnostics upload is typically configured **OnFailure**, so the sessions that fail — the ones where the IME logs and diagnostics ZIP would explain the root cause — are exactly the sessions whose evidence never arrives. Enrollment telemetry itself may still flow (the agent often starts before the gateway's client enforcement does, or other endpoints are treated differently), which makes the gap easy to miss until a failure needs investigating.\n\nNote this rule only fires when the blocking page carries a recognizable security-product marker. A plain HTML error page without one usually means a stale or stopped endpoint instead — that is a different problem.",
+  "remediation": [
+    {
+      "title": "Exempt the upload endpoint in the web gateway",
+      "steps": [
+        "Identify the product from the block-page title quoted in this event's message (e.g. a Skyhigh/McAfee Web Gateway notification page)",
+        "In that gateway, add the Autopilot Monitor API host shown in the event message to the SSL-inspection bypass AND the URL allowlist for the enrollment network segment",
+        "Enrollment traffic often originates from a dedicated provisioning VLAN or from devices without the proxy client yet — make sure the exemption applies to that segment, not only to managed clients",
+        "If the gateway enforces per-user policy, remember ESP-phase traffic runs as SYSTEM/device before any user signs in — the exemption must cover unauthenticated device traffic"
+      ]
+    },
+    {
+      "title": "Verify the fix",
+      "steps": [
+        "Re-run an enrollment (or wait for the next failed one) and confirm a diagnostics package appears on the session in the portal",
+        "Optionally set diagnostics upload to Always temporarily to validate the path without needing a failure"
+      ]
+    }
+  ],
+  "relatedDocs": [
+    {
+      "title": "Microsoft Learn: Windows Autopilot networking requirements",
+      "url": "https://learn.microsoft.com/en-us/autopilot/networking-requirements"
+    }
+  ],
+  "tags": [
+    "network",
+    "proxy",
+    "ssl-inspection",
+    "swg",
+    "diagnostics"
+  ]
+}

rules/analyze/ANALYZE-OFFICE-001.json

@@ -5,8 +5,12 @@
   "description": "Detects when the Microsoft 365 Apps (Office Click-to-Run) background install did not reach completion. The V2 OfficeInstallDetector watches the C2R client directly (registry + process) and emits office_install_failed when the install scenario was abandoned (worker gone and streaming never finished) or a C2R failure code was observed. This catches Office failures that the Intune integrated app type hides, because IME reports the app done within 1-2 minutes while C2R keeps installing in the background.",
   "severity": "warning",
   "category": "apps",
-  "version": "1.0.1",
+  "version": "1.1.0",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "baseConfidence": 75,
   "conditions": [
     {
@@ -28,7 +32,11 @@
     }
   ],
   "confidenceFactors": [
-    { "signal": "error_code_present", "condition": "exists", "weight": 15 }
+    {
+      "signal": "error_code_present",
+      "condition": "exists",
+      "weight": 15
+    }
   ],
   "confidenceThreshold": 40,
   "explanation": "The Microsoft 365 Apps (Office Click-to-Run) install did not finish.\n\nThe OfficeInstallDetector watches the C2R client directly and reports the real background install lifecycle. The Intune \"integrated\" Microsoft 365 Apps app type only pushes the configuration XML and starts the C2R bootstrapper, so IME marks the app done within 1-2 minutes while C2R keeps streaming and laying down the product for several more minutes. This event means C2R activity ended (the OfficeC2RClient worker exited and the install scenario cleared) without the StreamingFinished flag being set, or a C2R failure code was observed.\n\nReview the office_install_failed event payload: `products`, `channel`, `phase`, `streamingFinished`, `errorCode` (best-effort — may be empty) and `durationSeconds`.",
@@ -44,5 +52,11 @@
       ]
     }
   ],
-  "tags": ["apps", "office", "microsoft-365-apps", "click-to-run", "install-failure"]
+  "tags": [
+    "apps",
+    "office",
+    "microsoft-365-apps",
+    "click-to-run",
+    "install-failure"
+  ]
 }

rules/analyze/ANALYZE-SEC-001.json

@@ -2,11 +2,15 @@
   "$schema": "../schema/analyze-rule.schema.json",
   "ruleId": "ANALYZE-SEC-001",
   "title": "Secure Boot UEFI CA 2023 certificate not deployed",
-  "description": "Detects devices where the Windows UEFI CA 2023 certificate has not been deployed to the Secure Boot DB. The 2011 certificates expired in June 2026 — affected devices no longer receive Secure Boot security updates until the 2023 certificate is deployed.",
+  "description": "Detects devices where the Windows UEFI CA 2023 certificate has not been deployed to the Secure Boot DB. The 2011 certificates expired in June 2026 — affected devices no longer receive Secure Boot security updates until the 2023 certificate is deployed. Since v3 the agent reads the firmware db/KEK variables directly: when the firmware itself confirms the 2023 certificate, the rule is suppressed even if the Windows servicing status has not caught up yet.",
   "severity": "warning",
   "category": "security",
-  "version": "2.0.0",
+  "version": "3.1.0",
   "enabled": true,
+  "evaluateOn": [
+    "enrollment_end",
+    "whiteglove_sealed"
+  ],
   "baseConfidence": 70,
   "preconditions": [
     {
@@ -16,6 +20,14 @@
       "operator": "equals",
       "value": "false",
       "description": "Skip on virtual machines — Secure Boot DB is host-controlled (Hyper-V/VMware/etc), the inside-the-VM UEFICA2023Status registry value is not the right indicator and not actionable for the VM admin."
+    },
+    {
+      "source": "event_data",
+      "eventType": "secureboot_status",
+      "dataField": "uefiCa2023FirmwareConfirmed",
+      "operator": "not_exists",
+      "value": "",
+      "description": "Skip when the firmware db itself confirms the Windows UEFI CA 2023 certificate — the marker is only emitted on positive firmware confirmation, so old agents (field absent) and unconfirmed devices keep evaluating the rule. The servicing registry status lags behind actual firmware state (OEM factory image, WinCS, manual deployment, or WU simply not run yet)."
     }
   ],
   "conditions": [
@@ -54,13 +66,49 @@
       "operator": "exists",
       "value": "",
       "required": false
+    },
+    {
+      "signal": "db_ca2023_firmware_missing",
+      "source": "event_data",
+      "eventType": "secureboot_status",
+      "dataField": "uefiDbHasWindowsUefiCa2023",
+      "operator": "equals",
+      "value": "false",
+      "required": false
+    },
+    {
+      "signal": "kek_2023_missing",
+      "source": "event_data",
+      "eventType": "secureboot_status",
+      "dataField": "uefiKekHasMicrosoftKek2kCa2023",
+      "operator": "equals",
+      "value": "false",
+      "required": false
     }
   ],
   "confidenceFactors": [
-    { "signal": "ca2023_notfound", "condition": "exists", "weight": 20 },
-    { "signal": "ca2023_error", "condition": "exists", "weight": 10 }
+    {
+      "signal": "ca2023_notfound",
+      "condition": "exists",
+      "weight": 20
+    },
+    {
+      "signal": "ca2023_error",
+      "condition": "exists",
+      "weight": 10
+    },
+    {
+      "signal": "db_ca2023_firmware_missing",
+      "condition": "exists",
+      "weight": 20
+    },
+    {
+      "signal": "kek_2023_missing",
+      "condition": "exists",
+      "weight": 10
+    }
   ],
-  "explanation": "This device has Secure Boot enabled but the **Windows UEFI CA 2023** certificate has not been deployed to the Secure Boot DB.\n\nThe original Windows UEFI CA 2011 certificates **expired on June 27, 2026 — this deadline has passed**. The automatic pre-expiry rollout window is over: this device no longer receives Secure Boot security updates (DB/DBX) and cannot trust 2023-signed boot managers until the 2023 certificate is deployed. Deploying it now requires active remediation (Windows servicing opt-in and, on some models, an OEM firmware update) rather than waiting for an automatic update.\n\nCurrent UEFI CA 2023 status: `{{uefiCA2023Status}}`",
+  "explanation": "This device has Secure Boot enabled but the **Windows UEFI CA 2023** certificate has not been deployed to the Secure Boot DB.\n\nThe original Windows UEFI CA 2011 certificates **expired on June 27, 2026 — this deadline has passed**. The automatic pre-expiry rollout window is over: this device no longer receives Secure Boot security updates (DB/DBX) and cannot trust 2023-signed boot managers until the 2023 certificate is deployed. Deploying it now requires active remediation (Windows servicing opt-in and, on some models, an OEM firmware update) rather than waiting for an automatic update.\n\nOn devices running a current agent this finding is verified against the firmware itself: the agent reads the UEFI `db` signature database directly, and this warning is automatically suppressed when the firmware already contains the 2023 certificate — regardless of the Windows servicing status below.\n\nCurrent UEFI CA 2023 servicing status: `{{uefiCA2023Status}}`",
   "remediation": [
     {
       "title": "Deploy UEFI CA 2023 certificate now",
@@ -69,7 +117,7 @@
         "Use Intune policy to enable Secure Boot DB update (Windows UEFI CA 2023)",
         "Check with the device OEM whether a firmware update is required for the DB update to apply on this model",
         "Alternatively, use the WinCS CLI tool from Microsoft for manual deployment",
-        "Verify deployment: check registry HKLM\\SYSTEM\\CurrentControlSet\\Control\\SecureBoot\\Servicing\\UEFICA2023Status = 'Updated'",
+        "Verify deployment against the firmware directly: [Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name db).Bytes).Contains('Windows UEFI CA 2023') — this is authoritative; the registry value HKLM\\SYSTEM\\CurrentControlSet\\Control\\SecureBoot\\Servicing\\UEFICA2023Status = 'Updated' only reflects the Windows Update rollout",
         "After DB update: ensure the boot manager is updated to a 2023-signed version via monthly cumulative update"
       ]
     }
@@ -84,5 +132,11 @@
       "url": "https://support.microsoft.com/en-us/topic/kb5036210"
     }
   ],
-  "tags": ["security", "secureboot", "certificate", "ca2023", "compliance"]
+  "tags": [
+    "security",
+    "secureboot",
+    "certificate",
+    "ca2023",
+    "compliance"
+  ]
 }