verfahren: Refinement/Retro-Termine ausgearbeitet, Struktur-Workshop vorbereitet (#17)

- verfahren/refinement.md: Ablauf und Timeboxes fuer Refinement (woechentlich),
  Retro light (monatlich), AAR-Anlass; Zusammenspiel der parallelen Sessions
- roadmap.md + README: Kadenz-Abschnitt verweist darauf, Workshop-Einstieg verlinkt

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

verfahren/refinement.md

@@ -0,0 +1,56 @@
+# Refinement und Retro — die Termine des Frameworks
+
+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.
+
+## Refinement (≈ wöchentlich, 30–45 min)
+
+Der eine Termin, der das System am Leben hält. Immer dieselbe Reihenfolge:
+
+1. **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`.
+2. **WIP-Limit prüfen** — höchstens zwei Issues in `doing`. Ist es voll, wird nichts
+   Neues gezogen; stattdessen wird gefragt, was das Laufende blockiert.
+3. **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**.
+4. **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.
+5. **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](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).
+
+## 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`](../CLAUDE.md) und
+  sind über den Gitea-Mirror von überall lesbar.
+- Arbeit zwischen Sessions läuft über das
+  [Deploy-Übergabe-Verfahren](deploy-uebergabe.md) — 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.