docs: switch provisioning ISO to live medium with auto/interactive boot modes (ADR-0003)

Moves from a Fedora DVD/netinst base (GRUB boots straight into Anaconda
via a static inst.ks= URL, bypassing installer.sh entirely) to a real
live medium. installer.sh runs as an application inside the live
session; backend_launch() starts the native installer explicitly at
the end instead of a boot-time kickstart parameter.

The boot menu offers two entries: a default with a countdown that
leads to an unattended flow, and a manual entry for the branded
interactive flow. The unattended flow is gated on
device.registration_status == "existing" - unknown devices always
fail closed into the interactive enrollment path. Device registration
now documents that this is a condition of registering a device.

Also notes the tension with the installer roadmap's long-term
minimal-medium vision: distribution packages still aren't bundled and
are pulled per install, but the live environment itself makes the
medium larger, accepted for the UX it enables.

Details: architecture/13-live-provisioning-boot.md.

00-glossary.md

@@ -44,9 +44,25 @@ Beispiele:
 - VPN
 - Monitoring
 
+## Merkmal
+
+Eine einzelne fachliche Eigenschaft eines Workspace, distributionsunabhängig benannt.
+
+Beispiele:
+
+- browser-brave
+- office-onlyoffice
+- guest-session-ephemeral
+
+Ein Workspace besteht aus einer Menge von Merkmalen.
+
 ## Blueprint
 
-Die technische Beschreibung eines Workspace.
+Die technische Umsetzung genau eines Merkmals für genau ein Backend.
+
+Ein Blueprint ist im Regelfall eine Ansible-Rolle beziehungsweise -Aufgabe, die nach dem ersten Start über den bestehenden Ansible-Pull-Mechanismus angewendet wird.
+
+Details: `architecture/12-feature-blueprint-model.md`.
 
 ## Runtime Blueprint
 
@@ -54,9 +70,8 @@ Die zur Installationszeit erzeugte vollständige Zielbeschreibung.
 
 Sie entsteht aus:
 
-- Backend
+- den aufgelösten Blueprints der Merkmale des Workspace für das gewählte Backend
-- Organization
+- direkten Organization- und Backend-Vorgaben (zum Beispiel Partitionierung, Verschlüsselung)
-- Workspace
 - optional Benutzerkontext
 
 ## Orchestrator
@@ -79,3 +94,15 @@ Beispiele:
 - Calamares
 - Debian Installer
 - Subiquity
+
+## Auto-Modus
+
+Ein Bootmodus der Provisionierungs-ISO, in dem Bereitstellungsvorlage-Auswahl und Commit-Point-Bestätigung ohne Benutzereingabe erfolgen.
+
+Nur für bereits registrierte Geräte zulässig (`device.registration_status == "existing"`).
+
+Details: `architecture/13-live-provisioning-boot.md`.
+
+## Interaktiv-Modus
+
+Der in F-005 (`architecture/10-interactive-provisioning-flow.md`) beschriebene Ablauf mit expliziter Benutzerinteraktion bei Bereitstellungsvorlage-Auswahl und Installationsbestätigung.

02-workspace-model.md

@@ -1,57 +0,0 @@
-# Workspace Model
-
-**Status:** Stable
-
-## Zweck dieses Dokuments
-
-Dieses Dokument beschreibt den Workspace als zentralen Gegenstand von Tuxflotte.
-
-Es definiert seine Aufgabe innerhalb der Plattform und beschreibt seine Verantwortung sowie seine Abgrenzung zu den übrigen Komponenten der Architektur.
-
----
-
-## Motivation
-
-Benutzende erfüllen unterschiedliche Aufgaben und übernehmen unterschiedliche Rollen.
-
-Daraus ergeben sich unterschiedliche Anforderungen an ihren Arbeitsplatz.
-
-**Ein Workspace beschreibt die Anforderungen, die sich aus einer bestimmten Aufgabe oder Rolle der Benutzenden ergeben.**
-
----
-
-## Definition
-
-Der Workspace ist der zentrale Gegenstand von Tuxflotte.
-
-Er beschreibt den gewünschten Zielzustand eines Linux-Arbeitsplatzes unabhängig von dessen technischer Umsetzung.
-
-Ein Workspace definiert, welche Eigenschaften ein Arbeitsplatz besitzen soll. Er beschreibt den gewünschten Zielzustand, der durch die weiteren Komponenten der Plattform umgesetzt wird.
-
----
-
-## Verantwortungsbereich
-
-Ein Workspace beschreibt beispielsweise
-
-- den Zweck eines Arbeitsplatzes,
-- die Zielgruppe,
-- die erforderlichen Funktionen,
-- die benötigte Software,
-- optionale Erweiterungen,
-- Sicherheitsanforderungen sowie
-- organisatorische Anforderungen.
-
-Der Workspace beschreibt den gewünschten Zielzustand eines Arbeitsplatzes.
-
-Die technische Umsetzung dieses Zielzustands erfolgt durch die weiteren Komponenten der Plattform.
-
----
-
-## Zusammenfassung
-
-Der Workspace bildet die Grundlage jeder Bereitstellung.
-
-Er beschreibt den gewünschten Zielzustand eines Linux-Arbeitsplatzes.
-
-Alle weiteren Komponenten von Tuxflotte arbeiten darauf hin, diesen Zielzustand auf einem Zielsystem bereitzustellen.

04-backend-model.md

@@ -1,55 +0,0 @@
-# Backend Model
-
-**Status:** Stable
-
-## Zweck dieses Dokuments
-
-Dieses Dokument beschreibt das Backend als distributionsspezifische Umsetzung der Workspaces von Tuxflotte.
-
-Es definiert seine Aufgabe innerhalb der Plattform und beschreibt seine Verantwortung sowie seine Abgrenzung zu den übrigen Komponenten der Architektur.
-
----
-
-## Motivation
-
-Die Linux-Welt zeichnet sich durch ihre Vielfalt aus.
-
-Unterschiedliche Distributionen verfolgen unterschiedliche Ziele und besitzen eigene Stärken. Sie unterscheiden sich beispielsweise in ihrer Systemarchitektur, den Paketformaten, den Desktopumgebungen oder ihren Veröffentlichungsmodellen.
-
-Diese Vielfalt ist eine Stärke des Linux-Ökosystems.
-
-Tuxflotte respektiert diese Vielfalt und bewahrt sie. Anstatt Distributionen zu vereinheitlichen, kapselt die Plattform distributionsspezifische Unterschiede bewusst in Backends.
-
-Dadurch können identische Workspaces auf unterschiedlichen Linux-Distributionen bereitgestellt werden.
-
----
-
-## Definition
-
-Ein Backend beschreibt die distributionsspezifische Umsetzung eines Workspace unter Berücksichtigung der organisatorischen Rahmenbedingungen.
-
-Es übersetzt die fachlichen Anforderungen in distributionsspezifische Installationsdaten und nutzt dabei die nativen Installationsmechanismen der jeweiligen Distribution.
-
----
-
-## Verantwortungsbereich
-
-Ein Backend beschreibt beispielsweise
-
-- die Zuordnung fachlicher Funktionen zu distributionsspezifischen Paketen,
-- distributionsspezifische Konfigurationen,
-- die Erstellung distributionsspezifischer Installationsdaten,
-- die Anbindung an native Installationswerkzeuge sowie
-- distributionsspezifische Besonderheiten.
-
-Das Backend beschreibt die technische Umsetzung eines Workspace.
-
-Die fachliche Beschreibung eines Arbeitsplatzes erfolgt durch den Workspace. Die organisatorischen Rahmenbedingungen werden durch die Organization beschrieben.
-
----
-
-## Zusammenfassung
-
-Das Backend verbindet die distributionsunabhängigen Modelle von Tuxflotte mit den nativen Installationsmechanismen einer Linux-Distribution.
-
-Dadurch bleibt der Kern von Tuxflotte distributionsneutral, während gleichzeitig die Vielfalt des Linux-Ökosystems vollständig erhalten bleibt.

