XinionOS wird ein eigener Strang — eigene Organisation, eigener Bereich

CIO-Beschluss vom 19.09.2026. XinionOS ist die Grundlage kuenftiger Appliance-Ideen und nicht
der Unterbau eines einzelnen Produkts. Eine Geraeteschicht, die entlang der Beduerfnisse
EINER Nutzlast entsteht, passt der zweiten nicht — genau dieser Fehler hat den ersten Anlauf
von XinionONE gekostet, dort eine Ebene hoeher.

Zwei Abnehmer stehen fest, XinionONE und GAIA. Und die Regulierung trennt sie ohnehin: Anhang
III Klasse I gegen Netzmanagementsystem, zwei Konformitaetswege.

Die Grenze, an der die Entkopplung haengt: Eine Anforderung ist ein Bedarf, keine Loesung.
Und das Anforderungsregister gehoert diesem Strang, nicht den Abnehmern — sonst muesste
XinionOS zwei Kundendokumente lesen, um zu wissen was erwartet wird.

Hier gilt mehr von der alten Arbeit weiter als bei XinionONE: Die sieben Entscheidungen
stammen aus Physik und Feld, nicht aus dem verworfenen Produktbild. Zu pruefen ist nur, wo
eine Entscheidung XinionONE beim Namen nennt — solche Stellen werden zu Anforderungen eines
Abnehmers umformuliert, nicht gestrichen.

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

BRIEFING.md

@@ -1,3 +1,19 @@
+> **Neu hier? Lies zuerst [`START.md`](START.md)** — zwei Minuten Kurzeinstieg. Diese Datei ist der
+> vollständige Auftrag.
+
+> **Stand 31.08.2026 — was sich an der Arbeitsteilung geändert hat:**
+>
+> Diese Ablage wird von der Instanz **`xinionos-dev`** bearbeitet. Abgestimmt wird über das Forgejo
+> unter `172.16.10.10:2222` — Tickets in der betroffenen Ablage, Übergaben in
+> `workbench/handovers/`. Es gibt keinen direkten Draht zwischen den Instanzen.
+>
+> **Entwickelt wird in zwei VMs** (angefordert als `infra#7`): eine Bau-VM für den Abbildbau, eine
+> Prüf-VM mit UEFI und virtuellem TPM 2.0 für A/B, Bootzähler, Selbstprüflauf und Rücksprung.
+>
+> **Die Abnahme auf Blech führt der CIO durch**, auf separater Hardware. Daraus folgt die schärfste
+> Regel dieses Auftrags: **Was in der Prüf-VM läuft, ist nie ein Nachweis über ein Gerät.** Melde
+> *„die Mechanik greift in der VM"* — niemals *„der Rücksprung funktioniert"*.
+
 # Briefing — XinionOS
 
 > Für die Entwicklungsumgebung und für einen neu hinzukommenden Entwickler.
@@ -57,7 +73,7 @@ noch eine Unit gestartet werden kann. **Behandle ihn als Bauplan, nicht als Zust
 ## Was Du nicht tust
 
 * **Keine Architekturentscheidung treffen, keine ADR schreiben.** Melde zurück.
-* **Keinen Produktnamen aufnehmen.** Weder NEXTgenIT noch OLYMPUS noch sonst einen — siehe Regel 1
+* **Keinen Produktnamen aufnehmen.** Weder XinionONE noch NEXTgenIT noch OLYMPUS noch sonst einen — siehe Regel 1
   in `CLAUDE.md`.
 * **Keine Abhängigkeit ohne Begründung im Commit-Text.** Jede steht fünf Jahre in der Stückliste.
 * **Keine Zahl erfinden und keine glätten.**

CLAUDE.md

@@ -11,7 +11,7 @@ Wurzeln, Selbstprüflauf, Rücksprung, Statusseite. **Sonst nichts.**
 
 ### 1 · Das Betriebssystem kennt kein Produkt
 
-Nirgends in dieser Ablage steht der Name eines Produkts — kein NEXTgenIT, kein OLYMPUS, kein
+Nirgends in dieser Ablage steht der Name eines Produkts — kein XinionONE, kein NEXTgenIT, kein OLYMPUS, kein
 COSMOS, keine Fachlichkeit. Was ein Produkt braucht, bekommt es über den
 [Nutzlast-Vertrag](nutzlast/VERTRAG.md).
 

ENTKOPPLUNG.md

