retrospective

A follow-through audit of every retrospective, chronicle, plan and report in the Vaults counted 24 promised fixes: 15 live, 9 dead or never built. The worst mistake class, unverified claims reaching a human, had been written up 11 separate times, and both of its proposed fixes were still unbuilt. Meanwhile improvement-gate.sh, the hook that enforced "every run improves the system that does the work", was retired 2026-07-28 and nothing ever replaced it.

The old version of this skill was not badly reasoned. Its nine lenses were sharp. It failed for one structural reason: every output was a ledger row, and a ledger row enforces nothing. A lesson written to a ledger that nothing reads at the moment of action is a gravestone with better formatting.

So version 3 inverts what this skill is for.

	v2	v3
primary question	what did we learn	did the last learnings actually fire
output	ledger rows	installed mechanisms, or an explicit accepted-no-mechanism row
when learning happens	here, at end of run	at error time, by error-loop.py; here only for what error time cannot see
a finding with no mechanism	acceptable	REFUSED, or recorded as explicitly accepted with a reason

This skill is no longer the primary learning mechanism, and must not be treated as one. Error-time closing belongs to _meta/services/error-loop.py, which opens a defect the moment a gate we own fails and refuses the next commit until a lesson or a waive is recorded. That catches the single instance while the cause is still warm.

What error-time closing structurally CANNOT see is recurrence across runs: the same mistake in different clothes, three independent reinventions of one missing primitive, a guard that has been quietly dead for six weeks. That, and only that, is what this skill is for.

Proportionality is a hard rule, not a preference. Aria has named the failure out loud: "overengineering the fuck out of this". A retrospective longer than the work it describes is a defect. If phase 0 finds nothing dead and phase 2 finds no recurrence, the correct output is four lines saying so.

<on_start> agentdb read-start agentdb recall "<the run's concrete nouns: files, symbols, error text>" for L in beliefs patterns anomalies questions; do tail -20 "_meta/ledgers/$L.jsonl" 2>/dev/null; done python3 _meta/services/error-loop.py list # anything still open from error time? ls -t _meta/reports/retrospective-*.json 2>/dev/null | head -3 </on_start>

A run that adds a new promise while an old one lies dead has made the problem worse, so this phase runs first and cannot be skipped.

1. Read the previous retrospective's mechanisms[] and the last 20 rows of each ledger.
2. For each promised mechanism, resolve a verdict. LIVE requires two facts: the file exists AND something invokes it. Prove the second with a grep, never by reading the file.
   • wired into a settings.json hook chain, or
   • a jobctl registry entry that launchctl list actually shows loaded, or
   • a git hook, or
   • a script another live script calls.
3. Any mechanism whose file exists but which nothing invokes is DEAD, not live. Say so in those words. A file nobody runs is indistinguishable from a file nobody wrote.
4. Any mechanism that was retired: find its replacement and verify the replacement is LIVE. A retirement with no live successor is a REGRESSION and outranks every new finding this run.
5. Count: promised, LIVE, DEAD, NEVER BUILT. That ratio is the headline of the report.

OUTPUT: followthrough[], one row per prior mechanism with {name, verdict, invoked_by, evidence}, plus the four counts. A phase 0 with no counts did not run.