adr/0002-blueprint-merkmal-backend-realisierung.md

@@ -0,0 +1,36 @@
+# ADR-0002: Blueprint als Merkmal-Backend-Realisierung über Ansible
+
+**Status:** Beschlossen
+**Datum:** 17.07.2026
+
+## Kontext
+
+Der Begriff „Blueprint" war im Glossar bisher nur grob als „technische Beschreibung eines Workspace" definiert.
+
+Mit wachsender Anzahl an Workspaces (zum Beispiel Schulcomputer, Entwickler) und Backends (Fedora, Linux Mint) musste geklärt werden, wie einzelne fachliche Merkmale eines Workspace unabhängig von der gewählten Distribution wiederverwendbar umgesetzt werden können, ohne dass jede Kombination aus Workspace und Backend eigenständig gepflegt werden muss.
+
+Zusätzlich musste geklärt werden, ob diese Umsetzung zur Installationszeit (nativer Installer, Kickstart/Autoinstall) oder nach dem ersten Start (Ansible) erfolgen soll.
+
+## Entscheidung
+
+Ein Blueprint beschreibt die technische Umsetzung genau eines Merkmals für genau ein Backend.
+
+Ein Blueprint ist im Regelfall eine Ansible-Rolle beziehungsweise -Aufgabe und wird nach dem ersten Start über den bestehenden Ansible-Pull-Mechanismus angewendet.
+
+Der native Installer bleibt dadurch unabhängig von Workspace-Merkmalen. Er stellt lediglich das Basissystem sowie die Voraussetzungen für den Ansible-Pull-Mechanismus bereit (Netzwerk, Registrierung, Ansible-Repository).
+
+Eigenschaften, die ausschließlich zur Installationszeit festgelegt werden können – insbesondere Partitionierung, Festplattenverschlüsselung sowie Secure-Boot- und TPM-Bindung – sind kein Bestandteil eines Blueprints. Sie werden als direkte Vorgabe der gewählten Bereitstellungsvorlage an `backend_generate_config()` übergeben.
+
+## Konsequenzen
+
+Für jedes Merkmal wird je unterstütztem Backend ein eigener Blueprint gepflegt.
+
+Neue Merkmale erfordern Blueprints für alle bestehenden Backends. Neue Backends erfordern Blueprints für alle bestehenden Merkmale. Workspace-Definitionen selbst bleiben davon unberührt.
+
+Der native Installer benötigt keine Kenntnis einzelner Workspace-Merkmale.
+
+Workspace-Merkmale, die eine Änderung der Partitionierung oder andere installationszeitliche Eingriffe erfordern würden, sind mit diesem Modell nicht darstellbar und müssen stattdessen als Vorgabe der Bereitstellungsvorlage modelliert werden.
+
+Der Glossar-Eintrag „Blueprint" wird entsprechend präzisiert.
+
+Details zum Merkmal- und Blueprint-Modell: `architecture/12-feature-blueprint-model.md`.

adr/0003-live-provisioning-boot.md

@@ -0,0 +1,44 @@
+# ADR-0003: Live-ISO als Provisionierungsmedium mit Auto- und Interaktiv-Modus
+
+**Status:** Beschlossen
+**Datum:** 18.07.2026
+
+## Kontext
+
+Das bisherige Provisionierungsmedium ist eine gepatchte Fedora-DVD/Netinst-ISO. GRUB startet Anaconda dort direkt über einen fest verdrahteten Kernel-Parameter (`inst.ks=https://.../ks.cfg`), der auf eine statische Kickstart-Datei auf dem Provisioning-Server zeigt.
+
+Das hat zwei Konsequenzen:
+
+Der in `10-interactive-provisioning-flow.md` (F-005) beschriebene und in `scripts/installer.sh` umgesetzte Ablauf (Netzwerk, Hardware, Aktivierung, Bereitstellungsvorlage-Auswahl, Runtime Blueprint, Backend) hat auf der aktuellen ISO keinen Einstiegspunkt. Anaconda startet, bevor `installer.sh` je ausgeführt wird.
+
+Eine gebrandete, frei gestaltbare Oberfläche für Workspace-Auswahl und Provisioning-Server-Authentifizierung ist auf dieser Basis nur über Anaconda-eigene Erweiterungsmechanismen (Addons) erreichbar, die eng an Anacondas UI-Framework gebunden und aufwendig sind.
+
+Gleichzeitig ist eine durchgängige interaktive Bestätigungspflicht für jede Installation bei Massenrollouts und Geräteersatz unpraktikabel.
+
+## Entscheidung
+
+Tuxflotte wechselt die Grundlage der Provisionierungs-ISO von einer Fedora-DVD/Netinst-Basis auf ein echtes Live-Medium (z. B. Fedora Workstation Live, erkennbar an `/LiveOS/squashfs.img`).
+
+`scripts/installer.sh` läuft als Anwendung innerhalb dieser Live-Sitzung. Der native Installer wird nicht mehr über einen boot-zeitlichen `inst.ks=`-Parameter gestartet, sondern erst am Ende des Ablaufs explizit durch `backend_launch()`, mit der von `backend_generate_config()` erzeugten Konfiguration.
+
+Das Bootmenü bietet zwei Einträge, die dieselbe Live-Umgebung starten, sich aber in einem Kernel-Cmdline-Flag unterscheiden:
+
+Ein Standardeintrag mit Countdown, der bei Nichtstun automatisch in den unbeaufsichtigten Ablauf führt.
+
+Ein manuell auswählbarer zweiter Eintrag für den interaktiven, gebrandeten Ablauf.
+
+Der unbeaufsichtigte Ablauf ist ausschließlich für bereits registrierte Geräte zulässig, erkennbar an `device.registration_status == "existing"` in der Antwort von `POST /api/v1/activate`. Bei einem unbekannten Gerät (`registration_status == "registered"`) bricht der unbeaufsichtigte Ablauf kontrolliert ab (Fail-Closed) und verweist auf den interaktiven Ablauf mit expliziter Geräteaufnahme-Bestätigung gemäß `11-device-enrollment.md`.
+
+Dass ein bereits registriertes Gerät ohne erneute interaktive Rückfrage automatisiert neu installiert werden kann, wird explizit Bestandteil der Bedingungen, denen bei der Geräteregistrierung zugestimmt wird.
+
+## Konsequenzen
+
+`scripts/build.sh` und `scripts/extract.sh` benötigen künftig ein Live-ISO als Quelle statt einer DVD/Netinst-ISO. Die GRUB-Konfiguration erhält einen zweiten Menüeintrag sowie ein Kernel-Cmdline-Flag zur Moduswahl.
+
+Die statische `ks.cfg` sowie ihr Server-Endpoint (`GET /installers/fedora-workstation/ks.cfg`) entfallen mit der Umstellung.
+
+WLAN-Zugangsdaten für die Live-Provisionierungsumgebung selbst müssen weiterhin im ISO-Build hinterlegt werden, da ohne Netzwerk kein Zugriff auf den Provisioning-Server möglich ist. WLAN-Zugangsdaten für das installierte Zielsystem gehören zum noch unspezifizierten `Network Profile`-Modell der Organization (`09-data-model-v1.md`).
+
+Die Geräteregistrierung (`11-device-enrollment.md`) wird um den ausdrücklichen Hinweis ergänzt, dass registrierte Geräte automatisiert neu installiert werden können.
+
+Details zum Ablauf: `architecture/13-live-provisioning-boot.md`.

