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](verfahren/deploy-uebergabe.md)).

**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](hosts/cfgmon.md) |
| **game** | `157.90.155.206` (`game.axion1337.de`) | Pterodactyl / Gameserver | [hosts/game.md](hosts/game.md) |
| **matrix** | `49.13.132.245` (`matrix.axion1337.de`) | Matrix-Homeserver | [hosts/matrix.md](hosts/matrix.md) |
| **Overmind** | `10.58.73.17` (`git.lab`, **nur im Homelab auflösbar**) | GitLab + CI-Runner (Lab) | [hosts/overmind.md](hosts/overmind.md) |

## Übergreifend

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

## Verfahren

`hosts/` und `shared/` halten **offene Punkte**, [verfahren/](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](verfahren/deploy-uebergabe.md) | „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.