Thore CimbalandClaude Fable 5
d31fef4b28
Erster Teil des Struktur-Workshops. Die Entwuerfe vom 2026-08-01 trugen je zwei offene Fragen; vier davon sind entschieden, die Dokumente sind damit nicht mehr Entwurf. axion1337.chat - kontrolliert wachsend: offen fuer Neue, aber jeder Eintritt wird freigegeben. Das war faktisch schon gebaut (Invite-Workflow, @concierge, befristete Gast-Accounts) und ist jetzt auch so beschlossen; die Alternativen haetten entweder den Workflow ueberfluessig gemacht oder Moderationskapazitaet verlangt, die es nicht gibt. ThreadNet - die Forks werden oeffentlich, aber erst nach einem History-Audit. Ausschlaggebend war ein Widerspruch im eigenen Dokument: Das Prinzip 'reproduzierbar fuer Dritte' zahlt sich nur oeffentlich aus, blieben die Forks privat, waere dauerhaft fuer einen Zweck gebaut worden, den es nicht gibt. Der Audit ist als Bedingung vermerkt, samt konkretem Fund: Commit 0242238 entfernte ein Klartext-TURN-Secret, das weiter in der Historie steht. ThreadNet - das Rebranding wird in M4 zu Ende gebracht statt separat terminiert. Halbfertig ist der schlechteste Zustand: Der Desktop-Client heisst ThreadNet, der Web-Client zeigt Element. Homelab - konsolidieren vor ausbauen. Massstab ist nicht 'laeuft es', sondern 'ueberlebt es den Verlust der Maschine'. Mit sorbs Nachtrag, dass die Git-Daten bereits nach S3 gesichert werden - was den Befund aus #10 entschaerft, aber die Frage offen laesst, was diese Sicherung nicht umfasst. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
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 |
|---|---|
CLAUDE.md |
Kanonische Arbeitskonventionen für alle Agenten-Sessions (Topologie, Framework, Secrets, Karpathy-Guidelines) |
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, Refinement & Retro, AARs, Werkzeuge |
hosts/, shared/ |
Bestand + Historie je Host/Thema — u. a. Branding (Marke, Paletten, wo welches Theme eingestellt ist); offene Punkte sind Issues |
Gelesen wird das alles auch gebündelt unter axionwiki.lab —
dort stehen Plattform-Wiki, Homelab-Doku und dieses Repo nebeneinander
(ADR-0006, Konfiguration in
homelab/wiki). Geändert wird immer hier, nie dort.
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.