Thore CimbalandClaude Fable 5
70e81e2ff1
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>
3.4 KiB
type, id, status, date, supersedes, superseded_by, related
| type | id | status | date | supersedes | superseded_by | related |
|---|---|---|---|---|---|---|
| adr | 0006 | accepted | 2026-08-02 | null | null |
0006 — Wikis ins Lab konsolidieren, Docusaurus als gemeinsame Lesefläche
Status: akzeptiert · Datum: 2026-08-02 · Entscheider: sorb
Kontext
Die Dokumentation lag an drei Orten mit drei Ständen, was beim Audit auffiel:
- Gitea-Wiki-Repo
…gitops.wiki.git— 15 Seiten, gepflegt bis 2026-07-31. Vom Push-Mirror nicht erfasst: ein Wiki ist ein eigenes Repo, kein Branch. wiki-Branch im gitops-Repo — Stand 2026-05-14, mitgezogen, weil der Mirror alle Branches trägt. Inhalt: ein damaliger Abzug vondocs/, kein gepflegtes Wiki.docs/im main-Branch — die eigentliche, laufend gepflegte Repo-Doku.
Dazu waren die GitLab-Wikis aller Projekte leer, und die Wiki-Inhalte enthielten sachlich falsche Aussagen (node-exporter-DaemonSet als aktive Komponente, obwohl am 2026-08-01 entfernt; Issues „in Gitea", obwohl migriert).
Entscheidung
Das Wiki zieht ins Lab und wird Teil der git.lab-Wahrheit: Die 15 Seiten liegen im GitLab-Wiki des gitops-Projekts (Wiki-Reiter). Damit entfällt die letzte „direkt-zu-Gitea"-Ausnahme aus ADR-0001.
Eine gemeinsame Lesefläche statt einer gemeinsamen Struktur: Das Repo
homelab/wiki baut mit Docusaurus eine Seite unter
axionwiki.lab, die drei Quellen nebeneinander zeigt — Plattform (gitops-Wiki),
Homelab (homelab/docs), Arbeitsweise (management). Die Inhalte werden beim Bau
eingesammelt; das Wiki-Repo enthält selbst keinen Text.
Konsequenzen
- Änderungen gehören ins Quell-Repo, nie ins Wiki-Repo — was dort in
content/landet, wird beim nächsten Bau überschrieben. - Der Bau läuft in der Lab-CI (nur dort gibt es Lesezugriff auf die Quellen) und legt ein statisches Image in der Lab-Registry ab; Dokploy deployt es. Ein Pipeline-Zeitplan ist der eigentliche Aktualisierungsmechanismus: Das Wiki folgt den Quellen, ohne dass jemand im Wiki-Repo committen muss.
- Voraussetzung: Jedes Quell-Repo muss das Wiki-Projekt in seinen Job token permissions freigeben.
- Jede Quelle bleibt ohne dieses Tool lesbar (direkt im Repo oder in der
GitLab-Oberfläche). Deshalb bringen die Quellen keine Docusaurus-Metadaten mit und
.mdwird als CommonMark statt MDX geparst. - Der
wiki-Branch im gitops-Repo ist überholt. Er bleibt vorerst als Historie stehen, ist aber in README und CLAUDE.md ausdrücklich als „nicht die gepflegte Fassung" markiert. Löschen wäre sauberer — Entscheidung dazu steht aus (Issue #19).
Verworfene Alternativen
- Alles in ein Repo verschmelzen: Die Quellen haben unterschiedliche Leser und Halbwertszeiten; eine gemeinsame Struktur hätte alle drei schlechter gemacht.
- Wiki auf Gitea belassen: widerspricht ADR-0002 und hielt eine Ausnahme am Leben, die niemand mehr begründen konnte.
- Inhalte per Submodule einbinden statt beim Bau klonen: Submodules hätten die Quellen an feste Commits gebunden — genau das Gegenteil von „das Wiki folgt den Quellen".
- MkDocs/Wiki.js: Docusaurus gewählt wegen Multi-Instanz-Docs (die Bereiche nebeneinander) und weil es rein statisch ausliefert — kein Server, keine Datenbank, kein Betriebsaufwand.