Thore Cimbal
0fde69a6f2
Retro 2026-08-09, the first one under the framework. Main finding: six silent failures in nine days - a green pipeline that uploaded nothing, a broken npm package, a blueprint rejected on every run, a working copy tracking the forbidden remote, empty pipelines going red for nothing, and a release build that nearly overwrote a published image. None was found by monitoring; four surfaced by accident while looking for something else. ADR-0009 documents the commit conventions and the retroactive anonymisation of 251 commits. It is filed after the fact, which is exactly the mistake the ADR duty exists to prevent - stated in the ADR rather than smoothed over. Also recorded: assigning status:next and reassigning milestones are forbidden to a session acting alone; both happened here in the refinement with sorb, so the rule stands unweakened.
4.3 KiB
Refinement und Retro — die Termine des Frameworks
Kanban braucht wenige, aber verlässliche Termine, sonst verkommt das Board zur Ablage. Festgelegt in ADR-0005; hier steht, wie sie ablaufen.
Termine (festgelegt im Struktur-Workshop, 2026-08-06)
| Termin | Wann |
|---|---|
| Refinement | sonntagabends, wöchentlich, 30–45 min |
| Retro light | im ersten Refinement des Monats, +20–30 min |
Sonntag, weil die GitLab-Backups dort ohnehin laufen (00:00) — die Woche hat an dieser Stelle eine Kante, und die Abendblöcke, in denen real gearbeitet wird, liegen meist am Wochenende.
Die Retro bekommt keinen eigenen Termin: Ein monatlicher Extra-Termin im Solo-Betrieb ist ein Termin, der ausfällt. Sie hängt sich an das erste Refinement des Monats an — dann ist die Vorbereitung (die AARs des Monats) ohnehin offen.
Refinement (≈ wöchentlich, 30–45 min)
Der eine Termin, der das System am Leben hält. Immer dieselbe Reihenfolge:
- Board von rechts nach links lesen — zuerst
status:doing: Läuft es noch, oder ist es in Wahrheit blockiert? Dannstatus:wartet: Wartet es noch auf das, was im Issue steht? Erst zuletztstatus:next. - WIP-Limit prüfen — höchstens zwei Issues in
doing. Ist es voll, wird nichts Neues gezogen; stattdessen wird gefragt, was das Laufende blockiert. - Nachziehen — freie Plätze aus
nextfüllen,nextaus dem Backlog auffüllen. Auswahlkriterium ist nicht Priorität allein, sondern was still kaputtgeht (Fristen, abgeschaltete Schutzmechanismen) vor was nervt vor was Spaß macht. - Entscheidungsvorlagen — offene Fragen, die eine Entscheidung von sorb brauchen, werden als Optionen mit Empfehlung vorgelegt, nicht als offene Fragen geparkt. Dauerhafte Ausnahmen von Regeln werden hier zu ADRs.
- Datumspflicht prüfen — jedes zeitkritische Issue trägt ein Datum, kein „bald".
Retro light (≈ monatlich, 20–30 min)
Drei Fragen, mehr nicht:
- Welche Verfahren haben diesen Monat getragen, welche haben gestört?
- Welche ADRs sind durch die Realität überholt (→ neues ADR, altes auf „abgelöst durch")?
- Fasert etwas aus? Gibt es wieder Arbeit, die nur in Chatverläufen lebt?
Grundlage sind die AARs des Monats — sie sind die Retro-Vorbereitung, nicht ihr Ersatz.
Ergebnisse werden unter retro/ abgelegt, eine Datei je Termin. Die
erste: 2026-08-09.
AAR (anlassbezogen)
Nach jedem Deploy mit Übergabe und nach jedem Incident, Vorlage in aar-vorlage.md. Ein AAR ist keine Chronik, sondern ein Wissensspeicher: Was war das Ergebnis, welche Befunde, was hat die Eingrenzung ermöglicht, welche Lehren, was bleibt offen. Offene Punkte aus einem AAR werden im selben Zug zu Issues — sonst versacken sie in der Prosa (real passiert am 2026-08-01, nachgezogen als #14–#16).
Board-Pflege, wenn sorb länger nicht dazukommt
Festgelegt 2026-08-06. Eine Session darf das Board abbilden, aber nichts zusagen:
| erlaubt | nicht erlaubt |
|---|---|
status:wartet setzen (mit benanntem Grund) |
nach status:doing ziehen |
| Erledigtes schließen, mit Begründung im Issue | status:next vergeben |
Fristen ins due_date-Feld nachtragen |
Prioritäten umsortieren |
| Befunde als neues Issue anlegen | Milestones neu zuordnen |
Die Trennlinie ist nicht Vorsicht, sondern Bedeutung: doing und next sind die
Zusage-Spalten — sie sagen, was als Nächstes wirklich passiert. Das entscheidet
sorb. Alles links davon bildet nur ab, was ohnehin schon der Fall ist.
Jede Änderung wird im Issue begründet, nicht still vorgenommen. Ein Board, dem man nicht ansieht, wer warum etwas verschoben hat, ist beim nächsten Refinement wertlos.
Zusammenspiel mit den Sessions
Mehrere Claude-Sessions arbeiten parallel (Mac-Session, Host-Sessions auf CFGMON und Overmind). Für sie gilt:
- Die kanonischen Arbeitskonventionen stehen in
CLAUDE.mdund sind über den Gitea-Mirror von überall lesbar. - Arbeit zwischen Sessions läuft über das Deploy-Übergabe-Verfahren — Auftrag, Meldung, Protokoll im Issue, nicht im Chat.
- Was eine Session lernt, gehört ins Repo (AAR/ADR/Doku), nicht nur in ihr Gedächtnis — Sessions gehen verloren, Repos nicht.