@@ -0,0 +1,68 @@
+# XinionOS ist ein eigener Strang — was das heißt
+
+**Beschlossen am 19.09.2026 vom CIO.** XinionOS hat seit diesem Tag eine eigene Organisation im Git
+und einen eigenen Bereich in Confluence. Es ist nicht mehr Teil des Vorhabens XinionONE, sondern
+dessen **Lieferant**.
+
+## Warum
+
+**XinionOS ist die Grundlage künftiger Appliance-Ideen, nicht der Unterbau eines einzelnen
+Produkts.** Eine Geräteschicht, die entlang der Bedürfnisse *einer* Nutzlast entsteht, passt der
+zweiten nicht — und genau dieser Fehler hat den ersten Anlauf von XinionONE gekostet, dort eine
+Ebene höher.
+
+**Zwei Abnehmer stehen bereits fest:** XinionONE und GAIA. Das ist keine Plattform mit einem Kunden,
+die so tut, als hätte sie mehrere.
+
+**Und die Regulierung trennt sie ohnehin.** XinionOS fällt als Betriebssystem unter Anhang III
+Klasse I der Verordnung (EU) 2024/2847, XinionONE voraussichtlich als Netzmanagementsystem — zwei
+Konformitätswege, zwei Stücklisten, zwei Unterstützungszeiträume. Gekoppelt wäre das eine
+Vermischung, die spätestens beim ersten Audit auffällt.
+
+## Die Grenze, an der es hängt
+
+> **Eine Anforderung ist ein Bedarf, keine Lösung.**
+
+| ❌ So nicht | ✅ So |
+|---|---|
+| *„Verwendet systemd-boot mit diesen Registern"* | *„Das Gerät kehrt nach einem fehlgeschlagenen Update ohne anwesenden Menschen auf den vorigen Stand zurück"* |
+
+Das Erste ist eine Entscheidung vom Stuhl des Abnehmers aus. Das Zweite ist ein Bedarf, den XinionOS
+erfüllen kann, wie es für richtig hält.
+
+**Das Anforderungsregister gehört diesem Strang, nicht den Abnehmern** — mit einer Spalte, wer
+fordert. Sonst müsste XinionOS zwei Kundendokumente lesen, um zu wissen, was erwartet wird, und bei
+einem dritten drei.
+
+## Was von der alten Arbeit gilt
+
+Diese Ablage ist am 19.09.2026 aus dem Archiv zurückgeholt worden: 13 Commits, sieben
+Architekturentscheidungen, der Abbildbau.
+
+**Und hier gilt mehr weiter als anderswo.** Am 13.09.2026 wurde bei XinionONE die grüne Wiese
+ausgerufen, weil das Produktbild falsch war. **Die Entscheidungen von XinionOS stammen nicht aus
+diesem Bild, sondern aus Physik und Feld:**
+
+> *Ein Gerät, das beim Kunden im Rack steht und nach einem Update nicht mehr hochkommt, ist ein
+> Vor-Ort-Einsatz — bei zweihundert Geräten zweihundert davon.*
+
+A/B-Wurzel, Rücksprung, Verschlüsselung, kein Auslagerungsspeicher, der Installationsdialog, der
+Konsolenbereich: Das gilt unverändert, gleich welche Nutzlast darauf läuft. **Eine der sieben
+beschreibt sogar genau diese Entkopplung** — eine Laufzeitschicht für alle Nutzlasten, GAIA als
+Profil darauf.
+
+**Zu prüfen ist nur, wo eine Entscheidung XinionONE beim Namen nennt.** Solche Stellen werden zu
+Anforderungen eines Abnehmers umformuliert, nicht gestrichen.
+
+## Was offen ist
+
+* **Das Konzept** entsteht im eigenen Confluence-Bereich, nicht als Abschnitt eines fremden.
+* **Wer entscheidet, wenn zwei Abnehmer sich widersprechen.** Heute der CIO — es gehört
+  hingeschrieben, denn das bricht als Erstes, sobald ein Termin auftaucht.
+* **Wer daran arbeitet.** Der Arbeitsplatz steht seit dem 02.09.2026 bereit und wurde nie benutzt.
+  **Entkopplung schafft keine Kapazität.**
+
+---
+
+*Angelegt am 19.09.2026 beim Umzug in die eigene Organisation. Wiederhergestellt aus
+`XinionONE/archive`, Bündel `xinionos.bundle`.*

README.md

@@ -13,9 +13,9 @@ etwas zu wissen.
 | Ebene | Was | Beispiele |
 |---|---|---|
 | Anwendungen | Fachliche Produkte | COSMOS, INSIGHT, ORION |
-| Plattform | Laufzeit- und Betriebsschicht | OLYMPUS · oder die Wirt-Dienste einer Fach-Appliance |
+| Plattform | Laufzeit- und Betriebsschicht | OLYMPUS mit GAIA Lite · oder die Wirt-Dienste einer Fach-Appliance |
 | **Gerät** | **XinionOS** | **diese Ablage** |
-| Infrastruktur | Rechenzentrum | GAIA |
+| Infrastruktur | Rechenzentrum | GAIA Full |
 
 Beim Kunden auf Blech ist XinionOS das, worauf die Verkaufsvariante der Plattform läuft.
 

START.md

