autonomy-postmortemlisted

# Autonomy postmortem Every interruption is a defect in the setup, not a fact of life. Treated one at a time, they get resolved and forgotten; treated as postmortems, each one permanently removes a class of interruption. The failure mode this guards against is answering the question and moving on. The answer unblocks one run; the postmortem unblocks every future one. Blameless in the ordinary sense, and specifically: the agent's behaviour is a symptom. "The agent should have known" is not a finding — the finding is which document should have told it. ## 1 — Establish what happened - Where in the run did it stop, and what was the exact question or wrong output? - What did the agent already have available — spec, map, `CLAUDE.md`, glossary, contract? - What did it need that it did not have? - What did the human supply that unblocked it? That last answer is the raw material. Whatever the human said is, almost always, what should have been written down before the run started. ## 2 — Classify The class determines where the fix lands, and a fix in the wrong place does not prevent the recurrence: | Class | Signature | Fix lands in | |---|---|---| | **Missing context** | The human answered with a fact about the codebase or the team's conventions | `CLAUDE.md` via `context-baseline`, or `docs/agent/wiki/` via `dev-wiki` | | **Thin spec** | The human made a product or design decision | `spec-forge` — usually a dimension `grill-spec` should have asked about | | **Weak guardrail