Authentik's documentation is explicit that upgrades follow the sequence of major releases and must not skip, so the path is 2026.2.3 to 2026.5.6 to 2026.8.0. Both releases state they introduce no new requirements, and their one breaking change each was checked against our state rather than assumed: the deprecated Postgres connection options are not set, the removed WebAuthn option is not set, and there are no outposts to keep in step. Scanning all three images changes the shape of the plan. The intermediate version carries the entire critical gain — five instead of twenty-seven — and 385 of the 456 high findings. The second step adds high findings only. That is what makes splitting the two steps defensible rather than timid, and 2026.8.0 is three days old, which is a poor age for the login path of the whole platform. The rollback is a database restore, not a downgrade; the documentation says so outright. The backup is nightly and was actually replayed during #0030, so the fallback is proven rather than assumed — but sessions since the backup are lost with it, and that belongs in the plan rather than in the surprise.
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 |
|---|---|
AGENTS.md |
Kanonische Arbeitskonventionen für alle Agenten-Sessions (Topologie, Framework, Secrets, Karpathy-Guidelines). CLAUDE.md zeigt nur hierher. |
WORKFLOW.md |
Gates, Größenklassen, Debugging-Pfad, Refinement-Ritual |
schema.yaml |
Frontmatter-Schema — einzige Wahrheit über den Aufbau der Artefakte |
STATUS.md |
Generierte Übersicht; nicht von Hand ändern (scripts/gen_status.py) |
roadmap.md |
Linien, Meilenstein-Kandidaten, Kadenz — die Gruppen-Milestones halten den Stand |
FRAMEWORK-BEFUNDE.md |
Erzeugter Wegweiser; die Fehlerklassen liegen als Seiten in docs/wiki/stolpersteine/, die Übersicht in STATUS.md |
docs/adr/ |
ADRs — Pflicht bei Architektur- und Prozessentscheidungen; für dauerhafte Ausnahmen gilt dieselbe Pflicht aus dem Upstream-Teil von AGENTS.md |
docs/issues/ |
Das kanonische Backlog der ganzen Gruppe (ADR-0012, ADR-0019) |
docs/design/, docs/aar/ |
Design-Dokumente je Vorhaben; AARs zu Vorfällen und größeren Abweichungen |
docs/components/ |
Eine Datei je Projekt der Gruppe — wer hier fehlt, wird zum Befund |
docs/wiki/, docs/sources/ |
Wiki-Flächen (u. a. Deploy-Übergabe/DoD, Refinement & Retro, Branding) und unveränderliche Quellen |
scripts/, verfahren/ |
Deterministische Werkzeuge — Prüfungen, Spiegel, Migration/Adoption |
Die Prüfungen sind die Alarmanlage: validate.py und gen_status.py laufen bei jedem
Push, gruppenpruefung.py und stillstandspruefung.py täglich per Zeitplan. Bekanntes
wird in scripts/befund_quittungen.tsv quittiert, nicht toleriert
(ADR-0020) — eine Prüfung, die dauerhaft
rot steht, meldet nichts mehr.
Gelesen wird die Anwender- und Betriebsdoku unter
wiki.axion1337.chat (Wiki.js,
ADR-0014). Das frühere Docusaurus-Wiki
auf axionwiki.lab existiert nicht mehr — nicht danach suchen.
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.