Files

T

Thore CimbalandClaude Fable 5 92b448fe30 feat: slice 3 - wiki, sources and AARs in their neckbeard homes

Gate 4, slice 3: verfahren/, hosts/, vision/ and shared/ moved via git
mv - six AARs to docs/aar/ (four harvested by the 2026-08-09 retro,
two open), procedures and host knowledge to docs/wiki/ (admin,
deployment, architecture, new area vision), the retro protocol and the
commit mapping table to docs/sources/ (protokolle/, migration/). New:
the wiki index linking every page, and the mirror-topology page
carrying the why-two-places reasoning verbatim from the old CLAUDE.md
(F-013 preserved). All moved-path references retargeted; the link
checker drove the sweep to zero.

pruefe_prosa.py added (pattern C+D): SHA citations resolve via repo,
mapping table, optional component clones or a curated exemption list
(documented dead Gitea-force-push commits, a vendor-repo tag, an
Authentik uid that is hex but no git SHA, the external neckbeard
reference); wiki task prose without an issue reference errors, with a
visible pragma for deliberate checklists; the dead-tracker denylist
now covers every mirrored repo's retired Gitea tracker (F-005) - two
links re-verified against live GitLab titles and retargeted, five
defused into honest historical citations.

Verified: validate 0/0, gen_status --check current, drift 0. Demo on
the pre-migration state fires 6 findings (3 orphaned SHAs, 3 task
blocks); on the current tree exactly the 3 F-004 task blocks remain -
they turn green in slice 4 when the issues exist, which is why
pruefe_prosa joins CI only then.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-08-11 12:00:00 +00:00

5.8 KiB

Raw Permalink Blame History

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.

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

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

5.8 KiB Raw Permalink Blame History