docs: Hinweis auf Nachfolger mscadm/groundcontrol (ITSM lebt dort als Modul Service Desk weiter, ADR-010)

README.md

@@ -1,3 +1,7 @@
+> **Dieses Repo ist Historie.** Groundcontrol (`mscadm/groundcontrol`) hat den
+> Code seit 2026-07-28 uebernommen; das ITSM lebt dort als Modul *Service Desk*
+> weiter (siehe ADR-010). Neue Arbeit bitte im Groundcontrol-Repo.
+
 # ITSM
 
 ITSM-Plattform (Service-Katalog, Tickets, Wissensdatenbank, CMDB) -- AES ist ein

docs/adr/ADR-009-konzernplattform-modul-monolith.md

@@ -1,6 +1,6 @@
 # ADR-009: Konzernplattform als Modul-Monolith
 
-**Datum:** 2026-07-15 · **Status:** Akzeptiert · **Vorgabe:** "Wir machen aus dem ITSM eine Konzernplattform inkl. HR, CRM, usw."
+**Datum:** 2026-07-15 · **Status:** ERSETZT durch ADR-010 (2026-07-28) — Modul-Monolith bleibt gueltig, aber die Plattform (Groundcontrol) ist der Kern, nicht das ITSM · **Vorgabe:** "Wir machen aus dem ITSM eine Konzernplattform inkl. HR, CRM, usw."
 
 ## Kontext
 Das ITSM soll zur Unternehmensplattform mit Fachmodulen (HR, CRM, weitere)

docs/adr/ADR-010-groundcontrol-plattformschnitt.md