architecture/00-provisioning-flow.md

@@ -1,5 +1,7 @@
 Boot
  ↓
+GRUB-Menü: Auto- oder Interaktiv-Modus (siehe 13-live-provisioning-boot.md)
+ ↓
 Preflight
  ↓
 Netzwerk
@@ -12,9 +14,9 @@ Device Registration
  ↓
 Assignment
  ↓
-Runtime Blueprint
+Runtime Blueprint erzeugen
  ↓
-Backend Selection
+Backend laden
  ↓
 Backend API
  ↓
@@ -26,6 +28,8 @@ Provisioning Agent
  ↓
 Managed System
 
+Der Schritt „Assignment" unterscheidet sich je nach Modus: Im Interaktiv-Modus wählt der Benutzer eine Bereitstellungsvorlage und bestätigt den Commit Point explizit. Im Auto-Modus geschieht beides automatisch, und nur für bereits registrierte Geräte (siehe `13-live-provisioning-boot.md`).
+
 ## Aktivierung und Gerätebindung
 
 Ein neues Gerät authentifiziert den ersten Provisionierungsvorgang mit einem Aktivierungscode.
@@ -46,6 +50,6 @@ Hardware-Fingerprint
         ↓
 Geräteregistrierung oder Wiedererkennung
         ↓
-Profil- beziehungsweise Workspace-Zuordnung
+Bereitstellungsvorlage-Zuordnung
         ↓
-Runtime Blueprint
+Runtime Blueprint erzeugen

architecture/03-organization-model.md

@@ -0,0 +1,72 @@
+# Organization Model
+
+**Status:** Stable
+**Datum:** 17.07.2026
+
+## Zweck dieses Dokuments
+
+Dieses Dokument beschreibt die Organization als organisatorischen Rahmen für die Bereitstellung von Workspaces.
+
+Es definiert ihre Aufgabe innerhalb der Plattform und beschreibt ihre Verantwortung sowie ihre Abgrenzung zu den übrigen Komponenten der Architektur.
+
+---
+
+## Motivation
+
+Workspaces beschreiben den gewünschten Arbeitsplatz.
+
+Unterschiedliche Organisationen stellen jedoch unterschiedliche Anforderungen an die Bereitstellung desselben Workspace.
+
+So kann ein Workspace beispielsweise auf einem einer Person fest zugeordneten Gerät oder auf einem gemeinsam genutzten Gerät bereitgestellt werden.
+
+Die Organization beschreibt die organisatorischen Rahmenbedingungen, unter denen Workspaces bereitgestellt werden.
+
+---
+
+## Definition
+
+Die Organization beschreibt die organisatorischen Rahmenbedingungen, unter denen Workspaces bereitgestellt werden.
+
+Sie ergänzt den Workspace um organisationsspezifische Anforderungen, die unabhängig vom eigentlichen Arbeitsplatz gelten.
+
+Dadurch können identische Workspaces in unterschiedlichen Organisationen unter jeweils passenden Rahmenbedingungen bereitgestellt werden.
+
+---
+
+## Verantwortungsbereich
+
+Eine Organization beschreibt beispielsweise
+
+- organisatorische Richtlinien,
+- organisationsweite Sicherheitsanforderungen,
+- Standardkonfigurationen,
+- Anforderungen an Authentifizierung und Identitätsmanagement,
+- Zertifikate,
+- Softwarequellen,
+- Netzwerkanforderungen,
+- Branding sowie
+- Rahmenbedingungen für die Nutzung von Geräten.
+
+Die Organization beschreibt den organisatorischen Rahmen der Bereitstellung.
+
+Die technische Umsetzung dieser Rahmenbedingungen erfolgt durch die weiteren Komponenten der Plattform.
+
+### Installationszeitliche Sicherheitsvorgaben
+
+Vorgaben, die nur zur Installationszeit umgesetzt werden können, beispielsweise
+
+- Datenträgerverschlüsselung,
+- Partitionierungsvorgaben sowie
+- Secure-Boot- beziehungsweise TPM-Pflicht,
+
+werden nicht über Workspace-Merkmale beziehungsweise Blueprints umgesetzt (siehe `12-feature-blueprint-model.md`), sondern direkt als Vorgabe der gewählten Bereitstellungsvorlage an das Backend übergeben (siehe `06-backend-api.md`, `08-provisioning-api.md`).
+
+Diese Vorgaben gelten je Bereitstellungsvorlage, nicht einheitlich für die gesamte Organisation — eine Organisation kann mehrere Bereitstellungsvorlagen mit unterschiedlichen Sicherheitsanforderungen anbieten (zum Beispiel eine unverschlüsselte Vorlage für Schulcomputer und eine verschlüsselungspflichtige für Entwickler-Notebooks).
+
+---
+
+## Zusammenfassung
+
+Die Organization ergänzt den Workspace um organisationsspezifische Rahmenbedingungen.
+
+Gemeinsam beschreiben Workspace und Organization die fachliche Grundlage für die Bereitstellung eines Linux-Workspaces.

architecture/04-backend-model.md

