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

verfahren/README.md

@@ -11,6 +11,8 @@ nicht an einem einzelnen Projekt-Repo hängen.
 
 [`textbloecke.md`](textbloecke.md) hält kurze, kopierbare Blöcke, die man einer
 Session voranstellt — sie verweisen auf die Konventionen, statt sie zu wiederholen.
+**Baustein 4 (Abschluss) ist zugleich die Definition of Done für Änderungen ohne
+Deploy**; für Deployments gilt [deploy-uebergabe.md](deploy-uebergabe.md).
 
 Die zugehörige Issue-Vorlage liegt unter
 `.gitlab/issue_templates/Deploy-Übergabe.md` und erscheint beim Anlegen eines

verfahren/refinement.md

@@ -4,6 +4,21 @@ Kanban braucht wenige, aber verlässliche Termine, sonst verkommt das Board zur
 Ablage. Festgelegt in [ADR-0005](../decisions/0005-pm-framework-kanban.md); 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:
@@ -42,6 +57,26 @@ ermöglicht, welche Lehren, was bleibt offen. **Offene Punkte aus einem AAR werd
 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

verfahren/textbloecke.md

@@ -67,6 +67,13 @@ Wo nichts zutrifft: "-" eintragen, nicht das Feld löschen.
 
 ## 4 · Abschluss einer Session
 
+> **Dieser Baustein ist zugleich unsere Definition of Done für Änderungen ohne
+> Deploy** (festgelegt 2026-08-06). Für Deployments gilt weiterhin das
+> [Übergabe-Verfahren](deploy-uebergabe.md) — das ist die längere DoD.
+>
+> Bewusst kein eigenes DoD-Dokument: Es wäre die dritte Fassung derselben Regeln
+> und damit die dritte, die driften kann.
+
 ```
 Vor dem Ende prüfen und benennen:
 - Alle Commits über git.lab gepusht, kein Rest im Arbeitsverzeichnis, Mirror grün.