@@ -0,0 +1,41 @@
+# ADR-010: Groundcontrol — Plattform als Kern, ITSM als Modul
+
+**Datum:** 2026-07-28 · **Status:** Akzeptiert (ersetzt ADR-009)
+**Vorgabe:** "Wir brauchen einen besseren Projektnamen für die Plattform und ITSM darf nicht der Kern sein, eher ein Bestandteil (von Anfang an)."
+
+## Kontext
+ADR-009 hatte HR/CRM als Module in die bestehende ITSM-Anwendung gehängt: das
+ITSM blieb Namens- und Codekern (Repo `mscadm/ITSM`, Binary `itsm`, Routen
+ohne Modul-Präfix, Rollen in `itil.rs`). Mit weiteren Domänen — insbesondere
+der Systemverwaltung (Groundwork-OS, Linux, Windows) — wird diese Schieflage
+strukturell falsch: Fleet ist kein „ITSM-Feature".
+
+## Entscheidung
+**Name: GROUNDCONTROL** (Fortsetzung der Hausmarke Leerlauf.works /
+Groundwork-OS / PureIdle: Fundament legen → von hier steuern).
+
+Neues Repo `mscadm/groundcontrol`; `mscadm/ITSM` wird nach der Migration
+archiviert. Codeschnitt trennt Kern und Module strikt:
+
+    src/platform/   Mandanten, Auth/Sessions, RBAC, Audit, Retention,
+                    UI-Shell, Konfiguration, DB-Pool   (modulagnostisch)
+    src/modules/servicedesk/   ITIL v3/v4 (vormals „das ITSM")
+    src/modules/people/        HR
+    src/modules/sales/         CRM
+    src/modules/fleet/         Systemverwaltung (siehe ADR-011)
+    src/modules/aes/           AES-Suite-Erweiterung
+
+Module sind gleichrangig: eigener Routen-Präfix, eigene Tabellen-Präfixe
+(`sd_`, `hr_`, `crm_`, `fleet_`), eigene Rolle(n), eigene Nav-Gruppe, eigene
+Doku. Der Kern kennt kein Modul namentlich außer in der Registrierung.
+
+Bestandsdaten bleiben: bestehende Tabellen (tickets, kb_articles, …) werden
+NICHT umbenannt (Datenrisiko ohne Nutzen); der Präfix gilt für neue Tabellen.
+
+## Konsequenzen
++ Fleet und künftige Domänen sind erstklassig statt „angebaut".
++ Kern bleibt schlank und wiederverwendbar; Module sind einzeln testbar.
++ Marke passt zur Produktfamilie; „ITSM" wird zum Modulnamen *Service Desk*.
+− Einmaliger Migrationsaufwand (Repo, Pfade, URLs, Doku, Deployment).
+− Ein-Rollen-Modell wird durch Fleet endgültig zu eng → Modul-Grants sind
+  als groundcontrol phase-003 eingeplant.

docs/adr/ADR-011-fleet-agent-und-ssh.md

@@ -0,0 +1,46 @@
+# ADR-011: Fleet-Anbindung — Pull-Agent mit SSH-Fallback
+
+**Datum:** 2026-07-28 · **Status:** Akzeptiert
+**Vorgabe:** "Systemverwaltung aller Groundwork-OS Systeme, aber auch Windows und Linux System via Agent" (Anbindung: Agent + SSH-Fallback)
+
+## Kontext
+Zu verwaltende Systeme: Groundwork-OS-Instanzen, Linux-Server, Windows-
+Clients/Server. Sie stehen teils hinter NAT/Firewalls, teils ohne Möglichkeit
+zur Softwareinstallation. Reine Push-Steuerung (Server → Host) verlangt
+erreichbare Ports und hinterlegte Zugangsdaten für jedes System.
+
+## Entscheidung
+**Primär: Pull-Agent.** Der Agent wird mit einem mandantengebundenen
+Enrollment-Token einmalig registriert und erhält ein eigenes Host-Token
+(in der DB nur als SHA-256-Hash — gleiches Prinzip wie Sessions, ADR-002).
+Danach ausschließlich ausgehende HTTPS-Verbindungen:
+
+    POST /api/fleet/enroll     einmalig, mit Enrollment-Token
+    POST /api/fleet/heartbeat  zyklisch: Status + Inventar, Antwort = offene Jobs
+    POST /api/fleet/jobs/:id/result   Ergebnis (exit code, stdout/stderr gekürzt)
+
+Kein offener Port auf dem verwalteten System, NAT-tauglich, Token pro Host
+einzeln widerrufbar (Host sperren ⇒ Agent verliert sofort Zugriff).
+
+**Sekundär: SSH/WinRM-Fallback** für agentenlose Hosts — als Host-Typ
+`ssh` gepflegt, ausgeführt vom Server aus. Zugangsdaten werden **nicht** in
+Groundcontrol gespeichert (kein Passwort-Tresor im Produkt); genutzt wird der
+SSH-Key des Servers. Reichweite bewusst kleiner als beim Agenten.
+
+**Job-Sicherheit:** Jobs sind Kommandos auf fremden Systemen — daher
+- nur Rolle `fleet_operator`/`admin` darf Jobs anlegen (Rolle `fleet_viewer`
+  sieht nur Inventar),
+- jeder Job wird im Audit-Log mit Kommando, Ziel und Auslöser protokolliert,
+- Jobs sind an einen Host gebunden und laufen genau einmal (Status
+  Offen → Zugestellt → Erledigt/Fehler),
+- Agent führt Jobs unter seiner eigenen Kennung aus; Rechteausweitung ist
+  Sache des Systems, nicht der Plattform.
+
+## Konsequenzen
++ Funktioniert über NAT/Firewall hinweg, ohne eingehende Ports.
++ Host-Token einzeln widerrufbar; Kompromittierung bleibt lokal begrenzt.
++ Ein Agent-Binary für Linux und Windows (Rust, statisch gelinkt).
+− Latenz durch Polling (Heartbeat-Intervall statt Echtzeit) — für
+  Verwaltungsaufgaben akzeptabel; WebSocket wäre eine spätere Option.
+− SSH-Fallback ist bewusst eingeschränkt (Server-Key statt Credential-Store);
+  ein Passwort-Tresor wäre ein eigener ADR mit deutlich höherem Schutzbedarf.

docs/adr/README.md

@@ -14,3 +14,6 @@ neue, ersetzende ADRs (nie stillschweigend editieren).
 | 006 | Multi-Stage-Docker-Build statt Clone-on-Start | 2026-07-15 |
 | 007 | CSP ohne Inline-JavaScript | 2026-07-15 |
 | 008 | SSRF-Policy für Service-Endpoints | 2026-07-15 |
+| 009 | Konzernplattform als Modul-Monolith (ersetzt durch 010) | 2026-07-15 |
+| 010 | Groundcontrol — Plattform als Kern, ITSM als Modul | 2026-07-28 |
+| 011 | Fleet-Anbindung — Pull-Agent mit SSH-Fallback | 2026-07-28 |