docs: portal confirmation for new devices in auto mode without an enrollment session (ADR-0008)

The previous Auto-Modus-Gate rule unconditionally forced new devices
into the interactive flow because no better mechanism was known yet.
Enrollment Sessions (11-device-enrollment.md) already solve planned
bulk rollouts, but not a single, spontaneously booted new device.

New devices in auto mode now go on hold after the identification
handshake and wait for a customer to confirm registration and assign
a workspace via the future management UI, reusing the same
fail-closed poll mechanism already planned for the interactive flow's
kiosk communication (ADR-0007). Devices covered by an active
Enrollment Session are unaffected and remain fully unattended.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

adr/0008-neugeraete-auto-modus-portal-bestaetigung.md

@@ -0,0 +1,39 @@
+# ADR-0008: Portal-Bestätigung für Neugeräte im Auto-Modus ohne Enrollment Session
+
+**Status:** Beschlossen
+**Datum:** 23.07.2026
+
+## Kontext
+
+`13-live-provisioning-boot.md` (Abschnitt "Auto-Modus-Gate") legte bisher fest, dass ein unbekanntes Gerät (`registration_status == "registered"`) niemals den automatisierten Ablauf durchläuft, unabhängig vom gewählten Bootmenüeintrag — die Geräteaufnahme blieb ausnahmslos an eine lokale, interaktive Bestätigung gebunden. Diese Formulierung war der Situation geschuldet, dass zum Zeitpunkt der ursprünglichen Entscheidung noch keine bessere Umsetzung für eine unbeaufsichtigte Neugeräte-Provisionierung im Auto-Modus vorlag.
+
+`11-device-enrollment.md` beschreibt daneben bereits **Enrollment Sessions**: zeitlich begrenzte, organisationsgebundene Vorab-Freigaben für geplante Massenrollouts (maximale Geräteanzahl, erlaubte Bereitstellungsvorlagen, widerrufbar, auditierbar). Diese lösen den Fall eines *geplanten* Rollouts, aber nicht den Fall eines *einzelnen, spontan gebooteten* Neugeräts ohne vorab eingerichtete Session — genau diese Lücke schließt die vorliegende Entscheidung.
+
+## Entscheidung
+
+Ein neues Gerät (`registration_status == "registered"`), das im Auto-Modus bootet und **nicht** durch eine aktive Enrollment Session abgedeckt ist, wird nicht mehr zwingend in den interaktiven Ablauf gezwungen. Stattdessen:
+
+1. Das Gerät durchläuft den üblichen Identifikations-Handshake (Geräte-ID wird dem Provisioning Server bekanntgegeben).
+2. Es geht anschließend in einen **Wartezustand ("on hold")** über — die destruktive Installation beginnt nicht.
+3. Ein Kunde bestätigt über die künftige Verwaltungsoberfläche die Registrierung des Geräts und weist ihm einen Workspace zu.
+4. Erst nach dieser serverseitig vermerkten, zentralen Bestätigung überschreitet der Orchestrator den Commit Point.
+
+Damit ergeben sich für neue Geräte im Auto-Modus zwei Freigabewege, die sich nicht überschneiden, sondern ergänzen:
+
+- **Mit abdeckender Enrollment Session:** vollständig unbeaufsichtigt, wie ursprünglich für Massenrollouts vorgesehen — die Vorab-Freigabe der Session deckt die Autorisierung ab.
+- **Ohne abdeckende Enrollment Session:** Einzel-Bestätigung über das Portal, wie oben beschrieben — für den spontanen, ungeplanten Fall.
+
+Die beiden Bootmodi bleiben dadurch klar unterscheidbar:
+
+- **auto:** bei Neugeräten ist stets eine zentrale Bestätigung/Festlegung notwendig — vorab durch eine Enrollment Session, oder nachträglich durch eine Portal-Bestätigung.
+- **interaktiv:** der Benutzer bestätigt und konfiguriert lokal am Gerät, ohne dass parallel eine zentrale Aktion nötig wäre.
+
+Für bereits bekannte Geräte (`registration_status == "existing"`) ändert sich nichts — die automatisierte Reprovisionierung ohne erneute Bestätigung bleibt wie in `11-device-enrollment.md` beschrieben.
+
+## Konsequenzen
+
+- Der Auto-Modus für Neugeräte ohne Enrollment Session ist ohne ein funktionierendes Verwaltungsportal (Registrierung + Workspace-Zuweisung) nicht nutzbar. Für den aktuellen Piloten irrelevant — dort kommt der interaktive Modus zum Einsatz (siehe Pilot-Roadmap).
+- Technisch lässt sich der Wartezustand mit demselben Fail-Closed-Baustein umsetzen, der für den interaktiven Ablauf bereits vorgesehen ist: `25_installation_confirm.sh` pollt im Auto-Modus den Server auf einen expliziten Freigabe-Zustand, statt eine TTY-Eingabe zu lesen — dieselbe Grundmechanik wie in ADR-0007 für die Kiosk-Kommunikation festgelegt.
+- Kein statisches Geheimnis auf dem Medium (Aktivierungscode o.ä.) autorisiert je allein eine destruktive Aktion — konsistent mit der in `11-device-enrollment.md` ohnehin schon vorgesehenen schrittweisen Ablösung des Aktivierungscodes.
+- Offen, nicht Teil dieser Entscheidung: das genaue Zusammenspiel zwischen Enrollment Session und Workspace-Zuweisung — ob eine Session mit genau einer erlaubten Bereitstellungsvorlage die Workspace-Wahl implizit vorwegnimmt, oder ob auch dort noch ein einzelner Bestätigungsschritt nötig ist.
+- `13-live-provisioning-boot.md` (Auto-Modus-Gate) und `11-device-enrollment.md` werden entsprechend angepasst.

