fixing final SPDK deployment

docs/TODO.md

@@ -1126,3 +1126,20 @@ the wrapper, own the VA-API `--enable-features`:
 remains documented here if a minimal/auditable cmdline is ever wanted.
 **BENCH-VERIFY:** `chrome://policy` shows `ExtensionInstallBlocklist=["*"]` active;
 extensions can't install.
+
+## [ ] 14. (DESIGN) Centralised fleet management plane (health/version/usage/maintenance)
+
+**DESIGN CAPTURED 2026-06-28 — [docs/fleet-management-design.md](fleet-management-design.md).**
+Server-authoritative, pull-based, TPM-identified management plane reusing existing
+pieces: `fleet-hostapi` as the on-host data source, the audit-collector→Wazuh
+pipeline as telemetry transport, the digest-pinned deployment manifest as version
+truth, and the SPDK `spdk-loader`/`spdk-release` rolling-update flow (#6) as the
+redeploy/drain mechanics. Hosts stay stateless (identity from the TPM cert, no
+baked enrollment); control is pull/reconcile (no inbound surface); convergence to
+a new version = reboot. **Phased build:** (1) push hostapi snapshots as structured
+events into Wazuh + fleet dashboard (health/version-drift/offline/usage/alerting);
+(2) metrics push (OTLP/remote-write) → VictoriaMetrics + Grafana; (3) mTLS
+desired-state pull (version pin, reboot/drain, kiosk URL) wired to the deployment
+manifest + SPDK flow. Build-time decisions (telemetry encoding, metrics/desired-
+state store, per-host vs cohort, osquery/FleetDM eval) listed in the design note.
+Depends on the step-ca fleet CA (#8) for the mTLS identity.