Files

T

Thore CimbalandClaude Fable 5 ae62727a50 Workshop #17 , Punkte 4 und 5: Kadenz, Board-Regeln, ADR-0008, DoD

Vier Entscheidungen aus dem Struktur-Workshop.

Kadenz: Refinement sonntagabends, woechentlich. Sonntag, weil die GitLab-Backups
dort ohnehin laufen und die Woche an der Stelle eine Kante hat. Die Retro light
bekommt bewusst KEINEN eigenen Termin, sondern haengt am ersten Refinement des
Monats - ein monatlicher Extra-Termin im Solo-Betrieb ist ein Termin, der
ausfaellt.

Board-Pflege bei Abwesenheit: Eine Session darf abbilden, aber nicht zusagen.
Erlaubt sind status:wartet, Schliessen, Fristen nachtragen, Issues anlegen;
nicht erlaubt sind status:doing und status:next. Die Trennlinie ist nicht
Vorsicht, sondern Bedeutung - doing und next sagen, was als Naechstes wirklich
passiert, und das entscheidet sorb. Jede Aenderung wird im Issue begruendet.

ADR-0008 zu #14: Agenten-Sessions auf CFGMON laufen root-aequivalent ueber die
docker-Gruppe, und das bleibt so - ausdruecklich. Damit gilt 'sudo mit Passwort'
auf diesem Host nicht als Kontrollmechanismus. Option B haette das Auditproblem
geloest, indem sie den Arbeitsweg entfernt (sudo braucht ein TTY, das eine
Session nicht hat); Option C bleibt Ziel, lohnt aber erst bei einem zweiten
Menschen - ihr Nutzen ist Zuordnung, und im Ein-Personen-Betrieb gibt es
niemanden, gegen den sie schuetzen wuerde. Als ADR und nicht als Absatz in
hosts/cfgmon.md, weil eine Ausnahme nur zu dokumentieren statt sie zu
entscheiden genau der Fehler ist, den die ADR-Pflicht adressiert.

Die im Issue geforderte Vorklaerung - welche Konten sonst in der docker-Gruppe
sind, gilt dasselbe auf MATRIX - ist ausdruecklich als offen vermerkt statt
stillschweigend uebergangen.

Definition of Done: Baustein 4 der Textbausteine IST die kurze DoD fuer
Aenderungen ohne Deploy, statt eines eigenen Dokuments. Ein drittes Dokument
waere die dritte Fassung derselben Regeln und damit die dritte, die driftet.

62 relative Links geprueft, keiner tot.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj

2026-08-06 12:00:00 +00:00

4.2 KiB

Raw Blame History

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? Dann status:wartet: Wartet es noch auf das, was im Issue steht? Erst zuletzt status: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 next füllen, next aus 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.

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.md und 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.

4.2 KiB Raw Blame History Unescape Escape