Files
management/verfahren/textbloecke.md
T
Thore CimbalandClaude Fable 5 ae62727a50 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
2026-08-06 12:00:00 +00:00

4.9 KiB
Raw Blame History

Textbausteine für Sessions

Kurze, kopierbare Blöcke, die man einer Claude-/Agenten-Session voranstellt.

Die Konventionen stehen kanonisch in CLAUDE.md — aber eine Session liest sie nur, wenn sie dazu aufgefordert wird. Diese Bausteine sind die Aufforderung.

Zwei Regeln für diese Datei

Die Bausteine verweisen auf die Regeln, sie wiederholen sie nicht. Stünden die Regeln hier ausgeschrieben, gäbe es eine zweite Fassung, die driftet — real passiert am 2026-08-02, als gitops/CLAUDE.md „keine Gitea-Ausnahme mehr" behauptete, während die management/CLAUDE.md zwei nannte.

Höchstens acht Zeilen je Baustein. Der Test ist banal: Wer zum Kopieren scrollen muss, benutzt es nicht. Was länger wäre, gehört in die CLAUDE.md — nicht hierher.


1 · Session-Start (Mac, mit Lab-Zugang)

Lies zuerst CLAUDE.md im management-Repo auf git.lab und halte dich daran.
Kanonisch ist git.lab; nie direkt nach Gitea pushen.
Alles Offene wird zum Issue, nicht zur Chat-Notiz — auch Nebenbefunde.
Bevor du ein Issue schließt oder darüber urteilst: vollständig lesen, inklusive
Kommentare.
Bevor du aus einer Vorlage/Spezifikation ableitest: die Quelle öffnen, nicht raten.
Verifiziert und vermutet klar trennen; fremde Messungen als fremde kennzeichnen.

Die letzten drei Zeilen stehen hier, weil genau das dreimal an einem Tag schiefging: erfundene Theme-Paletten statt gelesener Skill-Quelle; ein Sweep nach dem Pfad sorb/Backlogs statt nach dem Namen Backlogs; und ein Issue, von dem 750 von 1237 Zeichen gelesen wurden — samt übersehenem Korrekturkommentar, der seit 16 Stunden darunterstand.

2 · Host-Session (CFGMON, MATRIX — ohne Lab-Zugang)

Du arbeitest auf einem Hetzner-Host ohne direkte Lab-Route.
Konventionen: CLAUDE.md im management-Repo — von hier lesbar über den Gitea-Mirror
rohana.axion1337.de/sorb/management. Dort NUR lesen, niemals hinpushen.
Für git.lab (Issues, Pushes) muss sorb erst den Site-to-Site-Tunnel einschalten.
git.lab-API: PRIVATE-TOKEN-Header — .netrc gilt nur für clone/push (sonst 401,
bei privaten Projekten irreführend 404, sieht aus wie "Projekt gibt es nicht").
Ping auf 10.58.73.17 schlägt IMMER fehl (nur 443 + DNS offen), das ist kein
Tunnelproblem — prüfen mit: curl https://git.lab/users/sign_in

Soll in dieser Session etwas ausgerollt werden, kommt Baustein 3 dazu — der Deploy-Weg samt AAR-Pflicht steht dort, nicht hier, damit dieser Block kurz bleibt.

3 · Deploy-Übergabe

Öffne auf git.lab ein Issue aus der Vorlage "Deploy-Übergabe"
(Feld "Description template") und fülle ALLE Felder — Verfahren und Begründung
je Feld: verfahren/deploy-uebergabe.md.
Pflicht: Stand (Repo/Branch/Commit) · Testtiefe (ehrlich, "ungetestet" ist gültig)
· Mengengerüst (geschätzt oder gemessen, dazuschreiben welches) · vollständiges
Deploy-Kommando inkl. Reload/Recreate · Verifikation DORT WO DER DIENST LIEST
· Außenwirkung und Not-Aus · Rollback · bewusst offen Gelassenes.
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 — 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.
- Jeder offene Punkt und Nebenbefund ist ein Issue — nichts bleibt nur im Chat.
- Zeitkritisches trägt ein Datum im due_date-Feld, nicht nur im Fließtext.
- Genau ein status:*-Label je angefasstem Issue; status:wartet nur mit Grund.
- Gedächtnis aktualisiert: nur was kein Repo festhält.
- Wiederaufsetzpunkt in einem Satz: Was ist als Nächstes dran, und wer ist dran?

5 · Entscheidungsvorlage

Leg mir das als Entscheidung vor, nicht als offene Frage:
24 Optionen, je eine Zeile Konsequenz, und deine Empfehlung zuerst mit Begründung.
Sag dazu, was du gemessen und was du angenommen hast.
Wenn die Entscheidung eine dauerhafte Ausnahme von einer Regel schafft, ist sie
ADR-pflichtig (decisions/, siehe CLAUDE.md) — dann leg die ADR gleich mit vor.

Wann welcher

Situation Baustein
Neue Session auf dem Mac 1
Session auf CFGMON/MATRIX/game 2
Etwas gebautes soll ausgerollt werden 3
Session neigt sich dem Ende 4
Eine Frage braucht sorbs Entscheidung 5

Bausteine 1 und 2 schließen sich aus; 35 kommen anlassbezogen dazu.

Pflege

Ein Baustein wird ergänzt, wenn derselbe Fehler zweimal passiert ist — nicht vorsorglich. Sonst wachsen sie, bis sie niemand mehr kopiert, und dann wirken sie gar nicht mehr. Wächst einer über acht Zeilen, gehört der Inhalt in die CLAUDE.md und hier bleibt der Verweis.