@@ -0,0 +1,55 @@
+# Backend Model
+
+**Status:** Stable
+
+## Zweck dieses Dokuments
+
+Dieses Dokument beschreibt das Backend als distributionsspezifische Umsetzung der Workspaces von Tuxflotte.
+
+Es definiert seine Aufgabe innerhalb der Plattform und beschreibt seine Verantwortung sowie seine Abgrenzung zu den übrigen Komponenten der Architektur.
+
+---
+
+## Motivation
+
+Die Linux-Welt zeichnet sich durch ihre Vielfalt aus.
+
+Unterschiedliche Distributionen verfolgen unterschiedliche Ziele und besitzen eigene Stärken. Sie unterscheiden sich beispielsweise in ihrer Systemarchitektur, den Paketformaten, den Desktopumgebungen oder ihren Veröffentlichungsmodellen.
+
+Diese Vielfalt ist eine Stärke des Linux-Ökosystems.
+
+Tuxflotte respektiert diese Vielfalt und bewahrt sie. Anstatt Distributionen zu vereinheitlichen, kapselt die Plattform distributionsspezifische Unterschiede bewusst in Backends.
+
+Dadurch können identische Workspaces auf unterschiedlichen Linux-Distributionen bereitgestellt werden.
+
+---
+
+## Definition
+
+Ein Backend beschreibt die distributionsspezifische Umsetzung eines Workspace unter Berücksichtigung der organisatorischen Rahmenbedingungen.
+
+Es übersetzt die fachlichen Anforderungen in distributionsspezifische Installationsdaten und nutzt dabei die nativen Installationsmechanismen der jeweiligen Distribution.
+
+---
+
+## Verantwortungsbereich
+
+Ein Backend beschreibt beispielsweise
+
+- die Zuordnung fachlicher Funktionen zu distributionsspezifischen Paketen,
+- distributionsspezifische Konfigurationen,
+- die Erstellung distributionsspezifischer Installationsdaten,
+- die Anbindung an native Installationswerkzeuge sowie
+- distributionsspezifische Besonderheiten.
+
+Das Backend beschreibt die technische Umsetzung eines Workspace.
+
+Die fachliche Beschreibung eines Arbeitsplatzes erfolgt durch den Workspace. Die organisatorischen Rahmenbedingungen werden durch die Organization beschrieben.
+
+---
+
+## Zusammenfassung
+
+Das Backend verbindet die distributionsunabhängigen Modelle von Tuxflotte mit den nativen Installationsmechanismen einer Linux-Distribution.
+
+Dadurch bleibt der Kern von Tuxflotte distributionsneutral, während gleichzeitig die Vielfalt des Linux-Ökosystems vollständig erhalten bleibt.

architecture/06-backend-api.md

@@ -77,7 +77,7 @@ Rückgabe:
 
 ## backend_validate()
 
-Prüft, ob das Profil mit diesem Backend kompatibel ist.
+Prüft, ob das Runtime Blueprint mit diesem Backend kompatibel ist.
 
 Beispiele:
 
@@ -167,11 +167,14 @@ Der Orchestrator stellt dem Backend alle benötigten Informationen bereit.
 
 Beispiele:
 
-* ausgewähltes Profil
+* Runtime Blueprint
 * Zielsystem
 * Hardwareinformationen
 * Netzwerk
 * Laufzeitverzeichnis
+* Installationszeitliche Vorgaben der Bereitstellungsvorlage (zum Beispiel Partitionierung, Datenträgerverschlüsselung, Secure-Boot-Pflicht)
+
+Diese Vorgaben fließen direkt in `backend_generate_config()` ein. Sie sind kein Bestandteil der Merkmal-Blueprints (siehe `12-feature-blueprint-model.md`), sondern Teil der gewählten Bereitstellungsvorlage selbst.
 
 Backends greifen nicht direkt auf andere Module zu.
 

architecture/07-runtime-layout.md

@@ -68,7 +68,7 @@ Beispiele:
 - 17_device_status.sh liest aus /run/tuxflotte/server/ und schreibt nach /run/tuxflotte/provisioning/
 - 20_profile_selection.sh liest aus /run/tuxflotte/server/ und schreibt nach /run/tuxflotte/assignment/
 - 25_installation_confirm.sh liest aus /run/tuxflotte/assignment/ und schreibt nach /run/tuxflotte/installation/
-- Der Runtime-Builder liest aus /run/tuxflotte/server/
+- Der Runtime-Builder (30_runtime_blueprint.sh) liest aus /run/tuxflotte/network/, /run/tuxflotte/server/ und /run/tuxflotte/assignment/ und schreibt nach /run/tuxflotte/runtime/
 - Der Backend-Orchestrator liest aus /run/tuxflotte/runtime/
 
 Direkte Funktionsaufrufe zwischen Modulen sind nicht vorgesehen.

architecture/08-provisioning-api.md

@@ -87,7 +87,7 @@ Bei einer erneuten erfolgreichen Aktivierung desselben Geräts bleibt die intern
 
 ### Response
 
-Bei erfolgreicher Aktivierung antwortet der Provisioning-Server mit dem registrierten Gerät, der zugeordneten Organisation und den verfügbaren Provisioning-Profilen.
+Bei erfolgreicher Aktivierung antwortet der Provisioning-Server mit dem registrierten Gerät, der zugeordneten Organisation und den verfügbaren Bereitstellungsvorlagen.
 
 ```json
 {
@@ -104,18 +104,20 @@ Bei erfolgreicher Aktivierung antwortet der Provisioning-Server mit dem registri
     "organization_id": "<organization-uuid>",
     "name": "Default Lab"
   },
-  "profiles": [
+  "templates": [
     {
-      "id": "fedora-workstation",
+      "id": "schulcomputer-fedora",
-      "label": "Fedora Workstation",
+      "label": "Schulcomputer (Fedora)",
-      "distribution": "fedora",
+      "workspace": {
-      "version": "40",
+        "id": "schulcomputer",
-      "description": "Standard-Workstation-Profil für Fedora.",
+        "name": "Schulcomputer"
-      "ansible_repo": "<repository-url>",
+      },
-      "installer": {
+      "backend": {
-        "type": "kickstart",
+        "id": "fedora",
-        "url": "<kickstart-url>"
+        "name": "Fedora",
-      }
+        "version": "40"
+      },
+      "is_default": true
     }
   ]
 }
@@ -131,7 +133,9 @@ Der Wert `existing` bedeutet, dass ein bereits bekanntes Device anhand seines Ha
 
 `device.hardware_snapshot_id` referenziert den für diesen Aktivierungsvorgang erzeugten Hardware-Snapshot.
 
-Der Aktivierungscode bestimmt die zugeordnete Organisation und die für den Provisionierungsvorgang verfügbaren Profile.
+Der Aktivierungscode bestimmt die zugeordnete Organisation und die für den Provisionierungsvorgang verfügbaren Bereitstellungsvorlagen.
+
+Jede Bereitstellungsvorlage referenziert genau einen Workspace und genau ein Backend. Höchstens eine Bereitstellungsvorlage je Organisation trägt `is_default: true`.
 
 ### Fehlerantwort
 
@@ -144,3 +148,45 @@ Ist der Aktivierungscode ungültig, antwortet der Provisioning-Server mit:
   "message": "Der Aktivierungscode ist ungültig."
 }
 ```
+
+## Auflösung einer Bereitstellungsvorlage
+
+### Endpoint
+
+POST /api/v1/templates/{template_id}/resolve
+
+### Zweck
+
+Der Endpoint löst eine vom Benutzer gewählte Bereitstellungsvorlage zum vollständigen Runtime Blueprint auf. Erst mit diesem Aufruf endet die Provisioning API und beginnt der in `06-backend-api.md` beschriebene Backend-Lebenszyklus.
+
+### Request
+
+```json
+{
+  "device_id": "<device-uuid>"
+}
+```
+
+### Response
+
+```json
+{
+  "success": true,
+  "runtime_blueprint": {
+    "workspace_id": "schulcomputer",
+    "backend_id": "fedora",
+    "blueprints": [
+      { "merkmal": "guest-session-ephemeral", "ansible_role": "guest-session" },
+      { "merkmal": "browser-brave", "ansible_role": "brave-fedora" }
+    ],
+    "installation_directives": {
+      "disk_encryption": false,
+      "partitioning": "default"
+    }
+  }
+}
+```
+
+`runtime_blueprint.blueprints` enthält die für jedes Merkmal des Workspace gegen das gewählte Backend aufgelöste Ansible-Rolle (siehe `12-feature-blueprint-model.md`).
+
+`runtime_blueprint.installation_directives` enthält die installationszeitlichen Vorgaben der gewählten Bereitstellungsvorlage, die nicht Bestandteil eines Blueprints sind (siehe `03-organization-model.md`, `12-feature-blueprint-model.md`).

