lorentz/wulf-pulse
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions
wulf-pulse/.planning/seeds/SEED-001-wulf-standards-engine.md

6.9 KiB
Raw Permalink Blame History

id status planted planted_during trigger_when scope
SEED-001 dormant 2026-05-07 v1.0 milestone (Pulse Mobile Shell Redesign), Phase 8 in flight After Pulse Mobile Shell Redesign milestone (v1.0) closes — surface during the next /gsd-new-milestone scan 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