architecture/11-device-enrollment.md

@@ -118,7 +118,7 @@ Für ein bereits registriertes, über seinen Hardware-Fingerprint wiedererkannte
 
 Mit der Registrierung eines Geräts wird akzeptiert, dass es künftig auf diesem Weg ohne erneute interaktive Bestätigung neu installiert werden kann, solange es als bereits registriert erkannt wird.
 
-Diese Eigenschaft gilt ausschließlich für bereits registrierte Geräte. Die Aufnahme eines unbekannten Geräts bleibt in jedem Fall an eine explizite, interaktive Bestätigung gebunden (siehe Sicherheitsprinzip unten).
+Diese Eigenschaft gilt ausschließlich für bereits registrierte Geräte. Die Aufnahme eines unbekannten Geräts bleibt in jedem Fall an eine explizite Bestätigung gebunden (siehe Sicherheitsprinzip unten) — lokal-interaktiv am Gerät, oder, im Auto-Modus ohne abdeckende Enrollment Session, zentral über die künftige Verwaltungsoberfläche (siehe ADR-0008 und `13-live-provisioning-boot.md`, Abschnitt „Auto-Modus-Gate").
 
 ## Enrollment Sessions
 

architecture/13-live-provisioning-boot.md

@@ -61,15 +61,18 @@ Beide Moduspfade laufen ab „Runtime Blueprint erzeugen" identisch weiter. Der
 
 ## Auto-Modus-Gate
 
-Der automatisierte Ablauf ersetzt keine Sicherheitsprüfung, sondern ersetzt nur, wer die Bestätigung gibt: statt einer Benutzereingabe entscheidet ein bereits bestehender, geprüfter Zustand.
+Der automatisierte Ablauf ersetzt keine Sicherheitsprüfung, sondern ersetzt nur, wer/wann die Bestätigung gibt: statt einer lokalen Benutzereingabe entscheidet ein bereits bestehender, geprüfter Zustand — eine Vorab-Freigabe, eine zentrale Freigabe, oder ein bereits bekannter Registrierungszustand.
 
-Voraussetzung für den automatisierten Ablauf ist ausschließlich:
+Für ein bereits bekanntes Gerät (`device.registration_status == "existing"` in der Antwort von `POST /api/v1/activate`) läuft der automatisierte Ablauf wie bisher ohne weitere Bestätigung durch.
 
-`device.registration_status == "existing"` in der Antwort von `POST /api/v1/activate`.
+Für ein neues Gerät (`registration_status == "registered"`) hängt der weitere Ablauf davon ab, ob eine aktive Enrollment Session (siehe `11-device-enrollment.md`) es abdeckt:
 
-Ein unbekanntes Gerät (`registration_status == "registered"`) durchläuft niemals den automatisierten Ablauf, unabhängig vom gewählten Bootmenüeintrag. Die Geräteaufnahme bleibt gemäß `11-device-enrollment.md` an eine explizite, interaktive Bestätigung gebunden.
+- **Mit abdeckender Enrollment Session:** automatisierter Ablauf wie vorgesehen — die Vorab-Freigabe der Session genügt, kein weiterer Bestätigungsschritt nötig.
+- **Ohne abdeckende Enrollment Session (ADR-0008, 23.07.2026):** das Gerät geht nach dem Identifikations-Handshake in einen Wartezustand über. Die destruktive Installation beginnt erst, nachdem ein Kunde über die künftige Verwaltungsoberfläche die Registrierung bestätigt und einen Workspace zugewiesen hat.
 
-Das Fail-Closed-Prinzip aus `10-interactive-provisioning-flow.md` gilt unverändert: Fehlt eine gültige Grundlage für die automatische Bestätigung (zum Beispiel eine unerwartete oder unlesbare Serverantwort), bricht der Ablauf ab, statt ersatzweise eine Bestätigung anzunehmen.
+Ein unbekanntes Gerät ohne abdeckende Enrollment Session durchläuft damit weiterhin keine unbeaufsichtigte Installation ohne jede Bestätigung — nur die Quelle der Bestätigung ist im Auto-Modus jetzt zentral (Portal) statt lokal (Kiosk-Browser).
+
+Das Fail-Closed-Prinzip aus `10-interactive-provisioning-flow.md` gilt unverändert: Fehlt eine gültige Grundlage für die automatische Bestätigung (zum Beispiel eine unerwartete oder unlesbare Serverantwort, oder ein Wartezustand, der nie in eine Freigabe übergeht), bricht der Ablauf ab beziehungsweise verharrt im Wartezustand, statt ersatzweise eine Bestätigung anzunehmen.
 
 ---