Tool-Ergebnisse als Content-Blöcke statt String

[webmatze]

This was generated by AI during triage.

Abgespalten von #31 (Variante B). #31 behält den Weg über @-Mentions, der ohne diesen Umbau funktioniert. Dieses Issue trägt den strukturellen Teil: ein Tool kann heute kein Bild zurückgeben.

Motivation

Sobald Bilder über @-Mentions in den Kontext kommen (#31), fehlt der zweite, offensichtliche Weg: read_file auf einen Screenshot. Der ist heute versperrt, weil Tool-Ergebnisse Strings sind. Damit bleibt dem Modell verwehrt, ein Bild selbst zu holen — es kann nur eines ansehen, das der Nutzer vorher angehängt hat.

Ist-Zustand — größer als in #31 beschrieben

#31 nennt CallResult, agent.cr, output.cr und „alle Tools". Es liegt eine Ebene tiefer:

• Tool#run(args : JSON::Any) : String ist die abstrakte Signatur der Basisklasse. Jedes Tool implementiert sie, inklusive der zur Laufzeit registrierten MCP-Tools.
• Tools::CallResult hält content : String und baut daraus per to_content_block einen Tool-Result-Block.
• Der Registry-Ausführungspfad gibt an mehreren Stellen früh Strings zurück (Approval abgelehnt, Tool-Exception, Hook-Nachbearbeitung, die den Output per String-Interpolation erweitert).
• Der JSON-Renderer schreibt result als Feld in den JSONL-Stream — ein Base64-Blob dort macht den Stream unbrauchbar.

Das ist der eigentliche Aufwand von #31, und er ist unabhängig vom Bild-Thema: Der Umbau ist derselbe, ob am Ende ein Bild, ein strukturiertes Diff oder mehrere Blöcke aus einem MCP-Server zurückkommen.

Zu klären, bevor Code entsteht

1. Wie weit trägt der Typwechsel? Ein Array(ContentBlock) überall, oder ein schmalerer Union-Typ (String | Array(ContentBlock)), damit die ~90 % Tools, die nur Text liefern, unverändert bleiben? Letzteres hält den Diff klein, verteilt aber Fallunterscheidungen im Registry.
2. MCP-Tools. Das MCP-Protokoll kennt bereits mehrteilige Ergebnisse mit Bildinhalten. Werden die beim Umbau gleich mitgenommen, oder bleibt der MCP-Adapter zunächst textig?
3. Rendering und Persistenz. Human-Renderer, JSONL-Renderer, Session-Datei und der rohe Transkript-Log müssen ein Nicht-Text-Ergebnis vertragen, ohne den Blob auszugeben oder zu speichern. Die Entscheidung dazu fällt sinnvollerweise gemeinsam mit Bild- und PDF-Input über @-Mentions #31, das dasselbe Problem für User-Nachrichten hat.
4. Reihenfolge. Dieses Issue ist erst sinnvoll, wenn Bild- und PDF-Input über @-Mentions #31 den Image-Block, die Magic-Byte-Erkennung, die Größengrenze und die Provider-Serialisierung etabliert hat. Vorher gibt es keinen Blocktyp zurückzugeben.

Nicht-Ziele

• Bilder über @-Mentions — das ist Bild- und PDF-Input über @-Mentions #31
• Der Binär-Guard in read_file — das ist read_file liest Binärdateien ohne Prüfung ein #63
• Bildbearbeitung, Skalierung, PDF-Parser