Thore CimbalandClaude Fable 5
ae62727a50
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
Architecture Decision Records (ADR)
Eine Datei pro Entscheidung, fortlaufend nummeriert, Format siehe
template.md (MADR-light). ADRs werden nie umgeschrieben —
eine revidierte Entscheidung bekommt ein neues ADR, das alte wird im Status
auf abgelöst durch NNNN gesetzt.
Wann ist ein ADR Pflicht:
- Architektur- oder Prozessentscheidungen, die mehrere Repos/Hosts betreffen
- Jede dauerhafte Ausnahme von einer bestehenden Regel — eine Ausnahme, die nur dokumentiert, aber nicht entschieden wurde, ist ein Fehler (gelernt beim git.lab-Cutover 2026-08-01: die „Übergabe-Issues bleiben auf Gitea"-Ausnahme hätte als Entscheidungsvorlage kommen müssen, nicht als Fußnote)
- Verworfene Wege, deren erneute Prüfung Zeit kosten würde („warum haben wir das damals nicht gemacht?")
Kleine, repo-lokale Entscheidungen bleiben im jeweiligen Projekt (Commit-Message oder Issue) — nicht jede Abwägung braucht ein ADR.