management/README.md

# 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](decisions/0005-pm-framework-kanban.md).

*(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](decisions/0002-issues-und-management-ins-lab.md)).
`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](verfahren/deploy-uebergabe.md)).

**Eine befristete Ausnahme:** Die **Deploy-Übergabe-Issues** laufen auf dem
Gitea-Mirror-Tracker, weil CFGMON und andere Hosts außerhalb des Labs `git.lab`
noch nicht erreichen. Abgelöst wird das durch das Site-to-Site-VPN
([ADR-0004](decisions/0004-site-to-site-vpn-hetzner-lab.md),
[Issue #12](https://git.lab/axion1337.chat/management/-/issues/12)).

## Struktur

| Pfad | Artefakt |
|---|---|
| `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](verfahren/deploy-uebergabe.md), [AARs](verfahren/aar/), Werkzeuge |
| `hosts/`, `shared/` | **Bestand + Historie** je Host/Thema — offene Punkte sind Issues |

## 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](https://git.lab/groups/axion1337.chat/-/boards)** 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**.