management/README.md

Backlogs

Zentrale Sammlung offener Punkte über alle Hosts und Dienste hinweg. Ein Eintrag landet hier, wenn er bewusst nicht sofort erledigt wurde — damit er nicht in einer Chat-Historie oder einem Kopf verschwindet.

Repo-Topologie (seit 2026-08-01)

Kanonisch lebt dieses Repo auf git.lab (axion1337.chat/Backlogs, nur im Lab bzw. via VPN erreichbar — das Lab ist die Quelle der Wahrheit). rohana.axion1337.de/sorb/Backlogs 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 bewusste Ausnahme: Die Deploy-Übergabe-Issues laufen weiter auf dem Gitea-Mirror (dortiger Issue-Tracker), weil CFGMON und andere Hosts außerhalb des Labs git.lab nicht erreichen — eine Übergabe muss aber von beiden Seiten lesbar/kommentierbar sein.

Aufbau

hosts/     ein File pro Host, benannt nach dem Hostnamen
shared/    Themen, die mehrere Hosts betreffen (DNS-Zone, Mail-Policy)
verfahren/ wiederkehrende Abläufe zwischen Personen und Hosts, plus AARs

Faustregel für die Einordnung: Der Eintrag gehört dorthin, wo die Arbeit stattfindet, nicht dorthin, wo das Symptom auftritt. Ein down-Target in Prometheus auf CFGMON, dessen Ursache ein blockierter Port auf dem Gameserver ist, gehört nach hosts/game.md — mit Querverweis von CFGMON.

Hosts

Host	Adressen	Rolle	Backlog
CFGMON	188.245.193.243, 2a01:4f8:c17:93eb::1, privat 10.0.0.3	Monitoring-Stack, Gitea, Traefik	hosts/cfgmon.md
game	157.90.155.206 (game.axion1337.de)	Pterodactyl / Gameserver	hosts/game.md
matrix	49.13.132.245 (matrix.axion1337.de)	Matrix-Homeserver	hosts/matrix.md
Overmind	10.58.73.17 (git.lab, nur im Homelab auflösbar)	GitLab + CI-Runner (Lab)	hosts/overmind.md

Übergreifend

Thema	Backlog
DNS-Zone axion1337.de und Mail-Policy (IONOS)	shared/zone-axion1337.md

Verfahren

hosts/ und shared/ halten offene Punkte, verfahren/ hält wie wir arbeiten — Abläufe, die zwischen Personen oder über mehrere Hosts hinweg gelten und deshalb an kein einzelnes Projekt-Repo gehören.

Verfahren	Inhalt
Deploy-Übergabe	„einer baut, ein anderer rollt aus": Issue-Vorlage, Prüfliste, AAR

Zur Deploy-Übergabe gehört die Issue-Vorlage .gitea/ISSUE_TEMPLATE/deploy-uebergabe.yaml — sie erscheint beim Anlegen eines Issues in diesem Repo als Deploy-Übergabe. Die Übergabe-Issues laufen auf dem Gitea-Mirror (siehe Repo-Topologie oben: CFGMON erreicht git.lab nicht), weil das Verfahren repo-übergreifend gilt; der fachliche Inhalt bleibt im jeweiligen Projekt-Repo.

Konventionen

IDs sind pro Datei fortlaufend mit einem Präfix, das den Ort benennt: CFGMON-01, GAME-01, MATRIX-01, ZONE-01 — ein Präfix pro Datei in hosts/ bzw. shared/, keine Liste losgelöst vom tatsächlichen Datei-Bestand. IDs werden nicht wiederverwendet — ein erledigter Punkt behält seine Nummer, damit Querverweise und Commit-Messages dauerhaft stimmen. Auch wenn eine ganze Datei entfällt (siehe hosts/k3s.md, entfernt 2026-07-30), wird ihr Präfix nicht für etwas anderes wiederverwendet.

Das Präfix für DNS-Themen ist bewusst ZONE- und nicht DNS-: DNS-01 ist der Name eines ACME-Challenge-Typs und käme in genau diesen Backlogs ständig als Fachbegriff vor.

Status:

Wert	Bedeutung
offen	noch nicht angefasst
in Arbeit	läuft gerade
wartet auf …	blockiert, mit Angabe worauf
erledigt	fertig, mit Datum — Eintrag bleibt stehen, siehe unten
verworfen	bewusst nicht umgesetzt, mit Datum und Begründung — nicht dasselbe wie erledigt: es ist nichts passiert, sondern es wurde entschieden, es zu lassen

Erledigte und verworfene Punkte werden nicht gelöscht, sondern nach unten in den Abschnitt „Erledigt" verschoben (verworfene Punkte darin klar als solche kennzeichnen). Der Grund: bei mehreren Hosts ist die Frage „haben wir das damals eigentlich gemacht, und warum so — oder haben wir es bewusst gelassen?" häufiger als die Frage „was ist noch offen".

Jeder Eintrag braucht einen Status, eine Beschreibung des tatsächlichen Zustands, und einen konkreten nächsten Schritt. Wenn eine Aussage nicht direkt verifiziert ist (aus einer Konsole, einer Doku, einer Ableitung statt einer Messung von dem betroffenen System selbst), wird kurz dazugeschrieben, woher sie stammt — eine unbestätigte Vermutung, die wie ein Befund aussieht, kostet beim nächsten Mal mehr Zeit als sie spart.

Zeitkritisches bekommt ein Datum in der Statuszeile, nicht nur „bald".

Gegenstücke in anderen Host-Dateien (z. B. ein Punkt, der von zwei Seiten beschrieben wird, wie ein Push von matrix auf einen offenen Port bei CFGMON) werden beim Schließen einer Seite auf der anderen Seite mitaktualisiert, nicht nur verlinkt und stehen gelassen — sonst bleibt eine Seite unbemerkt veraltet.

Verhältnis zu den Projekt-Repos

Dieses Repo hält die offenen Punkte. Die Konfiguration liegt weiter in den jeweiligen Projekt-Repos, z. B. sorb/threadnet-operating für den Monitoring-Stack auf CFGMON. Damit nichts doppelt geführt wird, verweisen die Projekt-Repos hierher statt eigene Backlog-Dateien zu pflegen.

Verhältnis zu Projekt-Issues

Die Projekt-Repos führen ihren eigenen Feature-/Fix-Backlog als Issues — seit 2026-08-01 auf git.lab (Migration per gitops#48, alte Gitea-Issues tragen einen Verweis auf ihr GitLab-Gegenstück). Das bleibt dort, wird hier nicht dupliziert. Faustregel für die Abgrenzung:

• Reiner Projekt-Scope (eine Funktion in einem Repo, ein Bug in einem Service): Issue im jeweiligen Projekt auf git.lab, kein Eintrag hier.
• Host-/Infrastruktur-Scope (betrifft einen Host direkt, oder eine Entscheidung über mehrere Hosts/Repos hinweg, z. B. wo ein CI-Runner laufen soll): Eintrag hier, mit Verweis auf betroffene Issues statt deren Inhalt zu wiederholen.
• Beides zugleich (ein Host-Thema hat ein konkretes Gegenstück als Issue, z. B. ein fehlender Gitea-Runner blockiert CI in mehreren Repos): kurzer Eintrag hier mit Link zum führenden Issue, statt den Issue-Inhalt hierher zu kopieren.