management/docs/wiki/admin/textbloecke.md

type, area, related

type	area	related
wiki-page	admin

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:
2–4 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; 3–5 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.

Vollständige Aufträge an frische Sitzungen

Die Bausteine oben sind Vorspann. Wenn eine ganze Aufgabe an eine frische Sitzung übergeben wird — weil sie eigenen Kontext braucht oder weil die laufende Sitzung sie nicht beurteilen darf —, wird der Auftrag als Seite abgelegt statt im Chat zu verschwinden:

Auftrag	Stand
Die Ernte bewerten und einarbeiten	ausgeführt
Judge-Funktion und Spurenpflicht entwerfen	ausgeführt
Verdikt über einen Durchlauf	offen

Zwei Gründe, das aufzuheben. Erstens ist der Auftrag der einzige Beleg dafür, was übergeben wurde — und damit die einzige Grundlage, auf der sich später beurteilen lässt, ob das Ergebnis dazu passt. Zweitens gibt es einen Fall, in dem die Trennung nicht Bequemlichkeit ist, sondern Bedingung: Ein Agent, der seinen eigenen Durchlauf beurteilt, rechtfertigt statt zu prüfen. Ein in derselben Sitzung erzeugtes Verdikt ist nichtig, unabhängig davon, was darin steht (WORKFLOW.md, Judging a Run).

⚠️ Ein solcher Auftrag enthält keine Vorbefunde. Wer der frischen Sitzung mitgibt, was er selbst gefunden hat, bekommt eine Bestätigung statt einer Prüfung — dann ist die Trennung nur noch Aufwand.