Files
management/docs/aar/template.md
T

49 lines
1.7 KiB
Markdown
Raw Normal View History

---
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. -->