Oliver Kieselbach b6a949bc02 refactor(decisioncore): engine foundation — dispatch, fail-safe, clock, serialization (M3.0)
M3.0 establishes the reducer infrastructure the scenario sub-milestones
(M3.1–M3.5) will build on. No domain-specific reducer behavior yet; only
kernel plumbing + a live SessionStarted / SessionRecovered / SessionAborted
lifecycle path.

Kernel (plan §2.5 / L.2 / L.3 / L.16):
 - DecisionEngine dispatches on (Kind, KindSchemaVersion) to partial-class
   handlers. Unhandled kinds produce a DeadEnd transition with a versioned
   reason string — never a throw, never a mutation.
 - Exception fail-safe (L.16): any handler exception is caught in the
   kernel, StepIndex + LastAppliedSignalOrdinal still advance (so the
   signal counts as processed and there is no retry loop), the transition
   records DeadEndReason="reducer_exception" + SHA256-short StackTraceHash.
   DecisionState is returned untouched beyond bookkeeping.
 - Shared helpers for Taken / DeadEnd transition construction keep
   partial-class handlers short and consistent.

State (plan §2.3 / L.3):
 - Immutable DecisionState gets a mutable DecisionStateBuilder companion —
   reducer handlers use state.ToBuilder().WithStage(...).Build() to
   express "copy with changes" without retyping 20+ ctor arguments.
 - Fluent helpers AddDeadline (replace-if-same-name), CancelDeadline,
   WithCurrentEnrollmentPhase carry the most common reducer operations.

Time (plan §2.6 / L.7):
 - IClock interface + SystemClock (wall-clock wrapper). The only way any
   decision-relevant code can observe time going forward. VirtualClock
   lives in the test assembly — never in shipping builds.

Serialization (plan §2.8 / §2.15 / L.14):
 - Newtonsoft.Json added to DecisionCore (both net48 + net8.0 consume the
   same DTOs with the same converters).
 - UnknownFallbackEnumConverter<T> maps unrecognized enum strings to a
   caller-provided fallback instead of throwing — lets an older backend
   read a newer DecisionCore's rows without crashing; the verifier will
   flag them as drift_tolerated in §2.10.
 - DecisionCoreJsonSettings registers fallback converters for every
   DecisionCore enum (DecisionSignalKind, EvidenceKind, HypothesisLevel,
   SessionStage, SessionOutcome, DecisionEffectKind, EnrollmentPhase).
 - SignalSerializer round-trips DecisionSignal JSONL with enforced
   Evidence.Identifier and Evidence.Kind — a line without Evidence throws
   just like constructor validation.

Lifecycle (DecisionEngine.Shared.cs):
 - SessionStarted: anchors the first journal transition; rejects mid-flight
   replay (StepIndex != 0) with a DeadEnd instead of silently resetting
   hypotheses.
 - SessionRecovered: neutral bookkeeping in M3.0 — WhiteGlove Part 1 → 2
   transition lands in M3.4 DecisionEngine.WhiteGlovePart2.cs.
 - SessionAborted: terminal, Outcome=Aborted, all deadlines cleared —
   orchestrator admin-action path (plan §2.7 audit).

Test coverage (37 total):
 - VirtualClockTests (6)     — monotonic clock, Delay instant-return
 - DecisionStateBuilderTests (5) — immutable semantics, deadline replace/cancel
 - SerializationTests (6)     — round-trip, UnknownFallback both string + numeric
 - ReducerFailSafeTests (6)   — null-arg, replay-on-active, unhandled kind,
                                SessionAborted clears deadlines, ReducerVersion
 - SmokeTests (7)             — smoke, updated: Reduce(SessionStarted) is a
                                real transition, not a throw
 - HarnessTests (6)           — empty-stream determinism, single-signal replay,
                                unknown-kind DeadEnd at harness level
 - VirtualClock helper (instance) covered via Harness integration

Suite totals unchanged elsewhere: 507 Legacy + 557 Functions. Full solution
builds 0 warnings, 0 errors.

Plan: plans/REFACTOR_AGENT_V2.md §4 M3 (sub-milestone M3.0 Foundation).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-20 13:51:45 +02:00
2026-03-17 18:24:01 +01:00
2026-03-26 07:02:33 +01:00
2026-04-04 19:17:01 +02:00

Autopilot Monitor

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

Autopilot Monitor is currently running as a Private Preview. Visit autopilotmonitor.com to request access and learn more.

Overview

Autopilot Monitor provides real-time tracking, intelligent diagnostics, and automated troubleshooting for Windows Autopilot enrollment processes. It consists of:

  • Bootstrap Script — PowerShell script deployed via Intune that starts monitoring early in the enrollment process
  • 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

Architecture

For detailed information about the system architecture, components, and data flow, see Architecture Documentation.

Documentation

Full documentation is available at autopilotmonitor.com/docs

License

This project uses a split licensing model:

  • 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

See LICENSE for full details.

S
Description
Windows Autopilot & Intune enrollment monitoring: live session timelines, fleet health, diagnostics, and an MCP server for AI-assisted troubleshooting.
Readme AGPL-3.0 60 MiB
Languages
C# 72.7%
TypeScript 25.7%
PowerShell 1%
JavaScript 0.5%