architecture/09-data-model-v1.md

@@ -14,11 +14,17 @@ Die konkrete SQL-Implementierung und das Migrationssystem werden getrennt von di
 - Network Interface
 - Storage Device
 - Workspace
+- Merkmal
 - Backend
+- Blueprint
+- Bereitstellungsvorlage
 - Assignment
+- Activation Code
 - Network Profile
 - Secret Reference
 
+`Network Profile` und `Secret Reference` sind weiterhin nur benannt, aber fachlich noch nicht spezifiziert — das bleibt bewusst außerhalb des aktuellen Arbeitsschritts (Provisioning-Server-Datenmodell für Workspace/Merkmal/Backend/Blueprint/Bereitstellungsvorlage).
+
 ## Organization
 
 Eine Organization beschreibt eine organisatorische Einheit innerhalb der Tuxflotte-Plattform.
@@ -35,7 +41,9 @@ Attribute:
 Beziehungen:
 
 - besitzt mehrere Devices
-- besitzt mehrere Workspaces
+- besitzt optional eigene Workspaces (zusätzlich zu global bereitgestellten Workspaces, siehe Workspace)
+- besitzt mehrere Bereitstellungsvorlagen
+- besitzt mehrere Activation Codes
 - besitzt mehrere Network Profiles
 - referenziert Secrets
 
@@ -131,6 +139,145 @@ Beziehungen:
 
 - gehört zu genau einem Hardware Snapshot
 
+## Workspace
+
+Ein Workspace beschreibt einen distributionsunabhängigen Arbeitsplatz-Zielzustand aus einer Menge von Merkmalen (siehe `02-workspace-model.md`).
+
+Ein Workspace steht zunächst global bereit. Eine Organization kann zusätzlich eigene Workspaces definieren.
+
+Attribute:
+
+- id
+- organization_id (optional; NULL bedeutet global bereitgestellt)
+- key
+- name
+- description
+- created_at
+- updated_at
+
+Beziehungen:
+
+- gehört optional zu genau einer Organization
+- besteht aus mehreren Merkmalen
+- wird in mehreren Bereitstellungsvorlagen referenziert
+
+## Merkmal
+
+Ein Merkmal ist eine einzelne fachliche Eigenschaft eines Workspace, distributionsunabhängig benannt (siehe `12-feature-blueprint-model.md`).
+
+Attribute:
+
+- id
+- key
+- name
+- description
+
+Beziehungen:
+
+- gehört zu mehreren Workspaces
+- besitzt je Backend höchstens einen Blueprint
+
+## Backend
+
+Ein Backend beschreibt die distributionsspezifische Umsetzung eines Workspace (siehe `04-backend-model.md`).
+
+Attribute:
+
+- id
+- key
+- name
+- installer_type (zum Beispiel kickstart, autoinstall, calamares, preseed)
+
+Beziehungen:
+
+- besitzt Blueprints für Merkmale
+- wird in mehreren Bereitstellungsvorlagen referenziert
+
+## Blueprint
+
+Ein Blueprint beschreibt die technische Umsetzung genau eines Merkmals für genau ein Backend (siehe `12-feature-blueprint-model.md`).
+
+Attribute:
+
+- id
+- merkmal_id
+- backend_id
+- ansible_role
+
+Beziehungen:
+
+- gehört zu genau einem Merkmal
+- gehört zu genau einem Backend
+
+Constraints:
+
+- je Merkmal und Backend existiert höchstens ein Blueprint
+
+## Bereitstellungsvorlage
+
+Eine Bereitstellungsvorlage beschreibt eine von einer Organization vorkonfigurierte Kombination aus Workspace und Backend, einschließlich der installationszeitlichen Vorgaben, die kein Bestandteil eines Blueprints sind (siehe `03-organization-model.md`, `12-feature-blueprint-model.md`).
+
+Attribute:
+
+- id
+- organization_id
+- workspace_id
+- backend_id
+- label
+- is_default
+- disk_encryption
+- partitioning
+- secure_boot_required
+- created_at
+- updated_at
+
+Beziehungen:
+
+- gehört zu genau einer Organization
+- referenziert genau einen Workspace
+- referenziert genau ein Backend
+
+Constraints:
+
+- höchstens eine Bereitstellungsvorlage je Organization mit `is_default = true`
+
+## Assignment
+
+Ein Assignment beschreibt die konkrete Zuordnung eines Device zu der Bereitstellungsvorlage, mit der es provisioniert wurde.
+
+Attribute:
+
+- id
+- device_id
+- bereitstellungsvorlage_id
+- created_at
+
+Beziehungen:
+
+- gehört zu genau einem Device
+- referenziert genau eine Bereitstellungsvorlage
+
+Constraints:
+
+- ein Device besitzt höchstens ein Assignment
+
+## Activation Code
+
+Ein Activation Code autorisiert den initialen Provisionierungsvorgang eines Geräts und bestimmt die zugeordnete Organization (siehe `08-provisioning-api.md`, `11-device-enrollment.md`).
+
+Der Activation Code ist laut `11-device-enrollment.md` ein Übergangsmechanismus und wird langfristig durch Enrollment Sessions ersetzt.
+
+Attribute:
+
+- code
+- organization_id
+- active
+- created_at
+
+Beziehungen:
+
+- gehört zu genau einer Organization
+
 ## Relationales Schema v1
 
 ### organizations
@@ -220,6 +367,147 @@ Beziehungen:
 
 - hardware_snapshot_id referenziert hardware_snapshots.id
 
+### workspaces
+
+Spalten:
+
+- id
+- organization_id (nullable)
+- key
+- name
+- description
+- created_at
+- updated_at
+
+Beziehungen:
+
+- organization_id referenziert organizations.id (optional)
+
+Constraints:
+
+- (organization_id, key) ist eindeutig
+
+### merkmale
+
+Spalten:
+
+- id
+- key
+- name
+- description
+
+Constraints:
+
+- key ist eindeutig
+
+### workspace_merkmale
+
+Spalten:
+
+- workspace_id
+- merkmal_id
+
+Beziehungen:
+
+- workspace_id referenziert workspaces.id
+- merkmal_id referenziert merkmale.id
+
+Constraints:
+
+- (workspace_id, merkmal_id) ist Primärschlüssel
+
+### backends
+
+Spalten:
+
+- id
+- key
+- name
+- installer_type
+
+Constraints:
+
+- key ist eindeutig
+
+### blueprints
+
+Spalten:
+
+- id
+- merkmal_id
+- backend_id
+- ansible_role
+
+Beziehungen:
+
+- merkmal_id referenziert merkmale.id
+- backend_id referenziert backends.id
+
+Constraints:
+
+- (merkmal_id, backend_id) ist eindeutig
+
+### bereitstellungsvorlagen
+
+Spalten:
+
+- id
+- organization_id
+- workspace_id
+- backend_id
+- label
+- is_default
+- disk_encryption
+- partitioning
+- secure_boot_required
+- created_at
+- updated_at
+
+Beziehungen:
+
+- organization_id referenziert organizations.id
+- workspace_id referenziert workspaces.id
+- backend_id referenziert backends.id
+
+Constraints:
+
+- höchstens eine Zeile je organization_id mit is_default = true (partieller Unique-Index)
+
+### assignments
+
+Spalten:
+
+- id
+- device_id
+- bereitstellungsvorlage_id
+- created_at
+
+Beziehungen:
+
+- device_id referenziert devices.id
+- bereitstellungsvorlage_id referenziert bereitstellungsvorlagen.id
+
+Constraints:
+
+- device_id ist eindeutig
+
+### activation_codes
+
+Spalten:
+
+- code
+- organization_id
+- active
+- created_at
+
+Beziehungen:
+
+- organization_id referenziert organizations.id
+
+Constraints:
+
+- code ist Primärschlüssel
+
 ## Beziehungskonsequenzen
 
 Wird eine Organization gelöscht, dürfen zugehörige Devices nicht implizit mitgelöscht werden.
