sync: auto-sync from HOWARD-HOME at 2026-05-31 13:37:41

Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-05-31 13:37:41

session-logs/2026-05-31-howard-gururmm-roadmap-and-features.md

@@ -93,3 +93,39 @@ Production build server (172.16.3.30): dashboard rebuilt + rsynced twice (v0.2.3
 - **Roadmap:** `projects/msp-tools/guru-rmm/docs/FEATURE_ROADMAP.md` (2055 lines), `docs/UI_GAPS.md`.
 - **Dashboard versions deployed:** v0.2.30 (ErrorBoundary), v0.2.32 (mappings + impersonation). Live bundle index-Di8C-nbq.js.
 - **BUG-013 agent code:** `agent/src/metrics/mod.rs:541-554` (WTSGetActiveConsoleSessionId + WTSQuerySessionInformationW) — SPEC-021 extends this.
+
+---
+
+## Update: 20:37 PT — SPEC-022 Windows Update management + Phase 1 shape-spec
+
+### Session Summary
+
+Howard requested a feature: GuruRMM control of Windows Update on managed devices (block/allow/delay/remove, like Syncro), with a policy toggle, monitoring of offered updates and their known issues, and eventual Apple support (Windows first). Held a design discussion covering the two control mechanisms (WUA COM API for per-update actions incl. IsHidden to block a KB; WUfB registry policy for deferral/pin/active-hours), how other RMMs do it (approval + rings + the auto-approve-after-N-days "delay insurance" + the fact that Windows doesn't natively tell you a patch is bad), and the Apple reality (real OS-update control needs MDM/DDM, ties to SPEC-017).
+
+After Howard answered the shaping questions (full loop; best-MSP approach; an ACG-controlled known-issues DB plus pulling official MS reports; both site-policy and per-device override; meet/exceed competitors without taxing devices), ran two parallel general-purpose research agents (web) to ground the design: (1) official programmatic sources for update intelligence, (2) RMM best practices + authoritative WUfB keys + WUA scan efficiency. Findings: the MS Graph Windows Updates API (beta) exposes knownIssue->KB with app-only auth (the authoritative "bad patch" spine); MSRC CVRF API (anonymous) maps CVE<->KB<->severity; CISA KEV + FIRST EPSS give exploitation urgency; AskWoody/blogs are license-locked (manual only); Update Catalog has no API (scrape via MSCatalogLTS or WSUS server-sync); and our own fleet install-failure telemetry is the proprietary signal no competitor can license. Efficiency answer: offline wsusscn2.cab daily compliance scan (cached, jittered, event-driven) + online only on demand.
+
+Synthesized all of it into SPEC-022 (Windows Update Management & Patch Intelligence) — dual engine, full loop, site+device policy, best-in-class approval model (deterministic precedence reject-wins + rings with auto-promote/auto-halt + CVE-risk prioritization), the patch-intelligence subsystem, conflict detection (WSUS/Intune/GPO), a meet-or-exceed comparison table, phasing (MVP->full), and a cited reference list. Marked it P1 on the roadmap and folded the old "Windows Update status"/"Patch management integration" lines into it.
+
+On "continue", shaped SPEC-022 Phase 1 (monitor + manual control MVP) into a structured spec folder via /shape-spec: specs/windows-update-mvp/ with shape.md, plan.md (Task 0 commit + Tasks 1-8 with file refs + verification), references.md (Discovery subsystem as the structural analog + real file:line anchors), standards.md. Committed (Task 0 done).
+
+### Key Decisions
+- Researched before writing the spec (2 parallel web-research agents) rather than hand-waving the known-issues sourcing — it was the explicit hard part.
+- Modeled the MVP on the existing Discovery subsystem (scan command -> result message -> DB table -> dashboard tab) — closest proven analog; reuse end to end.
+- WU policy fields ride in the existing PolicyData JSONB (no parallel policy system); site/device resolution reuses the effective-policy merge.
+- Agent WUA access via the SPEC-014 PowerShell-relay pattern for Phase 1 (native Rust COM deferred); Windows-only with explicit Linux/macOS no-ops (platform-parity).
+- Phase 1 deliberately excludes auto-install/reboot, patch intelligence, rings, and macOS — lowest-risk slice that is still more than "Windows Update status".
+
+### Configuration Changes
+- Created: docs/specs/SPEC-022-windows-update-management.md
+- Created: specs/windows-update-mvp/{shape,plan,references,standards}.md
+- Modified: docs/FEATURE_ROADMAP.md (SPEC-022 P1 entry; folded old Software Management lines)
+
+### Pending / Incomplete Tasks
+- SPEC-022 build: start at Phase 1 Task 1 (DB migration + PolicyData windows_update section) — server-only, unblocks downstream. Full task list in specs/windows-update-mvp/plan.md.
+- All prior-session pending items still stand (BUG-009/011 tails undeployed; #3 Client row + #4 dead-endpoint removal deferred behind build-server.sh risk; BUG-015; SPEC-021 build; judgment-call roadmap markings).
+
+### Reference Information
+- gururmm commits: SPEC-021 932c701; SPEC-022 b5562c3; windows-update-mvp shape-spec 6f31d22.
+- claudetools parent tips: 1ff8a72, c5ce1a4, be938bd.
+- Key data sources (SPEC-022 §17): MS Graph windowsUpdates knownIssue (beta), api.msrc.microsoft.com/cvrf/{yyyy-mmm} + /update-guide/rss, CISA KEV, FIRST EPSS, MSCatalogLTS.
+- Spec folder to resume Phase 1: specs/windows-update-mvp/ (read all four files = full context).