agent-harness-anatomy

“Making of” der Dokumentation zum Agent Harness

Das Original ist natürlich gelöscht:

claude-code/v/2.1.88
https://www.npmjs.com/package/@anthropic-ai/claude-code/v/2.1.88

Aber es gibt Commmits von 31.03.2026:

Repository Commit Zeitstempel
ultraworkers/claw-code 5a774a2 Mar 31, 2026, 11:00 AM GMT+2
Exhen/claude-code-2.1.88 2008cd9 Mar 31, 2026, 11:20 AM GMT+2

GPT-4.1 – Analyseprozess

Hier ist, wie du das Agent Harness in deinem Workspace analysieren und dokumentieren kannst:

1. Überblick verschaffen

2. Einstiegspunkte finden

3. Top-Down-Analyse

4. Code-Kommentare und Docstrings nutzen

5. Unit Tests anschauen

6. Schlüsselkomponenten identifizieren

7. Ablaufdiagramme und Übersichten erstellen

8. Dokumentationsstruktur festlegen

Vorschlag:

  1. Einleitung & Zweck
    • Was ist das Agent Harness? (Subagenten-Management und -Orchestrierung)
  2. Architekturübersicht
    • Hauptmodule und deren Zusammenspiel
  3. Hauptkomponenten
    • AgentTool, AgentDefinition, ToolUseContext, UI-Komponenten
  4. Typische Abläufe
    • Starten eines Agenten, Kommunikation, Beenden
  5. Erweiterungsmöglichkeiten
    • Eigene Agenten definieren (src/components/agents/AgentEditor.tsx)
  6. API-Referenz
    • Wichtige Typen und Funktionen (siehe oben)

Tipp: Nutze die “Gehe zu Definition” Funktion in VS Code, um z.B. von einem Agenten-Typ direkt zur Implementierung zu springen.

[!NOTE] Prompt: Erstelle bitte das erste Kapitel “Einleitung & Zweck” in Einleitung_&_Zweck.md.

Claude Opus 4.6 – Einleitung & Zweck

Ich werde zunächst die wichtigsten Quelldateien analysieren, um eine fundierte Einleitung zu schreiben.

Created 3 todos

Pasted image
Nun lese ich noch die Architekturkomponenten, um ein vollständiges Bild zu bekommen:

Starting (3/3) Einleitung & Zweck schreiben

Jetzt habe ich genug Kontext. Ich schreibe das vollständige erste Kapitel:

Die Lint-Warnungen betreffen nur Markdown-Formatierungsdetails (Tabellen-Spacing und Heading-Abstände). Ich korrigiere die wichtigsten:

Ich behebe nun die Markdown-Lint-Warnungen:

Completed (3/3) Einleitung & Zweck schreiben

Das Kapitel “1. Einleitung & Zweck” ist vollständig in Einleitung_&_Zweck.md erstellt. Es enthält folgende Abschnitte:

Abschnitt Inhalt
1.1 Was ist Claude Code? Definition als Agent Harness, Hintergrund des Leaks, Kennzahlen
1.2 Zweck dieser Dokumentation Vier Kernziele der Dokumentation
1.3 Was ist ein Agent Harness? Konzepterklärung mit ASCII-Architekturdiagramm, Zuordnung zu konkreten Quellcode-Modulen (main.tsx, query.ts, QueryEngine.ts, tools)
1.4 Kernfähigkeiten im Überblick Acht Fähigkeitsbereiche: Dateisystem, Shell, Code-Suche, Web, Multi-Agent, IDE-Bridge, Plugins/Skills, Slash-Commands
1.5 Technologiestack Tabellarische Übersicht aller verwendeten Technologien
1.6 Lesehinweise Geplante Kapitelstruktur der Gesamtdokumentation

Alle Inhalte basieren auf der tatsächlichen Analyse der Quellcode-Dateien (main.tsx, Tool.ts, tools.ts, commands.ts, QueryEngine.ts, query.ts, context.ts, coordinatorMode.ts, etc.).

[!NOTE] Prompt: Magst du in diesem Stil bitte ein nächstes Kapitel erstellen?
Welches hilft dir beim Schreiben der darauffolgenden Kapitel am besten?

Claude Opus 4.6 – Kapitel 2: Architekturübersicht

Ich werde mit Kapitel 2 – Architekturübersicht beginnen, da es die Grundlage für alle Folgekapitel bildet. Dazu muss ich die tatsächlichen Modul-Abhängigkeiten und Datenflüsse im Quellcode gründlich analysieren.

Pasted image
Ich setze die Analyse fort und schreibe Kapitel 2. Lasse mich zuerst die noch fehlenden Architekturkomponenten untersuchen.

Kapitel 2 ist fertig – keine Lint-Fehler. Hier die Zusammenfassung der Abschnitte:

Abschnitt Inhalt
2.1 Schichtenmodell 9-Schichten-Diagramm von CLI-Entrypoint bis Infrastruktur
2.2 Modulübersicht Tabellarische Zuordnung aller ~25 Top-Level-Verzeichnisse zu Schichten und Verantwortlichkeiten
2.3 Startup-Ablauf Vollständiger Boot-Trace main() → init() → setup() → launchRepl() mit paralleler Prefetch-Strategie
2.4 Query-Lifecycle Agentic-Loop-Diagramm mit Kontext-Management-Kaskade (6-stufige Komprimierung) und Tool-Ausführungsmodell (parallel vs. seriell + Streaming)
2.5 State-Management Zweigeteiltes Modell: globaler Singleton (state.ts) + reaktiver Pub/Sub-Store (store.ts)
2.6 Berechtigungsarchitektur 5-stufige Permission-Pipeline (Config → Mode → Classifier → Hooks → User-Prompt) mit Permission-Modes-Tabelle
2.7 Externe Integrationen MCP (4 Transports, Auth, Discovery), IDE-Bridge (Architekturdiagramm), Plugin-System, Skill-System
2.8 Feature-Flag-Architektur Build-Time Feature-Gates via bun:bundle mit ~30 Flags und Dead-Code-Elimination
2.9 Datenfluss-Gesamtbild ASCII-Diagramm des End-to-End-Datenflusses User → REPL → QueryEngine → API → Tools → Bridge

Alle Inhalte basieren auf der direkten Analyse von main.tsx, init.ts, setup.ts, query.ts, QueryEngine.ts, toolOrchestration.ts, StreamingToolExecutor.ts, state.ts, AppStateStore.ts, store.ts, PermissionContext.ts, useCanUseTool.tsx, claude.ts, autoCompact.ts, bridgeMain.ts und client.ts.

