retrolisted

Run a retrospective. Subject: $ARGUMENTS (plan slug, session or incident) 1. Look at the recent trend in docs/METRICS.md first (rework, questions, duration, and `bug:` plans that name a shipped slug — a failed acceptance; `hotfix:` lines piling up — three or more since the last retro means the plans' verification lets small defects through; the tests column — `tests +0` on a shipped plan, or the `n/a` share climbing across plans, means the proves gate is being waved), then pinpoint at most three places where rework, verification failures, review blockers, CEO intervention or incidents occurred, and write the root cause of each. Brainstorm and revision discussions are expected, not intervention; retro subjects are a brief whose `Corrections:` line reached 2 with items sent to Undecided, a spec section revised twice or more (`rev 3` or higher), a plan amended more than once (`rev 3` or higher in docs/METRICS.md), a plan whose sections 1–2 diverged from its section, and a revision that discarded shipped work — the CEO saw the product and it was not what they meant: what did the section miss. 2. Propose a countermeasure per cause and say where it belongs: one line in CLAUDE.md / a skill change / a guardrail hook (hard block) / a "## Risk paths" glob / the plan format / agent memory / a new role via `/recruit` (only for a new permission boundary or a separate judge). 3. Have team-planner apply only what the CEO approves. Add rules only for things that actually went wrong. Then co