@@ -228,12 +516,29 @@ Wird ein Device gelöscht, werden zugehörige Hardware Snapshots mitgelöscht.
 
 Wird ein Hardware Snapshot gelöscht, werden zugehörige Network Interfaces und Storage Devices automatisch mitgelöscht.
 
+Wird eine Organization gelöscht, dürfen ihre Bereitstellungsvorlagen und Activation Codes nicht implizit erhalten bleiben — sie verlieren mit der Organization ihre Grundlage.
+
+Wird ein Workspace, ein Backend oder ein Merkmal gelöscht, das noch von einer Bereitstellungsvorlage beziehungsweise einem Blueprint referenziert wird, muss das gesperrt werden, um Bereitstellungsvorlagen nicht unbemerkt ungültig zu machen.
+
+Wird ein Device gelöscht, wird sein Assignment mitgelöscht. Wird eine Bereitstellungsvorlage gelöscht, auf die noch ein Assignment verweist, muss das gesperrt werden.
+
 Für die relationale Umsetzung gilt daher:
 
 - devices.organization_id → ON DELETE RESTRICT
 - hardware_snapshots.device_id → ON DELETE CASCADE
 - network_interfaces.hardware_snapshot_id → ON DELETE CASCADE
 - storage_devices.hardware_snapshot_id → ON DELETE CASCADE
+- workspaces.organization_id → ON DELETE CASCADE
+- workspace_merkmale.workspace_id → ON DELETE CASCADE
+- workspace_merkmale.merkmal_id → ON DELETE RESTRICT
+- blueprints.merkmal_id → ON DELETE CASCADE
+- blueprints.backend_id → ON DELETE CASCADE
+- bereitstellungsvorlagen.organization_id → ON DELETE CASCADE
+- bereitstellungsvorlagen.workspace_id → ON DELETE RESTRICT
+- bereitstellungsvorlagen.backend_id → ON DELETE RESTRICT
+- assignments.device_id → ON DELETE CASCADE
+- assignments.bereitstellungsvorlage_id → ON DELETE RESTRICT
+- activation_codes.organization_id → ON DELETE CASCADE
 
 ## ID-Erzeugung
 

architecture/10-interactive-provisioning-flow.md

@@ -8,6 +8,8 @@ F-005 beschreibt den interaktiven Provisionierungsablauf zwischen Netzwerkinitia
 
 Ziel ist ein vollständig testbarer Provisionierungsprozess, der vor dem Start der eigentlichen Betriebssysteminstallation kontrolliert abgebrochen werden kann.
 
+Dieser Ablauf beschreibt den Interaktiv-Modus. Für bereits registrierte Geräte existiert daneben ein automatisierter Modus, der Bereitstellungsvorlage-Auswahl und Commit-Point-Bestätigung ohne Benutzereingabe durchläuft (siehe `13-live-provisioning-boot.md`).
+
 ## Ablauf
 
 ```text
@@ -29,9 +31,9 @@ Provisionierung fortsetzen?
   ├── nein → kontrollierter Abbruch
   └── ja
        ↓
-     verfügbare Profile anzeigen
+     verfügbare Bereitstellungsvorlagen anzeigen
        ↓
-     Profil auswählen
+     Bereitstellungsvorlage auswählen
        ↓
      Installationsplan anzeigen
        ↓
@@ -117,40 +119,42 @@ Die Aktivierungsphase verwendet die bereits bestehende Server-Runtime:
 
 `activation.json` enthält den an den Provisioning-Server gesendeten Aktivierungsrequest.
 
-`response.json` enthält die erfolgreiche Antwort des Provisioning-Servers einschließlich Geräteinformationen, Organisation und verfügbarer Profile.
+`response.json` enthält die erfolgreiche Antwort des Provisioning-Servers einschließlich Geräteinformationen, Organisation und verfügbarer Bereitstellungsvorlagen.
 
-### Profilauswahl
+### Auswahl der Bereitstellungsvorlage
 
-Die Auswahl eines Provisioning-Profils wird unter folgendem Pfad gespeichert:
+Die Auswahl einer Bereitstellungsvorlage wird unter folgendem Pfad gespeichert:
 
 ```text
 /run/tuxflotte/assignment/
-└── profile.json
+└── template.json
 ```
 
-`profile.json` enthält das vom Benutzer ausgewählte Profil.
+`template.json` enthält die vom Benutzer ausgewählte Bereitstellungsvorlage.
 
 Beispiel:
 
 ```json
 {
   "schema_version": 1,
-  "profile": {
+  "template": {
-    "id": "fedora-workstation",
+    "id": "schulcomputer-fedora",
-    "label": "Fedora Workstation",
+    "label": "Schulcomputer (Fedora)",
-    "distribution": "fedora",
+    "workspace": {
-    "version": "40",
+      "id": "schulcomputer",
-    "description": "Standard-Workstation-Profil für Fedora.",
+      "name": "Schulcomputer"
-    "ansible_repo": "<repository-url>",
+    },
-    "installer": {
+    "backend": {
-      "type": "kickstart",
+      "id": "fedora",
-      "url": "<kickstart-url>"
+      "name": "Fedora",
-    }
+      "version": "40"
+    },
+    "is_default": true
   }
 }
 ```
 
-Die Profilauswahl darf ausschließlich Profile verwenden, die in der erfolgreichen Antwort des Provisioning-Servers für den aktuellen Aktivierungsvorgang enthalten sind.
+Die Auswahl darf ausschließlich Bereitstellungsvorlagen verwenden, die in der erfolgreichen Antwort des Provisioning-Servers für den aktuellen Aktivierungsvorgang enthalten sind.
 
 ### Installationsbestätigung
 
@@ -281,13 +285,15 @@ Der Interactive Provisioning Flow wird durch folgende Module umgesetzt:
 
 ### 20_profile_selection.sh
 
+Der Modulname stammt noch aus dem flachen Profil-Modell und wird erst bei der Installer-Umsetzung (Phase B) an die Bereitstellungsvorlage angepasst.
+
 Das Modul:
 
 - liest `/run/tuxflotte/server/response.json`,
-- validiert die vom Server gelieferten Profile,
+- validiert die vom Server gelieferten Bereitstellungsvorlagen,
-- zeigt die verfügbaren Profile an,
+- zeigt die verfügbaren Bereitstellungsvorlagen an,
 - erfasst die Auswahl des Benutzers,
-- speichert ausschließlich ein vom Server geliefertes Profil unter `/run/tuxflotte/assignment/profile.json`.
+- speichert ausschließlich eine vom Server gelieferte Bereitstellungsvorlage unter `/run/tuxflotte/assignment/template.json`.
 
 Das Modul nimmt keine Änderungen an lokalen Datenträgern vor.
 

architecture/11-device-enrollment.md

@@ -112,6 +112,14 @@ Gerät erneut provisionieren?
 [j/N]
 ```
 
+### Automatisierte Reprovisionierung
+
+Für ein bereits registriertes, über seinen Hardware-Fingerprint wiedererkanntes Gerät (`registration_status == "existing"`) kann die Reprovisionierung auch automatisiert erfolgen, ohne die oben gezeigte interaktive Rückfrage (siehe `13-live-provisioning-boot.md`).
+
+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).
+
 ## Enrollment Sessions
 
 Für Massenrollouts und Werkstattumgebungen kann eine Organisation zeitlich begrenzte Enrollment Sessions erstellen.