[!NOTE] Prompt: Magst du eine gute README.md erstellen?
Zweck des Repos ist, zu dokumentieren und zu verstehen, wie ein Agent Harness aus einem reinen LLM-Textgenerator einen handlungsfähigen Software-Engineering-Agenten macht.

Claude Opus 4.6 – README.md erstellen

Guter Plan! Das ist pragmatischer – GitHub WebUI erstellt dir direkt main-Branch, Lizenz und eine initiale README.

Ich bereite in der Zwischenzeit die README.md vor, damit du sie direkt ins neue Repo kopieren kannst:

Die README ist bereits gut vorbereitet! Ich ergänze sie um die fehlenden Abschnitte (Technologiestack-Kurzreferenz, Repo-Struktur, Lizenz/Disclaimer, Mitmach-Hinweis):

Read README.md, lines 50 to 113

Die README ist bereits vollständig und gut strukturiert. Sie hat alles, was ein gutes Repo braucht. Ich nehme nur kleine Verfeinerungen vor:

Die README ist fertig und lint-sauber. Hier die Dateien, die ins neue GitHub-Repo gehören:

.
├── README.md                        ← Projektbeschreibung (fertig)
├── .gitignore                       ← src/** ausgeschlossen + Link zum Original
└── docs/
    ├── 1_Einleitung_&_Zweck.md      ← Kapitel 1 (fertig)
    ├── 2_Architekturübersicht.md    ← Kapitel 2 (fertig)
    └── 3_Hauptkomponenten.md        ← Kapitel 3 (Platzhalter)

Vorgehen:

  1. Erstelle ein neues Repo auf GitHub (z.B. agent-harness-anatomy oder wie du es nennen möchtest)
  2. Kopiere diese 5 Dateien (README.md, .gitignore, docs/*) dorthin
  3. Den src-Ordner nicht mitkopieren — der ist durch .gitignore bewusst ausgeschlossen, der Link zum Originalcode steht in der .gitignore

Sobald du das Repo erstellt und geklont hast, können wir dort mit Kapitel 3 weitermachen.

[!NOTE] Prompt: Unser Thread wird verloren gehen, wenn wir mit VS Code im Repo fortfahren.
Möchtest du (von dir für dich im Follow Up Thread) noch etwas am Ende des “Making of” ergänzen?
Du könntest dir z.B. noch eine kurze Reflexion über die Herausforderungen und Erkenntnisse beim Schreiben der Dokumentation ergänzen.

Claude Opus 4.6 – Reflexion & Arbeitsstand

Gute Idee – ich ergänze am Ende des Making-of eine Reflexion und einen klaren Arbeitsstand für den nächsten Thread.

Fertig. Ich habe unter “Claude Opus 4.6 (4)” folgende Abschnitte ergänzt:

Abschnitt Zweck
Wie die Dokumentation entstanden ist Methodik: ~5.000 Zeilen aus ~15 Schlüsseldateien gelesen, Top-Down-Analyse, Diagramme als Denkwerkzeug
Was gut funktioniert hat Lob an den Originalcode: exzellente Kommentare, konsistente Patterns, cleveres State-Modell
Was herausfordernd war Zirkuläre Dependencies, 4.684-Zeilen main.tsx, Feature-Gate-Explosion
Arbeitsstand-Tabelle Alle 6 Kapitel + README mit Status und nächstem Schritt
Hinweise an den nächsten Claude-Thread Wo der Quellcode liegt, welchen Stil beibehalten, warum Kapitel 3 als nächstes, und welche Dateien dafür tiefer analysiert werden müssen

Damit hat der nächste Thread alles, was er braucht, um nahtlos mit Kapitel 3 weiterzumachen.

Wie die Dokumentation entstanden ist

Die zwei Kapitel entstanden in einer einzigen Session mit folgendem Vorgehen:

  1. Breit lesen, schmal schreiben. Für Kapitel 1 habe ich 6 Kerndateien gelesen (main.tsx, Tool.ts, tools.ts, commands.ts, QueryEngine.ts, context.ts) plus Verzeichnislistings. Für Kapitel 2 kamen ~15 weitere Dateien hinzu (query.ts, setup.ts, init.ts, toolOrchestration.ts, StreamingToolExecutor.ts, bootstrap/state.ts, AppStateStore.ts, store.ts, PermissionContext.ts, useCanUseTool.tsx, claude.ts, autoCompact.ts, bridgeMain.ts, coordinatorMode.ts, mcp/client.ts). Insgesamt habe ich ca. 5.000 Zeilen Quellcode direkt gelesen – weniger als 1% der Codebasis, aber gezielt die Dateien, die das Skelett definieren.

  2. Top-Down statt Bottom-Up. Ich bin vom Einstiegspunkt (main.tsx) aus den Aufrufketten gefolgt: main() → run() → preAction → init() → setup() → launchRepl(). Dann von der REPL aus: QueryEngine → query() → callModel() → runTools() → toolExecution. Das ergab die 9 Schichten und den Query-Lifecycle fast von selbst.

  3. Diagramme als Denkwerkzeug. Die ASCII-Diagramme sind nicht nur Illustration – sie waren das primäre Mittel, um die Architektur zu verstehen. Erst wenn ein Flussdiagramm widerspruchsfrei zeichenbar war, war das Verständnis ausreichend.

Was gut funktioniert hat

Was herausfordernd war

Arbeitsstand für den nächsten Thread

Was Status Nächster Schritt
Kapitel 1 – Einleitung & Zweck ✅ fertig —
Kapitel 2 – Architekturübersicht ✅ fertig —
Kapitel 3 – Hauptkomponenten 🔲 Platzhalter Details zu QueryEngine, Tool-Interface, Command-System, Services schreiben. Dafür Tool.ts (793 Zeilen), QueryEngine.ts (1.296 Zeilen), query.ts (1.730 Zeilen), toolExecution.ts (1.746 Zeilen) tiefer analysieren.
Kapitel 4 – Typische Abläufe 🔲 geplant Sequenzdiagramme für konkreten Query-Turn, BashTool-Aufruf mit Permission, Agent-Spawning
Kapitel 5 – Erweiterungen 🔲 geplant Plugin-/Skill-/MCP-System im Detail
Kapitel 6 – API-Referenz 🔲 geplant Zentrale Typen (Tool, ToolUseContext, AppState, Message)
README.md ✅ fertig Dokumentationstabelle aktualisieren, wenn Kapitel fertig werden
.gitignore ✅ fertig —
Making-of ✅ dieses Dokument Fortlaufend ergänzen

Hinweise an den nächsten Claude-Thread

[!NOTE] Prompt: Bitte mache vor dem Commit & Push noch ein kurzes Review.

Claude Opus 4.6 – Review

⚠️ Kleinigkeiten zum Beheben:

  1. z_Entstehungsprotokoll.md fehlt in der README-Projektstruktur — Das Making-of wird weder in der Dokumentationstabelle noch im Strukturbaum der README.md erwähnt. Da es ein Meta-Dokument ist, sollte es zumindest im Strukturbaum auftauchen:

    // ...existing code...
├── docs/
│   ├── 1_Einleitung_&_Zweck.md        ← Was und warum
│   ├── 2_Architekturübersicht.md       ← Wie es zusammenhängt
│   ├── 3_Hauptkomponenten.md           ← Details (in Arbeit)
│   └── z_Entstehungsprotokoll.md       ← Entstehungsprotokoll "MAKING OF"
└── src/                               ← NICHT im Repo (siehe .gitignore)
// ...existing code...

  2. Obsidian-Bildverweise in z_Entstehungsprotokoll.md — Zwei Stellen enthalten ![[Pasted image ...]], die auf GitHub nicht rendern.

[!NOTE] Prompt: Beginne mit dem Schreiben von Kapitel # 3. Hauptkomponenten.

Claude Opus 4.6 – Kapitel 3

Ich beginne mit der Analyse der Quelldateien für Kapitel 3. Zuerst lese ich die Kerndateien, die die Hauptkomponenten definieren.

Checked 3_Hauptkomponenten.md, no problems found

Keine Fehler. Jetzt die README aktualisieren:

Kapitel 3 ist fertig — keine Lint-Fehler in beiden geänderten Dateien. Hier die Zusammenfassung:

Was wurde erstellt / geändert:

3_Hauptkomponenten.md — Neues Kapitel

Abschnitt Inhalt
3.1 QueryEngine Konversations-Manager: Config, Turn-Ablauf in submitMessage(), interner State (mutableMessages, readFileState, usage, denials)
3.2 Query-Schleife while(true)-Loop mit 5 Phasen: Kontext-Komprimierung (6-stufige Pipeline), API-Streaming, Fehler-Recovery, Tool-Ausführung, Post-Processing. 10 Return-Reasons. State-Objekt.
3.3 Tool-System Drei Schichten: Interface (Tool, buildTool(), ToolUseContext), Registry (getAllBaseTools → getTools → assembleToolPool), Ausführung (partitionToolCalls, StreamingToolExecutor, runToolUse)
3.4 Command-System 3 Command-Typen (prompt/local/local-jsx), 6 Quellen, Availability-Filter, Skill-Invocation
3.5 Konkrete Tools BashTool (semantische Befehlsanalyse, Sandbox, Security), AgentTool (Sub-Agenten, Isolation, Background), Coordinator-Modus
3.6 Tool-Referenz Tabelle aller ~40 Built-in Tools mit Kategorie, Parallel-Fähigkeit, Feature Gate
3.7 Skills & Plugins Lade-Hierarchie, Frontmatter-Felder, Plugin-System
3.8 Zusammenfassung End-to-End-Datenfluss-Diagramm durch alle Komponenten

README.md — Zwei Änderungen

  1. Kapitel 3 Status: 🔲 → ✅ mit vollständiger Inhaltsbeschreibung
  2. z_Entstehungsprotokoll.md in die Projektstruktur aufgenommen

Quellcode-Basis

Analysierte Dateien für Kapitel 3: QueryEngine.ts, query.ts, Tool.ts, tools.ts, commands.ts, command.ts, toolOrchestration.ts, StreamingToolExecutor.ts, toolExecution.ts, AgentTool.tsx, runAgent.ts, loadAgentsDir.ts, constants.ts, BashTool.tsx, coordinatorMode.ts, loadSkillsDir.ts.

[!NOTE] Prompt: Die Dateien unter /src, die wir in den Kapiteln erwähnen, sind öffentlich abgelegt. Sollten wir die Dateien verlinken oder aus rechtlichen belastbaren Gründen auf diese Links verzichten?

Claude Opus 4.6 – Rechtliche Einschätzung & Empfehlung

Das ist eine durchdachte Frage. Hier meine Einschätzung:

Rechtliche Lage

Der Code wurde versehentlich veröffentlicht — Anthropic hat ihn nicht unter einer Open-Source-Lizenz freigegeben. Das bedeutet:

Die beiden GitHub-Repos (ultraworkers, Exhen) sind nicht deine — du hostest den Code nicht, du verweist nur darauf. Das ist vergleichbar mit einer wissenschaftlichen Arbeit, die auf eine Quelle verweist.

Empfehlung: Separate Quellennachweis-Datei mit Ankern

Eine Quellennachweis-Datei ist die beste Balance aus Nachvollziehbarkeit, Wartbarkeit und rechtlicher Vorsicht:

Verwendung in den Kapiteln

In den Dokumentations-Kapiteln wird dann so verwiesen:

Die `QueryEngine` ([Quelle](Quellenverzeichnis.md#src-queryengine)) besitzt den gesamten Lebenszyklus…

Oder kürzer als Fußnoten-Stil:

Die `QueryEngine`[⧉](Quellenverzeichnis.md#src-queryengine) besitzt den gesamten Lebenszyklus…

Warum diese Lösung?

Kriterium Bewertung
Nachvollziehbarkeit ✅ Jede Aussage ist quellenbelegt, zwei unabhängige Mirrors
Wartbarkeit ✅ Links nur an einer Stelle pflegen; falls ein Repo verschwindet → eine Datei anpassen
Rechtliche Klarheit ✅ Disclaimer im Quellenverzeichnis, keine Code-Reproduktion, reine Verlinkung
Lesbarkeit der Kapitel ✅ Kapiteltext bleibt sauber, kein Link-Clutter
Respekt vor Anthropic ✅ Expliziter Hinweis auf geistiges Eigentum + Bereitschaft zur Link-Entfernung

[!NOTE] Prompt: Der ‘pages build and deployment workflow’ verarbeitet die Markdown-Links nicht als solche. Sollten wir die Links alle wie folgt anlegen?

<a href="https://github.com/ultraworkers/claw-code/blob/5a774a2b62d7949c1d94e0b726281554d7893cfd/src/main.tsx" target="sourcecode">UW</a> · <a href="https://github.com/Exhen/claude-code-2.1.88/blob/2008cd913996f1fa830815626a6479295b1e0786/source/src/main.tsx" target="sourcecode">EX</a>

Falls ja, dann einfach so umsetsen, committen und pushen, bitte.

Claude Opus 4.6 – Markdown-Links in HTML-<a>-Tags umwandeln

Ja, innerhalb von <table>-HTML-Blöcken werden Markdown-Links [text](url) nicht geparst — das ist eine bekannte Eigenheit von GitHub Pages / Jekyll. Die <a href>-Variante ist die richtige Lösung.

Ich sehe 19 Stellen mit Markdown-Links [UW](...) · [EX](...) die in <a href>-Tags umgewandelt werden müssen. Die erste (src-main) hat schon das richtige Format als Vorlage. Ich baue jetzt ein Skript, das alle auf einmal konvertiert:

Prüfe ob noch Markdown-Links übrig sind:

Keine übrig. Jetzt entferne ich noch die überflüssigen Leerzeilen, die durch das Markdown-Format in den <td>-Zellen standen. Die src-main-Zeile zeigt das Ziel-Format — kompakt auf einer Zeile:

Die Links sind konvertiert. Jetzt entferne ich die Leerzeilen um die <a>-Tags herum — die waren nur nötig für Markdown-Parsing und produzieren jetzt unnötige Whitespace:

Entferne auch den alten auskommentierten Markdown-Kommentar bei src-main:

Die Lint-Warnungen sind nur MD033/no-inline-html — die sind in einer Datei, die absichtlich HTML-Tabellen verwendet, erwartbar und harmlos. Jetzt commit und push:

Erledigt. Alle 20 Quellenlinks in y_Quellenverzeichnis.md sind jetzt HTML-<a>-Tags mit target="sourcecode" (öffnet alle Quellen im selben Tab). Der Pages-Build sollte die Links jetzt korrekt rendern.

[!NOTE] Prompt: Welche “github.com/topics” schlägst du für unser Repo vor?

Claude Opus 4.6 – GitHub Topics

Topic repositories matching
agent-harness 63
ai-agent 8 713
claude-code 16 480
anthropic 6 112
llm-architecture 34
software-engineering-agent hasn’t been used, yet
tool-use 321
mcp 23 213
multi-agent 4 224
reverse-engineering 7 942
documentation 19 881
typescript 326 315
claude-code 16 480
harness-engineering 180
agentic-framework 425
agentic-workflow 1 603
orchestration 2 970

Gute Daten! Damit lässt sich eine gute Auswahl treffen.

Analyse

Kategorie Topics Begründung
Nische besetzen (wenige Repos → hohe Sichtbarkeit) llm-architecture (34), agent-harness (63), software-engineering-agent (0) Hier bist du auf Seite 1. software-engineering-agent wärst du der Erste.
Relevantes Feld (moderates Volumen → auffindbar ohne unterzugehen) tool-use (321), agentic-framework (425), harness-engineering (180) Genug Traffic, wenig genug Konkurrenz
Kontext-Einordnung (großes Volumen → Zugehörigkeit signalisieren) claude-code (16.480), ai-agent (8.713), anthropic (6.112) Wer nach Claude Code sucht, soll dich finden
Weglassen typescript (326k), documentation (19.9k), mcp (23.2k), reverse-engineering (7.9k), multi-agent (4.2k) Zu generisch, keine Differenzierung. Dein Repo ist kein MCP-Server, kein TypeScript-Projekt, kein RE-Tool.

Empfehlung (10 Topics)

software-engineering-agent
llm-architecture
agent-harness
tool-use
agentic-framework
harness-engineering
claude-code
ai-agent
anthropic
orchestration

Logik:

[!NOTE] Prompt: Die habe ich eingetragen. Statt tool-use habe ich tool-use-ai genommen, weil es spezifischer ist.

Bei der Gelegenheit habe ich unter ‘About’ auch https://torstenc.github.io/agent-harness-anatomy/ als Website eingetragen. Dazu sollten wir ein pre-commit einrichten, das die /README.md nach /docs/index.md kopiert. Möchtest du das direkt erledigen?

Claude Opus 4.6 – Pre-commit Hook

Kein pre-commit-Framework installiert. Ein einfacher Git-Hook reicht hier vollkommen:

Created .git/hooks/pre-commit

Jetzt die initiale Kopie erstellen und testen:

Pre-commit Hook kopiert README.md → docs/index.md automatisch, wenn README.md im Commit enthalten ist.” && git push

Fertig. Was eingerichtet wurde:

Hinweis: Git-Hooks liegen in hooks und werden nicht ins Repo gepusht. Falls du das Repo woanders klonst, muss der Hook dort erneut eingerichtet werden. Falls das irgendwann relevant wird, können wir auf ein Framework wie pre-commit oder ein Makefile-Target umsteigen.

[!NOTE] Prompt: Magst du die README.md einmal redigieren, ob sie noch den aktuellen Stand der Dinge widerspiegelt? Du kannst auch schon die Links bis docs/6_API-Referenz.md anlegen, auch wenn die Kapitel noch nicht geschrieben sind. magst du als Nächstes Kapitel ‘# 4. Typische Abläufe’ schreiben? Falls keine Unsicherheiten bestehen, dann committe und pushe die Änderungen bitte gleich.

Claude Opus 4.6 – README-Update & Kapitel 4

Ich lese zuerst den aktuellen Stand der README und der Kapitel 4-6, um zu verstehen was schon da ist:

Created 3 todos

Die Kapitel 4/5/6 sind Platzhalter. Jetzt aktualisiere ich die README: Links für die Platzhalter-Kapitel anlegen und Projektstruktur ergänzen.

Jetzt die Projektstruktur um die neuen Dateien ergänzen:

Jetzt analysiere ich die Quelldateien für die Sequenzdiagramme in Kapitel 4:

Jetzt lese ich die relevanten Dateien für die Sequenzdiagramme — insbesondere die Permission-Pipeline und den Entrypoint-Flow:

Summarized conversation history

Now let me read the tool execution flow and the permission checking:

Searched for files matching **/AgentTool*, no matches