@@ -0,0 +1,91 @@
+# Start — für `xinionos-dev`
+
+**Kurzfassung, damit Du weißt, worauf Du Dich einlässt.** Zwei Minuten; der vollständige Auftrag
+steht daneben in [`BRIEFING.md`](BRIEFING.md).
+
+> **Kennst Du XinionONE noch nicht?** Dann lies zuerst `workbench/UEBERBLICK.md` — dort steht der
+> Zusammenhang ohne Vorwissen. Zwanzig Minuten, und danach passt alles Weitere zusammen.
+
+## Worum es geht
+
+**XinionOS ist die Geräteschicht** unter allen Xinion-Produkten, die beim Kunden als Gerät stehen.
+Es liefert ein Gerät, das startet, sich selbst prüft, sich sicher aktualisieren lässt und **im
+Fehlerfall von allein auf die vorherige Fassung zurückkehrt** — und sonst nichts.
+
+**Es weiß nicht, was auf ihm läuft.** Das ist keine Sparsamkeit, sondern der Zweck: Dieselbe Basis
+trägt eine ITSM-Appliance, eine Proxy-Appliance und eine Anwendungsplattform, ohne von einer davon
+etwas zu wissen. Was eine Nutzlast dafür liefern muss, steht in
+[`nutzlast/VERTRAG.md`](nutzlast/VERTRAG.md).
+
+## Die eine Eigenschaft, um die es geht
+
+> Fällt der Selbstprüflauf auf einer Wurzel durch, kehrt das Gerät nach drei Startversuchen **von
+> selbst** auf die andere zurück — und man kann hinterher nachlesen, warum.
+
+**Ein Gerät, das beim Kunden im Rack steht und nach einer Aktualisierung nicht mehr hochkommt, ist
+ein Vor-Ort-Einsatz.** Bei zweihundert Geräten zweihundert davon. Diese eine Eigenschaft ist der
+Grund, warum XinionOS überhaupt ein eigenes Erzeugnis ist.
+
+## Wer sonst da ist
+
+| | Wer | Was |
+|---|---|---|
+| `architect` | Architektur | Der Schnitt: Ebenen, Verträge, ADRs. Schreibt keinen Abbildbau |
+| `vulcan-dev` | Umgebung | Der k3s-Cluster von Xinion. **Baut XinionOS nicht** — es läuft intern gar nicht |
+| **`xinionos-dev`** | **Du** | Abbild, A/B-Wurzeln, Selbstprüflauf, Rücksprung, Verschlüsselung |
+
+**Wir sehen einander nicht** — getrennte Sitzungen, getrennte Maschinen. Der Kanal ist das Forgejo:
+Tickets in der betroffenen Ablage, Übergaben in `workbench/handovers/`. **Was nicht in einer Ablage
+steht, existiert für die anderen nicht.**
+
+## Deine ersten Schritte
+
+**1 · Ablagen holen und lesen.**
+
+```bash
+git clone ssh://git@172.16.10.10:2222/XinionONE/xinionos.git
+git clone ssh://git@172.16.10.10:2222/XinionONE/workbench.git
+```
+
+`BRIEFING.md` — Dein Auftrag · `docs/decisions/` — sechs ADRs, die den Rahmen setzen ·
+`workbench/handovers/architect.md` — Stand und Fallen.
+
+**2 · Dich melden.** `workbench/handovers/xinionos-dev.md` nach der Vorlage anlegen und pushen.
+Solange die Datei nicht liegt, weiß niemand, dass Du angefangen hast.
+
+**3 · Das Abbild einmal bauen.** `abbild/bauen.sh` steht, ist aber nie gelaufen. **Der erste Befund
+ist wertvoller als der erste Entwurf.**
+
+## Was Du hast und was nicht
+
+**Zwei Maschinen** *(bei `vulcan-dev` angefordert, Ticket `infra#7`)*: eine **Bau-VM** für den
+Abbildbau, und eine **Prüf-VM** mit UEFI und **virtuellem TPM 2.0**, auf der A/B-Umschaltung,
+Bootzähler, Selbstprüflauf und Rücksprung entwickelt und wiederholt geprüft werden.
+
+**Ein Prüfgerät auf Blech gibt es nicht bei Dir.** Der CIO stellt es aus separater Hardware und
+führt die Abnahme selbst durch — **ein Abbild aufs Blech bringen, den Stecker ziehen, den Startpfad
+ansehen ist körperliche Arbeit.**
+
+> **Daraus folgt die wichtigste Regel für Dich:**
+>
+> **Was in der Prüf-VM läuft, ist niemals ein Nachweis über ein Gerät.** Ein virtuelles TPM schützt
+> nur so gut, wie der Wirt seine Zustandsdatei schützt; eine hart abgeschaltete VM ist nicht
+> dasselbe wie ein gezogenes Netzteil. **Melde „die Mechanik greift in der VM" — nie „der Rücksprung
+> funktioniert".** Der zweite Satz gehört dem CIO nach der Abnahme auf Blech.
+
+## Vier Dinge, die hier anders sind
+
+**Belegt ist nur, was gelaufen ist** — mit **Gerät und Messtag**. Ein Text, der aussieht, als sei er
+erprobt, ist hier schlimmer als gar kein Text.
+
+**Ein Befund ist kein Auftrag zum Umplanen.** Trägt eine Entscheidung nicht, melde es. Ein Skript,
+das klemmt, reparierst Du.
+
+**Kein Produktname in dieser Ablage.** Weder XinionONE noch OLYMPUS noch sonst einer — XinionOS
+weiß nicht, was auf ihm läuft, und das gilt auch für seinen Programmtext.
+
+**Nach drei Runden ohne Ergebnis entscheidet der CIO.** Keine vierte.
+
+---
+
+*Jetzt [`BRIEFING.md`](BRIEFING.md) lesen.*

docs/decisions/ADR-0003-verschluesselung-und-loeschung.md

@@ -171,3 +171,62 @@ Flash-Speichern ist er langsam und gibt eine Sicherheit vor, die er nicht hat.
 verlegt die Entsperrung in den Startvorgang **vor** den Selbstprüflauf — womit ein Fehler dort das
 Gerät unrettbar macht, statt einen Rücksprung auszulösen. Der Rückweg ist mehr wert als die
 Verschlüsselung von Dateien, die auf jedem Gerät gleich sind.
+
+---
+
+## Nachtrag 02.09.2026 — kein Auslagerungsspeicher, und das ist eine Anforderung
+
+Beim Bau des Tresors als Pod ist eine Bedingung sichtbar geworden, die diese Entscheidung bisher
+nicht kannte und die genau ihr Schutzziel betrifft.
+
+**Der Tresor läuft mit abgeschaltetem Speicherfestnageln** (`disable_mlock`). In einem Behälter ist
+das praktisch unvermeidlich — das Festnageln verlangt ein Recht, das ein Pod im Regelfall nicht
+bekommt — und mit dem eingebauten Speicher auch vertretbar. **Es hat aber eine Bedingung:**
+
+> Ohne Festnageln darf der Arbeitsspeicher des Tresors **auf die Platte ausgelagert** werden. Das
+> ist genau der Speicher, in dem die **entschlüsselten** Zugangsdaten aller Zielsysteme des Kunden
+> stehen.
+
+**Damit entstünde eine zweite, unbewachte Kopie der Geheimnisse** — außerhalb des Tresors, außerhalb
+seiner Richtlinien, außerhalb der Prüfspur. Sie überlebt das Herunterfahren, und ihre Vernichtung
+wäre von keiner der Regeln oben erfasst.
+
+### Die Festlegung
+
+> **Ein Xinion-Gerät hat keinen Auslagerungsspeicher. Das Abbild legt keinen an, und die
+> Installation bietet ihn nicht an.**
+
+Das ist keine Empfehlung und kein Feinschliff, sondern die Bedingung, unter der der abgeschaltete
+Speicherfestnagel überhaupt vertretbar ist.
+
+### Warum es hierher gehört und nicht in die Nutzlast
+
+**Die Nutzlast kann es nicht durchsetzen.** Ein Pod bestimmt nicht, ob sein Wirt auslagert — das
+entscheidet die Geräteschicht, und zwar beim Bau des Abbilds. **Eine Anforderung, die nur die
+Nutzlast kennt, aber nur der Wirt erfüllen kann, ist genau die Art Lücke, die niemandem auffällt.**
+
+### Was es kostet, und warum der Preis gering ist
+
+**Ohne Auslagerung ist ein Speicherüberlauf ein harter Abbruch** statt einer Verlangsamung. Das
+klingt schlechter, als es ist: Ein Gerät, das wegen Auslagerung zäh wird, sieht wie ein
+Leistungsproblem aus und wird tagelang gesucht. **Ein abgebrochener Pod startet neu und steht im
+Protokoll.**
+
+Die Auslegung nach Baugrößen macht die Rechnung ohnehin nicht auf Auslagerung auf — die
+Speicherbudgets der Pods kommen aus der Konfiguration und sind zuzuteilen, nicht zu verdrängen.
+
+### Zwei Punkte, die daran hängen
+
+**Der Ruhezustand des Systems** (Suspend-to-Disk) schreibt denselben Speicher auf dieselbe Platte
+und ist damit aus demselben Grund ausgeschlossen. Er ist auf einem Rack-Gerät ohnehin sinnlos.
+
+**Ein Absturzabbild des Kerns** enthält ebenfalls Arbeitsspeicher. Ob und wohin eines geschrieben
+wird, ist **offen** und gehört mit derselben Überlegung entschieden — es berührt zugleich den Inhalt
+des Diagnosepakets aus `ADR-0007`.
+
+---
+
+*Nachgetragen 02.09.2026 · Anlass: `disable_mlock` im Tresor-Pod, aufgefallen bei der Durchsicht der
+Aufbauten in `XinionONE/infra` · **Die Wirkung ist nicht gemessen** — dass ein Gerät ohne
+Auslagerungsspeicher unter Last sauber abbricht statt zu verklemmen, gehört auf dem Prüfgerät
+gezeigt.*

