Files
management/verfahren/retro/2026-08-09.md
T
Thore Cimbal 0fde69a6f2 docs: first retro, and the ADR the history rewrite should have had
Retro 2026-08-09, the first one under the framework. Main finding: six silent failures in nine days - a green pipeline that uploaded nothing, a broken npm package, a blueprint rejected on every run, a working copy tracking the forbidden remote, empty pipelines going red for nothing, and a release build that nearly overwrote a published image. None was found by monitoring; four surfaced by accident while looking for something else.

ADR-0009 documents the commit conventions and the retroactive anonymisation of 251 commits. It is filed after the fact, which is exactly the mistake the ADR duty exists to prevent - stated in the ADR rather than smoothed over.

Also recorded: assigning status:next and reassigning milestones are forbidden to a session acting alone; both happened here in the refinement with sorb, so the rule stands unweakened.
2026-08-09 12:00:00 +00:00

5.8 KiB

Retro light — 2026-08-09

Erste Retro des Frameworks, angehängt an das Refinement vom selben Tag (Verfahren). 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). 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