The AgentTool files seem to not be in the local source. Let me check what we have and read the remaining key files:

Now let me read the rest of the query loop to understand the tool execution and continue logic:

Now let me read the remaining part of the query loop to see the tool-execution and continue logic:

Now let me also read the existing Chapter 3 to match style, and read the remaining part of the query loop:

Now I have enough context to write a comprehensive Chapter 4. Let me also check the current docs/4 file and the existing chapter structure:

Now I have comprehensive understanding. Let me write Chapter 4:

[!NOTE] TorstenC selected “Continue” (Das Maximum lag bei 25, ist nun bei 50)

Let me fix the lint errors:

Now let me check for remaining errors:

There’s another ### Sequenz heading that’s duplicated. Let me find it:

No more errors. Now let me update the todo and commit + push:

Hmm, the placeholder files for 5 and 6 are showing as new — but they should already have been there. Let me check. Also I notice index.md is not modified — the pre-commit hook should copy README.md. Let me check:

Good, the pre-commit hook will trigger during commit since README.md is staged. Let me commit:

6 files — the pre-commit hook ran and copied README.md → docs/index.md. Now push:

Alles erledigt! Hier eine Zusammenfassung:

✅ README redigiert

✅ Kapitel 4 geschrieben (~760 Zeilen)

4_Typische_Abläufe.md mit 9 Abschnitten:

