Files

T

Thore CimbalandClaude Fable 5 c481165ab4 docs: Gate 5 closeout - AAR, harvest, design doc done

The design doc closes with its AAR (planned/actual/why/learnings, the
six acceptance criteria checked off 6/6, the session's shakiest calls
named) and moves to docs/design/done/ with status done. Harvest: a
stolpersteine wiki page distilled from the AAR (hex is not a git SHA,
TZ on the git process, python floor, anonymous Gitea negatives,
negative tests, directory links), and the neckbeard feedback list
becomes issue 0040 - a deliberate separate act, per the design's
non-goals. Operational follow-up is issues 0041 (refine imported
wartegrund) and 0042 (go-live: push, first mirror run, CI schedule,
milestone for gitops#61). Final chain green: validate 0/0 over 36 open
issues, gen_status --check current, drift 0, prosa 0.

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

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

3.9 KiB

Raw Blame History

type, id, status, date, supersedes, superseded_by, related

type

status

date

supersedes

superseded_by

adr

0013

accepted

2026-08-11

null

docs/design/done/2026-08-11-neckbeard-migration.md

docs/adr/0001-gitlab-kanonisch-push-mirror.md

ADR-0013: Gruppenregeln kanonisch im management-Repo, Komponenten zeigen und werden geprüft

Kontext

Fünf Komponenten-Repos und dieses Repo teilen ein Regelwerk. Neckbeards ADR-0001 löst „ein Repo, viele Harnesse", nicht „viele Repos, ein Regelwerk" — die schärfste Lücke des Feldtests. Der alte Ansatz war bereits Pointer-basiert („Projekt-Repos haben eigene CLAUDE.mds", die Arbeitsgrundlage liegt im management-Repo, über den Gitea-Mirror von überall lesbar) und scheiterte nicht am Mechanismus, sondern an der Anwendung: 4 von 5 Komponenten haben schlicht keine Pointer-Datei (F-011), und nichts prüfte das. Zusätzlich tragen fünf Komponenten vier Namensschemata, ohne dass ein Artefakt den kanonischen Slug festhält (F-008) — diese Session musste die Slugs erfragen.

Optionen

A: Regelkopien in jede Komponente stempeln (generiert, mit Quell-SHA; Prüfskript vergleicht). Funktioniert offline im Komponenten-Checkout. Aber: sechs Kopien derselben Regeln sind genau die Drift-Maschine, die ADR-0001 upstream verwirft — der Stempel macht Drift erkennbar, nicht unmöglich, und jeder Regeländerung folgt ein Sechs-Repo-Commit-Zug.

B: Git-Submodule/Subtree eines Regel-Repos. Mechanisch streng, aber: koppelt jeden Komponenten-Clone an Lab-Erreichbarkeit, ist in Obsidian und Forge-Ansichten sperrig, und die Gruppe hat mit Submodules keinerlei Praxis — Reibung ohne belegten Bedarf.

C: Pointer + deterministische Prüfung. Die Gruppenregeln stehen genau einmal, im AGENTS.md dieses Repos (das gespiegelt und damit überall lesbar ist). Jede Komponente trägt nur Projektspezifika plus einen Pointer auf die Gruppenregeln (git.lab-Pfad und Mirror-URL). Neu gegenüber dem alten Ansatz ist der prüfende Teil: ein Artefakt benennt die Gruppe, ein Skript prüft die Anwendung.

Entscheidung

Option C.

Kanonisch: die Gruppenregeln leben als ausgewiesener Abschnitt im AGENTS.md dieses Repos. CLAUDE.md wird Ein-Zeilen-Pointer (neckbeard ADR-0001).
Komponenten-Artefakt: docs/components/<slug>.md (neuer Schema-Typ) deklariert je Repo den kanonischen Slug, Anzeigenamen, Mirror-Pfad und die Phase (active / staged / external) — damit ist F-008 maschinenlesbar beantwortet und die bewusst gestaffelte Dormanz von thread-net-git/threadnet-operating (F-009-Addendum) erstmals repräsentierbar statt nur mündlich.
Prüfung, zweigeteilt: offline prüft validate.py die Komponenten-Artefakte wie jedes andere Artefakt; in der Lab-CI prüft die Stillstandsprüfungs-Familie (a) dass jede deklarierte Komponente die Pointer-Datei tatsächlich trägt (schließt F-011) und (b) dass die zur Laufzeit gelesene Gruppenliste und docs/components/ deckungsgleich sind — die Projektliste bleibt bewusst ungehärtet im Code (Retro-Lehre: eine gepflegte Liste ist die Stelle, an der ein neues Repo jahrelang durchrutscht); neu auftauchende Repos werden Befund statt Lücke.
Rollout der Pointer-Dateien in die fünf Komponenten ist nicht Teil dieser Undertaking: fünf Folge-Issues, eines je Komponente.

Konsequenzen

Regeländerung = ein Commit in einem Repo; Komponenten folgen per Verweis, nicht per Kopie.
Eine Komponente ohne Pointer ist ab dem Rollout ein roter CI-Befund, kein stiller Zustand über Wochen (F-011-Klasse).
Die Slug-Unregelmäßigkeiten selbst (thread-net-git, CamelCase-ThreadNet-Web) werden hier nicht bereinigt — ein Rename fasst Forge-Zustand an und wird eigenes Issue mit eigener Abwägung; das Artefakt dokumentiert bis dahin den Ist-Stand.
Host-Sessions ohne Lab finden Regeln und Gruppenliste über den Gitea-Mirror; der Pointer nennt beide Wege.

3.9 KiB Raw Blame History