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>

tools-context/atomic-chain.md

@@ -0,0 +1,61 @@
+---
+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.