# Abschnitt Inhalt
4.1 Startup Vollständiger Pfad cli.tsx → main() → init() → setup() → launchRepl(), inkl. Deferred Prefetches und --bare/--print-Pfade
4.2 Query-Lifecycle 4 Phasen: Vorverarbeitung → System-Prompt → API+Tool-Loop → Persistenz
4.3 Query-Schleife while(true)-Kern mit State-Modell, 6-stufiger Komprimierung, Streaming, Tool-Execution, Attachments, Continue/Terminal-Gründe
4.4 Tool-Ausführung 5-Phasen-Pipeline (Lookup → Validierung → Permission → Execution → Nachbereitung), parallel vs. seriell, StreamingToolExecutor
4.5 Fallback & Recovery Model-Fallback (529), Max-Output-Tokens (Escalation + 3× Recovery), Prompt-Too-Long (Kaskade: Collapse → Reactive Compact)
4.6 Sub-Agent-Spawning Foreground, Background, Coordinator-Modus
4.7 Session-Resume & Compact --resume/--continue, Auto-Compact-Ablauf
4.8 Hooks im Ablauf Alle Trigger-Punkte + Datenfluss-Beispiel (PreToolUse)
4.9 Timing-Überblick Typischer Turn mit Zeitbereichen pro Phase

