soa-write-retrospectivelisted

# Write Retrospective Retrospectives are AI-readable artifacts first, human-readable second. Future agents read them at phase starts and epic planning to understand what patterns to repeat, what to avoid, and what the spec missed. Section naming must be consistent across retrospectives so agents can reliably extract signal. ## Required Sections (in order) ### 1. Scope delivered What shipped: PR numbers, branch name, scope items as a short list. One paragraph max. This is the factual anchor — without it the retro floats. ### 2. What went well Patterns to repeat. Include _why_ they worked, not just that they did. "TypeScript caught it" is noise. "TypeScript caught it because the type was narrow enough to make the error unambiguous at the call site" is signal. Aim for reusable lessons, not praise. ### 3. Pain points Friction sources with root cause. Distinguish **avoidable waste** (something that could be designed away) from **expected cost** (inherent to the work). Both are worth recording but they imply different follow-up. ### 4. Surprises Things not in the spec — good and bad. This is the highest-signal section for future AI readers: surprises are exactly what won't appear in docs or specs. A surprise that led to a fix belongs here with full context. A surprise that was benign still belongs here so the next agent doesn't have to rediscover it. ### 5. What we'd do differently Architectural or process choices that hindsight would change. Distinct from pain points: