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

```mermaid
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)

```mermaid
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

```mermaid
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

```mermaid
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.