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

Keine Ausnahmen mehr. Die Deploy-Übergabe-Issues liefen bis 2026-08-02 auf dem Gitea-Tracker, weil Hosts außerhalb des Labs git.lab nicht erreichten. Mit dem Site-to-Site-VPN (ADR-0004) ist der Grund entfallen — bei eingeschaltetem Tunnel erreicht CFGMON git.lab. Sie sind umgezogen (LABNET-03), der Gitea-Tracker ist leer, die Vorlage liegt als GitLab-Issue-Template. Alle Issues leben auf git.lab.

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.