Files

T

Thore CimbalandClaude Fable 5 70e81e2ff1 feat: slice 2 - all eleven decisions ported to docs/adr

Gate 4, slice 2: decisions/0001-0011 moved via git mv with schema
frontmatter prepended (status and date taken from each body's own
Status line - 0007 stays proposed, its decision is open in #20; bodies
unchanged except relative links gaining one directory level). The old
scheme's README and template retire - their rules already live in
AGENTS.md section 6 and the neckbeard ADR template. Every reference to
decisions/ across the tree retargeted (root files, not-yet-moved
verfahren/hosts/shared files, design doc and session ADR frontmatter).

Verified: validate 0 errors (11 ported + 2 session ADRs + duplicate-id
guard), gen_status --check current with all 13 ADRs listed, drift
check 0 findings, negative test shows a cloned id 0012 firing the
duplicate check.

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