Thore CimbalandClaude Fable 5
c481165ab4
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>
86 lines
3.9 KiB
Markdown
86 lines
3.9 KiB
Markdown
---
|
|
type: adr
|
|
id: "0013"
|
|
status: accepted
|
|
date: 2026-08-11
|
|
supersedes: null
|
|
superseded_by: null
|
|
related:
|
|
- "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.
|