Thore CimbalandClaude Fable 5
09bdd94da6
Die Umwidmung ist in ADR-0002, ADR-0005 und dem README beschrieben - die Verweise darauf hatte ich beim Umbau aber nie nachgezogen. Drei Stellen nannten weiter den alten Namen, eine davon mit gleich drei falschen Aussagen im Praesens. overmind.md, 'Repo-Topologie (Kontext)': sprach von '5 gespiegelten Repos' und 'Gitea bleibt: ... Issues, Backlogs (dieses Repo, ungespiegelt)'. Es sind sechs (die fuenf Produkt-Repos plus management), die Issues liegen seit ADR-0002 auf git.lab, und dieses Repo wird seit der Umwidmung selbst gespiegelt - es behauptete also das Gegenteil des heutigen Zustands. cfgmon.md: zwei Nennungen entschaerft. Beide stehen in Analyse-Abschnitten vom 2026-07-31 und sind als Historie richtig, lasen sich aber wie Gegenwart - 'Explizit nicht rueckbaubar' galt fuer den damaligen Gitea-CI-Rueckbau, nicht auf Dauer. Datierte Marker statt Umschreiben. Ausserdem trug der CFGMON-12-Abschnitt eine Liste 'Noch auf Gitea: Issues, Meilensteine, Wiki', obwohl die Migration am 2026-08-02 mit 62 Issues durch ist. Ergebnis vorangestellt, der Rest bleibt als Vorher-Stand stehen. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
management
Steuerungs-Repo für alles über den einzelnen Projekten: Visionen, Roadmap, Entscheidungen (ADR), Arbeitsverfahren, AARs — und der Bestand der Hosts. Framework: Kanban-Rückgrat mit leichten Scrum-Elementen, begründet und im Detail festgelegt in ADR-0005.
(Bis 2026-08-01 hieß dieses Repo Backlogs und führte offene Punkte als
Markdown — die leben jetzt als Issues, siehe unten.)
Repo-Topologie (seit 2026-08-01)
Kanonisch lebt dieses Repo auf git.lab (axion1337.chat/management, nur im
Lab bzw. via VPN erreichbar — das Lab ist die Quelle der Wahrheit,
ADR-0002).
rohana.axion1337.de/sorb/management ist ein Push-Mirror: git.lab
überschreibt ihn bei jedem Push per Force. Deshalb nie direkt zu Gitea
pushen — solche Commits gehen beim nächsten Mirror-Lauf verloren (Rettung:
.patch von Gitea ziehen + git am, siehe
Kanonisierung).
Eine auslaufende Ausnahme: Die Deploy-Übergabe-Issues laufen noch auf dem
Gitea-Mirror-Tracker, weil Hosts außerhalb des Labs git.lab historisch nicht
erreichten. Seit 2026-08-01 steht das Site-to-Site-VPN
(ADR-0004) — bei eingeschaltetem
Tunnel erreicht CFGMON git.lab. Der Umzug der Übergabe-Issues und der Rückbau
dieser Ausnahme sind Folgearbeit.
Struktur
| Pfad | Artefakt |
|---|---|
CLAUDE.md |
Kanonische Arbeitskonventionen für alle Agenten-Sessions (Topologie, Framework, Secrets, Karpathy-Guidelines) |
vision/ |
Eine Vision je Linie: Community (axion1337.chat), Tool (ThreadNet), Plattform (Homelab) |
roadmap.md |
Linien, Meilenstein-Kandidaten, Kadenz — GitLab-Milestones halten den Stand |
decisions/ |
ADRs — Pflicht bei Architekturentscheidungen und dauerhaften Ausnahmen |
verfahren/ |
Wie wir arbeiten: Deploy-Übergabe/DoD, Refinement & Retro, AARs, Werkzeuge |
hosts/, shared/ |
Bestand + Historie je Host/Thema — u. a. Branding (Marke, Paletten, wo welches Theme eingestellt ist); offene Punkte sind Issues |
Gelesen wird das alles auch gebündelt unter axionwiki.lab —
dort stehen Plattform-Wiki, Homelab-Doku und dieses Repo nebeneinander
(ADR-0006, Konfiguration in
homelab/wiki). Geändert wird immer hier, nie dort.
Das Backlog: Issues + Board
Alle offenen Punkte sind Issues in diesem Projekt (host-/infra-Scope, mit
host:-Labels; die alten IDs wie CFGMON-01 bleiben im Titel) bzw. in den
Produkt-Projekten der Gruppe (Projekt-Scope). Das
Gruppen-Board zeigt alles
über die status:-Labels:
| Label | Bedeutung | Policy |
|---|---|---|
| (keins) | Backlog | wird im Refinement gesichtet |
status:next |
als Nächstes gezogen | die einzige „Zusage" (Pull nach Kapazität) |
status:doing |
in Arbeit | WIP-Limit: max. 2 |
status:wartet |
blockiert | nur mit benanntem Grund im Issue |
Genau ein status:-Label pro Issue. Prioritäten weiter über priority:*.
Konventionen (unverändert gültig)
IDs (CFGMON-01, ZONE-01, …) werden nie wiederverwendet; sie leben in
Issue-Titeln weiter. Neue host-/infra-Punkte bekommen die nächste freie Nummer
ihres Präfixes als Issue.
Jeder Punkt braucht eine Beschreibung des tatsächlichen Zustands und einen konkreten nächsten Schritt; nicht selbst Verifiziertes wird als solches markiert (woher stammt die Aussage?). Zeitkritisches bekommt ein Datum, nicht „bald".
Erledigtes und Verworfenes bleibt sichtbar: Issues werden geschlossen (nicht
gelöscht), verworfen wird im Schlusskommentar begründet — der Unterschied
zwischen „gemacht" und „bewusst gelassen" ist die häufigste Rückfrage.
Verhältnis zu den Projekt-Repos
Konfiguration lebt in den Projekt-Repos (z. B. threadnet-operating für den
CFGMON-Stack), reine Projekt-Bugs/-Features in deren Issues auf git.lab.
Hierher gehört, was mehrere Hosts/Repos betrifft oder eine Entscheidung ist.
Ein Punkt, der von zwei Seiten beschrieben wird, verlinkt die andere Seite und
wird beim Schließen dort mitaktualisiert.