tim
ee18a1f591
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>
62 lines
2.3 KiB
Markdown
62 lines
2.3 KiB
Markdown
---
|
|
module_id: tools-context/atomic-chain
|
|
version: 0.1.0
|
|
description: Strikt-sequenzielles atomic_create_*-Pattern mit ID-Weiterreichung.
|
|
max_tokens: 250
|
|
applies_to: [lueckentext-builder, future-atomic-chain-builders]
|
|
sources:
|
|
- personas/lueckentext-builder.md (a→b→c→d-Workflow mit brickId/layerId-Verkettung)
|
|
extracted_at: 2026-06-02
|
|
extracted_by: 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.
|