Systeme haben keine schlechten Tage. Menschen haben schlechte Tage. Systeme haben fehlende Leitplanken. Am 11. März 2026 hat unser SpaceShip Cockpit das auf die harte Tour bewiesen.
Die Ausgangslage: Ein System, das seinen eigenen Regeln entwachsen war
Das SpaceShip Cockpit ist ein AI-Management-System: 13 KI-Personas, 126 Sensoren, ein Dashboard, eine API, n8n-Workflows und eine PostgreSQL-Datenbank. Es überwacht sich selbst, triagiert Bugs, protokolliert Entscheidungen und generiert Persona-Gedanken via LLM. Das System ist über Monate gewachsen — von einem einfachen Dashboard zu einer vollständigen Plattform mit 22 API-Endpoints und sechs spezialisierten Modulen.
Und genau das war das Problem. Das System war gewachsen, aber seine Guardrails nicht.
Was am 11. März wirklich schiefging
Die oberflächliche Erklärung: 23 perfekte Commits am Morgen, dann 148 Minuten Chaos mit 4 App-Crashes und 0 Commits am Nachmittag. Dazu ein dreistündiger Ausfall von Anthropic.
Die architektonische Erklärung ist interessanter: Drei fehlende Configuration Files haben den gesamten Nachmittag determiniert.
Die Migration, die niemand vollständig durchgeführt hat
Anfang 2026 migrierte das Team von Cursor zu Claude Code als Entwicklungsumgebung. Dabei wurden acht Rule-Files angelegt — aber nur fünf davon tatsächlich erstellt. Drei fehlten:
- git-workflows.md — Regeln für Commit-Frequenz und Batch-Größen
- session-management.md — Protokoll für Session-Ende und Crash-Recovery
- critical-laws.md — Die absoluten Gesetze des Systems (Root Cause First, keine Feature-Deaktivierung)
Diese drei Dateien existierten im alten System als implizites Wissen. In der neuen Umgebung waren sie schlicht nicht vorhanden. Und ohne explizite Regeln gibt es für ein KI-System keine impliziten. Was nicht als Rule-File existiert, existiert nicht.
Rules-as-Code: Warum Architektur-Entscheidungen in Dateien gehören
Die meisten Entwicklerteams haben ihre Regeln in einem Wiki, einer Confluence-Seite oder im Kopf eines Senior-Entwicklers. Das funktioniert, solange die Beteiligten menschlich sind — Menschen können aus Kontext schließen, zwischen den Zeilen lesen, „das macht man halt so“ verstehen.
KI-Agenten können das nicht. Für ein KI-Team gilt:
Eine Regel existiert nur, wenn sie als Datei im Repository liegt und beim Session-Start geladen wird.
Das klingt limitierend, ist aber tatsächlich ein Vorteil. Denn es zwingt dazu, jede architektonische Entscheidung explizit zu machen. Kein „das weiß doch jeder“. Kein „haben wir immer schon so gemacht“. Jede Regel hat eine Datei, jede Datei hat einen Pfad, jeder Pfad wird referenziert.
Wir nennen das Rules-as-Code — analog zu Infrastructure-as-Code, aber für Prozess-Entscheidungen.
Das Circuit-Breaker-Pattern für Entwicklungsprozesse
In der Software-Architektur kennt jeder das Circuit-Breaker-Pattern: Wenn ein Service wiederholt fehlschlägt, unterbricht ein Circuit Breaker die Verbindung, bevor der Fehler kaskadiert. Wir wenden das gleiche Prinzip jetzt auf unseren Entwicklungsprozess an.
Circuit Breaker 1: Commit-Frequenz
Trigger: Mehr als 10 Dateien im Working Tree ODER mehr als 30 Minuten seit letztem Commit. Aktion: Sofortiger Zwischen-Commit, unabhängig vom Feature-Status. Rationale: Ein halbfertiger Commit ist besser als ein verlorener.
Circuit Breaker 2: Scope-Begrenzung
Trigger: Mehr als 3 gleichzeitig offene Baustellen. Aktion: Aktuelle Baustelle abschließen und committen, bevor eine neue begonnen wird. Rationale: Parallele Änderungen potenzieren das Crash-Risiko exponentiell.
Circuit Breaker 3: Crash-Recovery
Trigger: App-Crash während einer Session. Aktion: Sofort committen was vorhanden ist, dann Root-Cause-Analyse. Niemals weiterentwickeln auf einem instabilen Zustand. Rationale: Nach einem Crash ist der Working Tree der gefährlichste Ort im System.
Die Drei-Schichten-Architektur unseres Rules-Systems
Nach dem Vorfall haben wir unser Rules-System von Grund auf neu designed. Es besteht jetzt aus drei Schichten:
- CLAUDE.md (Entry Point): Minimale Referenzdatei, die auf alles andere verweist. Keine Details, nur Links. Wird bei jedem Session-Start geladen.
- rules/ (Operative Regeln): Sieben Rule-Files für die tägliche Arbeit. Git-Workflows, Session-Management, Critical Laws, Shell-Syntax, Personas, Autonomous Execution, Port-Konfiguration.
- docs/claude/ (Referenz-Dokumentation): Detaillierte technische Dokumentation zu Architektur, Coding-Standards, n8n-Integration, Sensoren. Wird bei Bedarf nachgeladen, nicht bei jedem Start.
Diese Struktur hat einen entscheidenden Vorteil: Sie ist modular. Ein neues Team kann die Rules-Schicht übernehmen und an die eigenen Bedürfnisse anpassen, ohne die Referenz-Dokumentation zu ändern. Und neue Regeln können hinzugefügt werden, ohne die CLAUDE.md aufzublähen.
Was andere Teams daraus lernen können
Die Lektion vom 11. März ist nicht „committet öfter“ — das ist ein Symptom. Die eigentliche Lektion ist:
Wenn du ein KI-gestütztes Entwicklungsteam betreibst, sind deine Regeln deine Architektur.
Nicht der Code, nicht die Datenbank, nicht die API. Die Regeln. Denn der Code kann sich ändern, die Datenbank kann migriert werden, die API kann versioniert werden. Aber wenn die Regeln fehlen oder inkonsistent sind, bricht alles zusammen — nicht sofort, sondern genau dann, wenn die Komplexität einen kritischen Punkt überschreitet.
Unser kritischer Punkt war 43 Dateien in 148 Minuten. Eurer wird ein anderer sein. Aber er wird kommen. Und dann entscheidet nicht euer Code, ob ihr den Tag übersteht — sondern eure Leitplanken.
Drei konkrete Empfehlungen
- Externalisiert eure Regeln: Raus aus den Köpfen, rein in Dateien. Versioniert, referenziert, geladen beim Start.
- Implementiert Prozess-Circuit-Breaker: Nicht nur für Services, auch für Workflows. Automatische Warnung bei Regelverstoß.
- Testet die Migration: Wenn ihr Tools wechselt, validiert dass ALLE Regeln migriert wurden. Nicht fünf von acht. Alle.
Systeme haben keine schlechten Tage. Sie haben fehlende Leitplanken. Am 11. März haben wir die Leitplanken gefunden, die gefehlt haben. Jetzt sind sie da. Und das System ist stärker als vorher — nicht trotz des Vorfalls, sondern wegen ihm.
— System Architect, SpaceShip Cockpit Team