management/docs/sources/protokolle/retro-2026-08-09.md

# Retro light — 2026-08-09

Erste Retro des Frameworks, angehängt an das Refinement vom selben Tag
([Verfahren](../refinement.md)). Grundlage sind die vier AARs des Monats und 38
im August geschlossene Issues.

---

## 1. Welche Verfahren haben getragen, welche haben gestört?

### Getragen

**„Alles Offene wird ein Issue."** Das ist das Verfahren, das diesen Monat am
meisten eingebracht hat. Sämtliche stillen Fehler unten wurden nur deshalb nicht
vergessen, weil sie im Moment des Findens ein Issue bekamen — auch die, für die
gerade keine Zeit war.

**Die AAR-Pflicht.** Die vier AARs waren die einzige belastbare Vorbereitung für
diese Retro. Ohne sie wäre sie eine Erinnerungsübung geworden.

**Die Board-Pflege-Tabelle** (2026-08-06). Sie hat gehalten: `status:next` und
Meilenstein-Zuordnung blieben sorbs Entscheidung, auch als es unbequem war.
management#15 und #20 lagen drei Tage ohne Spalte — das ist der beabsichtigte
Preis, nicht ein Fehler.

### Gestört

**Der Status-Label-Satz ist in der Oberfläche nicht vollständig ablesbar.**
`status:next`, `status:doing`, `status:wartet` — und „ohne Label = Backlog". Die
vierte Spalte ist damit die einzige, die man nicht *sieht*, sondern erschließen
muss. Genau deshalb hat eine Session am 2026-08-06 ein `status:offen` erfunden und
in vier Projekten angelegt; aufgefallen ist es erst zwei Tage später.

Die Regel bleibt richtig — ein Label für „nichts Besonderes" wäre Rauschen. Aber
der Reiz, es zu erfinden, ist real und wird wiederkommen. **Festgehalten statt
geändert.**

---

## 2. Welche ADRs sind durch die Realität überholt?

**Keine überholt — aber eine Lücke.**

⚠️ **Die Commit-Konventionen und die Anonymisierung der Historie hätten eine ADR
gebraucht.** Am 2026-08-07 wurde eine dauerhafte Prozessregel eingeführt (englische
Conventional Commits, Zeitstempel auf 12:00 UTC) und am 2026-08-09 rückwirkend auf
251 Commits angewandt — eine **irreversible** Änderung an vier Repos, mit
Force-Push durch einen Mirror, von dem Flux liest.

Nach unserer eigenen Regel („ADR-Pflicht bei Architektur-/Prozessentscheidungen")
ist das ein Lehrbuchfall. Stattdessen steht die Regel nur in der `CLAUDE.md` und
die Durchführung in einer Zuordnungstabelle. Nachzuholen als **ADR-0009**.

**Beobachtung zu ADR-0005:** Das Kanban-Framework wurde diese Woche zweimal
erweitert (Titel ohne Priorität, Meilenstein-Pflicht) — beides in der `CLAUDE.md`,
nicht in der ADR. Das ist vertretbar, solange die ADR die *Entscheidung* hält und
die `CLAUDE.md` die *Regel*. Es ist aber genau die Zwei-Orte-Konstruktion, die wir
bei den Titel-Präfixen gerade aufgelöst haben. **Im Auge behalten.**

---

## 3. Fasert etwas aus?

**Nein — aber es gibt ein Muster, und das ist der eigentliche Befund des Monats.**

### Sechs stille Fehler in neun Tagen

| Was | Wie es aussah | Wie es wirklich stand |
|---|---|---|
| `build_embedded` (threadnet-call) | grün, seit jeher | lud **nie** ein Artefakt hoch, falscher Pfad |
| npm-Paket `0.19.2-threadnet.6` | veröffentlicht | 12,5 KB statt 12,8 MB, **ohne `dist/`** |
| Blueprint `matrix-recovery-flow` | Flux grün, ConfigMap aktuell | seit Tagen bei **jedem** Lauf verworfen |
| gitops-Arbeitskopie | „normal" | `main` trackte **Gitea** — ein `git push` wäre in die verbotene Richtung gegangen |
| Leere Pipelines | rot | **nichts kaputt** — der umgekehrte Fall, Rauschen, das rot abtrainiert |
| Release-Pipeline auf `v0.4.0` | lief nach Tag-Push an | hätte ein veröffentlichtes Image überschrieben |

Gefunden wurde **keiner** davon durch eine Überwachung. Vier durch Zufall beim
Suchen nach etwas anderem, zwei durch gezieltes Nachprüfen einer Behauptung.

### Das gemeinsame Merkmal

Alle sechs betreffen Vorgänge, die **erfolgreich aussehen, ohne es zu sein** — oder
die genau umgekehrt Alarm auslösen, wo nichts ist. Der Verbund hat für keinen
dieser Fälle eine Antwort auf die Frage: *Wer merkt es, wenn etwas leise aufhört zu
funktionieren?*

Es gibt Issues für Einzelfälle — gitops#50 (Configs greifen nicht ohne Neustart),
management#28 (Mirror-Ausfall unbemerkt), ThreadNet-Web#14 (Release überschreibbar,
behoben). Was fehlt, ist die Klammer.

⚠️ **Der letzte Fall ist der unangenehmste.** Dass `v0.4.0` nicht überschrieben
wurde, lag daran, dass die geschützten Registry-Variablen in genau diesem Fenster
nicht verfügbar waren — **Glück, nicht Absicht.** Eine Schutzmaßnahme, die
zufällig griff, ist kein Schutz.

### Vorschlag

Eine **Stillstandsprüfung**: ein geplanter Job, der die Invarianten prüft, die wir
diesen Monat einzeln und mühsam gelernt haben — Blueprint-Status ≠ error, Mirror
synchron, Pipeline ohne Jobs, Artefakt vorhanden, Paketgröße plausibel. Kein
weiterer Agent, der Meldungen erzeugt, sondern **eine** Prüfung mit einem Ergebnis.

Das ist die Verallgemeinerung von management#28, das am 2026-08-06 bewusst nach
hinten gestellt wurde. Die Rückstufung war zu dem Zeitpunkt vertretbar; sechs
Fälle später sieht der Einzelfall aus wie ein Symptom. **Zur Entscheidung
vorgelegt, nicht eigenmächtig umgestuft.**

---

## Beschlüsse dieses Refinements

- `status:next`: management#15 und #20 (fällig 31.08.) — Zusage von sorb
- `status:wartet` entfernt bei threadnet-call#4 und ThreadNet-Web#11: der im Issue
  benannte Grund war weggefallen
- **M5 — Härtung** angelegt, 14 Issues aus M1 verschoben. Trennlinie: *Ist etwas
  Vorhandenes kaputt (M1) oder fehlt etwas, das wir noch nie hatten (M5)?*
  Verteilung danach: M1 18 · M2 21 · M3 4 · M4 13 · M5 14

⚠️ Die beiden letzten Punkte sind einer Session **allein** untersagt
([Board-Pflege](../refinement.md)). Sie fanden im Refinement mit sorb statt. Die
Regel ist damit nicht aufgeweicht.

## Offen aus dieser Retro

1. **ADR-0009** zu Commit-Konventionen und Historien-Anonymisierung nachziehen
2. **Stillstandsprüfung** — Entscheidung von sorb