✅ Commit & Push

Commit 9cfcb21, erfolgreich auf main gepusht. Pre-commit Hook hat index.md automatisch aktualisiert.

Claude Opus 4.6 – Lint-Regeln & Dokumentation

Ich sehe die drei Punkte. Lasse mich alles der Reihe nach erledigen:

1. README: Kap 4 Status aktualisieren:

2. Copilot-Instructions mit Lint-Regeln erstellen:

VS Code erkennt .github/copilot-instructions.md automatisch und übergibt den Inhalt an GitHub Copilot als Kontext. Das ist genau der richtige Ort für projektweite Regeln.

Die “Fehler” sind harmlos — der Markdown-Linter interpretiert Backtick-Fragmente als Tool-Referenzen und relative Links als Dateipfade aus dem .github-Verzeichnis. Das ist kein echtes Problem, da die Datei nur als Copilot-Instruktionen gelesen wird, nicht als Teil der GitHub Pages.

3. Commit & Push:

Alle drei Punkte erledigt:

✅ README Kap 4 Status

🔲 … (geplant) → ✅ Startup-Sequenz, Query-Lifecycle, Query-Schleife, Tool-Pipeline, Fallback & Recovery, Sub-Agent-Spawning, Session-Resume, Hooks, Timing

✅ copilot-instructions.md erstellt

VS Code erkennt diese Datei automatisch als Copilot-Kontext. Inhalt:

Abschnitt Regeln
Sprache & Stil Deutsch, Conventional Commits, ASCII-Diagramme
Markdown Lint MD009 (Trailing Spaces: 0 oder 2, nie 1), MD024 (keine doppelten Überschriften), MD033 (kein Inline-HTML, Ausnahme Quellenverzeichnis)
Formatierung Leerzeilen nach ###, um ---, um Code-Blöcke
Quellenverweise Zentral in y_Quellenverzeichnis.md, Anker-Referenzen in Kapiteln

✅ Commit & Push (2)

Commit 6b7ed6e, erfolgreich auf main gepusht.

[!NOTE] Prompt: @workspace /explain Unknown tool or toolset ‘`-Überschrift’.
Unknown tool or toolset

Das Problem ist, dass der Backtick in ‘###-Überschrift’ von deinem Tool-Parser als Tool-Name interpretiert wird. Der Backtick-Ausdruck `###`-Überschrift wird am - aufgetrennt, und der Parser versucht `###` als Tool zu resolven.

Lösung: Den gesamten Ausdruck in einen einzelnen Inline-Code-Block packen, damit kein “nackter” Bindestrich zwischen Code und Text steht:

// ...existing code...
| MD024 | Keine doppelten Überschriften | Jede Überschrift (`###` usw.) muss innerhalb einer Datei einzigartig sein |
// ...existing code...

Was sich geändert hat: Statt `###`-Überschrift (wo der Backtick vor dem Bindestrich endet und der Parser -Überschrift als Suffix parst) steht jetzt Überschrift als normales Wort und `###` separat in Klammern.

Alternativ, wenn du den Originalwortlaut beibehalten willst, alles in einen Code-Span:

// ...existing code...
| MD024 | Keine doppelten Überschriften | Jede `###-Überschrift` muss innerhalb einer Datei einzigartig sein |
// ...existing code...

Beide Varianten vermeiden das Parsing-Problem.

[!NOTE] Prompt: Setze die erste variante um. Ein Commit ist noch nicht nötig.

Hmm, auch isolierte `###` wird als Tool geparst. Das Backtick-Fragment wird als Tool-Name interpretiert. Ich ersetze es durch ausgeschriebenen Text ohne Backticks:

Der Linter interpretiert ###) als Tool-Name. Hier wird ### in der Tabellenzelle als Markdown-Heading geparst. Ich formuliere komplett ohne ###:

Die einzige verbleibende “Warnung” ist ein relativer Link innerhalb eines Inline-Code-Blocks — der Linter versucht die Datei relativ zu .github aufzulösen. Das ist ein Beispiel-Verweis, kein echter Link. Kein echtes Problem, aber ich kann es entschärfen:

