---
type: wiki-page
area: architecture
related:
  - "docs/adr/0001-gitlab-kanonisch-push-mirror.md"
  - "docs/adr/0002-issues-und-management-ins-lab.md"
  - "docs/adr/0004-site-to-site-vpn-hetzner-lab.md"
  - "docs/adr/0006-wikis-konsolidieren-docusaurus.md"
---

# Mirror-Topologie: Das Lab ist die Quelle der Wahrheit

Begründungsprosa übernommen aus der alten `CLAUDE.md` (Abschnitt
„Projektrealitäten", Wortlaut in der git-Historie vor der
neckbeard-Migration); die verbindlichen Regeln stehen in `AGENTS.md` §6
und den verlinkten ADRs. Erhalten per Feldtest-Befund F-013: Diese
Begründung samt Gegenargument und Rettungspfad ist der Wert — sie
erklärt, warum die Topologie so aussieht und so bleiben soll.

- Kanonische Repos liegen auf `git.lab/axion1337.chat/*` (nur im
  Lab/VPN auflösbar). Gitea/rohana wird per **Push-Mirror** beliefert
  und bleibt Flux-Source, Container-/npm-Registry und Release-Download
  ([ADR-0001](../../adr/0001-gitlab-kanonisch-push-mirror.md)).
- **Warum überhaupt zwei Orte — und warum das kein Altbestand ist:**
  Auf git.lab liegen die *Baupläne*, auf Gitea eine Kopie, die der
  Cluster **ohne verfügbares Lab** erreicht. Der Hetzner-Cluster muss
  sich bauen und neu ausrollen lassen, wenn das Homelab aus ist, im
  Umbau steckt oder niemand zu Hause ist — er darf deshalb nicht von
  einem Host abhängen, der nur im Lab antwortet.
  ⚠️ **Die Flux-Quelle nicht „geradeziehen"** auf git.lab: Das sähe
  aufgeräumter aus und würde die Verfügbarkeit der Produktion an das
  Lab koppeln — genau das, was die Trennung verhindert.
- **Gespiegelt wird nur die Gruppe `axion1337.chat`** (die Produkt-Repos
  und `management`). Die Gruppe **`homelab`** (`docs`, `wiki`,
  `wiki-bookstack`) hat bewusst **keine Mirrors**: Sie beschreibt und
  konfiguriert ausschließlich Lab-Infrastruktur, und seit dem
  Site-to-Site-VPN ([ADR-0004](../../adr/0004-site-to-site-vpn-hetzner-lab.md))
  erreichen auch Host-Sessions git.lab direkt — Tunnel einschalten
  genügt. Betriebslehren, die von außen lesbar sein müssen, gehören
  deshalb in die **AARs** unter `docs/aar/` (dieses Repo ist
  gespiegelt), nicht nur in die READMEs der Lab-Repos.
- Landet doch ein Commit auf Gitea (z. B. aus einer Host-Session ohne
  Lab-Route): **Kanonisierungs-Verfahren** in
  [deploy-uebergabe](../deployment/deploy-uebergabe.md) — `.patch` von
  Gitea ziehen, `git am` (erhält Autorschaft), Push über git.lab.
- ⚠️ gitops-Issue-Nummern haben sich beim Gitea-Umzug verschoben (Gitea
  zählte PRs mit; z. B. Gitea#48 → GitLab#46) — alte „gitops#N"-Verweise
  meinen die Gitea-Nummer; verbindlich ist der Migrations-Fußtext im
  Issue ([ADR-0002](../../adr/0002-issues-und-management-ins-lab.md)).
- **Ausnahme** (bewusst entschieden, nur noch eine): der
  TURN-Rotations-CronJob schreibt weiter nach Gitea, weil er im Cluster
  läuft und git.lab nicht erreicht. **Die Rotation nicht von Hand
  nachziehen und den PR nie auf Gitea mergen** — das erledigt seit
  2026-08-02 der geplante CI-Job `canonize_rotation` im gitops-Repo
  täglich von git.lab aus. Scheitert er, bleibt die Pipeline rot; diese
  rote Pipeline **ist** der Alarm, einen zusätzlichen Termin gibt es
  bewusst nicht.
- **Dokumentation** ([ADR-0006](../../adr/0006-wikis-konsolidieren-docusaurus.md)):
  Das gitops-Wiki liegt seit 2026-08-02 auf git.lab (*Wiki*-Reiter im
  Projekt); ⚠️ der `wiki`-**Branch** im gitops-Repo ist ein überholter
  Mai-Abzug von `docs/` und nicht die gepflegte Fassung. Alle Quellen
  zusammen erscheinen unter **axionwiki.lab**
  ([`homelab/wiki`](https://git.lab/homelab/wiki), Docusaurus) —
  Inhalte werden beim Bau geholt, **Änderungen gehören ins Quell-Repo**.