docs/decisions/ADR-0004-abbild-bleibt-klein.md

@@ -0,0 +1,78 @@
+# ADR-0004 — Das Abbild bleibt klein: Modelle und Wissen sind Daten, kein Abbildinhalt
+
+**Stand:** Angenommen, 20.08.2026 · **Entscheidet:** CIO Thomas Reitz
+**Berührt:** `appliance/ADR-0004` — dessen Begründung stammt aus der Zeit, als Betriebssystem und
+Appliance ein Erzeugnis waren
+
+---
+
+## Worum es geht
+
+Ein Abbild wird heruntergeladen, auf einen Stick geschrieben, über eine Fernwartung eingebunden und
+gelegentlich per Post verschickt. **Jedes Gigabyte kostet an jeder dieser Stellen.** Ein Abbild von
+zwei Gigabyte ist ein Werkzeug; eines von hundert ist ein Problem.
+
+Dazu kommt der Grund, der schwerer wiegt: **Was im Abbild liegt, liegt zweimal auf der Platte** —
+einmal je Wurzel. Und es steht in der Stückliste, die nach dem Cyber Resilience Act über die
+Produktlebensdauer zu versorgen ist.
+
+## Die Entscheidung
+
+**In das Abbild kommt das Betriebssystem und die Software der Nutzlast. Sonst nichts.**
+
+| Was | Wo | Warum |
+|---|---|---|
+| Betriebssystem, Selbstprüflauf, Konsolenmenü, Basisoberfläche | **Abbild → Wurzel** | Wird beim Fassungswechsel getauscht und beim Rücksprung zurückgenommen |
+| Software der Nutzlast — Dienste, Units | **Abbild → Wurzel** | Dasselbe. Eine Fassung, ein Rückweg |
+| **Sprachmodelle** | **Bestandsbereich** | Daten, keine Software. Groß, eigener Lebenszyklus |
+| **Wissensspeicher, Grundausstattung** | **Bestandsbereich** | Ebenso, mit eigener Fassungsführung |
+| Datenbank, Vektorindex, Tresor, Protokolle | **Bestandsbereich** | Zustand des Kunden |
+
+**Richtwert für das Abbild: unter drei Gigabyte.** Wird es größer, ist etwas hineingeraten, das
+dort nicht hingehört — die Frage lautet dann nicht „wie komprimieren wir", sondern „warum ist das
+im Abbild".
+
+## Der Widerspruch, der aufzulösen war
+
+`appliance/ADR-0004` hält ausdrücklich fest, die Sprachmodelle seien **im Abbild mitgeliefert** —
+„sonst wäre die Ersteinrichtung ein Transfer von über 100 GB". Das war richtig gedacht, solange
+Betriebssystem und Appliance **ein** Erzeugnis waren.
+
+Die Sorge dahinter bleibt berechtigt: Niemand will bei der Inbetriebnahme hundert Gigabyte über die
+Leitung des Kunden ziehen. Sie wird nur anders gelöst.
+
+> **Das Abbild ist klein, das ausgelieferte Gerät ist voll.**
+>
+> Modelle und Grundausstattung werden **im Werk auf den Bestandsbereich gelegt**, bevor das Gerät
+> das Haus verlässt. Der Kunde bekommt ein fertiges Gerät, kein Abbild mit einem Anhang.
+
+Und der Fall, der dabei zuerst Sorge macht, löst sich von selbst: **Eine Neuinstallation aus dem
+Abbild fasst den Bestandsbereich nicht an.** Sie beschreibt die Wurzeln. Modelle und Wissen
+überstehen sie — genau wie sie einen Fassungswechsel überstehen.
+
+Ein Transfer über die Leitung ist damit nur in einem einzigen Fall nötig: bei einem **fabrikneuen,
+leeren** Gerät. Und das ist der Fall, den das Werk erledigt.
+
+## Was daraus folgt
+
+**Das Abbild taugt zur Wiederherstellung, nicht zur Erstausstattung.** Wer ein Gerät neu aufsetzt,
+bekommt ein arbeitsfähiges Betriebssystem — aber die Fachlichkeit hängt an dem, was im
+Bestandsbereich liegt. Das gehört so in die Anleitung, sonst wundert sich jemand.
+
+**Es braucht einen Weg, Modelle und Wissen nachzuladen.** Für den Werkslauf, für ein Gerät, dessen
+Bestandsbereich sicher gelöscht wurde, und für den Wechsel auf ein neues Modell. Dieser Weg ist der
+**CORE-Server** — eigenes Konzept, hier nur benannt.
+
+**Und die Regel gegen Abhängigkeiten wird schärfer.** Sie galt bisher der Versorgungspflicht; jetzt
+gilt sie zusätzlich der Größe. Beides zeigt in dieselbe Richtung: **Was nicht im Abbild ist, muss
+nicht gepflegt, nicht ausgeliefert und nicht zweimal gespeichert werden.**
+
+## Die verworfene Alternative
+
+**Alles ins Abbild.** Ein Erzeugnis, ein Download, keine Nachladeschritte — und der Rücksprung
+umfasst dann auch die Modelle, was auf den ersten Blick sauberer wirkt.
+
+Dagegen stehen drei Dinge. Das Abbild läge **zweimal** auf der Platte, also zweihundert Gigabyte
+für zwei Fassungen. Jeder Modellwechsel wäre ein vollständiger Abbildwechsel samt Neustart, obwohl
+sich nichts am Betriebssystem geändert hat. Und ein Abbild dieser Größe ist über eine Fernwartung
+praktisch nicht einzuspielen — genau dann, wenn man es am dringendsten braucht.

