mirror of
https://github.com/okieselbach/AutopilotMonitor.git
synced 2026-10-24 20:53:06 +00:00
a6184f165bfb489fffb930eb7067f6af70ed52df
105 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Oliver Kieselbach
|
5055db2de1 |
feat(rules): detect installer-mutex app failures (0x80070652) and SWG-blocked diagnostics uploads
Two analyze rules born from the pilatus-aircraft diagnosis (2026-08-27): - ANALYZE-APP-017 "App Install Blocked by Another Installer (0x80070652)": fires on app_install_failed with hresultFromWin32 -2147023278 (ERROR_INSTALL_ALREADY_RUNNING); confidence boosts for MSI exit code 1618 and for an ESP failure settling with the same code. The 08-26 burst failed 16 sessions deterministically at ~21 min (IME's fixed msiexec-busy retry budget) right after a preceding installer left the Windows Installer mutex held - previously only generic "Enrollment Failed" fired, naming no cause. - ANALYZE-NET-001 "Diagnostics Upload Blocked by Web Security Gateway": fires on diagnostics_upload_failed answered by an HTML block page carrying a recognizable security-product marker (McAfee/Skyhigh, Zscaler, Netskope, ...). OnFailure diagnostics are lost exactly on the sessions that need them; plain HTML errors without a vendor marker (stale/stopped endpoint) stay excluded on purpose. Both validated via MCP validate_rule (0 errors) and dry-run with test_analyze_rule: fire on the burst session (confidence 100 / 90), silent on a timeout-shaped failure and on a succeeded session that carried unrelated app_install_failed events. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
c91d8d4501 |
fix(agent): complete enrollments with zero user-targeted apps instead of failing them
IME never writes its "Completed user session" line when the user has no assigned Win32 apps - its zero-app branch returns before that statement (ApplicationPoller.cs:713-721, identical in 1.80/1.83/1.97/1.104). So ImeUserSessionCompletedUtc stayed null, every arm of ShouldTransitionToAwaitingHello was unsatisfiable, and the 30-min advisory_completion backstop resolved healthy enrollments as esp_exit_without_completion_evidence. One tenant: 10 of 30 sessions in a week, all false positives - DAD-validated desktop, Hello provisioned, RealmJoin still installing. Every Succeeded session there carries ime_user_session_completed; not one of the failed ones does. IME-USER-SESSION-ZERO-APPS reads the line IME does write there and routes it through the same OnUserSessionCompleted callback. That is IME's own verdict rather than a weakened gate: the zero-app branch locks the ESP in with an empty application list, and the sibling emit site returns ProvisioningComplete right after logging it. Guarded to the AccountSetup phase so it cannot burn the adapter fire-once flag on a pre-sign-in timestamp, and replayed on the phase transition when the observation predates the phase marker. AreUserEspAppsSettled accepts an empty app list only with that explicit observation, never on emptiness alone. Second, independent defect: advisory_completion (30 min) overran the RealmJoin completion gate, which deliberately holds the session and carries its own bounded resolution (60 min from detection, activity-extended, 4 h cap). One session installed 25 RealmJoin packages inside the window, the last 2 min before the failure, while completion_waiting still read "waiting on: realmjoin_resolution". The handler now re-arms while that gate is closed and its own deadline is still armed; convergence comes from the gate itself, which always ends with an Outcome set. ime_user_session_completed gains an evidence field (zero_user_apps_enumerated / user_session_completed) - no new event type, so the Constants -> resource-catalog -> shared-manifests triple stays untouched. The pattern ships via the config API and reaches existing agents, where an unknown action is a single Debug line; the behaviour needs the agent release. Build 0 warnings. DecisionCore 558/558, V2.Core 2530/2530, Backend 4634/4634, MCP event-types-drift 6/6. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
06cf1c4c12 |
feat(agent): system timeline watcher — clock steps + sleep episodes as ground truth
Two enrollment blind spots become timeline ground truth from the System event log via one EventLogWatcher (WindowsUpdateTracker pattern, 24h backfill with RecordId watermark recovering pre-agent records): - system_clock_changed (Kernel-General 1): oldTime/newTime/signed timeDeltaMs, reason and the setting process. 2s floor suppresses w32time 1ms micro-slews; steps >= 5min are Warning + immediate upload. Payload instants are the authoritative source (event timestamps can be clamped server-side). - system_sleep_episode (Power-Troubleshooter 1 classic sleep/hibernate, Kernel-Power 507 Modern Standby; 506 deliberately unconsumed): kind, enteredAt/exitedAt, durationSeconds, wake source / AC state. 60s real-sleep floor filters Modern Standby screen-off scenarios. ConfigVersion 39 (Collectors.EnableSystemTimelineWatcher + SystemEventBackfillLookbackMinutes). Both types are non-activity on agent and backend (idle/stall clocks unaffected; a sleeping device stays Stalled). Consumers: TimeJumpBadge gains the ground-truth cause "clock-set" (classifyTimeJump matches backward display steps against recorded clock sets); EventTimeline badge blocks for both events plus the previously bare power_state_change; SessionInfoCard keeps the wall-clock duration and adds a standby note; TimeAttributionCalculator builds SleepSpans (RebootSpan clone, AttributionVersion 3) persisted as SleepSeconds/SleepSpansJson and rendered in TimeAttributionLane; ANALYZE-DEV-012 (info, single) fires once per session for episodes >= 5min - deliberately the only new rule, clock findings stay with DEV-008 to avoid duplicate-finding flood. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
8f24876682 |
feat(agent): live power-state watcher + battery analyze rules DEV-009/010
Event-driven AC/battery observation during enrollment (no polling): a WMI Win32_PowerManagementEvent (EventCode 10) push subscription re-probes GetSystemPowerStatus and diffs snapshots through a pure tracker into power_state_change events - transition ac_to_battery (Warning, immediate) / battery_to_ac (Info) / threshold_crossed at 50/30/15% (per-level lifetime latch, lowest-crossed-only on jumps, arm-time baseline covers sessions starting low, 5s trailing-edge debounce, emission cap 20). Never armed on devices without a battery; arm failure surfaces as collector_degraded. Kill-switch Collectors.EnablePowerStateWatcher (ConfigVersion 38). power_state_change is classified non-activity on both sides (SignalActivityClassifier + IsPeriodicOrStallEvent) so battery drain can neither keep idle collectors alive nor heal a Stalled session. New analyze rules, both with on_event:power_state_change interim triggers and deliberately single-required-condition (event_data conditions scan events independently - no same-instance join): - ANALYZE-DEV-009 (high): thresholdPercent equals 15 - ANALYZE-DEV-010 (warning): transition equals ac_to_battery Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
81c14bb3ed |
fix(rules): close the rule-ID namespace gaps around the shared global keyspace
Custom rules are tenant-partitioned and functionally collision-free, but three
surfaces still keyed on the bare non-unique ruleId string:
- RuleStats global aggregate (global_{ruleId}) summed same-ID custom rules of
unrelated tenants (title/severity last-writer-wins). The global row is now
catalog-only: analyze gates on IsBuiltIn/IsCommunity, gather gates on the
reserved-namespace pattern (agent events carry no flag; custom rules can
never occupy the reserved pattern).
- The 'never ship a built-in in the CUSTOM namespace' commitment from
RuleIdPolicy was documented but unenforced: combine.js now fails on
duplicate or non-reserved built-in IDs, BuiltInRuleCatalogPolicyTests pins
the same invariants on the embedded catalog, and the GitHub reseed rejects
non-reserved IDs before writing to the global partition.
- DeleteRuleStatesForRuleIdAcrossTenantsAsync (cross-partition delete by bare
RowKey) now refuses IDs outside the reserved namespace with failed=-1 so
callers abort the follow-up global catalog delete.
Verified: prod global partitions (45 analyze + 11 gather) are fully inside the
reserved namespace, so the guards touch no existing data. New OKF doc
docs/rules/rule-id-namespace.md captures the identity/collision model.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
Oliver Kieselbach
|
ab61839685 |
feat(backend): P6 split - CMTrace skew tripwire + customer clock_skew rule
Operator side: CmTraceSkewTripwire piggybacks on the terminal counter
reconcile's partition scan (zero extra reads) and compares median
ReceivedAt-OccurredUtc deltas of IME-derived vs other events. A clean
15-min-grid divergence (residual < 2 min, >=20 samples / >=3 distinct
batches per side) emits the CmTraceTimeSkewRegression ops event
(Agent/Warning, goal: never fires). Bias-dominated sessions are
suppressed; measuredWriterOffsetMinutes is never consulted (sticky
after era flip-backs). Kill switch: CmTraceSkewTripwireDisabled.
Customer side: new clock_skew analyze condition source (skewMetric
clock_jump | sustained_offset, threshold seconds, gt/gte magnitude)
behind built-in ANALYZE-DEV-008 (300 s = the Kerberos/Entra 5-min skew
boundary). Batch-median frames with spool-spread filter, plateau step
detection (a gradual backlog-drain ramp cannot fake a jump) and
end-state persistence; IME-derived events are excluded so a CMTrace
anchoring regression can never fire the customer rule. Evidence carries
field=skewSummary/value for {{skewSummary}} interpolation.
Full mirroring chain: schema enum + skewMetric property, shared
manifest + combine.js regeneration, MCP authoring guide + semantic
lint, web SOURCES/form/card, ops-event dual-register, docs. P5 is
subsumed by the tripwire. PercentileMath is now the single nearest-rank
implementation (Apps/PlatformMetrics delegate).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
Oliver Kieselbach
|
e1b03de5b3 |
fix(agent): recover ESP completion after a forced mid-ESP reboot
Seven sits-d Cloud PCs enrolled the same day with identical configuration (~138 required apps at the user-ESP gate, DeviceGuard/DmaGuard device-assigned). The two that finished AccountSetup before the coalesced reboot landed succeeded; the five the reboot killed in Stage=EspAccountSetup never derived a completion again and ended Incomplete on healthy devices. Two defects behind that: ShellCoreTracker.BackfillRecentEspExitEvents() has existed since session 772fe502 but no caller ever invoked it, so the Shell-Core watcher only saw records written after Start(). Every agent restart silently dropped an ESP exit (62407) or Hello-wizard start (62404) from its downtime. EspAndHelloHost.Start() now calls it, and the fixed 5-minute window is sized to the actual downtime when the previous run died to a reboot (LastBootUtc, clamped to 360 min). The user-apps-settled synthesis ran only on the EspExited edge. When the ESP page exits with apps still in flight the single attempt misses and nothing re-checks — 8110e262 and a89aac2d both reached 138/138 apps, 0 failed, and still never completed. The exit edge is now recorded and the synthesis re-evaluated from ImeLogTracker.OnAppStateChanged. No new completion path: the gate conditions are unchanged, this only gives the existing conservative check a second look. The fire-once claim moves to Interlocked (edge and re-check run on different threads) and the re-check does not re-emit app_install_starved. Rules: ANALYZE-ESP-005 gains on_event:session_stalled so a hung session produces a finding at the 60-minute stall instead of staying finding-less for hours (verified against 8110e262 — fired, confidence 95). New ANALYZE-APP-016 turns the already-emitted app_install_starved events into a customer finding and, unlike ANALYZE-APP-015, fires even on a succeeded session: 3b9291aa was recorded Succeeded with 99 required apps that never started installing. ANALYZE-APP-015 and ANALYZE-ESP-001 were considered for the stall trigger and deliberately left alone — APP-015 is the documented worked example of the terminal-precondition trap, and ESP-001's phase_duration gate on a still-open phase is unverified mid-run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
2cf7216be5 |
Token-failure grace window + registry_app_baseline summary
Live findings from the first two 2.0.1402 sessions (Oliver, 2026-08-18): 1. "Failed to get AAD token" is logged routinely during the device phase (no user token exists yet) - both test sessions raised the Warning although nothing was wrong. The failure is now held pending: any IME-TOKEN-SUCCESS match clears it (staleness-gated so a replayed success from a previous enrollment cannot mask a current outage), and ime_token_failure fires only when no success follows for the 30-min grace window, then deduped per errorCode. Genuine auth outages run long enough to hit the window; routine device-phase failures never do. 2. New one-shot registry_app_baseline event (Info, only when non-empty): summary of the Win32Apps state that predates the agent run - counts by enforcement class + capped 50-app typed payload incl. LastUpdatedTimeUtc. On WDP the DPP-policy apps install in Batch 1 before the bootstrap-script agent exists; their outcomes live only in this baseline, closing the pre-agent app gap without log backfill. The diff rail stays silent on baseline state (anti-replay unchanged). Event type dual-registered (Constants + MCP catalog + manifests regen). Tests: grace-window cycle (resolved / unresolved / re-arm dedup), baseline summary (counts, one-shot, empty). All suites green (Agent 2274, Functions 4262, MCP 561, web 762), 0 warnings. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
68eb2da283 |
IME tracker: tail AppActionProcessor.log; GRS + token-failure signals
P0b/P1 of the 2026-08-17 IME code audit (agent release required):
- Tail AppActionProcessor.log (+ rollover glob) in ImeLogTracker and the
--run-ime-matching CLI. IME routes every [Win32App][ActionProcessor]
line there (enforcement decision engine), so IME-NO-ACTION and
IME-NOT-TARGETED-1/2 could never fire before, and GRS skips were
invisible. Live session 0fe2c562 carried 16 no-action and 64
classification lines in that file.
- New patterns (wordings verified in decompiled IME 1.97 AND 1.104):
IME-GRS-SKIP ("is in GRS. The app will not be enforced." -> Postponed;
THE canonical silent non-install reason), IME-GRS-CLEARED (early
subgraph termination, retry next check-in -> Postponed),
IME-TOKEN-FAILURE ("Failed to get AAD token ... errorCode = N").
- New action imeTokenFailure -> ime_token_failure Warning event (new
EventType: Constants + MCP resource-catalog + shared manifests
regenerated). Tracker dedups per distinct errorCode; included in
the historic-replay guard so stale lines from a previous enrollment
cannot emit a misleading warning. Complements IME-TOKEN-SUCCESS:
an auth outage previously left check-ins silently doing nothing.
Tests: adapter emission + unknown-code + tracker dedup; known-actions
catalog extended; all suites green (Functions 4262, Agent 2252, web 762).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
Oliver Kieselbach
|
ccf4f2e054 |
IME patterns: quote-flexible report deltas for IME 1.104 serialization
Live validation against session 0fe2c562 (IME 1.104.102, first session on
the repaired pattern set) showed all report-delta patterns at zero: IME
1.104 logs the delta JSON with single quotes ({"EnforcementState":...)
where older versions logged doubled quotes ({""EnforcementState"":...).
Every literal quote in the seven delta patterns (DETECTED-INSTALLED-1,
ENFORCEMENT-SUCCESS, ERROR-DOWNLOAD, ERROR-REPORT, NOT-APPLICABLE-2/3/4)
is now matched as "{1,2} to cover both serializations.
Verified against the session's AppWorkload.log via validate-ime-patterns:
ENFORCEMENT-SUCCESS 12 (was 0), ERROR-REPORT 14 (was 0); no CRITICALs;
the 2026-08-17 repair set confirmed live (ESP-TRACK-STATUS 24,
ESP-APP-REGISTERED 12, CACHE-MISS 11 in the agent's own match log).
Also observed in 1.104, tracked separately (no pattern change possible):
[DO TEL] line removed entirely - the DO download-duration display feeds
on it; needs an agent-side replacement (DO collector enrichment).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
Oliver Kieselbach
|
a3089753d3 |
IME patterns: repair drift found by decompiled-source audit (IME 1.97 Dec-25)
Audit vs decompiled IME 1.97.107: ~55/79 patterns verified verbatim, but several were broken or dead against the current V3 pipeline. Fixes: - IME-ESP-TRACK-STATUS: drop trailing anchor (line grew ' with name: <n>.') - HS-COMPLIANCE: tolerate both 'remdiation' typo and corrected wording; new HS-COMPLIANCE-POST for the reworded post-detection line - IME-DETECTION-RESULT: capture DetectedDifferentVersion (ordered first) - IME-ENFORCEMENT-SUCCESS: unpin OldValue (Error/PendingReboot/null paths) - IME-ERROR-REPORT: allow unquoted null OldValue on first write - Disable 11 dead patterns (emitters removed with IME's old V1/V2 pipeline; IME-DETECTED-OLD additionally collided with IME-SKIP-INSTALL-DETECTED) New signals (existing actions, tailed files only): - IME-ESP-APP-REGISTERED + IME-CACHE-MISS as app-name sources (replacing dead IME-UPDATE-NAME-1/2/3) - IME-WINGET-ERROR (WinGet failures were invisible) - IME-EXITCODE-MAPPED-FAILED (normal mapped-exit-code failure path) - IME-STOP-SIGNAL (service stop != OS shutdown) - IME-RESTART-STOP-PROCESSING (reboot-gated processing abort) Backend seed diff now also compares Enabled + Parameters - enable/disable flips and parameter changes previously never propagated to the table. All exact wordings verified against decompiled source; regex smoke-tested via validate-ime-patterns.py (engine=regex, 75/75 compiled, all new patterns fire on synthetic lines with the exact IME format strings). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
65651dd599 |
ANALYZE-ID-004 v1.2.0: pre-logon VPN + Hello-as-symptom self-service guidance
From the 3b7ba31f (succeeded) vs gardner/esa (parked) hybrid session comparison: explanation now covers the cached-credentials/pre-logon-VPN variant and why the Hello wizard never appearing is downstream of the missing PRT; new remediation block for VPN machine tunnels, cloud Kerberos trust, explicit Hello disable, update deferral and pre-provisioning. Links the new docs article. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
daa6df6bab |
rules: evaluate 30 device-phase built-ins at the WhiteGlove seal, 6 also on_event
Every built-in whose evidence exists by the end of pre-provisioning Part 1 now carries evaluateOn [enrollment_end, whiteglove_sealed] — app failures, low disk, memory pressure, unsupported build, WU failures, clock skew, ESP device subcategories, mid-ESP reboots, retry-recovery, cert store, local admins, critical vulnerabilities, firmware CA2023, Secure Boot, AutoLogon, PPKG scans, Office install and hybrid/TPM/MDM known-error codes. Six rules additionally evaluate when their (rare, acute) trigger event arrives: on_event:app_install_failed → APP-002/004/007 + CORR-003, on_event:windows_update_failed → DEV-004, on_event:modern_deployment_error → ENRL-003. Deliberately enrollment-end only: APP-010/ESP-004/ENRL-001 (require enrollment_complete/failed), ENRL-002 (session_timeout), DEV-001 (Hello = user phase), APP-015 (user phase, terminal-precondition design), ID-004 (keeps its own hybrid_login_pending trigger). Minor version bump on all 36 changed rules (seed contract); rule JSONs normalized to 2-space formatting; semantic equality vs HEAD verified (only evaluateOn/version differ). Backend 4157 tests green (APP-013 version pin updated). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
98fd173fb8 |
rules+backend+mcp: rule-verify sweep fixes (dead factor, {{token}} evidence, stats cap, list stringify)
Full verify pass over all 54 built-in rules (validate_rule sweep, 30d/7d
get_rule_stats, test_analyze_rule spot checks). Fixes:
- ANALYZE-APP-007 v1.1.0: declare enrollment_failed as a non-required
condition — the exists-factor referenced an undeclared signal and could
never apply.
- ANALYZE-APP-014 v1.1.0: add non-required event_data conditions for
espCategory/espErrorCode/topCandidatePackage/candidateCount/confidence
so all explanation {{tokens}} resolve instead of rendering literally.
- ANALYZE-ENRL-002 v1.2.0: capture session_timeout.timeoutHours so
{{timeoutHours}} interpolates (verified via dry-run: renders "5").
- RuleEngine TryFlatLookup/ResolveDotPath: flatten IEnumerable data
values to a comma-joined string — List fields (e.g. app_tracking_summary
.pendingNames) stringified to "System.Collections.Generic.List`1[…]",
breaking contains-matching and {{pendingNames}} interpolation.
- GetRuleStatsAsync: raise the 500-row cap to 10000 and log when hit.
The scan walks dates ascending, so the old cap silently dropped the
NEWEST dates of a 30d window — newly added rules (e.g. ANALYZE-SEC-008)
were entirely missing from global stats.
- MCP validate_rule lint: accept event_data_array itemField as a {{token}}
resolver — {{identity}} in ANALYZE-SEC-005/006 was a false positive.
Backend 4157 tests green, MCP 548 green + tsc clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
Oliver Kieselbach
|
06626a4095 |
web: evaluateOn in the analyze-rule editor + interim-trigger badge
The evaluateOn feature was API/MCP-only — portal users could not see or set evaluation triggers. The rule editor gains an Evaluation Triggers section (enrollment end / WhiteGlove seal checkboxes + on_event type list) with client-side grammar + hard-block validation sourced from the baked guardrails mirror (combine.js now emits BLOCKED_INTERIM_TRIGGER_EVENT_TYPES for the web); rule cards show an 'Interim: …' badge for interim-enabled rules (incl. the built-in ANALYZE-ID-004). Create/edit payloads round-trip evaluateOn; the template-copy path already deep-clones it server-side. Suites: web 762 + tsc + lint clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
22a8c7a51d |
rules: hard-block high-frequency event types as evaluateOn on_event triggers
A warning does not stop an end user — telemetry-cadence types (performance_snapshot, agent_metrics_snapshot, download_progress, network_state_change/connectivity_check, log_entry, agent_trace, stall_probe_check) would turn every ingest batch into an analyze run. Now enforced in three layers: - AnalyzeRuleTriggers.BlockedOnEventTypes (code-only enforcement): CRUD write is rejected with an explicit message, and OnEventTypes() drops blocked types at runtime so even a persisted row (pre-validation data, direct table write) is inert for the trigger registry and the engine alike. - rules/guardrails.json gains blockedInterimTriggerEventTypes as the display/ pre-flight mirror (baked into the MCP RULE_GUARDRAILS via combine.js); a parity test pins mirror and code set against drift — same pattern as the gather hard blocks. - MCP validate_rule: the high-frequency finding is now an ERROR sourced from the baked mirror, not a hardcoded warning. Suites: Backend 4155, MCP 548. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
72136f0273 |
backend+mcp+web: evaluateOn interim triggers for analyze rules
Implements docs/rules/analyze-rule-triggers.md (spec approved today): - AnalyzeRule.EvaluateOn (absent = [enrollment_end], today's behavior bit-for-bit) with the shared AnalyzeRuleTriggers grammar/matching helpers; grammar enforced in tenant rule CRUD and the analyze-rule JSON schema. - RuleEngine: AnalyzeRunContext (Terminal/Interim/Reanalyze), interim rule filter, KO suppression on interim runs, and RuleResult update-semantics replacing the permanent dedupe freeze — interim rows refresh, the terminal pass finalizes or resolves them (ResolvedAt, kept for audit), Reanalyze preserves lifecycle markers. - Notification dedupe moves onto RuleResult.NotifiedAt (one send per session+rule, stamped after a successful send; survives the manual reanalyze rebuild). - Handler: whiteglove_sealed / interim_trigger reasons — notify + SignalR yes, IssuesDetected + rule stats terminal-only (Rule Regression Radar baselines clean). - Ingest: InterimTriggerRegistry (per-tenant 5-min TTL cache, fail-soft) gates the interim_trigger enqueue (batch eventType intersection) and the whiteglove_sealed enqueue on the first genuine WhiteGlove seal. - Storage: EvaluateOnJson on AnalyzeRules; FirstDetectedAt/LastEvaluatedAt/ IsInterim/ResolvedAt/NotifiedAt on RuleResults (nullable — legacy rows read as final). - MCP: three authoring lints (terminal-precondition trap, unknown/high-frequency on_event types, KO-on-interim), authoring guide + baked schema updated; get_session_summary marks interim and excludes resolved findings. - Web: preliminary badge on interim findings, resolved findings behind a toggle, issue counts exclude resolved (analysis section + diagnosis flow). - ANALYZE-ID-004 v1.1.0: first interim-enabled rule (on_event:hybrid_login_pending), threshold raised to 75 so only repeated overdue-login signals fire mid-run. Suites: Backend 4152, MCP 548, Web 762 + tsc + lint clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
6c6014940e |
rules: hybrid user-affinity + never-settled-app detection, dsregcmd on_event snapshot, evidence interpolation fixes
ANALYZE-ID-004 (hybrid sign-in never establishes Entra user affinity),
ANALYZE-APP-015 (required app pending forever, ESP completion deferred),
ANALYZE-ENRL-002 v1.1 (desktop-reached + apps-done evidence), GATHER-DEVICE-006
(dsregcmd /status triggered by hybrid_login_pending). Engine: list evidence
values now comma-joined for UI/{{token}} interpolation; timeoutHours added to
the evidence whitelist so ANALYZE-ENRL-002's explanation interpolates.
Motivated by esa-logistics sessions 3ac8cb0e/95f71149 (user-phase stuck,
GlobalProtect never settling, placeholder identity persisting across reboots).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
Oliver Kieselbach
|
2f8ad82b0a |
gather-rules: mirror hard blocks in portal/MCP, stamp author on PUT-upsert; agent: bootstrap retry tests
Codex follow-ups to
|
||
|
Oliver Kieselbach
|
14acfd5c59 |
rules: renumber Secure Boot rule to ANALYZE-SEC-008 — SEC-002 is a retired ID
ANALYZE-SEC-002 was the sunset AutoLogon rule; BuiltInRulesTests pins that the ID never returns (the CI failure on main). Reusing a retired ID would also inherit any historical tenant state keyed to it. Rule content is unchanged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
9fce499f4c |
rules: ANALYZE-SEC-002 — warn when Secure Boot is disabled
Fires on secureboot_status.uefiSecureBootEnabled=false; legacy BIOS devices (registry key absent, agent sets note field) are skipped via precondition. +20 confidence on physical devices. Validated with MCP validate_rule (0 findings) and test_analyze_rule dry-runs: fired at 90 on a physical SecureBoot:False session, silent on a SecureBoot:True session. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
3c1229a301 |
MCP rule authoring: deterministic context, validate_rule, and session dry-run (#124)
* feat(backend): dry-run endpoint for draft analyze rules (rule authoring)
POST /api/rules/analyze/dryrun evaluates a DRAFT analyze rule against one
session's events and returns a full diagnostic trace: per-condition
matched/evidence (incl. per-eventType occurrence counts), per-factor
confidence breakdown, verdict, and the would-be MatchedConditions map for
{{token}} interpolation preview. Persists nothing: no RuleResult row, no
session-status change, no notifications.
- RuleEngine.DryRun.cs: DryRunRuleAsync / DryRunEvaluate share the exact
evaluators (EvaluatePrecondition/EvaluateCondition/EvaluateConfidenceFactor)
with the production path but evaluate ALL conditions instead of breaking on
the first failed required one; parity with EvaluateRule is pinned by tests.
- DryRunAnalyzeRuleFunction: TenantAdminOrGlobalReader (read-in-effect POST),
GA/GlobalReader cross-tenant via session tenant resolution, 1 MB body cap,
structural draft validation (unknown source/operator, correlation without
joinField, invalid regex, non-evaluable confidenceFactor DSL) with
actionable error messages.
- EndpointAccessPolicyCatalog: register the new route.
- RuleEngineDryRunTests: trace semantics, production parity matrix,
side-effect freedom (VerifyNoOtherCalls), draft validation matrix.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* feat(mcp): rule-authoring resources — guide, schemas, guardrails
Deterministic authoring context for customer AIs, replacing chunked
search_docs retrieval for rule creation: get_resource (and the MCP-protocol
resources) now serve
- rule_authoring_guide: hand-written, complete authoring knowledge (collector
types, triggers, condition sources, operators, confidence model incl. the
exact factor-condition DSL shapes, {{token}} interpolation order, guardrail
matching semantics, pitfalls, validate->dry-run workflow)
- rule_schemas: the JSON Schemas (2020-12) for gather + analyze rules
- rule_guardrails: the on-device collection allowlists
Schemas + guardrails are generated into rule-authoring.generated.ts by a new
combine.js emitter (same pattern as the web guardrails mirror; rules/ stays
the single source of truth and CI guardrails-in-sync guards the file).
rule-authoring-drift.test.ts additionally pins generated == repo source,
guide enums == schema enums, and the get_resource size cap.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* feat(mcp): validate_rule + test_analyze_rule tools and author-rule prompt
Closes the authoring loop for customer AIs: draft -> validate -> dry-run
against a real session -> iterate -> create in the portal.
- validate_rule (MCP-local, no backend call): ajv 2020-12 validation against
the baked schemas, guardrail pre-flight mirroring the agent matching
semantics (hive-stripped segment-bounded registry/file prefixes,
whitespace-bounded WMI, exact commands, /-bounded event log channels, hard
blocks), and semantic lint for schema-valid-but-dead rules (unreachable
threshold, non-evaluable factor DSL, unknown eventTypes, unanchored
not_regex allowlists, unresolvable {{tokens}}, trigger cross-fields,
outputEventType conventions/collisions).
- test_analyze_rule: calls the new POST /api/rules/analyze/dryrun and adds
the {{token}}-interpolated explanation/remediation preview via the
existing interpolate-rule-template.
- author-rule MCP prompt guiding scenario -> resources -> draft -> validate
-> dry-run.
- Both tools are visible to every role (backend enforces
TenantAdminOrGlobalReader on the dryrun route); catalog snapshot updated.
- deps: ajv + ajv-formats promoted to direct dependencies.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* docs(okf): rule authoring surface concept doc
docs/rules/rule-authoring-surface.md: the AI-assisted authoring stack
(deterministic MCP resources via combine.js baking, MCP-local validate_rule
layers, the dry-run trace twin with its parity + side-effect invariants, and
what is deliberately absent); registered in index.md, logged 2026-08-05.
Customer docs (rules/ai-assisted-rule-authoring.md + SUMMARY + FAQ entry) are
committed in the autopilotmonitor-docs repository separately.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
|
||
|
Oliver Kieselbach
|
e7ea431ccf |
feat(esp): recovery story for terminally reported ESP failures (session 4910a5a5)
DeviceSetup/Apps failed, the user pressed "Try again" ~23 min later, apps recovered to 10/10 and DeviceSetup resolved - yet the advisory_completion window un-defanged the stale failure and failed the live enrollment, because the advisory variant was exempt from all re-arm/rebase guards. Engine fix (DecisionCore): - New facts EspAdvisoryFailureResolvedUtc + EspAdvisoryFailureCategory (state-borne; deadline payload would be lost on re-arm/rebase). - TryResolveAdvisoryOnCategoryRecovery in both ProvisioningComplete handlers: category match sets the fact + emits esp_failure_advisory_resolved. - Guards now (!hasAdvisoryAnchor || advisoryResolved): enforcement-progress re-arm, hello-never-observed promote and the reboot rebase apply again once the failure demonstrably un-happened; unresolved advisories keep the legacy un-defang exactly. - Truthful terminal reason esp_recovered_without_completion_evidence (+ failureRecovered=true, LastFailureTrigger=DeadlineFired so the likely-stuck app promotion stays off). Story events (agent tracker): - esp_failure_retry_detected: failed subcategory leaves "failed" after the terminal fire - consistent with the user pressing "Try again". - esp_failure_recovered: previously failed category reaches success. - EspFailureDetectedEventArgs.LikelyCulpritApps (never-started first, cap 3) rides the EspTerminalFailure payload so esp_failure_advisory / enrollment_failed name the culprit app directly. Surfacing: MCP resource-catalog, web timeline badges (Recovered / User retry pills, culprit chip on advisory), gather-rule autocomplete, ANALYZE-ESP-006 "ESP Failure Recovered After User Retry". Tests: AdvisoryRecoveryTests (13, incl. the 527/611/635/671 field-ordinal replay that no longer fails the session), EspFailureRecoveryStoryTests (5), snapshot-builder guards 18 -> 20. All suites green (DecisionCore 493, V2.Core 2018, Backend 3201, web vitest 589, MCP 449 incl. drift). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
9e24b92fbf |
feat(agent): ESP policy-provider stall detector + Autopilot registry guardrail
Customer field case: pre-provisioned devices with the ConfigMgr client as a
blocking app occasionally park the user ESP at "Apps (Identifying)" for days.
Root cause (verified against the EnrollmentStatusTracking CSP doc): only a
"ConfigMgr" provider is registered under Device\Setup\Apps\PolicyProviders
(no "Sidecar" = IME) and TrackingPoliciesCreated never becomes 1 - a wait the
CSP defines WITHOUT any timeout. Renaming the key to Sidecar unblocks
immediately. Microsoft documents that ESP providers are not aware of each
other and that pre-provisioning is unsupported with co-management.
New always-on esp_policy_provider_stalled tripwire, generalized to any
provider in both kinds (Setup/Apps TrackingPoliciesCreated != 1,
DevicePreparation InstallationState not in {2,3}):
- EspPolicyProviderProbe: fail-soft registry read of the
EnrollmentStatusTracking mirror (device + user-SID scopes), defensive
value parsing (missing/unparseable = incomplete), ScopedOverride test seam.
Research and CSP contract quotes captured in the XML doc header.
- EspPolicyProviderStallDetector: pure EvaluateStallTransition on a 15-min
continuous-incompleteness dwell (resets on completion/disappearance;
absent key = normal early enrollment), one-shot per provider,
StartupEventGate fingerprint over the sorted stalled key set for
cross-restart dedup. Warning + ImmediateUpload via InformationalEventPost;
purely observational, no decision-engine coupling, no config toggle,
no ConfigVersion bump (disk_space_low precedent).
- EspPolicyProviderStallHost: 60-s wall-clock tick, deliberately outside the
StallProbe idle gate (idle clock resets on session activity) and the
idle-stopped periodic collectors.
- Registered in Constants.EventTypes, MCP resource-catalog (health_events),
web gather-rule autocomplete (stall category).
Guardrail companion: SOFTWARE\Microsoft\Windows\Autopilot joins the
gather-rule registry allowlist ("Autopilot / OOBE / Setup") so tenants can
build custom rules on the subtree (e.g. not_exists on the Sidecar provider
key); generated web mirror regenerated via combine.js; positive + sibling-
spoof guard tests added.
Docs: OKF concept doc agent/esp-policy-provider-stall.md (+ index/log).
Tests: 22 new detector tests (pure transition matrix + emission surface incl.
the ConfigMgr-only customer scenario and gate-across-restart dedup); agent
suite 2013/2013, web vitest 589/589 + tsc clean, MCP 449 passed incl.
event-types-drift.
Both the detector and the embedded allowlist take effect with the next agent
release.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
Oliver Kieselbach
|
90012d9a66 |
feat(agent): verify Secure Boot CA-2023 state against firmware, not just servicing registry
Customer report: ANALYZE-SEC-001 warned on devices whose firmware already carried the Windows UEFI CA 2023 certificate — the agent only read the SecureBoot\Servicing registry value, which mirrors the Windows Update rollout and lags behind reality (OEM factory image, WinCS, WU not run yet). Agent: new UefiSecureBootCertReader reads the UEFI db/KEK variables natively (GetFirmwareEnvironmentVariableExW; SeSystemEnvironmentPrivilege enabled on the process token and restored — first privilege-adjustment code in the repo). Fail-soft, never throws; legacy BIOS maps to not_uefi. secureboot_status gains per-certificate booleans, uefiFirmwareReadStatus, and the one-sided marker uefiCa2023FirmwareConfirmed (emitted only on positive confirmation, never as false). Rule v3.0.0: not_exists precondition on the marker suppresses the rule when the firmware confirms the certificate; the marker's absence keeps old agents on exact v2 behavior, so the rule is safe to seed before the agent rollout. Firmware-verified-missing raises confidence (+20 db, +10 KEK 2K CA 2023). Verified: full solution build; backend 3201, agent 1988, web 582 tests green; tsc/ajv clean; elevated cross-check on real firmware matches Get-SecureBootUEFI on all seven certificate probes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
3f9576d4a9 |
fix(agent): enforce the gather-rule allowlist in every collector
LogParserCollector and EventLogCollector called no guard at all, while File/Json/Xml did — and rules/gather-rules.md already promised customers that log-parser paths were allowlisted. A tenant admin could author a logparser rule against C:\Users via POST /api/rules/gather and have up to 1000 lines uploaded as telemetry, bypassing the hard C:\Users block the same page guarantees; eventlog could read any channel, Security included. The backend validates no collectorType, target, or parameters, so the agent is the only place this can be enforced. Both now guard. logparser cannot check rule.Target directly (GetFullPath throws on a wildcard), so it checks the directory for wildcard targets and re-checks each resolved path. Event log channels get an allowlist matched on a "/" boundary. Hard-blocked channels live in a C# constant rather than guardrails.json: a parse error drops the allowlists to empty, which is fail-closed, but would have lifted a block sourced from the same file. Also fixes an inert timeout in CommandCollector: ReadToEnd() blocks until the pipe closes, so WaitForExit(30000) was only reached once the process had already exited and a hung command pinned its worker indefinitely. Adds the first real CI gate. No workflow ran tests on a pull request — the deploy workflows build without testing and build-agent.yml covered only DecisionCore.Tests on manual dispatch — while trust/security-faq.md already told customers automated tests run in CI. ci.yml now runs all six suites on every PR and merge, plus a job that fails on generated-guardrail drift, alongside CodeQL and Dependabot. OfficeBinaryWatcherTests is marked SerialThreading; its bounded re-probe races the shared ThreadPool and failed once under full-suite load. Verified: 3101 backend, 1911 agent V2, 474 decision core, 44 dialog, 572 web, 447 MCP. The timeout fix is verified by runtime, not assertion — a Start-Sleep 120 command now returns after ~30s. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
dbf6e50e2d |
feat(agent,web,shared): phase_exit gather trigger — one-shot collection at a phase's end
Follow-up to gather-rule phase scoping. One-shot collection at a phase START
already existed (phase_change dedups per (rule, phase)) and at enrollment END
(on_event + enrollment_complete); the END of a specific phase had no trigger.
New trigger value "phase_exit": fires once when TriggerPhase is LEFT (empty =
every phase transition). Together with phase_change it forms the two one-shot
bookends of a phase.
Agent (GatherRuleExecutor.OnPhaseChanged):
- Exit rules are evaluated BEFORE _currentPhase advances, so both the
TriggerPhase match and the phase-scope gate see the phase being LEFT. A rule
scoped to DeviceSetup therefore fires on its own exit even though the phase
being entered is out of scope.
- A transition into Failed fires the exit rules of the failing phase — the
snapshot at a failure boundary is the point of the trigger.
- Exit of Unknown never fires; a repeated identical phase signal is not a
transition.
- Dedup key "exit:{ruleId}|{phase}" shares _phaseRulesExecuted with the
phase_change keys but stays in a disjoint key space, so an enter-rule and an
exit-rule on the same phase cannot consume each other's slot.
Portal: trigger labels are now "Phase Start" / "Phase End"; the canonical phase
dropdown and the create/save payloads cover both via PHASE_TRIGGERS; the card
renders "entering X" / "leaving X".
No ConfigVersion bump: no new field is transported. Old agents do not know the
value and simply never fire the rule (silent no-op).
Tests: GatherRuleExecutorPhaseExitTests (11) — enter-vs-exit, no refire on
re-entry, empty-triggerPhase, exit-of-Unknown, same-phase-signal, into-Failed,
Complete, scope-against-left-phase, out-of-scope slot preservation, key-space
disjointness, on_change interplay. Build 0 Errors; V2.Core.Tests 1884/1884;
Functions.Tests 3099/3099; vitest 557/557; tsc silent.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
Oliver Kieselbach
|
a97888ebd5 |
fix(agent): neutral aggregated 2800 observations; reboot claim gated on observed reboot
Rework after the first real enrollment (session b2e890c1) exposed three
defects in
|
||
|
Oliver Kieselbach
|
a654c7309e |
feat(agent): attribute mid-ESP coalesced reboots to MDM policy URIs (second sign-in detection)
Device-assigned MDM policies whose CSP URIs match the OS reboot-required
catalog force a coalesced reboot at the end of ESP DeviceSetup - the user
sees an unexpected restart and a second sign-in before AccountSetup.
Invisible in the Intune console; admins simply lived with it. Now attributed
and actionable (PMPC research).
- MdmRebootPolicyTracker (+host): watches DeviceManagement-Enterprise-
Diagnostics-Provider/Admin EventID 2800, emits one mdm_policy_reboot_required
per reboot-forcing URI (Warning, ImmediateUpload; tolerant EventData-first
URI extraction with regex fallback; fail-soft OMADM RebootRequired probe).
Cross-restart RecordId watermark (mdm-reboot-watermark.json) - mandatory,
the coalesced reboot restarts the agent and the backfill re-reads the log.
- ShellCoreTracker: RebootCoalescing branch on the already-watched 62407
stream -> esp_reboot_coalescing corroboration event; deliberate deviation:
emits on backfill too (live emit races the reboot kill).
- ANALYZE-ESP-005 advisory (warning): names the first URI via {{rebootUri}},
remediation = reassign profiles device -> user groups; +20 confidence on
coalescing corroboration, +10 on >=2 URIs.
- Config: Collectors.MdmRebootPolicyWatcherEnabled (default ON, internal
steering only - agent-native collector, NOT an IAgentAnalyzer, no admin UI),
MdmRebootPolicyBackfillLookbackMinutes=60; ConfigVersion 35.
- Event types deliberately distinct from system_reboot_detected so the
backend RebootCount (exact-string match, 2 sites) stays uninflated.
- Docs: docs/agent/mdm-reboot-coalescing.md (+index/log). Exact 2800/62407
message texts are unverified until E2E VM validation (tolerant matching).
Tests: Agent.V2.Core 1868/1868 (21 new), Functions 3099/3099, MCP 400 passed
(event-types drift), solution build 0 errors.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
Oliver Kieselbach
|
21dd35f787 |
feat(backend,shared): gather-rule phase scoping + emit-mode fields, custom-rule toggle wipe fix
Step 0-2 of the gather-rule anti-spam plan:
- GatherRuleService.UpdateRuleAsync: toggle-style partial PUTs ({enabled,
isBuiltIn, isCommunity}) previously full-replaced the stored custom rule and
wiped Title/Target/Trigger/Parameters. Partials now merge Enabled into the
existing row; full edit payloads preserve the original CreatedAt.
- GatherRule: new opt-in fields ActivePhases (run only during listed phases),
ActiveFromPhase (sticky latch from a phase onwards), EmitMode (always |
on_change). Absent fields = legacy behavior; schema updated accordingly.
- TableStorageService.Rules: Store+Map for the three columns (absent column /
stored-empty -> null); MapToGatherRule internal for roundtrip tests.
- ContentEquivalent covers the new fields, null-tolerant for ActivePhases so
pre-existing rows never diff against seeds (no reseed churn).
- GatherRulesFunction.ValidateScopeAndEmitMode: canonical EnrollmentPhase name
list Start..Complete (Unknown/Failed and numeric tokens rejected), mutual
exclusion of the two scope fields, emitMode whitelist; 400 on violation.
- ConfigVersion 33 -> 34 (33 was taken by MigrateToApiBaseUrl).
Tests: GatherRuleUpdatePartialMergeTests (merge/replace/unknown-rule/built-in
path), GatherRuleScopeFieldsTests (Store<->Map roundtrip incl. legacy rows,
ContentEquivalent matrix, validation accept/reject). Functions.Tests 3029/3029.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
Oliver Kieselbach
|
34edadf0db |
docs(rules): document observability limits of the ZTD known-issue rules
The agent is normally installed by an IME platform script AFTER MDM enrollment succeeded, so pre-enrollment failures (enrollment blockers, TPM attestation) are invisible in the normal flow — no enrollment means no agent and no authenticable session. Await-enrollment mode does not help either: the binary only polls for the MDM certificate and cannot authenticate without it. Only bootstrap-token deployments (one pilot customer) can report pre-MDM. - New Observability section in docs/agent/autopilot-ztd-diagnostics.md with a per-rule visibility matrix (normal / bootstrap / await) and the follow-up option of backfilling Autopilot-channel error records - ANALYZE-ENRL-003/004 descriptions state the limitation explicitly so portal users understand why these rules rarely fire Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
cd870e639d |
feat(agent+rules): evidence-backed ZTD diagnostics for missing Autopilot profiles
Agent (autopilot_profile_missing evidence package): - ZtdEvidence collector: one-shot all-level query of the ModernDeployment Autopilot event channel (807/809/815/908 errors + 100/153/160/161/163/164 flow events) -> ztdVerdict field (device_not_registered / no_profile_assigned / download_attempted_no_profile_returned / ...); the continuous watcher can't supply this (filters out Info) - Diagnostics\Autopilot registry dump (IsAutopilotDisabled, TenantMatched, CloudAssignedTenantDomain/Id) on every autopilot_profile event, flat evidence fields on the missing event - ztd.dds.microsoft.com reachability probe (official endpoint per the requirements page - several blogs cite ztd.ssd.*, which is wrong); volatile probe fields excluded from the restart-dedup fingerprint; Intune diag-upload endpoint deliberately NOT probed (user decision) Analyze rules (known-issue map from Microsoft Learn): - ANALYZE-ENRL-003: TPM attestation known error codes (0x800705B4, 0x801C03EA, 0x81039001/23/24, 0x80070490) - ANALYZE-ENRL-004: enrollment-blocked known codes (0x80180014, 0x80180018, 0xC1036501, 0x801C03F3, 0x80070774) - ANALYZE-ENRL-005: hybrid-join 0x80004005 timeout with per-version KB fix builds (gated on isHybridJoin via confidence threshold) - ANALYZE-DEV-007: NTP clock skew > 2min (documented TPM-attestation/ESP timeout cause) using existing ntp_time_check offsetSeconds Docs: new OKF reference docs/agent/autopilot-ztd-diagnostics.md (event-ID table, diagnostic registry, endpoints, error-code map, sources + re-check RSS feed), linked from ZtdEvidence/ModernDeploymentTracker code comments, indexed in docs/index.md + agent/index.md + log.md. Tests: 11 ZtdEvidence verdict tests; full V2 suite 1799 green; rule schema validated (ajv draft2020); backend rule tests 123 green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
fa03e290b2 |
feat(agent): os_build_changed detection + WU channel blind-spot census (session 7443317c)
Session 7443317c proved a WU-tracker blind spot: an OOBE quality update
installed (OsBuild 26200.8037 -> 26200.8655 across the mid-enrollment reboot)
yet the deployed WindowsUpdateTracker emitted ZERO events - the watcher armed
fine (no collector_degradation), the spool is durable, and two 60-min backfills
covered the install window, so the WindowsUpdateClient channel simply carried
none of the targeted EventIDs 19/20/43/44. The tenant has diagnostics upload
disabled, so the fix makes the feature self-evidencing instead of guessing IDs:
- OsBuildChangeHost: persists CurrentBuild.UBR (Registry64 view) to
AgentState/os-build-state.json and emits os_build_changed (Info, immediate)
when it differs across a restart - deterministic update corroboration that
cannot be lost to timing, watermarks, or unexpected servicing paths. First
run seeds silently; corrupt state re-seeds.
- WindowsUpdateTracker channel census: when the build provably changed AND zero
targeted WU events were emitted this run, emit a one-shot
windows_update_channel_census (Debug) with an unfiltered EventID histogram of
the WindowsUpdateClient AND UpdateOrchestrator channels over the lookback
window (capped at 5000 records, cap surfaced as censusTruncated). The
histogram arrives via normal event upload and tells us which IDs to add to
WindowsUpdateTargetedEventIds via remote config - no redeploy, no diag ZIP.
Gated by CollectorConfiguration.WindowsUpdateChannelCensusEnabled (default
on, model-default pattern, no ConfigVersion bump).
- No new hardcoded EventIDs (per the device-validation rule) - census data
decides what to enable remotely.
- ANALYZE-DEV-006 "OS Build Changed During Enrollment" (info, not KO):
interpolates {{previousBuild}}/{{currentBuild}}, counts the census as
corroboration. Catalogs: Constants.cs + MCP resource-catalog.ts + web
eventTypes.ts (drift-test enforced).
Tests: 6 OsBuildChangeHost (seed/same/changed/unreadable/corrupt/no-dir),
7 census (gating matrix, truncation surfaced, scanner-throw swallowed,
histogram format), 3 ANALYZE-DEV-006. Agent.V2.Core 1754/1754, Backend
2874/2874, MCP 379 (drift green), web tsc + vitest 367/367, sln 0 errors.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
Oliver Kieselbach
|
50295e8304 |
feat(agent): AppX/MSIX failure enrichment in ESP settle window (esp_appx_failure_analysis)
Session 2bc884b6: ESP failed AccountSetup/Apps with 0x80073cf9 while all 8 tracked Win32/WinGet apps succeeded — the failing app was a MSIX/Store app that installs outside the IME Win32 pipeline and is invisible to ImeLogTracker. The session ended as a blackbox failure. When an Apps-subcategory failure arms the 30s settle window, the tracker now queues a one-shot scan of Microsoft-Windows-AppXDeploymentServer/Operational (Critical+Error, session window, 200-record/10s cap), scores candidate packages (exact-HRESULT match > AppX-family error > time proximity, recency bonus), and emits esp_appx_failure_analysis with flat RuleEngine fields plus a capped candidates[] detail list — before enrollment_failed lands in the timeline. Negative results are emitted too (no_appx_candidates points back at Win32). Fire-once per session; scan runs lock-free on the threadpool; settle expiry never waits; failures degrade to collector_degraded. - New: AppxDeploymentFailureScanner (one-shot reader, injectable seam), AppxFailureAnalyzer (pure scoring/verdicts, incl. negative-decimal HRESULT + PackageFullName extraction from message/properties) - ProvisioningStatusTracker: optional scanner/dispatcher ctor seams, MaybeStartAppxFailureScan at settle-arm time - Rule ANALYZE-APP-014 (MSIX/Store app failure during ESP) keyed on verdict=appx_candidate_identified; dist regenerated - MCP resource-catalog + web HRESULT badge + gather-rules eventTypes - Tests: 16 analyzer + 7 trigger; settle-window fixture now injects a fake scanner + sync dispatcher (no real event log in tests) Inert until agent redeploy (rule needs backend redeploy). Post-deploy checks in tasks/todo.md. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
33618e183d |
feat(wu-oobe): detect & surface Windows Update during OOBE + self-maintaining rule sunset
Windows Update activity during Autopilot OOBE/ESP is a blind spot no other tool (Intune console included) surfaces well — a cumulative update installing mid-OOBE can break enrollment (r/Intune KB5095189). This makes it visible with secured evidence. Agent (net48): - WindowsUpdateTracker + WindowsUpdateWatcherHost: watch Microsoft-Windows-WindowsUpdateClient/Operational (EventIDs 19/20/43/44 = success/failure/install-started/download-started), startup backfill (OOBE updates run before the agent starts), RecordId watermark dedup (restart boundary vs intra-run seen-set so a high-id live event can't hide older backfill events), HRESULT->symbol decode. Emits windows_update_succeeded/_failed/_started with the real event Timestamp. Default-on config knobs; uncertain EventIDs configurable without redeploy. - RegistryCollector: emitOnlyIfExists (suppress positive-assertion events when the key is absent) + Registry64 base view by default (bitness-independent, matches TenantIdResolver) with optional registryView override. Rules: - ANALYZE-DEV-004 (high: WU failed during enrollment, high-insight not KO) + ANALYZE-DEV-005 (info: WU installed). reboot_pending corroboration matches event_data exists==true. - GATHER-DEVICE-005 -> windows_update_reboot_pending (emitOnlyIfExists), GATHER-DEVICE-004 -> windows_update_history (Get-HotFix, opt-in). - 5 EventTypes synced across Constants + MCP resource-catalog + web eventTypes. Self-maintaining rule lifecycle (analyze + gather parity): - Gather rules gain the sunset/orphan-GC that only analyze had (ProcessSunsetGatherRuleAsync + runtime filter + seed/reseed/github paths). - RuleProvenance field (embedded/github, null=embedded back-compat): the embedded catalog only sunsets its own rules; GitHub-reseeded rules ahead of the deployed binary (new ids AND content updates to existing ids) are exempt and reclaimed to embedded once the binary catches up. No orphans, no operator knowledge required. Verified: full solution builds; backend suite 2770 pass, agent suite 1638 pass; rules AJV-valid + combined. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
a70785fb42 |
feat(rules): built-in analyze-rule hygiene pass ahead of public docs catalog
- Retire ANALYZE-ESP-003 (duplicate of ESP-001) and ANALYZE-CORR-002 (duplicate of APP-004) via the established sunset path; ESP-001 gains a >60min factor, APP-004 absorbs the co-occurrence story with working confidence factors - CORR-003: download evidence (errorPatternId) is now a required condition — no more firing on proxy + any unrelated app failure - DEV-002 v2: 'sustained' semantics — new event_count value filter (filterField/filterOperator/filterValue in schema, Shared model, engine, web types) requires >=3 snapshots above 90% memory instead of one transient spike - DEV-003 v2: build-cutoff-only condition (<=22621) now also covers Windows 10; LTSC caveat + maintenance note (raise to 22631 after 2026-11-10) - SEC-001 v2: rewritten for the post-June-2026 reality — certificates HAVE expired, active remediation required (OEM firmware hint added) - SEC-005/006 v2.1: allow-list extended with OEM factory-preload families (Intel PPM, AMD Power, Lenovo ThinkPad power/battery, Surface/carrier), telemetry-curated from 1780 fired sessions; imaging leftovers (USMT.PPKG, InstallOrder.ini) and generic names deliberately still alert - APP-001: suppressByEvent on app_install_completed; APP-002: exact MSI exit codes instead of bare 16xx; APP-006 reframed as 'App Install Retry Loop'; ID-001: title/logic mismatch fixed + GATHER-ID-002 dependency documented - Fix all 13 dead confidence factors (signal-name mismatches / unsupported syntax) by rewiring or removal; version bumps everywhere so seeding propagates the updates - New RuleEngineEventCountFilterTests + SEC-005 OEM allow-list coverage Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
44203423ec |
feat(rules): ANALYZE-ESP-004 soft-failure for ESP-timeout + Continue-anyway
Devices that hit the ESP terminal timeout in DeviceSetup on a profile that allows "Continue anyway" are recorded as Failed even though the user most likely dismissed the error and reached the desktop. The existing advisory- defang only covers AccountSetup failures, so DeviceSetup timeouts (e.g. a slow blocking app missing the 30-min wall) show up as hard failures. Add a built-in, enabled-by-default analyze rule (severity: warning) keyed on enrollment_failed.mayHaveContinuedAnyway==true. It surfaces the soft failure and points at the root cause (slow blocking app / ESP timeout / detection mismatch / masked certificate failure) without changing session lifetime or the terminal status. No agent change required; ships via EmbeddedResource or ReseedFromGitHub. Tests: RuleEngineEspSoftFailureTests (fires on the continue-anyway shape, stays silent on hard failures and when the flag is absent). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
474af7f78c |
fix(agent): ESP-Apps failure correlation + platform-script stdout/exit contamination
Two V2 IME fixes, verified against client logs of sessions fc48c71a / 6b4993e5. Bug 1 — on an ESP terminal failure of the DeviceSetup Apps subcategory the only device app was stuck mid-install (RealmJoin stuck Downloading 0%) and IME logged no per-app error, so app_tracking_summary showed 0 failed and the failure was visible only via the opaque "Apps (Error)" registry string. New esp_apps_failure_correlation event names the in-flight (IsActive: InProgress/ Downloading/Installing) device app(s) as the likely cause WITHOUT mutating state (no fabricated app_install_failed) and only on the Apps subcategory. Bug 2 — AgentExecutor.exe hosts both platform and proactive-remediation scripts interleaved in the shared AgentExecutor.log; the policyId-less PS-AGENT-EXITCODE / PS-AGENT-OUTPUT lines from a remediation invocation bled into the last-started platform script via the sticky pointer (c3e0124c emitted result=Failed but with exit 0 + the Teams remediation's "[Compliant] No Classic Teams found" stdout). New PS-AGENT-INVOCATION pattern (resetPlatformScriptContext) clears the platform line-capture pointer at every "ExecutorLog AgentExecutor gets invoked" boundary, so a remediation invocation cannot capture into a platform slot; the platform result stays keyed by policyId via PS-SCRIPT-RESULT. Agent-only, V2, inert until redeploy; no ConfigVersion bump. New event type added to the MCP resource catalog (dual-sync). Green: V2.Core 1522, DecisionCore 400, Backend BuiltInRules 8, MCP vitest 252. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
ecd8036dc0 | updated guardrails | ||
|
Oliver Kieselbach
|
cf8fadfc17 |
fix(rules): drop AutoLogon false-positive on normal Autopilot enrollments
ANALYZE-SEC-002 fired Warning (confidence 90) on every normal user-driven Entra-join enrollment. During ESP, Windows writes AutoAdminLogon=1 + DefaultUserName + AutoLogonSID + no DefaultPassword for the enrolling user — the exact fingerprint the sysinternals_autologon_suspected heuristic targeted (enabled && user && !password). AutoLogon-enabled is registry-indistinguishable from a Sysinternals/kiosk setup during Autopilot, so the heuristic and SEC-002 could never tell a benign enrollment from a real one. Declare AutoLogon only when a plaintext password is actually present: - delete ANALYZE-SEC-002 (broad AutoLogon-active warning) - remove the non-discriminating sysinternals heuristic from AutoLogonAnalyzer (computation + finding label + checks.sysinternals_autologon_suspected) - strip the sysinternals condition+factor from SEC-004 (kiosk allow-list, still a disabled opt-in template) and refresh its now-stale SEC-002 guidance - ANALYZE-SEC-003 (plaintext DefaultPassword -> high) is now the sole default-on AutoLogon grade; the autologon_analysis event still carries all raw facts at Info Tests: assert SEC-002 absent + no rule references the sysinternals signal; add analyzer regression guard for enabled+user+no-password. V2-only, no ConfigVersion bump. Build 0 err, AutoLogon 19/19, BuiltInRulesTests 8/8, web tsc clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
dbfdc9b239 |
feat(agent): event-driven Office (M365 Apps C2R) install detector + DO telemetry
Surfaces the real Microsoft 365 Apps Click-to-Run install lifecycle that the Intune "integrated" app hides (IME reports done in 1-2 min while C2R keeps streaming in the background). V2-only. Event-driven, no idle polling: - OfficeProcessWatcher: WMI Win32_ProcessStartTrace push on OfficeC2RClient.exe (+ startup probe) for start; Process.Exited for stop, debounced by a settle window (OfficeInstallSettleSeconds, default 10s) so short worker gaps in one install don't trigger a premature office_install_failed. - RegistryChangeWatcher: RegNotifyChangeKeyValue push on ...\Office\ClickToRun (Configuration value + Scenario subkey churn); bootstrap fallback watches the nearest existing ancestor non-recursive + name-only until ClickToRun appears. - OfficeInstallDetector: pure state machine (Idle->Active->Terminal), emits office_install_started/progress/completed/failed (progress on real change only, no heartbeat). Error code only from non-zero numeric/hex Scenario values. Office Delivery Optimization: - DeliveryOptimizationCollector extended with a 2nd wake source (Office active), classifies non-IME Office-CDN jobs and folds aggregated DO bytes/peers/real download-% into the office_install_* events (not emitted as download_progress to avoid a phantom app in the backend AppInstallSummary). Plumbing: office_install_* event-type constants, EnableOfficeInstallDetector + OfficeInstallSettleSeconds config (ConfigVersion 28->29), MCP + web event-type catalogs, ANALYZE-OFFICE-001 (office_install_failed -> Warning). 22 detector unit tests; full V2 suite green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
425502c419 |
feat(ppkg): array-aware analyze rules + allow-list + size-chunked scan event
Reworks PPKG detection to one aggregate event the rules parse as an array, adds a default + customizable allow-list, and makes the event storage-safe. Rule engine: - New condition source event_data_array + ItemField: iterates an array field (any-element match), with dot-path dataField support. (RuleEngine.ConditionEvaluators) Agent: - Drop per-package provisioning_package_detected events (noise: a clean Win11 VM ships ~22 OS-inbox .ppkg). One provisioning_package_scan carries an artifacts[] array; anyPpkgFound derived from it (consistent, incl. recovery residue). - Size-based chunking: split artifacts across multiple scan events so each event's Newtonsoft DataJson stays < 24k (well under the 30k Table-Storage truncation that would blind the rule); never drops a tail artifact. Per-artifact string fields (identity/dir/rank/installTime) hard-capped at 256; scanErrors capped. Rules: - ANALYZE-SEC-005 (default on) + SEC-006 (template) fire on artifacts.identity not matching an anchored allow-list (^(?:...)\b) that covers OS-inbox families. - ANALYZE-SEC-007 alarms when a per-source collection cap was hit (scanTruncated). Web/MCP/docs: event_data_array in the rule form (types + fields), analyze-rules docs section + example, event-type catalogs. Tests: rule-engine array/anchor/dot-path/SEC-007; agent artifacts/chunking/field-cap /worst-case-size. Build green; V2.Core 1236; backend rule + web tsc green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
01fac29bcb |
feat(agent): AutoLogon detector + analyze rules (V2)
V2-only AutoLogonAnalyzer that reads the Winlogon AutoLogon configuration and emits an autologon_analysis event with raw facts at Info severity. AutoLogon can be a legitimate kiosk/shared-device setup or a way to automate enrollment/OOBE; the agent reports facts only and never reads the DefaultPassword value (presence detected via value-name enumeration). Backend analyze-rules grade the facts. - AutoLogonAnalyzer (always-on, no tenant toggle): startup no-op, runs at DeviceSetup-phase completion (new AutoLogonDeviceSetupTrigger on EspAndHelloHost.DeviceSetupProvisioningComplete) and at final shutdown. - Sysinternals Autologon heuristic (AutoLogon enabled + default user + no registry password = LSA-secret credential); never reads the LSA secret. - Analyze rules: ANALYZE-SEC-002 (AutoLogon enabled -> warning, default-on), ANALYZE-SEC-003 (plaintext DefaultPassword -> high), ANALYZE-SEC-004 (kiosk allow-list template). Sysinternals graded via a real confidence condition inside SEC-002/004 so the allow-list still suppresses approved kiosks. - autologon_analysis added to all event-type catalogs; rule-builder picker also gains the previously-missing integrity_bypass_analysis + local_admin_analysis. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
2900b35256 |
feat(agent): provisioning-package (PPKG) detector + analyze rules (V2)
V2 PPKG scanner that runs once at DeviceSetup-phase start and reports raw facts only — .ppkg file presence, Provisioning\Packages registry metadata, Recovery\Customizations residue, and best-effort per-package content indicators. PPKGs can come from legitimate bulk enrollment or be a pre/in-enrollment manipulation vector; intent is judged by backend analyze-rules, not the agent. - ProvisioningPackageCollector + ProvisioningPackageHost, wired as a kernel host in DefaultComponentFactory (one-shot at DeviceSetup start, not at agent start). - Events: provisioning_package_scan (aggregate) + provisioning_package_detected (one scalar event per artifact so analyze rules can match per package). - Analyze rules ANALYZE-SEC-005/006 incl. a per-tenant allow-list template. - Event-type catalogs kept in sync (Constants.EventTypes, MCP resource-catalog, rule-builder eventTypes). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
9855860f1c |
feat(mcp): interpolate {{token}} rule-template placeholders in analysis output
MCP-side mirror of the web interpolateRuleTemplate: resolve
{{reason}}/{{appName}}/{{errorCode}}/... from each rule result's
matchedConditions before get_session_details and get_session_summary
ship the explanation + remediation text, so MCP tool output never leaks
raw {{...}} placeholders. Resolution order is kept in lock-step with the
web copy (byField -> whitelisted auto-field -> signal name).
Also rewords the ANALYZE-ENRL-001 footnote to explain that a remaining
literal {{...}} means the field simply was not recorded for this session
(version 1.1.0 -> 1.1.1; compiled dist and the rule-version assertion in
RuleEngineDetectionFailureTests updated to match).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
Oliver Kieselbach
|
3318467857 |
fix(sessions): emit terminal session_timeout event so 5h-timeout sessions analyze
The maintenance sweep graduated a stalled session to terminal Failed via the repo (MaintenanceService Stage 2, SessionTimeoutHours=5h default) but wrote no event into the session stream and never enqueued analyze. The analyze pipeline fires on stream events, so a server-timed-out session analyzed to totalIssues:0 — unlike the agent max-lifetime path, which emits a real enrollment_failed and is correctly analyzed. - New server-authored event type Constants.EventTypes.SessionTimeout = "session_timeout" (+ MCP termination_events catalog; drift test green). - MaintenanceService Stage 2 now captures the UpdateSessionStatusAsync result and, only on the real first transition (idempotent — the sweep never re-collects a Failed session), emits a session_timeout event (new pure static BuildSessionTimeoutEvent: Sequence = max(session events)+1 so it sorts last, Phase=Unknown, Source=System. Maintenance, Severity=Error) and enqueues auto-analyze with ReasonEnrollmentFailed. Best-effort try/catch — never blocks the timeout transition. Producer injected. - RuleEngine: EvaluatePrecondition gains a pure event-type-presence gate (no-dataField exists/not_exists) — additive (no rule used dataField-less preconditions), enables a session-level suppression with no shared join field. - New rule ANALYZE-ENRL-002 "Session Timed Out": fires on session_timeout, suppressed when enrollment_complete OR enrollment_failed exists (5h<6h late-completion race + no double-report with ANALYZE-ENRL-001). dist regenerated via combine.js. - Web: session_timeout treated as terminal for stale-status refetch (the sweep sends no SignalR delta). Tests: +3 RuleEngine pure-type precondition, SessionTimeoutRuleTests (real shipped rule fire/suppress), MaintenanceServiceSessionTimeoutEventTests (shape/sequence). Backend 2168 pass, web 434 pass, MCP 177 pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Oliver Kieselbach
|
dff5ba65f4 |
fix(rules): sunset = delete, with cross-tenant orphan RuleState GC
Session 080edee9 follow-up — the customer screenshots showed ANALYZE-CORR-001
("Slow Network") and ANALYZE-APP-009 ("App Download Stalled") still firing
on a clean re-analyze, despite my previous fix shipping them as
enabled:false in the JSON. Investigation via direct DB query:
- AnalyzeRules/global rows for both: Enabled=false ✓ (version-bump landed)
- RuleStates/{tenant} rows for both: Enabled=true ✗ (orphan overrides
from the user toggling them in the portal UI on 2026-03-09)
[AnalyzeRuleService.cs:60](src/Backend/AutopilotMonitor.Functions/Services/AnalyzeRuleService.cs#L60)
overlays per-tenant RuleState on top of the global Enabled, so the orphans
kept resurrecting the rules. No reseed path was cleaning them up.
The right semantic is "sunset = remove from catalog", not "ship as
enabled:false and hope nobody overrides". Three coordinated changes:
1. Both sunset rules deleted from the rules/analyze/ source tree (they
never had a working condition shape — CORR-001 didn't actually check
download speeds, APP-009 matched the V2 termination handler's
post-mortem-synthetic download_progress:failed event).
2. New IRuleRepository.DeleteRuleStatesForRuleIdAcrossTenantsAsync
cross-partition cleanup primitive — scans RuleStates by RowKey, deletes
matching rows across every tenant partition.
3. Both reseed paths now do orphan-state GC:
- AnalyzeRuleService.EnsureBuiltInRulesSeededAsync (on-startup):
detects rules that exist in DB as built-in but aren't in
BuiltInAnalyzeRules.GetAll() anymore → deletes the global row +
fans out the per-tenant RuleState GC.
- AnalyzeRuleService.ReseedBuiltInRulesAsync (delete+reimport): same
diff-based detection on the pre-delete snapshot.
- ReseedFromGitHubFunction.ReseedAnalyzeAsync (admin "Reseed from
GitHub" button — the path the user actually clicks): mirrored
identical logic so every reseed flavor leaves the same DB invariant.
4. ReseedBuiltInRulesAsync return shape extended to
(deleted, written, orphanStatesGcd) so the admin UI can surface the
cleanup count to operators.
Coverage:
- RuleEngineDetectionFailureTests: the two version-bump assertions for
CORR-001/APP-009 are replaced with `DoesNotContain` against the
built-in catalog (sunset semantic).
- AnalyzeRuleServiceSunsetTests (new, 3 tests): pins EnsureSeed orphan-GC
invariant, asserts live-rule states are NOT touched, and pins the
ReseedBuiltIn (deleted, written, orphanStatesGcd) tuple shape.
After deploy + a single GetAllRulesForTenantAsync call (any analyze run
triggers it), the orphan RuleStates for sunset rules are automatically
cleaned. The user's tenant 5ca2b350-… will see CORR-001 + APP-009
disappear from the Rules UI on the next analyze cycle.
Backend 2073/2073.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Oliver Kieselbach
|
8e26eb15e6 |
fix(rules): make detection-failure result actionable for end users
Session 080edee9 follow-up — the analyze cards the user saw on re-analysis
were neither accurate (Slow Network / App Download Stalled both fired as
false positives) nor specific (Enrollment Failed never named the offending
app; ANALYZE-APP-013 never fired). Five coordinated changes, all
version-bumped so EnsureBuiltInRulesSeededAsync re-imports them on the next
backend boot — the title/severity/version-check filter does not pick up
condition-only diffs:
ANALYZE-APP-013 v1.1.0 — fire on legacy + new agent shape:
Previous rule keyed on `failureType == esp_apps_detection_failure`,
which is only emitted by agents that shipped AFTER
|
||
|
Oliver Kieselbach
|
6007b9ecc5 |
fix(rules,web): pin rule template interpolation to the required-condition event
Codex review (P2): ANALYZE-APP-013's `failed_app_name` + `detection_hresult`
optional conditions scanned all app_install_failed events independently of
the required condition. In a session with multiple app failures the
template could interpolate {{appName}} / {{errorCode}} from a different
event than the one that matched `failureType == esp_apps_detection_failure`.
Two coordinated changes:
1. `interpolateRuleTemplate` gains an "auto-field" resolution tier between
the explicit byField path and the bySignal fallback. The backend's
`RuleEngine.AddDataFieldsToEvidence` already injects a whitelist of
identifying fields (appId, appName, errorPatternId, errorCode, exitCode,
status) onto every matched-condition evidence dict — the interpolator
now reads those, pinning to the FIRST matched condition (= the required
condition) so a rule with a single required match resolves all four
tokens against the same source event.
2. ANALYZE-APP-013 is trimmed to a single required condition; the redundant
optional conditions for appName / errorCode are removed because the
auto-field tier already exposes them from the required match. Same
pattern applied to ANALYZE-ENRL-001's `failed_app` condition.
Coverage: 4 new vitest cases (multi-failure correct interpolation, first-
condition-wins shadowing, explicit-field precedence, internal-field leakage
guard). 413/413 web tests.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Oliver Kieselbach
|
db7ca6ed87 |
fix(rules): surface detection-failure root cause in analyze pipeline
Session 080edee9 fired only ANALYZE-ENRL-001 ("Enrollment Failed") with a
generic explanation, even though we already had all the data to point at
the specific failed app (Microsoft Apps for Enterprise) and the specific
HRESULT (0x87D1041C - Intune detection rule mismatch). Three coordinated
rule changes close that enrichment gap:
ANALYZE-APP-001 (Win32 App Detection Script Failure):
Switch from a regex on the `message` field (which never matched the
agent's "Install status unconfirmed - ESP timed out" wording) to a
direct check on `dataField: detectionResult, operator: equals,
value: NotDetected`. The rule engine already supports nested DataJson
fields on `event_type` conditions, so this is the right shape and the
rule now fires whenever the IME reported a detection-rule mismatch.
ANALYZE-APP-013 (App Detection Failure During ESP - 0x87D1041C, new):
Matches the canonical `failureType: esp_apps_detection_failure` tag
emitted by the V2 agent's new classifier. Severity=critical, baseConf=90.
Pulls failed appName + HRESULT into the explanation via the existing
`{{token}}` interpolator, and ships a three-step remediation plan:
(1) validate the detection rule against an installed reference device,
(2) investigate post-install async tasks (the install may complete only
after ESP's detection probe runs), (3) cross-check the per-app event's
detectionResult + bytesDownloaded + hresultFromWin32.
ANALYZE-ENRL-001 (Enrollment Failed):
Add optional conditions that capture {reason, failedSubcategory, errorCode,
failedApp.appName} into MatchedConditions so the explanation can resolve
`{{reason}}` / `{{failedSubcategory}}` / `{{errorCode}}` / `{{appName}}`
via the existing `interpolateRuleTemplate` engine. Remediation text now
cross-references ANALYZE-APP-* rules for the actionable root cause.
dist regenerated via `node rules/scripts/combine.js` (25 -> 26 rules).
Backend embeds dist/analyze-rules.json as a resource; next deploy picks up
the new content automatically.
Coverage: 2058/2058 backend tests pass.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|