---
type: aar
status: open            # open | harvested
date: YYYY-MM-DD
related: []             # design docs, issues, ADRs involved
---

<!-- Copy to docs/aar/YYYY-MM-DD-slug.md. Delete comments when filling in.
     Standalone AARs are for incidents and major deviations only —
     normal undertakings get their AAR as Gate 5 inside the design doc. -->

# AAR: Title

## What was planned / expected

## What happened

<!-- Facts and timeline, not blame. -->

## Why the difference

<!-- Root cause. For failures, name the routing class:
     intent issue / spec issue / code issue. -->

## Learnings

<!-- What future-you should know. Blunt beats polite. -->

## Actions

<!-- Concrete: wiki pages updated (FAQ, Stolpersteine) with links,
     framework issues opened, tests added. When all actions are done,
     set status: harvested. The refinement session walks all AARs
     still marked open. -->

<!-- ## Nachtrag YYYY-MM-DD — <Thema>   (optional, append-only)

     Nachträge sind erlaubt und haben sich bewährt (Korrekturen, spätere
     Auflösung eines offenen Punktes). Regeln:
     - ANHÄNGEN, nie oben im Text nachbessern: der ursprüngliche Stand bleibt
       lesbar, sonst verschwindet genau der Irrtum, aus dem man lernen wollte.
     - Datiert überschreiben und benennen, was sich geändert hat.
     - Widerspricht ein Nachtrag einer früheren Aussage, dort einen Verweis
       setzen ("→ korrigiert im Nachtrag vom …") statt sie umzuschreiben.
     - Befunde-Tabellen dürfen nachträglich um Issue-Referenzen ergänzt werden
       (reine Vervollständigung, kein Nachtrag nötig).
     Wächst ein AAR über ~drei Nachträge hinaus, gehört das Thema in ein
     eigenes Folge-AAR statt in den vierten Anhang. -->