Thore CimbalandClaude Opus 5
8280ead37d
Three task briefs lived only in a chat and in a home directory. They are the only record of what was actually handed over, and therefore the only basis on which a result can later be judged to match its request. They land beside textbloecke.md rather than in a new directory: that page already holds "short, copyable blocks you put in front of a session", and these are the same idea at full length. Each carries its state at the top, because a brief that reads as pending when it is done is the stale-head failure this project keeps finding. The third one exists for a reason worth stating: an agent judging its own run justifies rather than checks, so that verdict must not be written by the session that produced the run. And such a brief carries no findings of the author's own - handing them over buys a confirmation instead of a check, and then the separation is only cost. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01F2Q4Ri8NGwyTZzScvKnWFM
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.