d9ed1bc2ff
Die Geraeteschicht — Abbild, zwei Wurzeln, Selbstprueflauf, Ruecksprung — verlaesst die Ablage der ersten Appliance und wird ein eigenes Erzeugnis mit eigenem Takt und eigenem Nachweis. Drei Gruende, nach Gewicht: Der Cyber Resilience Act verpflichtet fuer das gesamte Produkt einschliesslich der Betriebssystemschicht — vier gewachsene Basissysteme waeren vier Stuecklisten und vier Schwachstellenprozesse, eine gemeinsame Basis ist ein Dossier. Der Ruecksprung wird nur einmal richtig gebaut, weil er nur geprueft wird wenn ihn jemand braucht. Und eine abgegrenzte Aufgabe laesst sich ausschreiben, was unmittelbar auf das groesste benannte Risiko des Hauses einzahlt. Der Einwand der Vertraeglichkeitsmatrix wird durch den Nutzlast-Vertrag entkraeftet statt weggeredet: Die Nutzlast liegt in der Wurzel und wird mit ihr getauscht. Eine Fassung, ein Rueckweg, keine Matrix. Das OS kennt kein Produkt — Regel 1. Alle Namen sind entkoppelt, die Statusseite ist auf die Standardbibliothek umgestellt, weil jede Abhaengigkeit im Grund-OS eine Verpflichtung ueber die Produktlebensdauer ist. Nichts davon ist gelaufen. Der Inhalt gilt als Bauplan. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.4 KiB
Nachweise — hier steht, was wirklich gemessen wurde
Dieses Verzeichnis ist die Ablage für gemessene Ergebnisse. Es existiert, weil das Produkt mit dem Satz „kein erledigt ohne Nachweis" verkauft wird und diese Regel für die eigene Entwicklung genauso gilt wie für das Gerät beim Kunden.
Alles andere im Repo ist Absicht, Entwurf oder Bauplan. Nur was hier liegt, ist belegt.
Wann ein Nachweis fällig ist
Immer dann, wenn eine Architekturentscheidung oder eine Zusage aus dem Konzept zum ersten Mal wirklich läuft — und immer dann, wenn eine Zahl entsteht, die später jemand in ein Angebot oder ein Datenblatt schreiben könnte.
Ein Nachweis ist kein Protokoll der Arbeit. Er beantwortet eine vorher gestellte Frage mit Ja oder Nein.
Wie ein Nachweis aussieht
Eine Datei je Nachweis, benannt nach Datum und Sache: 2026-08-20-ruecksprung-greift.md.
| Abschnitt | Inhalt |
|---|---|
| Behauptung | Was geprüft wurde, wörtlich — und woher sie stammt (ADR, Backlog-Punkt, Konzeptseite) |
| Gerät | Auf welcher Maschine gemessen wurde, mit Ausstattung. Virtuelle Maschine oder Blech ist ein Unterschied |
| Zeitpunkt | Datum, und bei Zeitmessungen die Uhrzeit |
| Ablauf | Was getan wurde, Schritt für Schritt, so dass es jemand anderes wiederholen kann |
| Beobachtung | Was herauskam — roh, mit den echten Ausgaben. Keine beschönigende Zusammenfassung |
| Urteil | belegt · nicht belegt · teilweise belegt, mit einem Satz Begründung |
Drei Regeln, die den Unterschied machen
Ein Fehlschlag ist ein Nachweis. „Nicht belegt" ist ein vollwertiges Ergebnis und gehört genauso hierher wie ein Erfolg. Ein Verzeichnis, in dem nur Erfolge stehen, ist kein Nachweis-, sondern ein Werbeordner.
Die echte Systemmeldung, nicht die Zusammenfassung darüber. Dieselbe Regel, die für das Gerät gilt: Wer eine Fehlermeldung glättet, nimmt dem Nächsten die Information, die er braucht.
Das Gerät gehört zur Zahl. Eine in einer virtuellen Maschine gemessene Startzeit ist keine Aussage über ein Kundengerät. Eine auf einer Grafikkarte gemessene Antwortzeit keine über eine andere. Ohne Gerät ist eine Zahl nicht unvollständig, sondern irreführend.
Was hier nicht hineingehört
Vermutungen, Planungen und Absichten — die stehen in docs/decisions/ und docs/auslegung/.
Und Zwischenstände einer laufenden Arbeit; die gehören in den Commit-Text.