xinionos/BRIEFING.md

Neu hier? Lies zuerst 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. Erst lesen, dann anfangen.

Was dieses Erzeugnis ist

Das Betriebssystem der Xinion-Appliances. 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.

Es weiß nicht, was auf ihm läuft. Alles Fachliche kommt über den Nutzlast-Vertrag.

Rollenverteilung

Wer	Was
Architektur (CIO und Entwurf)	entscheidet, was gebaut wird und warum
Entwicklung	baut es, bringt es zum Laufen, misst und legt den Nachweis ab

Begegnet der Bauplan der Wirklichkeit und verliert, ist das ein Befund und kein Auftrag zum Umplanen. Melde zurück, entwirf nicht neu. Faustregel: Musst Du eine Architekturentscheidung anfassen, um weiterzukommen, ist es eine Entscheidung und keine Reparatur.

Was zuerst zu bauen ist

Das Abbild baut reproduzierbar, und der Rücksprung greift nachweislich.

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.

Der Nachweis, Schritt für Schritt

1. abbild/bauen.sh <ubuntu-server.iso> — Abbild bauen, in einer virtuellen Maschine installieren. Das Gerät startet in Wurzel A.
2. Statusseite auf Anschluss 8080 aufrufen: Wurzel A, Fassung, Selbstprüflauf bestanden.
3. Wurzel B befüllen, Starteintrag mit drei Versuchen anlegen.
4. In Wurzel B /etc/xinionos/selbstpruefung-scheitert anlegen — der Prüfschalter.
5. Auf B umschalten, neu starten.
6. Beobachten: dreimal Fehlschlag, danach startet das Gerät ohne Zutun wieder in A.
7. Die Statusseite zeigt unter Verlauf drei durchgefallene Läufe auf B und darunter den bestandenen auf A.

Schritt 6 ist der Nachweis. Ergebnis nach docs/nachweise/.

Wo der erste Lauf voraussichtlich scheitert

Beim Anhängen von autoinstall ds=nocloud;s=/cdrom/xinionos/ an die Startzeile — die Pfade zu grub.cfg unterscheiden sich zwischen Ubuntu-Fassungen. Startet das Medium und fragt trotzdem nach der Sprache, liegt es dort und sonst nirgends. Schnappschuss der VM vor dem ersten Versuch.

Der Stand: nichts davon ist gelaufen

Der gesamte Inhalt ist auf einem Mac geschrieben worden, auf dem weder ein Ubuntu-Abbild gebaut noch eine Unit gestartet werden kann. Behandle ihn als Bauplan, nicht als Zustand.

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 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.
• Kein git add -A.

Wo alles steht

Was	Wo
Regeln	CLAUDE.md
Vertrag zur Nutzlast	nutzlast/VERTRAG.md
Startverfahren und Rücksprung	docs/decisions/ADR-0002-startverfahren-und-ruecksprung.md
Gemessene Ergebnisse	docs/nachweise/

Bei Widerspruch gilt: ADR schlägt Dokumentation, Messung schlägt ADR. Eine Messung, die einer Entscheidung widerspricht, ist der wertvollste Fund überhaupt — melde ihn, bevor Du weiterbaust.