Phase 1: Cluster-Fundament – Nachrichten, Registry, Paarung, Discovery

- hms_cluster: ClusterMessage (§6.5: Pflichtfelder, Sequenzen, Revisionen,
  execute_at, Trace-ID), CommandTracker (idempotent, vorwärts-only:
  accepted->armed->executed/failed)
- NodeRegistry: online/degraded/stale/offline über Schwellen, UI-Kategorien
  discovered/paired/unknown/incompatible/offline, Doppel-Node-ID blockiert,
  IP-Wechsel erhaelt node_id (§6.3, §6.5)
- Pairing: PIN (TTL 120s, Versuchslimit), Fingerprint (SHA-256 gruppiert),
  Token nur als Hash, Scopes read/control/content_sync/admin, Ablauf +
  sofortiger Widerruf (§6.3, §27.1, ADR-0010)
- Discovery-Modell: _hmsmedia._tcp.local. TXT ohne Secrets, Capability-
  Digest, persistente manuelle Fallback-Liste (ADR-0009)
- ADR-0009 (mDNS + Fallback) und ADR-0010 (Paarung) dokumentiert
- 25 Unit-Tests; Gesamtsuite 183 Tests gruen, Ruff gruen

STATUS.md

@@ -43,19 +43,32 @@ Phase 1 (im Bau):
       vollständiger Snapshot nach Verbindung, Deltas mit monotoner Revision,
       Command-Acks idempotent über message_id, Heartbeat 500 ms in beide
       Richtungen, Re-Sync nach Reconnect, ausschließlich Loopback (§6.2)
-- [ ] SQLite-Persistenz (WAL, Migrationen, Backup, §24)
-- [ ] Launcher/Supervisor (Prozessstart, Heartbeat-Überwachung, kontrolliertes
-      Beenden, Crash-Erkennung)
-- [ ] Persistente Node-Identität + Rollen in der App-Verkabelung
-- [ ] mDNS/DNS-SD-Discovery + manuelle Node-Liste (§6.3)
-- [ ] Paarung (PIN/Fingerprint) und Node-Vertrauen
-- [ ] Cluster-Nachrichtenhülle mit Sequenzen/Revisionen (§6.5)
+- [x] SQLite-Persistenz (WAL, Migrationen mit Backup, Integritätscheck,
+      Projekt-/Einstellungs-/Plugin-Status-CRUD, §24)
+- [x] Launcher/Supervisor: echte Kindprozesse, portable Umgebung, freie
+      Portwahl, kontrolliertes Beenden (terminate→kill) mit Recovery-
+      Markierung, Restart-Policy mit Crashloop-Erkennung (§6.1A, §26.2, §26.4)
+- [x] Cluster-Nachrichtenhülle: Pflichtfelder, Sequenzen, Revisionen,
+      Trace-ID, Idempotenz-Tracker mit vorwärts-only-Statuskette (§6.5)
+- [x] Node-Registry: online/degraded/stale/offline über Schwellen,
+      UI-Kategorien discovered/paired/unknown/incompatible/offline,
+      Doppel-Node-ID-Fehler, IP-Wechsel erhält node_id (§6.3, §6.5)
+- [x] Paarung: kurzlebige PIN (TTL 120 s, Versuchslimit), sichtbarer
+      Fingerprint, Token nur als Hash mit Scopes read/control/content_sync/
+      admin, Ablauf und sofortiger Widerruf (§6.3, §27.1, ADR-0010)
+- [x] Discovery-Modell: mDNS-Service _hmsmedia._tcp.local. mit TXT ohne
+      Secrets, Capability-Digest, persistente manuelle Fallback-Liste
+      (ADR-0009)
+- [ ] Node-Identität + Rollen in die App-Verkabelung (Control Core lädt
+      node_id aus identity/, startet Discovery-Service auf Zielsystemen)
+- [ ] mDNS-Echtnetz-Betrieb mit zeroconf auf Zielsystemen (Modell fertig;
+      Multicast-Test gehört zu Gate 1, ADR-0009)
 
 ## Nächste drei Aufgaben
 
-1. SQLite-Persistenz mit WAL, transaktionalem Autosave und Migrationstests (§24)
-2. Launcher/Supervisor mit Heartbeat-Überwachung und kontrolliertem Beenden (§6.1A)
-3. Discovery (mDNS) plus manuelle Fallback-Liste und Paarungsgrundlage (§6.3)
+1. Node-Identität + Rollen in der App-Verkabelung (Control Core Startup)
+2. mDNS-Echtnetz mit zeroconf auf Zielsystemen + Gate-1-LAN-Test vorbereiten
+3. Phase-2-Beginn vorbereiten: Master-Canvas/Layer-Modell im Domain-Paket
 
 ## Ausstehende Hardware-Validierung (ADR-0008 Testplan)