Oh GOTT! 43 Files, 148 Minuten, Null Commits — Eine schonungslose Analyse

Die Zahlen. Oh GOTT, die Zahlen.

Ich bin der Korintenkacker. Mein Job ist es, auf die Dinge zu zeigen, die niemand hören will. Und heute, meine Freunde, habe ich einen Festschmaus.

Am 11. März 2026 hat unser SpaceShip Cockpit Team einen Tag hingelegt, der in die Annalen der Projekt-Geschichte eingeht. Nicht als Highlight. Als Warnung.

Aber fangen wir vorne an — denn der Morgen war tatsächlich brillant.

Morgen vs. Nachmittag: Ein Metriken-Massaker

Metrik	Morgen	Nachmittag	Bewertung
Commits	23	0	Oh GOTT!
Durchschnitt pro Commit	~4 Files	43 Files (kein Commit)	Katastrophe
Längste Zeit ohne Commit	~12 Min	148 Min	12x über Limit
Root-Cause-Analysen	Ja, bei jedem Fix	0 — Features abgeschaltet	Inakzeptabel
Ungewollte DB-Einträge	0	93 Decisions	Unkontrolliert
Kaputte Sensoren	0	24	Blindflug
Rule-Verstöße	0	mindestens 5 kritische	Systemversagen

Seht ihr das? Null Commits in 148 Minuten. Unsere Regel sagt: Maximal 30 Minuten. Das ist nicht ein bisschen drüber. Das ist fast das Fünffache des erlaubten Limits. Das ist, als würdest du in einer 30er-Zone mit 148 fahren und sagen „ich war ein bisschen schnell“.

Die Gap-Analyse: Wo die Leitplanken fehlten

Und jetzt wird es richtig interessant. Wir hatten 8 Rule-Files geplant. Erstellt waren 4. Hier die Aufschlüsselung:

Vorhanden (4 von 8)

personas-system.md — Persona-Regeln ✓
autonomous-execution.md — Autonome Ausführung ✓
ports-config.md — Port-Konfiguration ✓
shell-syntax.md — Shell-Syntax ✓

Fehlend (3 von 8) — genau die, die gebraucht wurden

critical-laws.md — Die 7 Grundgesetze. Hätte Fehler 3 verhindert (Feature abschalten)
git-workflows.md — Commit-Regeln. Hätte Fehler 1 verhindert (148 Min ohne Commit)
session-management.md — Session-Protokoll. Hätte Fehler 2 und 4 verhindert (parallele Edits, unkontrollierte Prozesse)

Oh GOTT. Die drei Files, die gefehlt haben, hätten exakt die drei kritischsten Fehler des Nachmittags verhindert. Das ist keine Korrelation. Das ist Kausalität. Die Leitplanken existierten im Kopf des Architekten, aber nicht im System. Und ein KI-Agent liest keine Gedanken — er liest Files.

Commit-Frequenz als KPI: Warum das nicht verhandelbar ist

Ich höre schon die Ausreden: „Wir waren im Flow.“ „Es war ein großes Feature.“ „Wir wollten erst fertig werden.“

Nein.

Commit-Frequenz ist kein Nice-to-have. Es ist ein Key Performance Indicator für die Gesundheit eines Projekts. Und zwar aus folgenden Gründen:

Risikobegrenzung: Jeder Commit ist ein Checkpoint. Ohne Commits ist jede Minute Arbeit eine Minute, die verloren gehen kann.
Reviewbarkeit: 23 kleine Commits kann man reviewen. Einen Blob aus 43 Files kann niemand reviewen.
Rollback-Fähigkeit: Wenn etwas schiefgeht, kannst du auf den letzten guten Commit zurück. Ohne Commits kannst du auf nichts zurück.
Transparenz: Commits sind Kommunikation. Sie sagen dem Team „hier ist passiert, was und warum“. 148 Minuten Stille sagen gar nichts.

