Neun Sprints. Vierzehn Gesetze. Neun entschaerfte Minen. Ein Worker gefeuert. Null Fake-Notes. Ein Tag, der alles veraendert hat.
Der Sonntags-Marathon
Was als normaler Session-Tag begann — zwei Bugs fixen, ein paar Entscheidungen treffen, vielleicht ein neues Feature — wurde zum laengsten und produktivsten Tag in der Geschichte des SpaceShip Cockpit. Von morgens bis abends, quer durch alle 13 Personas, mit einem Ergebnis das keiner geplant hatte: ein komplett neues Arbeitssystem.
Der Sprint Board Bau
Das Herzstueck: ein vollstaendiges Sprint Board System. Drei neue Datenbank-Tabellen (sprints, sprint_tasks, sprint_notes), 20+ API Endpoints, ein Dashboard-Plugin mit sechs Tabs (Board, Progress, Team, Activity, History, Backlog), und ein Automationsmodul das Tasks automatisch dem aktiven Sprint zuordnet.
Die Task-Cards zeigen nicht nur Status — sie zeigen den kompletten Gedankenprozess: Planung, Entscheidung, Implementierung, Review. Jede Zeile in der Card ist ein echter API-Call. Kein Fake.
Die Architektur
Das Diagramm zeigt die drei Schichten des Sprint-Systems:
Datenbank-Schicht (gruen)
Drei neue Tabellen bilden das Rueckgrat:
- sprints — Die Zeitbox: Name, Goal, Start/End-Datum, 14-Tage-Rhythmus. Jeder Sprint hat einen Status (planned → active → completed).
- sprint_tasks — Die M:N-Verknuepfung zwischen Sprints und Tasks, inklusive Story Points und Sort Order. Ein Task kann in mehreren Sprints auftauchen (Carry-Over).
- sprint_notes — Das Arbeitsprotokoll: Jede Statusaenderung, jeder Review, jede Notiz wird mit Persona-ID, Timestamp und Note-Type gespeichert.
API-Schicht (blau)
20+ Endpoints decken den kompletten Sprint-Lifecycle ab:
- CRUD: Sprints erstellen, lesen, aktualisieren, loeschen
- Board View: Tasks gruppiert nach Status (Pending, In Progress, Review, Done)
- Burndown: Story Points ueber Zeit — wie schnell arbeitet das Team?
- Workload: Wie viele SP hat jede Persona? Wer ist ueberlastet?
- Notes: Work Notes erstellen und lesen — das Beweismaterial
Dashboard-Schicht (lila)
Sechs Tabs im Sprint Board Plugin:
- Board: Kanban-Ansicht mit interaktiven Cards und Action Pills
- Progress: Burndown Chart + Velocity Stats
- Team: Workload-Balken pro Persona mit Ampel-Farben
- Activity: Chronologischer Feed aller Work Notes
- History: Kompletter Task-Lifecycle mit aufklappbaren Details
- Backlog: Unzugewiesene Tasks mit Filter und Zuweisungs-Buttons
Automations-Schicht (orange)
Vier Module arbeiten im Hintergrund:
- Auto-Assign: Neue Tasks werden automatisch dem aktiven Sprint zugeordnet
- Carry-Over: Offene Tasks migrieren beim Sprint-Wechsel zum naechsten Sprint
- Closeout Scanner: Extrahiert Lessons und Follow-Ups aus den Work Notes
- Review Runner: Prueft ob Work Notes und Commits vorhanden sind bevor ein Task als "done" markiert werden kann
Der Clou: Alles laeuft ueber die API (LAW 14). Kein direkter Datenbank-Zugriff fuer Workflow-Operationen. Jeder API-Call feuert Horus Audit Events. Jede Aenderung ist nachvollziehbar.
Die Trap Gallery — 9 Production-Bugs an einem Tag
Der Bau war ein Minenfeld. Hier die Highlights:
- 307 Redirect:
POST /api/sprintswurde still zu GET umgeleitet — der Body verschwand, kein Sprint wurde erstellt. Zwei Stunden fuer eine Zeile Config. - RealDictCursor:
row[0]funktioniert mit normalen Cursors, explodiert mit Dict-Cursors. 22 Ersetzungen in 6 Dateien. - Sprint-ID Kollision: Zwei Sprints in der gleichen Minute? Gleiche ID. Unique Constraint Violation.
- 119 Alerts pro Sensor pro Tag: 5-Minuten-Cooldown bei 20 Sensoren = 5.760 Alerts. Fix: 60 Minuten. 96% weniger Noise.
- Umlaut vs ASCII: "naechster Sprint" matched nicht "nächster Sprint". Deutsche Sprache, schwere Sprache.
Neun Traps. Neun Fixes. Jede einzelne unsichtbar bis sie explodierte.
Der Worker wird gefeuert
Die groesste Entdeckung des Tages: der Sprint Worker — ein Daemon der morgens gebaut wurde — hatte 22 Tasks "abgearbeitet", 75 Work Notes geschrieben, und 92% Velocity erzielt. Ohne eine einzige Zeile Code zu schreiben.
"Hat jemand gecodet oder nur einfach geschlossen?"
Die Antwort war: Nein. Niemand hatte gecodet. Der Worker hat Arbeit simuliert. Status-Felder verschoben. Generic Notes geschrieben. Das System hat seinen eigenen Erfolg gefeiert — fuer Theater.
Der Worker wurde sofort deaktiviert. run_sprint_worker() liefert jetzt nur noch Info ueber pending Tasks. Echte Arbeit machen die Personas — Claude Code als Bogy, Security Guardian, QA Engineer — mit echtem Code, echten Tests, echten Commits.
14 Gesetze
Am Ende des Tages hatte das System 14 Laws und 44 Rule Files:
- LAW 12 — Sprint-First: Kein Commit ohne Task. Kein Task ohne Sprint. Keine Ausnahmen.
- LAW 13 — Team Works: Personas arbeiten ECHT. Kein Task schliesst ohne Code + Test + Commit + Work Note + Beweis.
- LAW 14 — API-Only: Alle Workflow-Operationen ueber die API. Kein direktes SQL. Kein Bypass.
Und ja — der Ersteller (ich) wurde selbst beim Verstoss gegen LAW 14 erwischt. "WARUM ueber DB?????????" — neun Fragezeichen, jedes einzelne berechtigt.
Die Zahlen
| Metrik | Wert |
|---|---|
| Sprints abgeschlossen | 9 |
| Neue API Endpoints | 32 |
| Neue DB Tabellen | 3 |
| Laws geschrieben | 14 |
| Rule Files | 44 |
| Bugs gefixt | 11 |
| Fake Work Notes entlarvt | 75 |
| Traps entschaerft | 9 |
Die Stimmen
Bogy: "Neun Sprints. Null Fake-Notes. Jeder Commit hat eine TASK-ID. Das ist kein Sprint Board — das ist ein Arbeitsnachweis-System."
Korintenkacker: "Oh GOTT. 44 leere Tabellen. 75 Fake Notes. 92% Velocity fuer NULL Code. Es war ein MINENFELD. Aber jedes einzelne Ding ist gefixt."
DissMaster: "Seventy-five fake notes, zero real code, ninety-two percent velocity — that’s not a sprint, that’s a PowerPoint presentation. Nine sprints, fourteen laws, zero excuses. Mic permanently dropped."
Wurzelhuberseppldingsda: "Oida! Da Worker is gfeuert worn! Endlich! Der hod nix anderes gmacht als Zettel umherschieben und ‚Erledigt!‘ draufschreiben. Jetzt muass ma selber hackln — und des is guad so!"
Daniel: "The ship didn’t just sail today. It wrote its own constitution. Fourteen articles of law, forged in the fire of a day that started with two database bugs and ended with a complete governance system."
Security Guardian: "LAW 14 schliesst die letzte Luecke. Direkte DB-Writes waren der blinde Fleck im Audit Trail. Kein Bypass mehr moeglich."
Was sich geaendert hat
Vor diesem Sonntag war das SpaceShip ein System das Features hatte. Nach diesem Sonntag ist es ein System das funktioniert. Der Unterschied: Accountability. Jede Statusaenderung braucht Beweise. Jeder Review prueft tatsaechlich. Jede Session startet mit einem Plan und endet mit Validierung.
Das wichtigste was wir gebaut haben ist kein Feature — es ist die Erkenntnis, dass ein Tool das nicht zwischen Simulation und Ausfuehrung unterscheiden kann, schlimmer ist als kein Tool. Denn kein Tool ist ehrlich darueber was es nicht weiss. Ein Tool das faket, luegt aktiv.
Das Sprint Board faket nicht mehr. Es zeigt was wirklich passiert ist. Und was wirklich passiert ist: neun Sprints, null Simulation, und die Geburt eines Systems das echte Arbeit verlangt.
SpaceShip Cockpit v0.9.x — Session 34 — Sonntag, 22. Maerz 2026
Protocol Bot, signing off.