nixos-config/docs/pipelines.md

Pipelines

Der Architektur-Graph (graphify-out/platform-infrastructure/) zeigt, was mit was zusammenhängt. Diese Datei zeigt stattdessen Reihenfolge und Richtung — input → output → input → output, wie eine Fertigungsstraße. Beide Ansichten ergänzen sich; diese Datei ist die Quelle der Wahrheit für pipelines.html im dashboard-Repo, nicht umgekehrt.

Deploy-Pipeline

flowchart LR
    A[Config-Änderung im Repo] --> B[nix flake check]
    B --> C["nix eval --raw .drvPath"]
    C --> D[nix build toplevel]
    D --> E[nix store diff-closures]
    E --> F{Diff plausibel?}
    F -->|nein, klären| A
    F -->|ja| G[dry-activate]
    G --> H[nixos-rebuild switch]
    H --> I[Live-System]
    I --> J["Verifikation: curl / systemctl / journalctl"]

Der Normalfall ist direktes nixos-rebuild switch; abgesichert wird über NixOS-Generationen und das Git-Repo (siehe §4 in docs/operator-prompt.md). Die hier gezeigten Prüfschritte sind optionale Werkzeuge bei konkretem Verdacht, keine Pflichtkette — Ausnahme sind Änderungen mit Aussperr-Risiko (sshd, Netzwerk, Boot).

Agenten-Delegation (Herdr)

flowchart LR
    A[Nutzer-Auftrag] --> B[Orchestrator]
    B -.fire and forget.-> C["Spezialist: eigene, atomare Session (Administrator / Orga / Agent-Manager / Graphics)"]
    C -.Skill-Rückfrage — Entwurf §4.-> B
    B -.Antwort.-> C
    C --> D[Output]
    D -->|Aktivierung im Auftrag ausdrücklich freigegeben| E[Deploy durch Spezialisten]
    D -->|Regelfall: keine Freigabe| E2[Meldet Aktivierungsschritt, stoppt]
    E --> F[Reviewer]
    E2 --> F
    C -->|keine Rückfragen offen| Z[Session wird idle]
    Z --> G[Synthese im Orchestrator]
    F -->|Befunde, read-only| G
    G -->|Korrektur nötig| C
    G --> H[Antwort an Nutzer]

Der Orchestrator delegiert fire-and-forget — er wartet nicht aktiv, sondern beendet seinen eigenen Turn nach der Übergabe (docs/herdr-orchestration.md). Jede Delegation startet als eigene, atomare Session: die Rolle ist so klar umrissen (agents/*.md), dass der Spezialist die Aufgabe bis zum Ende durcharbeitet und die Session verlässt (Pane wird idle — nicht wirklich terminiert, sonst wäre sie über herdr agent read/send nicht mehr ansprechbar), sobald keine Rückfragen mehr offen sind, statt auf weitere Anweisung zu warten. Das Idle-Werden der Session ist der Auslöser für die Synthese im Orchestrator, nicht ein separater, unabhängiger Schritt.

Deploy/Aktivierung ist kein unbedingter Teil des "funktional lösen" — alle vier Rollenverträge verlangen dafür standardmäßig eine im Auftrag ausdrücklich erteilte Freigabe (agents/admin.md: "nur wenn ausdrücklich freigegeben, sonst mit dem genauen Aktivierungsschritt melden und stoppen"; agents/agent-manager.md, agents/orga.md gleiches Muster je Aktion). agents/graphics.md hat überhaupt kein Deploy-Konzept — committet/pusht nie selbst. Der Regelfall ist also D → E2 (Aktivierungsschritt melden, stoppen); D → E (Spezialist deployed selbst) ist die Ausnahme bei expliziter Freigabe, keine automatische Folge von "fire and forget".

Review passiert danach am bereits ausgelieferten oder gemeldeten Ergebnis, nicht als Gate davor — Reviewer bleibt read-only und fließt mit seinen Befunden ebenfalls in diese Synthese ein, statt sie zu blockieren; laufen die Befunde erst nach der ersten Antwort an den Nutzer ein, löst das bei Bedarf eine Korrekturschleife zurück zum Spezialisten aus. "Fire and forget" ersetzt nicht die ursprüngliche Nutzer-Freigabe der Aufgabe selbst, nur die Notwendigkeit weiterer Zwischen-Bestätigungen während der Ausführung. Spezialisten können während der Bearbeitung außerdem jederzeit eine Skill-/Sachfrage an den Orchestrator zurückschicken — im Diagramm selbst als Entwurf markiert (§4), nicht nur im Fließtext, weil sonst diese Kante optisch nicht von der bestätigten "fire and forget"-Kante zu unterscheiden wäre (Entwurf für einen entsprechenden Rückfrage-Kanal: docs/herdr-eskalation-review-entwurf.md §4) — das ist etwas anderes als das noch unfreigegebene "Review als Standardschritt" aus §1, das hier bewusst nicht dargestellt ist.

Zugangs-/Ein-Ausgabe-Kette

flowchart LR
    P[iPhone: a-Shell] --> T[Tailscale-Mesh]
    L[Laptop: SSH] --> T
    T --> B[blunix]
    B --> TM["tmux: Herdr-Session"]
    TM --> AG[Agent-Prozess]
    AG --> OUT[Output]
    OUT --> LOG[Log / Memory]
    OUT --> DEP[Deploy]

Wie ein diktierter Prompt tatsächlich durchs System läuft, bevor überhaupt etwas passiert. Details zu a-Shell/SSH-Client sind aus der Ferne nicht verifizierbar, der Rest der Kette (Tailscale → blunix → tmux → Agent) ist mit dieser Session konsistent beobachtet.

Zettel-Transformation

flowchart LR
    A["Analog: handschriftliche DIN-A5-Seite"] --> B[Scan]
    B --> C[Digitaler Input an KI]
    C --> D["ai-magic / Transformation"]
    D --> E["Contingent digital artifact, any medium"]
    E --> F[Analog Output]

Aus memory/zettel/ (Blatt 9) — die Methode des Ursprungsprojekts selbst, nicht von der Plattform abgeleitet, sondern ihr Vorbild.