332 lines
15 KiB
HTML
332 lines
15 KiB
HTML
<!DOCTYPE html>
|
|
<html lang="de">
|
|
<head>
|
|
<meta charset="UTF-8">
|
|
<meta name="apple-mobile-web-app-capable" content="yes">
|
|
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">
|
|
<link rel="icon" href="/icon-192.png" type="image/png">
|
|
<link rel="apple-touch-icon" href="/icon-192.png">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover">
|
|
<meta name="color-scheme" content="light dark">
|
|
<meta name="theme-color" content="#000000">
|
|
<title>Pipelines — [dashboard]</title>
|
|
<link rel="manifest" href="manifest.json?v=2">
|
|
<link rel="stylesheet" href="style.css">
|
|
<link rel="stylesheet" href="system.css">
|
|
<script src="mermaid.min.js"></script>
|
|
</head>
|
|
<body>
|
|
<div class="system">
|
|
<a class="back" href="/system.html">← zurück zu System</a>
|
|
<h1>Pipelines</h1>
|
|
<p class="subtitle">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.</p>
|
|
|
|
<section id="deploy">
|
|
<h2>Deploy-Pipeline</h2>
|
|
<div class="diagram-toolbar"><button type="button" class="fullscreen-btn" data-target="diagram-1">⛶ Vollbild</button></div>
|
|
<div class="diagram-wrap" id="diagram-1">
|
|
<pre class="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"]
|
|
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
|
|
</pre>
|
|
</div>
|
|
<p class="stale-note">Folgt der in <code>CLAUDE.md</code> dokumentierten
|
|
Verifikationskaskade. Nicht jeder Schritt ist im Nachhinein per
|
|
Journal belegbar (<code>flake check</code>/<code>build</code>/
|
|
<code>diff-closures</code> laufen non-sudo, ohne Log-Spur) — bei
|
|
Boot-/Netzwerk-/Firewall-/sshd-/Secret-Änderungen kommt zusätzlich
|
|
ein <code>nixos-rebuild test</code>-Fallback dazwischen, hier zur
|
|
Übersicht weggelassen.</p>
|
|
</section>
|
|
|
|
<section id="delegation">
|
|
<h2>Agenten-Delegation (Herdr)</h2>
|
|
<div class="diagram-toolbar"><button type="button" class="fullscreen-btn" data-target="diagram-2">⛶ Vollbild</button></div>
|
|
<div class="diagram-wrap" id="diagram-2">
|
|
<pre class="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]
|
|
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
|
|
</pre>
|
|
</div>
|
|
<p class="stale-note">Der Orchestrator delegiert
|
|
fire-and-forget — er wartet nicht aktiv, sondern beendet seinen
|
|
eigenen Turn nach der Übergabe (<code>docs/herdr-orchestration.md</code>).
|
|
Jede Delegation startet als eigene, atomare Session: die Rolle
|
|
ist so klar umrissen (<code>agents/*.md</code>), 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 <code>herdr agent read/send</code> 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.</p>
|
|
<p class="stale-note">Deploy/Aktivierung ist <strong>kein</strong>
|
|
unbedingter Teil des "funktional lösen" — alle vier
|
|
Rollenverträge verlangen dafür standardmäßig eine im Auftrag
|
|
ausdrücklich erteilte Freigabe (<code>agents/admin.md</code>:
|
|
"nur wenn ausdrücklich freigegeben, sonst mit dem genauen
|
|
Aktivierungsschritt melden und stoppen"; <code>agents/agent-manager.md</code>,
|
|
<code>agents/orga.md</code> gleiches Muster je Aktion).
|
|
<code>agents/graphics.md</code> hat überhaupt kein
|
|
Deploy-Konzept — committet/pusht nie selbst. Der Regelfall ist
|
|
also <code>D → E2</code> (Aktivierungsschritt melden,
|
|
stoppen); <code>D → E</code> (Spezialist deployed selbst) ist
|
|
die Ausnahme bei expliziter Freigabe, keine automatische Folge
|
|
von "fire and forget".</p>
|
|
<p class="stale-note">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: <code>docs/herdr-eskalation-review-entwurf.md §4</code>)
|
|
— das ist etwas anderes als das noch unfreigegebene "Review
|
|
als Standardschritt" aus §1, das hier bewusst nicht
|
|
dargestellt ist.</p>
|
|
</section>
|
|
|
|
<section id="access">
|
|
<h2>Zugangs-/Ein-Ausgabe-Kette</h2>
|
|
<div class="diagram-toolbar"><button type="button" class="fullscreen-btn" data-target="diagram-3">⛶ Vollbild</button></div>
|
|
<div class="diagram-wrap" id="diagram-3">
|
|
<pre class="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]
|
|
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
|
|
</pre>
|
|
</div>
|
|
<p class="stale-note">Wie ein diktierter Prompt tatsächlich durchs
|
|
System läuft, bevor überhaupt etwas passiert.</p>
|
|
</section>
|
|
|
|
<section id="zettel-flow">
|
|
<h2>Zettel-Transformation</h2>
|
|
<div class="diagram-toolbar"><button type="button" class="fullscreen-btn" data-target="diagram-4">⛶ Vollbild</button></div>
|
|
<div class="diagram-wrap" id="diagram-4">
|
|
<pre class="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]
|
|
click A commentZettel
|
|
click B commentZettel
|
|
click C commentZettel
|
|
click D commentZettel
|
|
click E commentZettel
|
|
click F commentZettel
|
|
</pre>
|
|
</div>
|
|
<p class="stale-note">Aus <code>memory/zettel/</code> (Blatt 9) —
|
|
die Methode des Ursprungsprojekts selbst, nicht von der Plattform
|
|
abgeleitet, sondern ihr Vorbild.</p>
|
|
</section>
|
|
|
|
<section id="deep-research">
|
|
<h2>Deep-Research-Agent</h2>
|
|
<div class="diagram-toolbar"><button type="button" class="fullscreen-btn" data-target="diagram-5">⛶ Vollbild</button></div>
|
|
<div class="diagram-wrap" id="diagram-5">
|
|
<pre class="mermaid">
|
|
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
|
|
</pre>
|
|
</div>
|
|
<p class="stale-note">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
|
|
<q>Agent</q> 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.</p>
|
|
</section>
|
|
|
|
<section id="evidence-store">
|
|
<h2>Evidenzspeicher — internes Schema</h2>
|
|
<div class="diagram-toolbar"><button type="button" class="fullscreen-btn" data-target="diagram-6">⛶ Vollbild</button></div>
|
|
<div class="diagram-wrap" id="diagram-6">
|
|
<pre class="mermaid">
|
|
flowchart LR
|
|
Q["Research Question<br/>id · scope · status"] --> C["Claim<br/>id · assertion · type · status"]
|
|
S["Source<br/>id · title · author · date · url · retrieved_at"] --> P["Passage<br/>id · source_id · locator · excerpt · context"]
|
|
P --> E["Evidence Link<br/>passage_id · claim_id · relation · strength"]
|
|
E -->|supports / contradicts / qualifies| C
|
|
C --> A["Assessment<br/>confidence · freshness · consensus · caveats"]
|
|
C --> R["Report Statement<br/>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
|
|
</pre>
|
|
</div>
|
|
<p class="stale-note">Die Quelle und ihr genauer Fundort bleiben
|
|
getrennt: Eine Quelle kann viele Passagen liefern, und dieselbe
|
|
Passage kann über <code>Evidence Link</code> 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.</p>
|
|
</section>
|
|
</div>
|
|
<script>
|
|
// 'loose' (not 'strict') so the click-to-comment bindings below work --
|
|
// safe here since the diagram source is our own docs/pipelines.md,
|
|
// not untrusted input.
|
|
mermaid.initialize({
|
|
startOnLoad: true,
|
|
theme: window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'default',
|
|
securityLevel: 'loose',
|
|
flowchart: { htmlLabels: true, curve: 'basis' },
|
|
});
|
|
|
|
const FORGEJO_ISSUE_URL = 'https://git.0ff.space/lukas/nixos-config/issues/new';
|
|
|
|
function commentOn(diagram, nodeId) {
|
|
const title = `Pipeline-Kommentar: ${diagram} / ${nodeId}`;
|
|
const body = [
|
|
`Bezug: **${diagram}**, Knoten **${nodeId}** (siehe docs/pipelines.md und dashboard-Repo pipelines.html).`,
|
|
'',
|
|
'(Kommentar hier. Um eine Kante/Verbindung statt eines Knotens zu kommentieren -- Mermaid unterstützt Klicks nur auf Knoten -- einfach an einem der beiden verbundenen Knoten öffnen und die Kante im Text benennen, z. B. "Kante A→B: ...".)',
|
|
].join('\n');
|
|
window.open(
|
|
`${FORGEJO_ISSUE_URL}?title=${encodeURIComponent(title)}&body=${encodeURIComponent(body)}`,
|
|
'_blank'
|
|
);
|
|
}
|
|
|
|
window.commentDeploy = (id) => commentOn('Deploy-Pipeline', id);
|
|
window.commentDelegation = (id) => commentOn('Agenten-Delegation', id);
|
|
window.commentAccess = (id) => commentOn('Zugangs-/Ein-Ausgabe-Kette', id);
|
|
window.commentZettel = (id) => commentOn('Zettel-Transformation', id);
|
|
window.commentResearch = (id) => commentOn('Deep-Research-Agent', id);
|
|
window.commentEvidence = (id) => commentOn('Evidenzspeicher', id);
|
|
document.querySelectorAll('.fullscreen-btn').forEach(btn => {
|
|
btn.addEventListener('click', () => {
|
|
const el = document.getElementById(btn.dataset.target);
|
|
if (el.requestFullscreen) {
|
|
el.requestFullscreen();
|
|
} else if (el.webkitRequestFullscreen) {
|
|
el.webkitRequestFullscreen();
|
|
}
|
|
});
|
|
});
|
|
</script>
|
|
</body>
|
|
</html>
|