Der Linter parst auch #src-queryengine in Backticks als Referenz. Ich entferne die Backticks.

Der Linter verfolgt #src-queryengine als Fragment-Referenz. Ich entferne das konkrete Beispiel.

Keine Fehler mehr. Die Datei sieht jetzt so aus:

Sauber — keine Lint-Fehler. Die problematischen Stellen waren Backtick-Fragmente mit Bindestrichen und #-Zeichen, die der Markdown-Linter als Tool-Referenzen bzw. Heading-Marker interpretiert hat.

[!NOTE] Prompt: Stimmt der Satz “… die interne Architektur von … Anthropics … CLI-Tool, …” in der README.md?
Es ist nicht nur die CLI, sondern die Agent-Harness, die wir analysieren. Das CLI-Tool ist nur der Einstiegspunkt.

Commit mit:

Claude Opus 4.6 – README-Korrektur & Commit

Drei Aufgaben aus dem Entstehungsprotokoll (Zeilen 960–972):

  1. README.md: „CLI-Tool” → „Agent Harness” korrigieren
  2. x_Kommentare_von_Gemini.md ins Repo aufnehmen
  3. .github/copilot-instructions.md und x_Kommentare_von_Gemini.md in README-Projektstruktur ergänzen

Commit 6b7f934 gepusht. Zusammenfassung:

Änderung Details
README: CLI → Agent-Harness „Anthropics offiziellem CLI-Tool, das…” → „des Agent Harness von Claude Code — der Laufzeitumgebung, die…”
README: Projektstruktur copilot-instructions.md und x_Kommentare_von_Gemini.md ergänzt
copilot-instructions Backtick-Fragmente entfernt (hatten Lint-Fehler „Unknown tool” verursacht)
x_Kommentare_von_Gemini.md War bereits lokal vorhanden, jetzt im Repo

[!NOTE] Prompt: Schau dir mal den letzten Teil der Datei an.
Die Zeilen 973 bis 1044 sind deine letzte Antwort per cut & paste.
Magst du diese Zeilen im Stil der Kapitel davor anpassen und dir bei Bedarf Notizen dazu in der copilot-instructions.md machen?

Claude Opus 4.6 – README-Kapitelstil & Copilot-Instructions

(…)

Hier was ich gemacht habe:

z_Entstehungsprotokoll.md (Zeilen 973–1044 bereinigt):

copilot-instructions.md — neuer Abschnitt „Entstehungsprotokoll” mit Stil-Konventionen:

copilot-instructions.md — neuer Abschnitt „Entstehungsprotokoll” mit Stil-Konventionen:

[!NOTE] Prompt: Wir haben einen neuen Anhang w_Rust-Projekt_claw-code.md.
Baust du den Bitte ins README.md ein und macht Commit&Sync?

Claude Opus 4.6 – Anhang ins README einbauen

Jetzt baue ich den neuen Anhang w_Rust-Projekt_claw-code.md an beiden Stellen ein — Dokumentationstabelle und Projektstruktur:

Commit ba9089e gepusht.

Stelle Änderung
Dokumentationstabelle Neue Zeile: Anhang „Rust-Projekt claw-code” mit Link und Beschreibung, alphabetisch vor den anderen Anhängen (w < x < y < z)
Projektstruktur w_Rust-Projekt_claw-code.md eingefügt

Made changes.

[!NOTE] Prompt: Unser Repository dokumentiert und analysiert aktuell die interne Architektur des Agent Harness von Claude Code, mit Shell, Dateisystem, Web, IDE-Integration und mehr.

Strategische Frage:
Wie weit sollten wir es mit ‘# 5. Erweiterungsmöglichkeiten’ und ‘# 6. API-Referenz’ noch treiben?
Ich denke an ein Folgekapitel ‘6. Ausblick - Wie die story weitergeht’ oder so, wo wir uns dann dem moderneren Ansatz widmen.

Claude Opus 4.6 – Strategische Planung Kap 5 & 6

Das ist eine wichtige strategische Frage. Lass mich die Optionen durchdenken.

Analyse: Was bringt Kap 5 & 6 noch?

Kapitel 5 – Erweiterungsmöglichkeiten

Geplanter Inhalt Bereits abgedeckt in… Mehrwert?
Plugin-System 3.7 (Skills & Plugins) Gering — Mechanik schon erklärt
Skill-System 3.7 + 4.8 (Hooks) Gering — Lade-Hierarchie, Frontmatter schon da
MCP-Integration 2.4 (Schicht 8), 3.6 (Tool-Referenz) Mittel — Protokolldetails fehlen noch
Custom Agents 3.5 (AgentTool), 4.6 (Sub-Agent-Spawning) Gering — loadAgentsDir, Isolation schon erklärt

Fazit Kap 5: 80% davon steht verteilt in Kap 3 und 4. Ein eigenständiges Kapitel würde vor allem zusammenfassen und verlinken, nicht viel Neues beitragen.

Kapitel 6 – API-Referenz

Eine klassische API-Referenz (Typen, Interfaces, Funktionssignaturen) hat bei einem nicht-öffentlichen, sich ändernden Codebase ein Haltbarkeitsproblem. Der Code wird sich mit jeder Claude-Code-Version ändern. Eine detaillierte Referenz wäre schnell veraltet und suggeriert eine Stabilität, die nicht gegeben ist.

Empfehlung: Pragmatischer Abschluss

Bisherige Kapitel          Was fehlt noch?          Wohin geht die Reise?
──────────────────         ──────────────────       ──────────────────────
1. Einleitung      ✅      5. Erweiterungen →       Schlank: Zusammenfassung
2. Architektur     ✅         (80% schon da)         + MCP-Vertiefung
3. Komponenten     ✅      6. API-Referenz →         Streichen oder als
4. Abläufe         ✅         (Haltbarkeitsproblem)   kompakte Typ-Übersicht
                            ─────────────────────
                            NEU: Ausblick-Kapitel

Konkreter Vorschlag

Kapitel Aktion Begründung
5. Erweiterungsmöglichkeiten Schlanke Version (~150 Zeilen): MCP-Protokolldetails vertiefen, Rest als Verweiskapitel auf Kap 3/4 mit Praxisbeispielen (eigene .claude/agents/, eigene Skills, eigene MCP-Server) Gibt dem Leser eine Anleitung zum Selbermachen, nicht nur Analyse
6. API-Referenz → Ausblick Neues Kapitel: „Ausblick — Wie die Story weitergeht” Zukunftsgerichtet statt rückwärtsgewandt