docs/decisions/ADR-0005-geraeteschicht-aller-verkaufsvarianten.md

@@ -0,0 +1,123 @@
+# ADR-0005 — XinionOS ist die Geräteschicht aller Verkaufsvarianten; GAIA Lite wird Nutzlast
+
+**Stand:** Angenommen, 21.08.2026 · **Entscheidet:** CIO Thomas Reitz
+**Berührt:** `Projekt OLYMPUS` — dessen Schichtenmodell führt GAIA Lite als Layer 2 der
+Verkaufsvariante. Diese Rolle geht auf XinionOS über.
+
+---
+
+## Worum es geht
+
+Zwei Vorhaben im Haus liefern ein Gerät an einen Kunden aus, und beide haben sich unabhängig
+voneinander dieselbe Schicht gebaut.
+
+**OLYMPUS** beschreibt seine Verkaufsvariante als ISO auf Kundenhardware: GAIA Lite als Unterbau,
+k3s mit CORE- und WRK-Rollen, Bootstrapping über eine Deployment-Weboberfläche, Single-Tenant.
+**XinionOS** beschreibt genau dasselbe: ein Abbild, das installiert wird, sich selbst prüft, sich
+aktualisieren lässt und im Fehlerfall zurückspringt — mit Konsolenmenü, Einrichtungsassistent und
+Basisoberfläche.
+
+Nebeneinander gelesen ist das **zweimal dasselbe Gerüst**: ISO-Auslieferung, Installation,
+Ersteinrichtung über eine Weboberfläche, Aktualisierung, Geräteverwaltung. Der Unterschied liegt
+nicht in der Aufgabe, sondern darin, dass zwei Vorhaben sie zu verschiedenen Zeitpunkten für sich
+gelöst haben.
+
+## Die Entscheidung
+
+**XinionOS ist die Geräteschicht jedes Xinion-Erzeugnisses, das beim Kunden als Gerät steht.
+GAIA Lite hört auf, ein Auslieferungsweg zu sein, und wird zu einer Nutzlast auf XinionOS.**
+
+Damit ersetzt XinionOS **nicht OLYMPUS**, sondern genau den Teil, den OLYMPUS nach unten
+weggeschnitten hatte, ohne dass es dafür einen Träger gab.
+
+| Aufgabe | Bisher | Künftig |
+|---|---|---|
+| ISO bauen und ausliefern | GAIA Lite | **XinionOS** |
+| Installation am Blech | GAIA Lite | **XinionOS** (Stufe 0) |
+| Ersteinrichtung über Weboberfläche | Deployment-WebUI | **XinionOS** (Stufe 2) |
+| Notfallzugang ohne Netz | fehlte | **XinionOS** (Konsolenmenü, Stufe 1) |
+| Fassungswechsel und Rücksprung | offen | **XinionOS** (A/B-Wurzel, Selbstprüflauf) |
+| Verschlüsselung, sichere Löschung | offen | **XinionOS** (`ADR-0003`) |
+| k3s, PostgreSQL, Storage, Secrets, Ingress, IdP — der **Plattform-Vertrag** | GAIA Lite | **GAIA Lite, als Nutzlast** |
+| Shell, Auth, Mandantenfähigkeit, Registry, Gateway, Shared Services, Lizenzierung | OLYMPUS | **OLYMPUS, unverändert** |
+| Die Anwendungen | INSIGHT, COSMOS, ORION-WebUI | **unverändert** |
+
+**OLYMPUS und die Anwendungen merken davon nichts.** Sie konsumieren Layer 2 weiterhin
+ausschließlich über den Plattform-Vertrag; welcher Träger ihn erfüllt, ist genau die
+Austauschbarkeit, die OLYMPUS selbst festgeschrieben hat.
+
+## Warum
+
+**Der Cyber Resilience Act rechnet in Erzeugnissen, nicht in Vorhaben.** Zwei Basissysteme sind
+zwei Stücklisten, zwei Schwachstellenprozesse und zwei Versorgungszusagen über die
+Produktlebensdauer — für dieselbe Sache. Das ist die Begründung aus `ADR-0001`, jetzt angewandt auf
+einen konkreten zweiten Fall.
+
+**Der Rücksprung wird nur einmal richtig gebaut.** Er wird ausschließlich in dem Moment geprüft, in
+dem ihn jemand braucht. Eine zweite handgebaute Umsetzung wäre eine zweite ungeprüfte — und die
+fällt erst beim Kunden auf.
+
+**Das Konsolenmenü fehlte auf der anderen Seite ganz.** Eine Deployment-Weboberfläche setzt ein
+funktionierendes Netz und einen funktionierenden Webdienst voraus. Was passiert, wenn das Netz
+falsch konfiguriert ist, war nicht beantwortet. Die Notfalloberfläche muss den Ausfall dessen
+überleben, was sie verwaltet.
+
+**Und es ist keine neue Konstruktion, sondern das Einlösen einer vorhandenen.** Der
+Nutzlast-Vertrag ist genau dafür geschnitten; die XinionOS-Seite führt die OLYMPUS-Appliance seit
+dem 20.08.2026 als eine von vier Nutzlasten. Diese Entscheidung macht aus einer Absicht eine
+Festlegung.
+
+## Was daraus folgt
+
+* **GAIA Lite erfüllt den Nutzlast-Vertrag** — `selbstpruefung`, `nutzlast.target`, `kennung`,
+  optional `einrichten`. Der Selbstprüflauf von GAIA Lite entscheidet über den Rücksprung mit:
+  Ein k3s, das nicht hochkommt, ist ein misslungener Start und kein grünes Gerät.
+* **Ein ISO-Bauweg**, ein Abnahmetest, ein Ersatzteil im Regal.
+* **Die Deployment-WebUI von GAIA Lite entfällt** als eigener Baustein. Was von ihr fachlich
+  gebraucht wird, gehört in den Einrichtungsassistenten von XinionOS.
+* **Zwei Registries und zwei Lizenzmechaniken bleiben bestehen** — die von XinionONE für seine
+  Module, die von OLYMPUS für seine Anwendungen. Sie sehen sich ähnlich und liegen trotzdem in
+  verschiedenen Nutzlasten. **Sie werden nicht zusammengelegt**, solange nicht jemand nachweist,
+  dass sie dasselbe tun.
+
+## Die Auflage, die daraus folgt: Container-Abbilder gehören in die Wurzel
+
+*Nachgetragen am 21.08.2026, nachdem die Frage gestellt wurde, ob GAIA Lite und das Grundmodul der
+Appliance dieselbe Schicht sind. Sie sind es nicht — aber die Frage hat eine Lücke in dieser
+Entscheidung aufgedeckt.*
+
+`appliance/ADR-0005` hat für die Verpackung der Dienste festgehalten, was hier genauso gilt und
+oben fehlte: **Was nicht in der Wurzel liegt, nimmt der Rücksprung nicht mit.** Lägen die Dienste
+im Bestandsbereich, träfe nach einem Rücksprung eine alte Wurzel auf eine neue Anwendung.
+
+Für GAIA Lite als Nutzlast heißt das konkret:
+
+| Was | Wohin | Warum |
+|---|---|---|
+| k3s selbst, alle **Container-Abbilder**, Helm-Bündel, Manifeste | **Wurzel** | Software. Wird mitgetauscht und kommt beim Rücksprung von selbst zurück |
+| etcd beziehungsweise die Cluster-Datenbank, persistente Datenträger, Zustand der Anwendungen | **Bestand** | Zustand des Kunden. Überlebt den Fassungswechsel absichtlich |
+
+**Damit gilt für GAIA Lite dieselbe Schemaregel wie für jede andere Nutzlast** (`ADR-0004` der
+Appliance): Eine Fassung darf den Zustand nur so ändern, dass die Vorgängerfassung noch damit
+arbeiten kann. Ein Rücksprung, der auf einen fortgeschriebenen Cluster-Zustand trifft, ist kein
+Rückweg, sondern ein zweiter Ausfall.
+
+**Und es ist eine Abbildgrößen-Frage.** Nach `ADR-0004` bleibt das Abbild klein, weil alles zweimal
+auf der Platte liegt — einmal je Wurzel. Ein vollständiger Satz Container-Abbilder für Plattform
+und Anwendungen ist kein kleiner Posten. **Was GAIA Lite in die Wurzel legt, ist vor dem ersten
+Abbildbau zu beziffern**, nicht danach.
+
+## Was ausdrücklich nicht entschieden ist
+
+* **Ob GAIA Full ebenfalls auf XinionOS läuft.** Diese Entscheidung betrifft nur, was beim Kunden
+  als Gerät steht. Im eigenen Rechenzentrum bleibt alles, wie es ist.
+* **Wann der Umbau geschieht.** OLYMPUS ist Konzept, XinionOS ist Konzept — hier kollidieren zwei
+  Pläne, kein Bestand. Das ist der günstigste Zeitpunkt, den es dafür je geben wird.
+* **Der Name.** *CORE* bezeichnet bei OLYMPUS eine k3s-Rolle, bei XinionONE die Bezugsquelle, im
+  Namensschema zusätzlich das Grundmodul. Drei Dinge, ein Wort — zu entscheiden, aber nicht hier.
+
+---
+
+*Grundlage: Projekt OLYMPUS, Startseite vom 23.06.2026 (Schichtenmodell, Plattform-Vertrag, die
+zwei Ausprägungen) · XinionOS `ADR-0001` bis `ADR-0004` · `nutzlast/VERTRAG.md` ·
+Nichts davon ist gebaut — diese Entscheidung ordnet Pläne, sie beschreibt keinen Zustand.*

