Thore CimbalandClaude Fable 5
92b448fe30
Gate 4, slice 3: verfahren/, hosts/, vision/ and shared/ moved via git mv - six AARs to docs/aar/ (four harvested by the 2026-08-09 retro, two open), procedures and host knowledge to docs/wiki/ (admin, deployment, architecture, new area vision), the retro protocol and the commit mapping table to docs/sources/ (protokolle/, migration/). New: the wiki index linking every page, and the mirror-topology page carrying the why-two-places reasoning verbatim from the old CLAUDE.md (F-013 preserved). All moved-path references retargeted; the link checker drove the sweep to zero. pruefe_prosa.py added (pattern C+D): SHA citations resolve via repo, mapping table, optional component clones or a curated exemption list (documented dead Gitea-force-push commits, a vendor-repo tag, an Authentik uid that is hex but no git SHA, the external neckbeard reference); wiki task prose without an issue reference errors, with a visible pragma for deliberate checklists; the dead-tracker denylist now covers every mirrored repo's retired Gitea tracker (F-005) - two links re-verified against live GitLab titles and retargeted, five defused into honest historical citations. Verified: validate 0/0, gen_status --check current, drift 0. Demo on the pre-migration state fires 6 findings (3 orphaned SHAs, 3 task blocks); on the current tree exactly the 3 F-004 task blocks remain - they turn green in slice 4 when the issues exist, which is why pruefe_prosa joins CI only then. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
4.5 KiB
type, area, related
| type | area | related |
|---|---|---|
| wiki-page | admin |
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? Dannstatus:wartet: Wartet es noch auf das, was im Issue steht? Erst zuletztstatus: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
nextfüllen,nextaus 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.
Ergebnisse werden unter docs/sources/protokolle/ abgelegt, eine Datei je Termin. Die
erste: 2026-08-09.
AAR (anlassbezogen)
Nach jedem Deploy mit Übergabe und nach jedem Incident, Vorlage in docs/aar/template.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.mdund 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.