---
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.