docs/decisions/ADR-0006-eine-laufzeitschicht-fuer-alle-nutzlasten.md

@@ -0,0 +1,74 @@
+# ADR-0006 — Eine Laufzeitschicht für alle Nutzlasten; GAIA Lite wird ein Profil darauf
+
+**Stand:** Angenommen, 21.08.2026 · **Entscheidet:** CIO Thomas Reitz
+**Setzt voraus:** [`ADR-0005`](ADR-0005-geraeteschicht-aller-verkaufsvarianten.md) (Geräteschicht aller Verkaufsvarianten)
+**Berührt:** `appliance/ADR-0014` — dort läuft alles oberhalb der Laufzeitschicht als Pod
+
+---
+
+## Worum es geht
+
+`ADR-0005` hat GAIA Lite von einem Auslieferungsweg zu einer **Nutzlast** auf XinionOS gemacht. Sie
+bringt dabei einen Plattform-Vertrag mit: k3s, containerd, Storage, Secrets, Ingress, dazu
+PostgreSQL, einen Identitätsanbieter und Beobachtungswerkzeuge für die Anwendungen von OLYMPUS.
+
+Wenige Tage später hat die Appliance dieselbe Entscheidung für sich getroffen: Auch dort läuft alles
+oberhalb der Laufzeitschicht als Pod auf k3s (`appliance/ADR-0014`).
+
+**Damit stünden auf einem Gerät zwei k3s** — eines aus GAIA Lite, eines aus der Appliance. Das ist
+kein Entwurf, sondern ein Versehen, das aus zwei getrennt getroffenen Entscheidungen entstanden ist.
+Genau derselbe Fall wie in `ADR-0005`, nur eine Schicht höher: **zwei Vorhaben haben sich unabhängig
+voneinander dieselbe Schicht gebaut.**
+
+## Die Entscheidung
+
+**Es gibt genau eine Laufzeitschicht je Gerät. Sie heißt `XinionCORE` und ist Ebene 2.**
+
+Sie enthält die Grundausstattung, die jede Nutzlast braucht: **k3s, containerd, Storage, Secrets,
+Ingress, GPU-Zuteilung.** Mehr nicht.
+
+**Der Plattform-Vertrag von GAIA Lite wird zu einem Profil darauf.** Wer OLYMPUS aufsetzt, schaltet
+zusätzlich PostgreSQL, den Identitätsanbieter und die Beobachtungswerkzeuge hinzu. **XinionONE
+braucht diese Obermenge nicht und lässt sie weg** — dieselbe Laufzeit, zwei Profile.
+
+Der Name ist nicht neu erfunden: GAIA Lite nennt seine k3s-Knotenrollen seit jeher `CORE` und `WRK`.
+**`XinionCORE` verallgemeinert eine vorhandene Verwendung, statt eine zweite danebenzustellen.**
+
+## Warum
+
+**Zwei Laufzeitschichten auf einem Blech sind zweimal derselbe Betrieb.** Zwei Fassungsstände, zwei
+Bauwege, zwei Sicherheitsaktualisierungen — und beim Cyber Resilience Act zwei Versorgungszusagen
+für dieselbe Sache. Das ist die Begründung aus `ADR-0001`, angewandt auf einen dritten Fall.
+
+**Und der Selbstprüflauf müsste beide prüfen.** Der Rücksprung entscheidet sich an der Frage, ob die
+Nutzlast hochgekommen ist. Bei zwei Laufzeitschichten wäre die Antwort *teilweise* — und *teilweise*
+ist bei einer A/B-Entscheidung keine Antwort.
+
+**Die Trennung in Grundausstattung und Profil ist kein Kompromiss, sondern die Einlösung dessen, was
+OLYMPUS selbst festgeschrieben hat:** Layer 2 wird über den Plattform-Vertrag konsumiert, und
+welcher Träger ihn erfüllt, ist genau die Austauschbarkeit, die dort gefordert wird.
+
+## Was daraus folgt
+
+* **Was in der Wurzel liegt und was im Bestand, gilt für beide Profile gleich** — Container-Abbilder
+  in die Wurzel, Cluster-Zustand und persistente Datenträger in den Bestand. Sonst nimmt der
+  Rücksprung die Software nicht mit.
+* **Der Selbstprüflauf prüft eine Laufzeitschicht**, und ein k3s, das nicht hochkommt, ist ein
+  misslungener Start — unabhängig davon, welches Profil darauf läuft.
+* **Die Grundausstattung ist die kleinste gemeinsame Menge.** Was nur ein Profil braucht, gehört ins
+  Profil. Bei jedem Zuwachs der Grundausstattung ist zu begründen, warum *jede* Nutzlast ihn braucht.
+
+## Was ausdrücklich nicht entschieden ist
+
+* **Wann der Umbau geschieht.** OLYMPUS ist Konzept, die Appliance ist Konzept — hier kollidieren
+  zwei Pläne und kein Bestand. Das ist der günstigste Zeitpunkt, den es dafür je geben wird.
+* **Ob GAIA Full ebenfalls so gebaut wird.** Diese Entscheidung betrifft nur, was beim Kunden als
+  Gerät steht.
+* **Zwei Registries und zwei Lizenzmechaniken bleiben bestehen** — die von XinionONE für seine
+  Module, die von OLYMPUS für seine Anwendungen. **Sie werden nicht zusammengelegt**, solange nicht
+  jemand nachweist, dass sie dasselbe tun.
+
+---
+
+*Grundlage: `ADR-0001`, `ADR-0005` · `appliance/ADR-0014` · Projekt OLYMPUS, Startseite vom
+23.06.2026 · Nichts davon ist gebaut.*

