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.

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. Das ist die eine Ausnahme von der Regel unter „Verhältnis zu Gitea-Issues": die Übergabe-Issues laufen hier, 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 Gitea-Issues

Manche Projekt-Repos (z. B. sorb/axion1337.chat-gitops) führen ihren eigenen Feature-/Fix-Backlog als Gitea-Issues — 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): Gitea-Issue im jeweiligen Projekt-Repo, 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.