BRIEFING.md

@@ -1,19 +1,3 @@
-> **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.
@@ -73,7 +57,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 XinionONE noch NEXTgenIT noch OLYMPUS noch sonst einen — siehe Regel 1
+* **Keinen Produktnamen aufnehmen.** Weder 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 XinionONE, kein NEXTgenIT, kein OLYMPUS, kein
+Nirgends in dieser Ablage steht der Name eines Produkts — kein NEXTgenIT, kein OLYMPUS, kein
 COSMOS, keine Fachlichkeit. Was ein Produkt braucht, bekommt es über den
 [Nutzlast-Vertrag](nutzlast/VERTRAG.md).
 

ENTKOPPLUNG.md

@@ -1,68 +0,0 @@
-# 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 mit GAIA Lite · oder die Wirt-Dienste einer Fach-Appliance |
+| Plattform | Laufzeit- und Betriebsschicht | OLYMPUS · oder die Wirt-Dienste einer Fach-Appliance |
 | **Gerät** | **XinionOS** | **diese Ablage** |
-| Infrastruktur | Rechenzentrum | GAIA Full |
+| Infrastruktur | Rechenzentrum | GAIA |
 
 Beim Kunden auf Blech ist XinionOS das, worauf die Verkaufsvariante der Plattform läuft.
 

START.md

@@ -1,91 +0,0 @@
-# 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,62 +171,3 @@ 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

@@ -1,78 +0,0 @@
-# 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

@@ -1,123 +0,0 @@
-# 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

@@ -1,74 +0,0 @@
-# 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

@@ -1,140 +0,0 @@
-# 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.*