33363c90e3
Ausgelöst durch einen Soll/Ist-Abgleich des Agent-Managers gegen ein vom Nutzer entworfenes Delegations-Diagramm: agent-manager.md behauptete Session-Start/-Stop-Kontrolle, die es nicht hat (Starten ist Orchestrator-Funktion, Schließen ist für niemanden verdrahtet). Neuer Zielbild-Abschnitt in herdr-orchestration.md dokumentiert das vom Nutzer gewünschte atomare Self-Close-Verhalten explizit als Entwurf mit den technischen Voraussetzungen dafür, nicht als Ist-Zustand. orga.md an die bereits getroffene 31.08.-Policy zu Kalender-Schreibrechten angeglichen. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FTxMGYHPd7YrRBtgvRtqNk |
||
|---|---|---|
| .. | ||
| README.md | ||
Diagramme (draw.io)
Ergänzt docs/pipelines.md (Mermaid, textbasiert, kein GUI-Editing) um
ein Format, das sich per Maus editieren lässt — ausgelöst durch die
Frage, ob es dafür eine schematische Oberfläche gibt, die sowohl am
Laptop mit Maus/Tastatur als auch im Terminal bearbeitbar ist, und die
für mich (Claude) lesbar bleibt.
Editor: https://schema.0ff.space — selbst gehosteter
draw.io/diagrams.net-Webclient, Tailnet-only
(hosts/blunix/localServices/drawio.nix). Nur der statische Webapp-Teil
von upstream, kein Java/Tomcat/Docker — läuft mit static-web-server,
demselben Muster wie dashboard/launcher/tasks.
Warum draw.io statt Excalidraw: draw.io bindet Pfeile fest an Knoten-IDs (echter Graph aus Boxen+Kanten), Excalidraws Pfeile sind freier mit den Formen verbunden — für maschinelles Verstehen (Claude, später eventuell Graphify) ist draw.ios striktere Struktur zuverlässiger lesbar.
Speicherformat
.drawio-Dateien sind XML (mxGraphModel). Diese hier sind bewusst
unkomprimiert gespeichert (draw.io kann beides lesen/schreiben) —
komprimiert wäre eine Binärblob-artige Base64/Deflate-Zeile, damit weder
git-diffbar noch von mir lesbar. Beim Speichern in der draw.io-UI unter
Edit → "Diagram Properties" prüfen, dass komprimiertes Speichern
deaktiviert ist, sonst wird der nächste Commit ein einzeiliger Blob statt
eines lesbaren Diffs.
Workflow
Kein automatischer Datei-Transport — bewusst einfach gehalten, kein zusätzlicher Dienst dafür nötig:
- Ich schicke die
.drawio-Datei direkt im Chat. - Lokal öffnen — entweder
https://schema.0ff.space(Tailnet, "Open Existing Diagram" → "Device") oder eine lokal installierte draw.io-App. - Mit Maus/Tastatur bearbeiten (Boxen verschieben, Kanten ziehen, Beschriftungen ändern).
- Bearbeitete Datei zurückschicken — ich übernehme sie ins Repo und committe.
(Ein früherer Versuch, das über einen ?url=-Parameter automatisch aus
dem Repo nachzuladen, scheiterte an einem noch ungeklärten
"file not found" in der draw.io-UI trotz funktionierendem HTTP/TLS/CORS
auf Server-Seite — der zusätzliche Dienst dafür wurde wieder entfernt,
nicht des Debuggens wert für das, was der manuelle Chat-Transfer genauso
gut löst.)
Für Terminal-Edits (meine Seite): direkt die XML bearbeiten — jeder
Knoten ist eine <mxCell id="..." value="...">, jede Kante hat
source/target auf diese IDs. Kein Build-Schritt nötig, draw.io liest
die Datei beim nächsten Öffnen einfach neu ein.
Verhältnis zu docs/pipelines.md
docs/pipelines.md (Mermaid) bleibt die Quelle der Wahrheit für die
Dashboard-Ansicht (pipelines.html, gerendert, mit
Kommentar-Verlinkung zu Forgejo) — Mermaid ist leichtgewichtig und
bereits in den Graphify-Korpus eingebunden. .drawio-Dateien hier sind
der Editier-Layer: zum Durchdenken/Umbauen einer Pipeline-Struktur
per Maus, bevor die finale Fassung von Hand zurück nach
docs/pipelines.md übertragen wird. Beide halten sich also bewusst
nicht automatisch synchron — wer eine .drawio-Datei ändert, überträgt
das Ergebnis manuell in die Mermaid-Fassung, wenn es fertig ist.
Bestehende Dateien
agenten-delegation.drawio— Testmigration der Agenten-Delegations-Pipeline ausdocs/pipelines.md, zum Beweis, dass der Round-Trip (Terminal-XML → draw.io-UI → zurück) funktioniert.