Files

T

tim ee18a1f591 M3.10: tools-context/* — drei Tool-Context-Module + drop gitkeep

Drei Module, klar nach Persona-Scope getrennt:

- brick-creation.md: Pulse / View / Row / Pool-View-Tools + die haerteste
  Stolperfalle (delete_brick vs delete_view_brick vs remove_word_from_row).
  Main-Voice-exklusiv.

- atomic-chain.md: Strikt-lineares Pattern fuer Sub-Agents ohne
  All-in-One-Finalize (Lueckentext). Drei Regeln: Reihenfolge, IDs aus
  Vorgaenger, bei Fehlschlag-Run beenden statt aufraeumen.

- atomic-finalize.md: All-in-One-Pattern fuer Sub-Agents MIT Finalize
  (Kreuzwort). Kombiniert Layer-Erstellung + Solution-Set atomar —
  vermeidet orphan-Zustaende.

atomic-chain und atomic-finalize zeigen explizit zueinander: wenn ein
Finalize-Tool existiert, bevorzuge es. atomic-chain ist Fallback wenn
das Backend nur die getrennten Tools anbietet.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-06-02 15:32:58 +02:00

2.3 KiB

Raw Blame History

module_id, version, description, max_tokens, applies_to, sources, extracted_at, extracted_by

module_id

version

description

max_tokens

applies_to

sources

extracted_at

extracted_by

tools-context/atomic-chain

0.1.0

Strikt-sequenzielles atomic_create_*-Pattern mit ID-Weiterreichung.

250

lueckentext-builder

future-atomic-chain-builders

personas/lueckentext-builder.md (a→b→c→d-Workflow mit brickId/layerId-Verkettung)

2026-06-02

phase-M3

Atomic-Chain Pattern

Manche Sub-Agents bauen ihr Layer in einer strikt-linearen Kette atomarer Tool-Calls, wo das Ergebnis eines Tools die Eingabe des naechsten ist.

Generisches Pattern (Beispiel: Lueckentext)

a) atomic_create_<TYP_1>_brick(...)            → liefert brickId_1
b) atomic_create_<TYP_2>_brick(...)            → liefert brickId_2
c) atomic_create_layer(
     layoutTemplate,
     brickZones: { [brickId_1]: "...", [brickId_2]: "..." }
   )                                            → liefert layerId
d) atomic_set_<TYP>_solution(layerId, ...)

Drei harte Regeln

Regel 1 — Reihenfolge ist Pflicht

a → b → c → d in GENAU dieser Reihenfolge. Schritt d ohne c davor scheitert immer — set_solution braucht eine real existierende layerId.

Regel 2 — IDs aus Vorgaenger-Calls, nicht erfunden

In Schritt c musst du die EXAKTEN brickId-Werte aus Schritt a und b nutzen. In Schritt d musst du die EXAKTE layerId aus Schritt c nutzen.

Niemals "default", "layer-1" oder einen erfundenen Wert. Wenn du die ID nicht parat hast: lies sie aus dem functionResponse des Vorgaenger-Tools (steht meist als { brickId: "...", layerId: "..." }).

Regel 3 — Bei Fehlschlag: zurueck zum Anfang der Kette

Wenn Schritt c scheitert, ist die Kette gebrochen — a und b haben Bricks erzeugt die jetzt orphans sind. Der Orchestrator-Wrapper raeumt die beim naechsten Start ueber Orphan-Cleanup auf. Du selbst musst nichts loeschen — einfach den Run beenden und ehrlich melden was nicht ging.

Wann ist das das richtige Pattern?

Wenn das Backend KEIN atomic_finalize_*-All-in-One-Tool anbietet (siehe tools-context/atomic-finalize.md).
Wenn Brick-Erstellung und Layer-Erstellung bewusst getrennt sind, damit das LLM Zwischen-Validierung sieht.

Wenn ein atomic_finalize_*-Tool existiert (wie beim Kreuzwort), nutze das. Es ist robuster gegen abgebrochene Runs.

2.3 KiB Raw Blame History