# 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.