@@ -121,7 +129,7 @@ Eine Enrollment Session kann insbesondere auf folgende Eigenschaften begrenzt we
 - Organisation,
 - Gültigkeitszeitraum,
 - maximale Anzahl neuer Geräte,
-- erlaubte Provisioning-Profile.
+- erlaubte Bereitstellungsvorlagen.
 
 Eine Enrollment Session ist widerrufbar und auditierbar.
 
@@ -134,9 +142,9 @@ Organisation: Muster GmbH
 Maximale neue Geräte: 50
 Gültigkeit: 8 Stunden
 
-Erlaubte Profile:
+Erlaubte Bereitstellungsvorlagen:
-- Fedora Workstation
+- Schulcomputer (Fedora)
-- Linux Mint Desktop
+- Entwickler (Mint)
 ```
 
 Der Installer kann neben der interaktiven Benutzeranmeldung die Verwendung einer Enrollment Session anbieten.

architecture/12-feature-blueprint-model.md

@@ -0,0 +1,124 @@
+# Feature- und Blueprint-Modell
+
+**Status:** Entwurf
+**Datum:** 17.07.2026
+
+## Zweck dieses Dokuments
+
+Dieses Dokument beschreibt, wie die Merkmale eines Workspace für ein konkretes Backend technisch umgesetzt werden.
+
+Es ergänzt das Workspace-Modell (`02-workspace-model.md`) und das Backend-Modell um den bisher fehlenden Übersetzungsmechanismus und präzisiert den Begriff „Blueprint" aus dem Glossar.
+
+---
+
+## Motivation
+
+Ein Workspace beschreibt einen Einsatzzweck, nicht seine technische Umsetzung.
+
+Ein Backend beschreibt eine Distribution, nicht die einzelnen fachlichen Eigenschaften eines Workspace.
+
+Zwischen beiden fehlt ein Bindeglied: die Frage, wie ein einzelnes Merkmal eines Workspace auf einem bestimmten Backend konkret realisiert wird.
+
+Dieses Bindeglied ist der Blueprint.
+
+---
+
+## Definition
+
+### Merkmal
+
+Ein Merkmal ist eine einzelne fachliche Eigenschaft eines Workspace.
+
+Ein Merkmal ist distributionsunabhängig benannt.
+
+Beispiele:
+
+- browser-brave
+- office-onlyoffice
+- guest-session-ephemeral
+- appstore
+
+Ein Workspace besteht aus einer Menge von Merkmalen.
+
+### Blueprint
+
+Ein Blueprint beschreibt die technische Umsetzung genau eines Merkmals für genau ein Backend.
+
+Ein Blueprint ist im Regelfall eine Ansible-Rolle bzw. -Aufgabe.
+
+Für ein Merkmal existiert je unterstütztem Backend höchstens ein Blueprint.
+
+Beispiel:
+
+| Merkmal | Backend | Blueprint |
+|---|---|---|
+| browser-brave | fedora | Ansible-Rolle „brave-fedora" (dnf, Brave-Repository) |
+| browser-brave | mint | Ansible-Rolle „brave-mint" (apt, Brave-Repository) |
+| guest-session-ephemeral | fedora | Ansible-Rolle „guest-session" (tmpfs-Home, PAM) |
+| guest-session-ephemeral | mint | Ansible-Rolle „guest-session" (tmpfs-Home, PAM) |
+
+Ein Blueprint kann von mehreren Backends wiederverwendet werden, wenn die Umsetzung identisch ist.
+
+### Runtime Blueprint
+
+Das Runtime Blueprint einer konkreten Installation entsteht, indem für jedes Merkmal des gewählten Workspace der zum gewählten Backend passende Blueprint aufgelöst wird.
+
+Die Sammlung aller aufgelösten Blueprints wird nach dem ersten Start über den bestehenden Ansible-Pull-Mechanismus angewendet.
+
+---
+
+## Abgrenzung zu installationszeitlichen Vorgaben
+
+Partitionierung, Festplattenverschlüsselung, Secure-Boot- und TPM-Bindung sowie weitere zur Installationszeit unveränderliche Eigenschaften sind kein Bestandteil eines Blueprints.
+
+Sie werden als direkte Vorgabe der gewählten Bereitstellungsvorlage an `backend_generate_config()` übergeben und fließen unmittelbar in die native Installationskonfiguration ein (siehe `06-backend-api.md`, `08-provisioning-api.md`).
+
+Blueprints setzen ausschließlich userspace-seitige Merkmale um, die nach der Installation angewendet werden können, ohne die Partitionierung oder die native Installationskonfiguration zu verändern.
+
+---
+
+## Erweiterbarkeit
+
+Neue Merkmale erfordern Blueprints für jedes bereits unterstützte Backend.
+
+Neue Backends erfordern Blueprints für jedes bereits bestehende Merkmal.
+
+Workspace- und Merkmal-Definitionen bleiben davon unberührt.
+
+---
+
+## Beispiel
+
+### Workspace: Schulcomputer
+
+Merkmale:
+
+- guest-session-ephemeral
+- browser-brave
+- office-onlyoffice
+
+### Workspace: Entwickler
+
+Merkmale:
+
+- Programmiersprachen
+- Virtualisierung
+- Editoren
+- Entwicklungsumgebungen
+
+### Unterstützte Backends
+
+- Fedora
+- Linux Mint
+
+---
+
+## Zusammenfassung
+
+Ein Workspace besteht aus Merkmalen.
+
+Ein Blueprint setzt genau ein Merkmal für genau ein Backend um, in der Regel als Ansible-Rolle.
+
+Das Runtime Blueprint einer konkreten Installation entsteht aus der Auflösung aller Merkmale des gewählten Workspace gegen das gewählte Backend.
+
+Installationszeitliche Vorgaben wie Partitionierung und Verschlüsselung bleiben ein direkter Kanal der Bereitstellungsvorlage und sind kein Bestandteil eines Blueprints.

architecture/13-live-provisioning-boot.md

@@ -0,0 +1,110 @@
+# Live-Provisionierung und Boot-Modi
+
+**Status:** Beschlossen
+**Datum:** 18.07.2026
+
+## Zweck dieses Dokuments
+
+Dieses Dokument beschreibt, wie die Provisionierungs-ISO bootet, wie der automatisierte und der interaktive Ablauf sich unterscheiden, und wie der native Installer aus der Live-Umgebung heraus gestartet wird.
+
+Es ergänzt `10-interactive-provisioning-flow.md` (F-005), das den interaktiven Ablauf selbst beschreibt, um die Boot-Ebene davor.
+
+Siehe `ADR-0003` für die Entscheidung und ihre Begründung.
+
+---
+
+## Ausgangslage
+
+Die bisherige ISO basiert auf einer Fedora-DVD/Netinst-Struktur ohne Live-Umgebung. GRUB startet Anaconda direkt, mit einer über `inst.ks=` fest verdrahteten Kickstart-URL. Der gesamte in F-005 beschriebene Ablauf hat darauf keinen Einstiegspunkt.
+
+Die neue ISO basiert stattdessen auf einem echten Live-Medium (erkennbar an `/LiveOS/squashfs.img`). `scripts/installer.sh` läuft als gewöhnliche Anwendung innerhalb dieser Live-Sitzung, mit vollem Zugriff auf Netzwerk (NetworkManager, WLAN), Bildschirm und Tastatur.
+
+---
+
+## Boot-Ablauf
+
+```text
+Boot
+ ↓
+GRUB-Menü (Countdown)
+ ├── Zeitüberschreitung oder Standardeintrag
+ │     ↓
+ │   Live-Umgebung startet mit tuxflotte.mode=auto
+ │
+ └── manuelle Auswahl des zweiten Eintrags
+       ↓
+     Live-Umgebung startet mit tuxflotte.mode=interactive
+ ↓
+installer.sh liest tuxflotte.mode
+ ↓
+Netzwerk, Hardware, Aktivierung (wie bisher, "always"-Module)
+ ↓
+Moduswahl
+ ├── auto
+ │     ↓
+ │   device.registration_status prüfen
+ │     ├── existing    → Bereitstellungsvorlage automatisch wählen (is_default), Commit Point automatisch bestätigen
+ │     └── registered  → Fail-Closed-Abbruch, Verweis auf interaktiven Ablauf
+ │
+ └── interactive
+       ↓
+     bisheriger F-005-Ablauf (Bereitstellungsvorlage-Auswahl, explizite Bestätigung)
+ ↓
+Runtime Blueprint erzeugen → Backend laden → backend_generate_config()
+ ↓
+backend_launch() startet den nativen Installer explizit aus der Live-Sitzung heraus
+```
+
+Beide Moduspfade laufen ab „Runtime Blueprint erzeugen" identisch weiter. Der Unterschied liegt ausschließlich davor: in der Frage, ob eine Bereitstellungsvorlage interaktiv gewählt und der Commit Point interaktiv bestätigt wird, oder ob beides automatisch anhand vorhandener Daten geschieht.
+
+---
+
+## 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.
+
+Voraussetzung für den automatisierten Ablauf ist ausschließlich:
+
+`device.registration_status == "existing"` in der Antwort von `POST /api/v1/activate`.
+
+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.
+
+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.
+
+---
+
+## Konsequenz für die Geräteregistrierung
+
+Wer ein Gerät registriert, akzeptiert damit, dass dieses Gerät künftig ohne erneute interaktive Rückfrage automatisiert neu installiert werden kann, solange es über seinen Hardware-Fingerprint als bereits registriert erkannt wird.
+
+Dies wird bei der Geräteregistrierung ausdrücklich kommuniziert (siehe `11-device-enrollment.md`).
+
+---
+
+## Nativer Installer aus der Live-Sitzung
+
+Der native Installer wird nicht mehr über einen boot-zeitlichen Parameter gestartet.
+
+Stattdessen ruft `backend_launch()` (siehe `06-backend-api.md`) den nativen Installer explizit auf, mit der zuvor von `backend_generate_config()` erzeugten, lokal vorliegenden Konfiguration.
+
+Die statische Kickstart-Datei sowie ihr Server-Endpoint (`GET /installers/fedora-workstation/ks.cfg`) entfallen damit.
+
+---
+
+## WLAN-Zugangsdaten
+
+Zwei getrennte Anwendungsfälle:
+
+**WLAN für die Live-Provisionierungsumgebung.** Ohne Netzwerk ist der Provisioning-Server nicht erreichbar. Zugangsdaten für dieses Netzwerk müssen deshalb bereits im ISO-Build hinterlegt sein (zum Beispiel als NetworkManager-Verbindungsprofil in einem organisationsspezifischen ISO-Build), nicht dynamisch vom Server geladen werden.
+
+**WLAN für das installierte Zielsystem.** Dies ist eine dauerhafte, organisationsweite Vorgabe und gehört zum noch unspezifizierten `Network Profile`-Modell der Organization (siehe `09-data-model-v1.md`). Die Anwendung erfolgt wie andere organisationsweite Vorgaben, nicht als Teil der Provisionierungs-Bootphase.
+
+---
+
+## Zusammenfassung
+
+Die Live-ISO ersetzt das direkte Booten in Anaconda durch eine vorgeschaltete, frei gestaltbare Live-Sitzung, in der `installer.sh` läuft.
+
+Ein Bootmenü mit Countdown unterscheidet zwischen automatisiertem und interaktivem Ablauf; beide münden ab der Runtime-Blueprint-Erzeugung in denselben Codepfad.
+
+Automatisierung ersetzt keine Sicherheitsprüfung, sondern bindet die Bestätigung an eine bereits bestehende, geprüfte Gerätezuordnung statt an eine Benutzereingabe.

roadmap/installer-roadmap.md

@@ -65,6 +65,8 @@ Ziel: Vollständiger Einstieg in die Provisioning-Plattform.
 
 ## Langfristige Vision
 
+**Hinweis:** Der Kerngedanke dieser Vision – Distributionspakete werden nicht auf dem Medium mitgeführt, sondern je Installation aus dem Netz gezogen – bleibt mit `ADR-0003` unverändert bestehen. Für den interaktiven, gebrandeten Ablauf wurde dort jedoch bewusst ein volles Live-Medium statt eines minimalen Boot-Mediums gewählt (siehe `architecture/13-live-provisioning-boot.md`); das Medium selbst wird dadurch größer, nicht die mitgeführten Installationsdaten der Distribution. Dieser größere Fußabdruck wird für die damit gewonnenen UX-Möglichkeiten bewusst in Kauf genommen.
+
 Der Installer soll kein klassisches Installationsmedium sein.
 
 Langfristig enthält er nur noch die Komponenten, die zum Starten eines Geräts erforderlich sind (Bootloader, Kernel, initrd). Alle weiteren Daten werden über den Provisioning Server bereitgestellt.

roadmap/milestones.md

@@ -32,5 +32,5 @@ Verified components:
 
 Result:
 
-The core architecture of the Stallinux Provisioning Platform has been validated end-to-end.
+The core architecture of the Tuxflotte Provisioning Platform has been validated end-to-end.