Files
management/README.md
T
Thore Cimbal 21797a005a FRAMEWORK-BEFUNDE.md: wo das Verfahren nicht getragen hat
Auf Wunsch von sorb: eine Eingangsliste fuer die Framework-Ernte, damit
wiederkehrende Fehlerklassen in der naechsten neckbeard-Iteration nicht erneut
passieren muessen. Je Befund kurze Beschreibung, Ursachen-Einschaetzung, Belege
und ein Vorschlag.

Name bewusst FRAMEWORK-BEFUNDE statt 'Framework Defects': 'Befund' ist im Projekt
der feststehende Begriff (gruppenpruefung meldet Befunde, quittungen quittiert
sie, AGENTS.md: 'Jeder Befund gehoert als Issue erfasst'). 'Defect' waere zudem
zu eng - das Uebergehen der AAR-Pflicht ist kein Defekt DES Frameworks, sondern
eine Abweichung, die eine Luecke darin sichtbar macht. Umbenennen ist ein git mv.

Sieben Erstbefunde, alle aus dieser Sitzung belegt:
FB-01 AAR-Pflicht setzt sich ohne Werkzeug nicht durch
FB-02 'meldet Erfolg, ist aber blind' - sieben Vorkommen, fuenf Werkzeuge
FB-03 Pruefungen erzeugen Befunde, die niemand beheben kann
FB-04 Issues behaupten Zustaende, die laengst ueberholt sind
FB-05 Dashboards und Pruefungen ohne Datenbeleg
FB-06 Dokumente werden ergaenzt, aber nicht revidiert
FB-07 Werkzeuge messen unbemerkt die falsche Instanz

Verlinkt in README (Struktur) und roadmap (Kadenz, bei der Retro) - eine Datei,
die niemand findet, waere selbst ein Befund der Klasse FB-06.

⚠️ validate.py prueft nur unterhalb von docs/. Diese Datei ist damit NICHT
schema-geprueft - bei einer Liste ueber fehlende Durchsetzung ist das eine
Ironie, die im Refinement einen Blick wert ist.
2026-08-20 12:00:00 +00:00

5.5 KiB

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 Wo das Verfahren nicht getragen hat — Eingangsliste für die Framework-Ernte
docs/adr/ ADRs — Pflicht bei Architektur-/Prozessentscheidungen und dauerhaften Ausnahmen
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.