---
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