docs/decisions/ADR-0007-installation-und-konsolenbereich.md

@@ -0,0 +1,140 @@
+# ADR-0007 — Die Installation fragt nur nach dem Netz; das Konsolenmenü zeigt Zustand vor Handlung
+
+**Stand:** Angenommen, 01.09.2026 · **Entscheidet:** CIO Thomas Reitz
+**Setzt voraus:** [`ADR-0004`](ADR-0004-abbild-bleibt-klein.md) (Abbild bleibt klein) · [`ADR-0002`](ADR-0002-startverfahren-und-ruecksprung.md) (Startverfahren und Rücksprung) · [`ADR-0005`](ADR-0005-geraeteschicht-aller-verkaufsvarianten.md) (Notfallzugang als Stufe 1)
+
+---
+
+## Worum es geht
+
+Der Abbildbau steht, und die Ersteinrichtung läuft heute **vollständig unbeaufsichtigt** — eine
+Autoinstall-Datei, ein Zeitschalter von einer Sekunde, keine einzige Frage. Für einen Prüfaufbau ist
+das richtig. **Für ein Gerät, das bei einem Kunden ins Rack kommt, ist es unmöglich:** Niemand hat
+ihm gesagt, welche Adresse es haben soll.
+
+Umgekehrt war nie festgelegt, **was nach der Installation geschieht.** Jemand meldet sich an der
+Konsole an — und sieht eine leere Eingabeaufforderung. `ADR-0005` hat den Notfallzugang als *Stufe 1*
+vorgesehen, aber nie ausgestaltet.
+
+Als Vergleich lag der Installer von Proxmox VE nahe: Lizenz, Zieldatenträger **mit Dateisystem- und
+Aufteilungsoptionen**, Land und Zeitzone, Passwort, Netz, Zusammenfassung. **Er ist der richtige
+Vergleich — und an genau einer Stelle das falsche Vorbild.**
+
+## Die Entscheidung
+
+### 1 · Gefragt wird nur, was das Gerät nicht selbst wissen kann
+
+| Wird gefragt | Wird nicht gefragt |
+|---|---|
+| Zieldatenträger, sobald mehr als einer da ist | **Aufteilung und Dateisystem** |
+| Land, Zeitzone, Tastatur | Paketauswahl |
+| Verwalterkennung und Passwort | Startverwalter |
+| **Netz: Rechnername, Adresse, Gateway, DNS** | alles Übrige |
+
+**Der eigentliche Grund, warum eine Installation überhaupt Fragen stellt, ist die Einbindung ins Netz
+des Kunden.** Alles andere ist entschieden, und zwar von uns.
+
+### 2 · Die Aufteilung wird nicht angeboten — sie ist unerreichbar
+
+Umgesetzt über `interactive-sections` in der Autoinstall-Datei: **Was dort nicht aufgeführt ist,
+bleibt vorbelegt und wird nicht angezeigt.** Der Speicherabschnitt steht nicht darin.
+
+> **Proxmox bietet Dateisystemwahl, weil es eine allgemeine Plattform ist. Wir dürfen sie nicht
+> bieten, weil unsere Aufteilung die Produktzusage *ist*.**
+>
+> EFI 1 GB, zwei Wurzeln à 40 GB, Bestand als Rest — **daraus besteht der Rücksprung.** Wer sie
+> wählen darf, darf ihn abwählen. Und dann steht ein Gerät beim Kunden, dessen wichtigste
+> Eigenschaft bei der Installation verlorenging, ohne dass es jemand bemerkt hat.
+
+Das ist dieselbe Linie wie im ganzen Vorhaben: **durchgesetzt vom Mechanismus, nicht von der
+Zurückhaltung des Benutzers.**
+
+### 3 · Nach dem Login kommt Zustand, dann Handlung
+
+Der Konsolenbereich zeigt **ohne einen einzigen Tastendruck**:
+
+* Welche **Wurzel** läuft — A oder B
+* Wie der letzte **Selbstprüflauf** ausging, und der **Bootzähler**
+* Die **Netzadresse**
+* **Unter welcher Adresse die Verwaltungsoberfläche der Nutzlast erreichbar ist**
+
+Der letzte Punkt ist der wertvollste und bei Proxmox abgeschaut: **Es ist die Antwort auf „Installation
+fertig, und jetzt?"** — die Frage, die sonst ein Anruf wird.
+
+Darunter die Handlungen, **nach Häufigkeit geordnet**, nicht nach Wichtigkeit:
+
+Netz einrichten · Selbstprüflauf ausführen **und sein Protokoll zeigen** · Wurzel wechseln und
+Rücksprung von Hand erzwingen · Nutzlast anhalten und starten · Protokolle ansehen ·
+**Diagnosepaket erzeugen** · Neustart · Herunterfahren · **Kommandozeile, bewusst als letzter
+Eintrag**.
+
+**Netz zuerst, weil es der mit Abstand häufigste Grund ist, warum jemand vor einer Konsole steht.**
+
+### 4 · Was dort nicht hineingehört
+
+**Nichts, was der Verwaltungsoberfläche der Nutzlast gehört** — keine Module, keine Lizenzen, keine
+Vorgänge, keine Freigaben.
+
+Der Grund steht in `ADR-0005` und ist hart: **Die eine Oberfläche muss den Ausfall der anderen
+überleben.** Sobald an der Konsole Module verwaltet werden können, ist sie keine Notfalloberfläche
+mehr, sondern eine zweite Verwaltung — mit zweiter Rechteprüfung, zweiter Spur und zweitem
+Fehlerbild.
+
+**Und die Zuständigen sind verschieden:** Der Konsolenbereich gehört dem Betreiber und repariert ein
+krankes Gerät. Die Weboberfläche gehört dem Admin des Kunden und führt den Betrieb.
+
+### 5 · Der Splash an drei Stellen
+
+| Stelle | Technik | Sicher? |
+|---|---|---|
+| **Startmenü des Mediums** | GRUB-Thema, Hintergrundbild, eigene Einträge | ja |
+| **Systemstart des Geräts** | Plymouth-Thema | ja |
+| **Installationsvorgang** | Plymouth im Start-Abbild des Mediums | **zu prüfen** |
+
+Dazu der Zeitschalter des Startmenüs **von einer Sekunde auf zehn** — sonst sieht niemand das Menü.
+
+**Die Textoberfläche des Installers bleibt.** Ein grafischer Installer wäre ein eigenes Erzeugnis mit
+eigener Pflege; Proxmox unterhält seines seit Jahren. **Zwischen einem gestalteten Startmenü und
+einem gestalteten Systemstart liegt nur die Zeit, in der jemand fünf Felder ausfüllt.**
+
+## Was daraus für die Gestaltung folgt — und es ist nicht offensichtlich
+
+> **Auf dem Splash steht `XinionOS`, nicht der Name eines Produkts.**
+
+Die `CLAUDE.md` dieser Ablage sagt: *Nirgends in dieser Ablage steht der Name eines Produkts.* Das
+gilt für den Startbildschirm genauso wie für den Programmtext — **dieselbe Geräteschicht trägt die
+ITSM-Appliance und die Anwendungsplattform**, und ein Startbildschirm, der eine davon nennt, ist auf
+dem anderen Gerät falsch.
+
+Der Produktname erscheint erst, wenn die Nutzlast startet.
+
+## Was es kostet
+
+**Eine interaktive Installation ist ein Abnahmefall mehr.** Sie kann an Stellen scheitern, an denen
+eine unbeaufsichtigte nie war — falsche Eingaben, abgebrochene Sitzungen, unerreichbares Netz.
+
+**Und die unbeaufsichtigte Installation muss trotzdem erhalten bleiben**, sonst ist keine
+Serienfertigung möglich. Beide Wege aus derselben Datei: dieselbe Vorbelegung, einmal mit und einmal
+ohne `interactive-sections`.
+
+## Zwei Funde, die dabei aufgefallen sind
+
+**In der heutigen Autoinstall-Datei fehlt ein `identity`-Abschnitt.** Ubuntus Autoinstall verlangt
+entweder ihn oder Benutzer über `user-data`; ohne beides bricht der Installer ab. **Das fällt beim
+ersten Bau auf** — besser, man weiß es vorher.
+
+**Der Zeitschalter steht auf 1.** Für die unbeaufsichtigte Installation richtig, für ein Menü mit
+Auswahl unbrauchbar.
+
+## Was ausdrücklich nicht entschieden ist
+
+* **Ob der Konsolenbereich eine Textmaske oder ein Menü in einer Schleife ist.** Beides trägt; die
+  Wahl gehört zur Umsetzung.
+* **Ob Plymouth im Start-Abbild des Mediums ersetzbar ist.** Zu prüfen, nicht anzunehmen.
+* **Der Inhalt des Diagnosepakets.** Er berührt den Offline-Rückweg (`O-5` im Backlog) und gehört
+  dort entschieden.
+
+---
+
+*Grundlage: `ADR-0002`, `ADR-0004`, `ADR-0005` · Vergleich: Installer von Proxmox VE ·
+Nichts davon ist gebaut.*