← zurück zu System

Pipelines

Der Architektur-Graph zeigt, was mit was zusammenhängt. Das hier zeigt stattdessen Reihenfolge und Richtung — input → output → input → output, wie eine Fertigungsstraße. Beide Ansichten ergänzen sich, keine ersetzt die andere. Klick auf einen Knoten öffnet einen vorausgefüllten Forgejo-Issue, um direkt am Diagramm zu kommentieren.

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"]
    click A commentDeploy
    click B commentDeploy
    click C commentDeploy
    click D commentDeploy
    click E commentDeploy
    click F commentDeploy
    click G commentDeploy
    click H commentDeploy
    click I commentDeploy
    click J commentDeploy

Folgt der in CLAUDE.md dokumentierten Verifikationskaskade. Nicht jeder Schritt ist im Nachhinein per Journal belegbar (flake check/build/ diff-closures laufen non-sudo, ohne Log-Spur) — bei Boot-/Netzwerk-/Firewall-/sshd-/Secret-Änderungen kommt zusätzlich ein nixos-rebuild test-Fallback dazwischen, hier zur Übersicht weggelassen.

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]
    click A commentDelegation
    click B commentDelegation
    click C commentDelegation
    click D commentDelegation
    click E commentDelegation
    click E2 commentDelegation
    click F commentDelegation
    click G commentDelegation
    click H commentDelegation
    click Z commentDelegation

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]
    click P commentAccess
    click L commentAccess
    click T commentAccess
    click B commentAccess
    click TM commentAccess
    click AG commentAccess
    click OUT commentAccess
    click LOG commentAccess
    click DEP commentAccess

Wie ein diktierter Prompt tatsächlich durchs System läuft, bevor überhaupt etwas passiert.

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]
    click A commentZettel
    click B commentZettel
    click C commentZettel
    click D commentZettel
    click E commentZettel
    click F commentZettel

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

Deep-Research-Agent

flowchart TD
    A[Forschungsauftrag] --> B["Agent: Frage, Scope und Ziel schärfen"]
    B --> C["Research Contract: Teilfragen, Quellenstandard, Budget und Abbruchkriterien"]
    C --> D["Agent: Hypothesen und priorisierte Arbeitsliste"]
    D --> E{"Agent wählt nächsten Werkzeugaufruf"}

    E --> T1["Websuche / Browser"]
    E --> T2["Paper-, PDF- und Dokumentparser"]
    E --> T3["Lokaler Korpus / Code-Suche"]
    E --> T4["Rechnen / strukturierte Datenanalyse"]

    T1 --> F[Beobachtung]
    T2 --> F
    T3 --> F
    T4 --> F
    F --> G["Evidenzspeicher: Fundstelle, Claim, Beleg, Datum, Provenienz"]
    G --> H["Agent: Claim Map, Widersprüche und Unsicherheit aktualisieren"]
    H --> I{"Abdeckung und Qualität ausreichend?"}
    I -->|nein| J["Agent: Lücke bestimmen und Arbeitsliste neu priorisieren"]
    J --> E
    I -->|ja| K["Agent: Synthese entlang belegter Claims"]
    K --> L["Agent: Citation Audit und Gegenbeispiel-Suche"]
    L -->|Lücke gefunden| J
    L -->|tragfähig| M["Research Report: Ergebnis, Belege, Grenzen, offene Fragen"]

    click A commentResearch
    click B commentResearch
    click C commentResearch
    click D commentResearch
    click E commentResearch
    click T1 commentResearch
    click T2 commentResearch
    click T3 commentResearch
    click T4 commentResearch
    click F commentResearch
    click G commentResearch
    click H commentResearch
    click I commentResearch
    click J commentResearch
    click K commentResearch
    click L commentResearch
    click M commentResearch

Alle Entscheidungen bleiben in einer Agenten-Session mit einem gemeinsamen Zustand. Die Werkzeuge sind passiv: Der Agent wählt jeden Aufruf, bewertet dessen Beobachtung und aktualisiert selbst Arbeitsliste, Evidenz und Claims. Die als Agent markierten Knoten sind Phasen dieses einen Agenten, keine delegierten Rollen. Die Recherche endet durch explizite Qualitäts-/Abbruchkriterien — nicht dadurch, dass bereits genug Text geschrieben wurde.

Evidenzspeicher — internes Schema

flowchart LR
    Q["Research Question
id · scope · status"] --> C["Claim
id · assertion · type · status"]
    S["Source
id · title · author · date · url · retrieved_at"] --> P["Passage
id · source_id · locator · excerpt · context"]
    P --> E["Evidence Link
passage_id · claim_id · relation · strength"]
    E -->|supports / contradicts / qualifies| C
    C --> A["Assessment
confidence · freshness · consensus · caveats"]
    C --> R["Report Statement
claim_id · citation_ids"]
    A --> R

    click Q commentEvidence
    click S commentEvidence
    click P commentEvidence
    click E commentEvidence
    click C commentEvidence
    click A commentEvidence
    click R commentEvidence

Die Quelle und ihr genauer Fundort bleiben getrennt: Eine Quelle kann viele Passagen liefern, und dieselbe Passage kann über Evidence Link mehrere Claims stützen, einschränken oder widerlegen. Der Bericht referenziert Claim- und Evidenz-IDs, statt Quellen erst beim Schreiben lose anzuhängen. So bleiben Provenienz, Widersprüche und spätere Neubewertungen erhalten.