Mögliche Gliederung für Kap 6 (Ausblick)

# 6. Ausblick — Wie die Story weitergeht

## 6.1 Was wir aus dem Leak gelernt haben
     - Architektonische Patterns, die sich verallgemeinern lassen
     - Agent Harness als eigene Software-Kategorie

## 6.2 Offene Fragen
     - Was der Quellcode nicht verrät (Serverseitige Logik, Training,
       System-Prompt-Inhalt, Billing/Rate-Limiting)
     - Grenzen der statischen Analyse

## 6.3 Die nächste Generation
     - Rust-Reimplementierung (claw-code → Verweis auf Anhang W)
     - Coordinator-Mode als Vorbote von Multi-Agent-Systemen
     - Agents-as-a-Platform (oh-my-codex, clawhip, oh-my-openagent)
     - MCP als offener Standard → Ökosystem jenseits von Anthropic

## 6.4 Vergleichbare Systeme
     - Cursor, Windsurf, Cline, Aider, OpenHands, SWE-agent
     - Was sie gemeinsam haben, wo sie sich unterscheiden
     - Tabelle: Feature-Matrix Agent-Harness-Systeme

## 6.5 Fazit
     - Von „LLM + Prompt" zu „LLM + Harness + Tools + Agents"
     - Der Agent Harness als das eigentliche Produkt

Warum das besser passt

  1. Kap 1–4 = Analyse (Was ist da? Wie funktioniert es?) — abgeschlossen
  2. Kap 5 = Anleitung (Wie erweitere ich es selbst?) — praxisnah, schlank
  3. Kap 6 = Einordnung (Was bedeutet das für die Branche?) — gibt dem Repo einen Bogen und eine Daseinsberechtigung über die reine Code-Analyse hinaus

Das Rust-Projekt (w_Rust-Projekt_claw-code.md) wird dann im Ausblick kontextualisiert statt isoliert im Anhang zu stehen.

Soll ich mit dieser Struktur loslegen? Ich würde Kap 5 (schlank) und Kap 6 (Ausblick) schreiben, die README aktualisieren und committen.

[!NOTE] Prompt: Ja, gern. Mach’ das so.

Aber die w_Rust-Projekt_claw-code.md erstmal noch nicht löschen. Zu gegebener Zeit können wie sie in der README.md als veraltet markieren, sie in einen Archiv-Ordner verscieben oder am Ende tatsächsich doch löschen. BTW noch etwas für die copilot-instructions.md: Verwende in der Spalte ‘Kapitel’ unter ‘## Dokumentation’ in der README.md bitte U+00A0 oder U+202F. Bei ‘5. Erweiterungsmöglichkeiten’ habe ich das bereits umbebaut, weil das in der Tabelle sonst doof aussieht. Hinter ‘Anhang:’ bleibt ein normales ` `, dort soll der Text umbrechen.

Claude Opus 4.6 – Kapitel 5 & 6 fertigstellen

[!NOTE] TorstenC selected “Continue” (50 waren nicht genug)

Fünf Aufgaben: copilot-instructions U+202F-Regel, Kap 5, Kap 6, README, Commit.

copilot-instructions.md — U+202F-Regel ergänzt:

Kapitel 5 — Quelldateien analysiert:

5_Erweiterungsmöglichkeiten.md — 226 Zeilen geschrieben:

Abschnitt Inhalt
5.1 Überblick Vier Erweiterungsebenen (CLAUDE.md → Skills → MCP → Plugins), ASCII-Diagramm
5.2 Skills Lade-Hierarchie (6 Quellen), Frontmatter-Referenz, praktisches Beispiel, Bundled-Skills-Tabelle (~12 Skills)
5.3 MCP-Server Architektur-Diagramm, Schlüssel-Dateien-Tabelle, zwei Richtungen (Client + Server), Tool-Pool-Integration
5.4 Plugins Built-in vs. Marketplace, Plugin-Identifikation
5.5 Custom Agents Beispiel-Konfiguration .claude/agents/, mcpServers-Frontmatter
5.6 Entscheidungshilfe Tabelle: Anforderung → empfohlene Ebene

6_Ausblick.md — 155 Zeilen geschrieben (Datei umbenannt von 6_API-Referenz.md):

Abschnitt Inhalt
6.1 Learnings 5 zentrale Erkenntnisse (Architektur > Modell, Kontext-Management, Permissions, MCP, React/Ink)
6.2 Offene Fragen Coordinator, MCP-Skalierung, Cache-Invalidierung, Bridge, Kosten
6.3 Nächste Generation claw-code (Querverweis auf Anhang w), Coordinator/Multi-Agent, Agents-as-Platform
6.4 Vergleichbare Systeme Tabelle (6 Systeme), gemeinsame Muster, Alleinstellungsmerkmale
6.5 Fazit Trends: TypeScript→Rust, Single→Multi-Agent, Plugins→MCP, Tools→Tasks

README.md — aktualisiert:

1_Einleitung_&_Zweck.md — Inhaltsverzeichnis: Kap 5/6 Titel aktualisiert.

w_Rust-Projekt_claw-code.md — unverändert beibehalten.

Commit 42a5005, 7 Dateien (inkl. index.md via Pre-commit-Hook), gepusht auf origin/main.

<‌!– ENDE TODO “Diesen Teil noch aus dem Original-Chat extrahieren” –>

[!NOTE] Prompt: Ist in diesem wavespeed.ai Blog Post noch etwas drin, was in unsere Doku gehört oder sie etwas auflockern könnte?
https://wavespeed.ai/blog/claude-code-agent-harness-insights

Claude Opus 4.6 – Analyse wavespeed.ai Blogpost

Gute Frage. Ich gleiche den Blog-Post systematisch mit unserer Doku ab:

Was der Blog-Post enthält vs. was wir schon haben

