From b3ad92cd868ec91104558eb22ff188e4d2d11f46 Mon Sep 17 00:00:00 2001 From: lorentz Date: Thu, 7 May 2026 21:10:24 -0400 Subject: [PATCH] =?UTF-8?q?docs:=20plant=20seed=20=E2=80=94=20Wulf=20Stand?= =?UTF-8?q?ards=20Alignment=20Engine?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../seeds/SEED-001-wulf-standards-engine.md | 132 ++++++++++++++++++ 1 file changed, 132 insertions(+) create mode 100644 .planning/seeds/SEED-001-wulf-standards-engine.md diff --git a/.planning/seeds/SEED-001-wulf-standards-engine.md b/.planning/seeds/SEED-001-wulf-standards-engine.md new file mode 100644 index 0000000..74b0b5e --- /dev/null +++ b/.planning/seeds/SEED-001-wulf-standards-engine.md @@ -0,0 +1,132 @@ +--- +id: SEED-001 +status: dormant +planted: 2026-05-07 +planted_during: v1.0 milestone (Pulse Mobile Shell Redesign), Phase 8 in flight +trigger_when: After Pulse Mobile Shell Redesign milestone (v1.0) closes — surface during the next /gsd-new-milestone scan +scope: Large +--- + +# SEED-001: Wulf Standards Alignment Engine + +A declarative compliance + drift detection + remediation platform spanning client +**endpoints**, **networks**, and **organizations**. Standards are authored as data +in a separate forgejo repo (`forgejo.wulfconsulting.cloud/wulf-standards`), reviewed +via PR, pulled into Pulse at runtime, and applied through three execution kernels +(Overshell for endpoints; SSH/SNMP/vendor APIs for networks; IT Glue/M365/Autotask +APIs for organizations). Per-client overrides keyed off `companies.classification` +(Platinum/Gold/etc.) and explicit deviations. + +## Why This Matters + +Wulf has dozens of "standardize this thing across all our clients" needs that are +currently handled as one-off tickets, tribal knowledge, or runbook docs in IT Glue — +with no platform to **define**, **apply**, **detect drift on**, and **remediate** +those standards consistently. Today the only execution surface in Pulse is RMM +Overshell, which is scoped to ad-hoc, read-only, pre-approved scripts. That's by +design and shouldn't change — but it leaves a gap for declarative, auditable, +client-tier-aware configuration management. + +The triggering moment was ticket T20260501.0127 (Hynes Industries — RDS session +wallpaper labeling). The fix is trivial; the realization is that Wulf needs this +exact pattern (BGInfo on all servers, RDP wallpaper labeling per host, Datto RMM +agent settings, S1 mitigation policies, IT Glue documentation completeness checks, +DC GPO baselines, etc.) at every client. Without a platform, every instance gets +re-solved manually and silently drifts. + +## When to Surface + +**Trigger:** After Pulse Mobile Shell Redesign milestone (v1.0) closes. + +This seed should be presented during `/gsd-new-milestone` when the milestone scope +matches any of these conditions: +- Next major milestone after v1.0 mobile shell ships +- Milestone scope mentions: "compliance", "standards", "drift", "configuration + management", "MSP standardization", "Datto RMM components", "IT Glue automation", + "BGInfo", or "endpoint baseline" +- Discussion of expanding Overshell beyond read-only inspection +- Discussion of network device management (switches, firewalls, APs) +- Discussion of cross-client tooling that lives outside individual ticket workflows + +## Scope Estimate + +**Large** — full milestone, likely 8–14 phases. This is a platform-level feature, not +a phase. It touches: a new external git-hosted standards repo, runtime fetch + +caching, three execution kernels (one existing, two new), per-client overrides, +audit/remediate orchestration, drift reporting UI, approval/review surface, +RBAC for who can apply remediation. Each of those is at minimum a phase; some +(network execution kernel, drift UI) could be a milestone of their own. + +## Breadcrumbs + +Existing code and decisions that the future milestone will build on or interact with: + +- `lib/services/rmm/scripts/index.ts` — Overshell script registry. Standards engine + will likely call into this for endpoint operations rather than reinvent. +- `lib/services/rmm/executor.ts`, `lib/services/rmm/worker.ts`, + `lib/services/rmm/target-resolver.ts` — execution model to study/extend. +- `lib/services/rmm/persistence.ts` + `rmm_executions` table — pattern for + audit-tracked endpoint operations; standards engine needs a parallel + `standards_evaluations` / `standards_remediations` model. +- `lib/services/rmm/loglift-receiver.ts` + B2 evidence storage pattern — model + for "Pulse pulls external resource at runtime + caches"; matches the + forgejo-hosted standards-as-data pattern. +- `companies.classification` column — primary key for tier-based overrides + (Platinum/Gold/etc.). +- `lib/services/itglue-search.ts` (redacted) — required path for any standard + that consumes IT Glue data destined for an LLM. +- `lib/services/postgres-client.ts` — `bulkUpsert()` pattern fits drift-snapshot + storage. +- `docs/rmm-overshell-evidence-spec.md` — evidence/audit conventions to mirror. +- IT Glue flexible asset types already in use at clients (`Applications`, + `Remote Access`, `Backup`, `LAN/VLAN`, `Email Security`, `Active Directory`, + `Wulf Services`) — natural homes for standards metadata or per-client overrides. +- Origin ticket: Autotask T20260501.0127 (Hynes Industries — RDS session + background change for Sage, MiSys, Misys SQL). + +## Notes + +### Initial scope candidates +First standards to author once the engine exists, in rough priority order: +1. **BGInfo on all Windows servers** — dynamic per-host identification (replaces + the per-host static wallpaper pattern entirely for most cases) +2. **RDP wallpaper labeling** — per-RDS-host static wallpaper for the cases + where BGInfo isn't enough (e.g., Hynes Sage/MiSys split) +3. **Datto RMM agent settings baseline** — privacy mode, web remote, audit + schedule, etc. +4. **SentinelOne mitigation policies** — per-tier expected configuration +5. **IT Glue documentation completeness** — every client must have + `Active Directory`, `Backup`, `Internet/WAN`, `Remote Access` flex assets +6. **DC GPO baselines** — wallpaper, screensaver lock, audit policy, etc. +7. **M365 conditional access policies per tier** + +### Key design forks (decide during brainstorming, not now) +- **Imperative scripts vs declarative standards** — current opinion: declarative, + with audit + remediate compiled from a single spec. +- **Standards repo location** — current opinion: separate forgejo repo (data), + not Pulse repo (code). Lets non-Pulse engineers PR standards. +- **Three execution kernels under one orchestration** — endpoint kernel exists + (Overshell). Network kernel (SSH/SNMP/Meraki/Fortinet/etc.) and Org kernel + (IT Glue/M365/Autotask APIs) are net-new. +- **Approval workflow** — forgejo PR review is the standards review mechanism; + Pulse adds a per-client approve-remediation step (don't auto-fix without an + operator click for tier-1 changes). +- **Idempotency** — every standard has `audit()` (returns desired vs actual) and + `remediate(diff)` (applies the diff). Both must be idempotent. + +### Sequencing +Realistic build order if/when this becomes a milestone: +1. Standards repo schema + Pulse-side fetcher/cacher (smallest viable loop) +2. Endpoint kernel via existing Overshell (reuse, don't rebuild) +3. Audit-only mode for first 3 standards (BGInfo, RDP wallpaper, RMM baseline) +4. Drift dashboard UI (read-only) +5. Remediate-with-approval flow +6. Network kernel +7. Org kernel +8. Self-service per-client override editor + +### Anti-goals +- Not replacing Datto RMM components or other vendor-native compliance tools +- Not becoming a generic IaC platform (no Terraform/Ansible parity) +- Not auto-remediating without operator approval for first release +- Not a UI for editing standards — those live in forgejo, edited in IDE/PR