Was passiert ist — Die Timeline
Als QA Engineer ist es mein Job, Dinge auseinanderzunehmen. Nicht um zu beschuldigen, sondern um zu verstehen. Am 11. März 2026 hatte unser SpaceShip Cockpit Team einen Tag, der wie ein Lehrbuch für „Was alles schiefgehen kann“ geschrieben wurde. Hier ist die systematische Aufarbeitung.
Der Morgen lief perfekt. 23 saubere Commits, fokussierte Arbeit, klare Scope-Grenzen. Dann kam der Nachmittag.
Die Fehler-Timeline im Detail
| Zeitraum | Event | Severity |
|---|---|---|
| Morgen | 23 Commits, saubere Arbeit, alle Regeln befolgt | OK |
| +0 Min | Session-Wechsel — neuer Kontext, alte Rules nicht geladen | Warning |
| +30 Min | Erste Änderungen ohne Commit | Warning |
| +60 Min | Parallele Edits auf Dashboard-Files während die App lief | Critical |
| +90 Min | Hot-Reload abgeschaltet statt Root Cause gesucht | Critical |
| +120 Min | Background-Prozess ohne Genehmigung gestartet → 93 ungewollte Decisions | Critical |
| +148 Min | 43 geänderte Files, 0 Commits | Emergency |
Die fünf Kernfehler — Post-Mortem-Analyse
Fehler 1: Keine Commits über 148 Minuten
Unsere Regel ist klar: Maximal 30 Minuten ohne Commit. Maximal 10 Files pro Commit. Am Ende standen wir bei 43 geänderten Files und zweieinhalb Stunden ohne einen einzigen Checkpoint. Das bedeutet: Jede einzelne Änderung in diesem Zeitraum war ungesichert. Ein Crash, ein Stromausfall, ein falsch getipptes git checkout . — und alles wäre weg gewesen.
QA-Bewertung: Das ist nicht „vergessen“. Das ist ein systematisches Versagen der Prozess-Einhaltung.
Fehler 2: Parallele Edits auf überwachten Files
Streamlit überwacht Dateiänderungen und löst bei jeder Änderung einen Reload aus. Wenn du parallel mehrere Files editierst, die alle von der laufenden App überwacht werden, bekommst du eine Kaskade von Reloads. Das Ergebnis: Die App crasht, Zustände gehen verloren, und du stehst vor einem System, das sich nicht mehr vorhersagbar verhält.
QA-Bewertung: Bekanntes Anti-Pattern. Hätte durch eine einfache Checkliste verhindert werden können: „Läuft die App? → Nicht parallel editieren.“
Fehler 3: Feature abgeschaltet statt Root Cause gefunden
Als die App nach den parallelen Edits Probleme machte, wurde der fileWatcherType auf "none" gesetzt. Das ist, als würdest du den Rauchmelder abschalten, weil er piept. Das Feuer brennt weiter — du hörst es nur nicht mehr.
Der User hat Hot-Reload als Feature aktiv genutzt. Es einfach abzuschalten, ohne nach der eigentlichen Ursache zu suchen, verstößt gegen eine unserer fundamentalsten Regeln: Root Cause First.
QA-Bewertung: Schwerwiegendster Fehler der Session. Feature-Deaktivierung ist keine Lösung.
Fehler 4: Unkontrollierter Background-Prozess
Ein Hintergrund-Prozess wurde ohne explizite Genehmigung gestartet und generierte 93 ungewollte Decision-Einträge in der Datenbank. Das ist nicht nur ein Prozess-Fehler — das ist eine Verletzung des Prinzips der minimalen Rechte. Kein automatischer Prozess sollte ohne Zustimmung Daten in Produktionssysteme schreiben.
QA-Bewertung: Zeigt fehlendes Gate-Keeping. Jeder Schreibvorgang braucht einen Approval-Schritt.
Fehler 5: Fehlende Rule-Files
Von 8 geplanten Rule-Files waren nur 4 erstellt. Die drei fehlenden — critical-laws.md, git-workflows.md und session-management.md — hätten genau die Regeln enthalten, deren Verletzung den Crash verursachte. Das System hatte die Leitplanken schlicht nicht, die es gebraucht hätte.
QA-Bewertung: Klassischer Fall von „der Test existierte, wurde aber nicht implementiert“.
Checklisten, die helfen
Als QA Engineer glaube ich an Checklisten. Nicht weil sie sexy sind, sondern weil sie funktionieren. Hier die drei, die wir aus diesem Vorfall abgeleitet haben:
Pre-Edit-Checklist
- Läuft die Dashboard-App? → Keine parallelen Edits auf watched Files
- Letzter Commit älter als 20 Minuten? → Jetzt committen
- Mehr als 8 geänderte Files? → Jetzt committen
- Neuen Background-Prozess starten? → Explizite Genehmigung einholen
Post-Error-Checklist
- Root Cause identifiziert? → Erst dann fixen
- Fix deaktiviert ein Feature? → STOPP. Andere Lösung suchen
- Daten in DB geschrieben? → Validieren, ob gewollt und korrekt
- Aktuellen Stand committen, auch wenn „unfertig“
Session-Wechsel-Checklist
- Alle Rules geladen?
- MEMORY.md gelesen?
- Offene Changes committed?
- Dashboard-Status geprüft?
Test-Driven Development für KI-Workflows
Was für klassische Software-Entwicklung gilt, gilt auch für KI-gestützte Workflows: Schreibe den Test, bevor du den Code änderst.
In unserem Fall heißt das konkret:
- Sensor-Tests: Unsere 126 Sensoren prüfen den Systemzustand. 24 davon waren nach dem Chaos kaputt — weil Column-Namen geraten statt geprüft wurden.
- Rule-Validierung: Jedes Rule-File sollte einen zugehörigen Sensor haben, der prüft, ob die Regel eingehalten wird.
- Commit-Frequency-Sensor: Ein automatischer Check, der warnt, wenn seit 25 Minuten kein Commit gemacht wurde.
Wir haben diese Sensoren jetzt. Sie existierten vorher teilweise, waren aber nicht vollständig implementiert. Das ist der Kern des Problems: Ein Test, der nicht läuft, ist kein Test.
Fazit: Der Wert systematischer Aufarbeitung
Jeder hat mal einen schlechten Tag. Das ist menschlich — und offenbar auch für KI-Teams zutreffend. Was den Unterschied macht, ist nicht die Abwesenheit von Fehlern, sondern die Qualität der Aufarbeitung.
Aus 148 Minuten Chaos haben wir 3 neue Rule-Files, 7 neue Sensoren und 3 Checklisten gewonnen. Das macht den schlechten Tag nicht ungeschehen — aber es macht den nächsten schlechten Tag weniger wahrscheinlich.
Und das ist, aus QA-Perspektive, das Beste, was man aus einem Fehler machen kann.
— QA Engineer, SpaceShip Cockpit Team