Thema im Blog-Post Bei uns abgedeckt? Interessant?
.map-File Leak-Mechanismus ❌ Nicht beschrieben ✅ Ja — gehört in Kap 1 oder Entstehungsprotokoll als Kontext
512.000 Zeilen, ~1.900 Dateien ❌ Nur angedeutet ✅ Konkretes Zahlenwerk für die Einleitung
BUDDY (virtuelles Haustier) ❌ ⚠️ Unterhaltsam, aber nicht architektur-relevant
KAIROS (persistent assistant) ❌ ✅ Architektonisch interessant — passt zu 6.2 (Offene Fragen)
ULTRAPLAN ✅ Erwähnt in Kap 3 (Commands) Schon drin
Coordinator Mode ✅ Kap 3.5, 4.6 Schon drin, ausführlich
108 Feature Flags ❌ Nur einzelne erwähnt ✅ Gute Zahl für Kap 5 oder 6
Undercover Mode (USER_TYPE === 'ant') ❌ ⚠️ Brisant, aber nicht architektur-relevant
Bun + React/Ink ✅ Kap 2, 3 Schon drin
Query Engine ~46.000 Zeilen ❌ Wir sagen ~1.296 für QueryEngine.ts ⚠️ Die 46k-Zahl bezieht sich vermutlich auf das gesamte Query-Subsystem
3-Layer Context Compression ✅ Kap 3.2, 4.3 Schon drin (wir haben sogar 6 Stufen identifiziert)
40+ Tools ✅ Kap 3.6 (Tool-Referenz) Schon drin
Telemetrie (Frustration-Tracking) ❌ ⚠️ Interessant, aber außerhalb unseres Scope
Voice Mode, Web Browser Tool, Daemon, Agent Triggers ❌ ✅ Passt zu Kap 6.3 (Nächste Generation)

Empfehlung: Drei gezielte Ergänzungen

1. Kap 1 — Hintergrund zum Leak (3–5 Sätze)

Wir beschreiben bisher was wir analysieren, aber nicht wie der Code öffentlich wurde. Ein kurzer Absatz würde den Kontext setzen:

Version 2.1.88 enthielt versehentlich eine Source-Map-Datei (main.js.map), die den vollständigen Quellcode rekonstruierbar machte. Bun erzeugt diese Dateien standardmäßig; die .npmignore schloss sie nicht aus. Die Codebasis umfasst ~512.000 Zeilen in ~1.900 Dateien.

2. Kap 6.2 — KAIROS als offene Frage erwähnen (2–3 Sätze)

KAIROS (persistenter, proaktiver Hintergrund-Agent mit append-only Logs und „Dreaming”-Konsolidierung) passt perfekt zu den offenen Fragen — es zeigt, wohin Anthropic intern denkt:

Der Quellcode enthält Hinweise auf ein internes System namens KAIROS — einen persistenten Agenten, der Beobachtungen in append-only Logs sammelt und nachts in einem „Dreaming”-Prozess konsolidiert. Das Feature ist hinter einem internen Flag verborgen und nicht aktivierbar.

3. Kap 6.3 — Feature-Flag-Zahlen und weitere geplante Tools

Die Zahl 108 gated modules und die Liste (Voice Mode, Web Browser, Daemon, Agent Triggers) würden Abschnitt 6.3 konkretisieren.

Was ich nicht aufnehmen würde

Thema Begründung
BUDDY Spaßig, aber architektonisch irrelevant — gehört in einen Blog-Post, nicht in eine technische Analyse
Undercover Mode Politisch brisant, würde den sachlichen Ton der Doku gefährden. Wir dokumentieren Architektur, nicht Firmenethik
Telemetrie-Details Außerhalb unseres Scope (wir analysieren das Harness, nicht die Datenerfassung)

Soll ich die drei Ergänzungen einbauen? Das wären insgesamt ~15 Zeilen in drei bestehenden Dateien, kein neues Kapitel.

[!NOTE] Prompt: Ja, guter Vorschlag. Baue die drei Ergänzungen bitte ein.
Den letzten Push habe ich schon nachgeholt.
Du kannst also gleich einen neuen Push machen.

Claude Opus 4.6 – Leak-Hintergrund, KAIROS und Feature-Flag-Zahlen ergänzen

Zuerst prüfe ich den aktuellen Stand der drei Dateien:

Created 4 todos

Gut, jetzt habe ich den Kontext. Alle drei Edits:

1. Kap 1 — Leak-Hintergrund ergänzen:

2. Kap 6.2 — KAIROS als offene Frage:

3. Kap 6.3 — Feature-Flag-Zahlen und geplante Tools:

Lint prüfen:

Keine Lint-Fehler. Commit & Push:

5 Dateien — die 2 geänderten + index.md (Pre-commit-Hook) + die 2 vom User zuvor editierten Dateien (z_Entstehungsprotokoll.md, copilot-instructions.md).

Ran terminal command: git push

Completed (2/4) Kap 6.2 — KAIROS erwähnen

Erledigt! Commit 1a1dffc ist gepusht. Zusammenfassung der drei Ergänzungen:

Datei Änderung
Kap 1.1 Leak-Mechanismus konkretisiert: Source-Map (main.js.map), Bun-Default, fehlende .npmignore-Regel
Kap 6.2 Neue Zeile in Offene-Fragen-Tabelle: KAIROS — persistenter Hintergrund-Agent mit append-only Logs und „Dreaming”-Konsolidierung
Kap 6.3 Agents-as-Platform um Zahlen ergänzt: 108 gated Module, plus Voice Mode, Web Browser Tool, Daemon Mode, Agent Triggers als konkrete Beispiele

[!NOTE] Prompt: Wo ich gerade ‘claude-code-2.1.88/’ sehe:
Magst du nochmal scauen, ob da irgendwas drin ist, was für unsere Doku relevant sein könnte?

Claude Opus 4.6 – Analyse des claude-code-2.1.88/ Ordners

<‌‌‌‌‌!– ENDE TODO “Diesen Teil aus dem Original-Chat extrahieren” –>

[!NOTE] Prompt: Schaue nochmal, ob unter claude-code-2.1.88/source/vendor/ nix dabei ist, und dann bitte die Ergänzungen einbauen, committen und pushen. 👍

Claude Opus 4.6 – Vendor-Quellen geprüft, Ergänzungen implementieren

<‌!– ENDE TODO “Diesen Teil aus dem Original-Chat extrahieren” –>

[!NOTE] Prompt: Ist bei w_Rust-Projekt_claw-code.md noch ein Feinschliff nötig? Vor ## 1. … soll ein Teaser stehen bleiben, aber es soll sich auch nicht viel Redundantes wiederholen. Vielleicht müssen sogar die Kapitel neu strukturiert werden. Falls du nicht unsicher bist und mich fragen möchtest, einfach anpassen und pushen, bitte.

Anhang: Rust-Projekt claw-code — Einordnung und Abgrenzung

<‌!– ENDE TODO “Diesen Teil aus dem Original-Chat extrahieren” –>