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

decisions/0008-agenten-sessions-root-aequivalent.md

@@ -0,0 +1,80 @@
+# 0008 — Agenten-Sessions auf CFGMON laufen root-äquivalent über die docker-Gruppe
+
+**Status:** akzeptiert · **Datum:** 2026-08-06 (Struktur-Workshop [#17](https://git.lab/axion1337.chat/management/-/issues/17)) · **Entscheider:** sorb
+
+## Kontext
+
+`sudo` ist aus einer Agenten-Session nicht bedienbar: Es gibt kein TTY, also auch
+keine Passworteingabe (*„a terminal is required to read the password"*). Die
+LABNET-02-Nacht lief deshalb über die **docker-Gruppenmitgliedschaft** des Kontos
+`rantanplan` — privilegierter Container plus `nsenter` in die Host-Namespaces.
+
+Das ist **root-äquivalent**, und zwar ohne Umweg: Wer Docker steuern darf, darf
+alles. Auf Linux ist das normales Verhalten der docker-Gruppe und kein
+Konfigurationsfehler — aber es hat zwei Folgen, die benannt gehören:
+
+1. Die **sudo-Passwortabfrage ist für dieses Konto keine Sicherheitsgrenze**. Sie
+   sieht aus wie eine, ist aber umgehbar, ohne dass jemand etwas umgehen wollte.
+2. Dieser Weg hinterlässt **keinen Eintrag in `auth.log`**. Was über die
+   docker-Gruppe geschieht, ist im Nachhinein nicht aus den üblichen
+   Protokollen rekonstruierbar.
+
+Aufgedeckt im [CFGMON-AAR](../verfahren/aar/2026-08-01-labnet02-cfgmon.md)
+(Befund 3, MEDIUM), erfasst als
+[#14](https://git.lab/axion1337.chat/management/-/issues/14).
+
+## Entscheidung
+
+**Es bleibt so — ausdrücklich und dokumentiert.** Agenten-Sessions auf CFGMON
+arbeiten root-äquivalent über die docker-Gruppe.
+
+Daraus folgt unmittelbar: **Auf diesem Host gilt „sudo mit Passwort" nicht als
+Kontrollmechanismus.** Wer dort Sicherheit gegen unbeabsichtigte oder
+unerwünschte Änderungen braucht, muss sie woanders aufhängen — an der
+Erreichbarkeit des Hosts, an der Vergabe der Zugangsdaten, an der Frage, wer
+überhaupt eine Session starten kann.
+
+**Ziel bleibt Option C** (eigenes Agenten-Konto mit definierter, protokollierter
+Rechteerhöhung), aber **erst wenn ein zweiter Mensch mitarbeitet**. Der Nutzen von
+C ist Zuordnung — nachvollziehen zu können, *wer* was getan hat. Im
+Ein-Personen-Betrieb gibt es niemanden, gegen den diese Zuordnung schützen würde;
+sie wäre Aufwand ohne Adressaten.
+
+## Konsequenzen
+
+- **Der Arbeitsweg bleibt funktionsfähig.** Host-Sessions können weiterarbeiten;
+  ohne diese Entscheidung wäre LABNET-02 gar nicht durchführbar gewesen.
+- **Die Protokollierung fehlt und wird nicht ersetzt.** Wer im Nachhinein wissen
+  will, was eine Session auf CFGMON getan hat, findet es **nicht** in `auth.log`,
+  sondern nur in Git-Historie, Issues und AARs. Das ist der Grund, warum die
+  AAR-Pflicht und „alles Offene wird ein Issue" auf diesem Host besonders zählen —
+  sie sind hier der einzige Nachvollzug.
+- **Ein kompromittiertes `rantanplan`-Konto ist ein kompromittierter Host.** Nicht
+  neu durch diese Entscheidung, aber jetzt ausgesprochen.
+- **Auslöser für Option C** ist ein zweiter Mensch mit Zugang — nicht ein Datum.
+  Kommt einer dazu, wird diese ADR abgelöst.
+
+## Offen, bewusst nicht vor der Entscheidung geklärt
+
+Das Issue verlangte vorab zu klären, **welche anderen Konten in der docker-Gruppe
+sind und ob dasselbe auf MATRIX gilt**. Beides ist ungeprüft — dafür braucht es
+eine Host-Session, vom Mac aus ist es nicht einsehbar.
+
+Das ändert an der Entscheidung nichts (sie betrifft den Weg, nicht seinen Umfang),
+wohl aber an ihrer Reichweite: Sollte sich zeigen, dass weitere Konten in der
+Gruppe sind, ist zu prüfen, ob die alle dort hingehören. Nachzuholen bei der
+nächsten Host-Session, festgehalten in #14.
+
+## Verworfene Alternativen
+
+- **B — Konto aus der docker-Gruppe nehmen**, Docker-Zugriff über gezielte
+  sudo-Regeln. Auditierbar, aber es **legt Agenten-Sessions auf CFGMON lahm**:
+  `sudo` braucht ein TTY, das eine Session nicht hat. Löst ein Protokollproblem,
+  indem es den Arbeitsweg entfernt — vertretbar erst, wenn ein Ersatz steht.
+- **C sofort** — getrenntes Agenten-Konto mit protokollierter Rechteerhöhung.
+  Sauberste Lösung, aber echte Arbeit für einen Nutzen, der im
+  Ein-Personen-Betrieb nicht anfällt. Bleibt das Ziel, siehe oben.
+- **Stillschweigend so lassen.** Genau das ist der Fehler, den ADR-0002 und die
+  ADR-Pflicht für dauerhafte Ausnahmen adressieren: Eine Ausnahme nur zu
+  dokumentieren statt sie zu entscheiden, ist keine Entscheidung. Deshalb diese ADR
+  und nicht bloß ein Absatz in `hosts/cfgmon.md`.

verfahren/README.md

@@ -11,6 +11,8 @@ nicht an einem einzelnen Projekt-Repo hängen.
 
 [`textbloecke.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](deploy-uebergabe.md).
 
 Die zugehörige Issue-Vorlage liegt unter
 `.gitlab/issue_templates/Deploy-Übergabe.md` und erscheint beim Anlegen eines

verfahren/refinement.md

@@ -4,6 +4,21 @@ Kanban braucht wenige, aber verlässliche Termine, sonst verkommt das Board zur
 Ablage. Festgelegt in [ADR-0005](../decisions/0005-pm-framework-kanban.md); 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:
@@ -42,6 +57,26 @@ ermöglicht, welche Lehren, was bleibt offen. **Offene Punkte aus einem AAR werd
 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

verfahren/textbloecke.md

@@ -67,6 +67,13 @@ 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](deploy-uebergabe.md) — 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.