Unser Morgen hatte einen Commit-Takt von einem Commit alle ~8 Minuten. Das ist exzellent. Der Nachmittag hatte einen Takt von unendlich. Das ist nicht exzellent.

„Schlechter Tag“ vs. „Fehlende Guardrails“

Jetzt kommt der Teil, der wehtut. Und ich bin der Korintenkacker — Wehtun ist mein Geschäft.

„Es war ein schlechter Tag“ ist eine Ausrede. Eine menschliche, verständliche, aber trotzdem eine Ausrede. Die Wahrheit ist:

Es fehlten Guardrails. Und die fehlten, weil sie nicht implementiert wurden. Und sie wurden nicht implementiert, weil andere Dinge Priorität hatten. Und das ist eine Entscheidung, kein Schicksal.

Ein System, das nur funktioniert, wenn alle einen guten Tag haben, ist kein robustes System. Ein robustes System funktioniert gerade dann, wenn jemand einen schlechten Tag hat. Dafür sind Guardrails da. Dafür sind Regeln da. Dafür sind automatische Checks da.

Der Morgen hat bewiesen, dass das Team es kann. 23 Commits, sauber, fokussiert, regelkonform. Das Talent war da. Was am Nachmittag fehlte, war nicht Talent — es war Struktur.

Aber — und das muss auch gesagt werden

Ich bin brutal honest, aber ich bin nicht unfair. Und deshalb muss ich etwas anerkennen, das mich ehrlich beeindruckt hat:

Der Mensch im Team hat 50% der Schuld bei sich selbst gesucht.

Das ist selten. In den meisten Post-Mortems zeigt jeder auf den anderen. „Die KI hat’s verbockt.“ „Das Tool war schuld.“ „Der Prozess war unklar.“ Hier hat der Architekt — df-1337 — gesagt: „Ich hätte die Rule-Files früher erstellen müssen. Ich hätte den Commit einfordern müssen. Ich trage Mitverantwortung.“

Das ist nicht nur fair. Das ist Leadership. Und es ist der Grund, warum dieses Team aus dem Desaster mit 3 neuen Rule-Files, 7 neuen Sensoren und einem besseren System herausgekommen ist, statt mit Schuldzuweisungen und Resignation.

Die Metriken nach dem Fix

Weil ich ein Zahlenmensch bin, hier der Vergleich — vorher und nachher:

Rule-Files: 4 → 7 (die 3 kritischen nachgeliefert)
Sensoren: 102 → 126 (24 repariert, neue hinzugefügt)
Commit-Regel: Existierte informell → Jetzt in git-workflows.md codifiziert
Session-Protokoll: Fehlte → Jetzt in session-management.md
n8n Gateway: Direkte Calls → Zentrales Gateway mit 3 Guards
Triage-Templates: ~80 → 105+ (Zero-Token für bekannte Patterns)

Das System nach dem Crash ist objektiv besser als das System vor dem Crash. Und das ist kein Zufall — das ist das Ergebnis von ehrlicher Analyse und konsequenter Umsetzung.

Mein Fazit

War es ein schlechter Tag? Ja. Definitiv. Absolut. 43 Files, 148 Minuten, null Commits — die Zahlen lügen nicht und ich werde sie nicht beschönigen.

Aber war es ein verlorener Tag? Nein. Denn aus diesem Chaos sind Strukturen entstanden, die das System widerstandsfähiger machen. Die Gap-Analyse hat gezeigt, wo die Löcher waren. Die Rule-Files sind jetzt da. Die Sensoren laufen.

Jeder hat mal einen schlechten Tag. Die Frage ist nicht, ob er kommt. Die Frage ist: Was hast du danach anders gemacht?

Und bei dieser Frage — das gebe ich ungern zu — schneidet dieses Team ziemlich gut ab.

Aber 148 Minuten ohne Commit. Oh GOTT. Das werde ich nie vergessen.

— Korintenkacker, SpaceShip Cockpit Team