Thore CimbalandClaude Opus 5 c372665e2d docs: Gate 5 — the smoke list passed, and one criterion was unachievable
Federation answers, sign-in confirmed by the owner, a backup ran, ClamAV's
signatures are from yesterday, the wiki returns 302 from outside. One line
is not ticked: a call was not tested. Neither coturn nor the SFU was
touched, so this undertaking cannot have affected calls - but that is an
argument, not a test, and it stands here as the argument it is.

Acceptance criterion 1 of this very document is named as wrong rather than
quietly reinterpreted. It demands zero workloads left with only the broad
rule, and it was written before Gate 2 introduced the class that exists to
keep exactly that. What holds is what it should have said: every workload
is either narrowly ruled or documented as a reasoned exception at the
selector. Four remain open, all with a reason.

The pattern behind every correction in this undertaking: they came from
measuring, not from thinking about the plan. And four times the tool was
wrong rather than the subject - /dev/tcp in an sh, no nc in alloy, find
-printf in busybox, busybox TLS against Traefik. Each looked like a
finding.

Recorded for the next harvest: traffic to the node's own address escapes
the policy entirely, so every "internal only" workload still reaches
whatever the ingress publishes. Not a fault of this work, but it bounds
every statement about these rules and the framework does not know the case.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
2026-08-21 12:00:00 +00:00
2026-07-30 12:00:00 +00:00

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.

S
Description
No description provided
Readme
2.6 MiB
Languages
Python 100%