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
Verfahren
Wiederkehrende Abläufe zwischen Personen und Hosts — dort festgehalten, wo sie nicht an einem einzelnen Projekt-Repo hängen.
| Datei | Inhalt |
|---|---|
| deploy-uebergabe.md | Ablauf und Prüfliste für „einer baut, ein anderer rollt aus" |
| aar-vorlage.md | Vorlage für den After Action Report nach einem Deploy |
| aar/ | Abgelegte AARs, benannt JJJJ-MM-TT-<vorhaben>.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.
Die zugehörige Issue-Vorlage liegt unter
.gitlab/issue_templates/Deploy-Übergabe.md und erscheint beim Anlegen eines
Issues in diesem Repo im Auswahlfeld Description template als
Deploy-Übergabe.
Abgrenzung zum Rest des Repos: hosts/ und shared/ halten offene Punkte,
dieses Verzeichnis hält wie wir arbeiten. Ein Verfahren wird hier nur
aufgenommen, wenn es mindestens einmal an einem echten Vorfall gescheitert
oder bewährt ist — der auslösende AAR wird jeweils verlinkt.