Einstieg fuer xinionos-dev: zwei VMs, und was eine VM nicht beweisen kann

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.

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