Retro

Retro

/lean-agent:lean-retro runs after every batch, weekly at the latest. It proposes changes to the method. It never changes the method, a script, a CLAUDE.md or memory by itself. A person approves.

1. Collect facts

lean-stats collect --since <YYYY-MM-DD> owner/repo ...
lean-stats report --since <YYYY-MM-DD>

report gives cost per change by model and role, the escalation rate, findings by where they were caught, critic misses, fix rounds and hook fires. A no data line is a gap in what was recorded, not a zero, and the retro says so instead of reasoning from it. For the raw row per pull request, run REVIEW_LOG=<path> retro-signals.sh --since <YYYY-MM-DD> owner/repo ....

Also gathered:

• the batch's adversarial review findings, by category;
• every step that needed a person;
• anything an agent worked out by reasoning that an earlier agent had also worked out;
• .lean/lessons.tsv in each repository, written by the lesson-log.py hook.

2. Check the last change first

Every accepted change named a number that should move. The retro reads that number first. If it did not move, or moved the wrong way, the retro proposes reverting the change.

3. Fixed triggers

Signal	Proposal
A finding category in two or more changes	A scripted check, a Risks line or a critic question
A check or critic question with no findings for three batches	Drop it for that tier
Reasoning repeated across agents	A script, with a test
A step that needed a person in two or more changes	Automate it, or script it with confirmations
Fix rounds or cost per change rising	Name the step that grew and a change to it
An escaped defect	A check that would have caught it, proven against that defect
Reviews not logged	Make logging part of the review script

Nothing is proposed without a trigger. If no trigger fires, the retro says so. That is a valid result.

4. The proposal

One short file with the facts the proposals use, the result of step 2, and each proposal as: what changes, where, the signal that triggered it, and the number that should move if it works, by how much, by which batch.

5. After approval

Each approved proposal is one pull request to the method. A script that works on any repository goes to arnelirobles/lean-agent, with a test. One tied to a repository goes to that repository's scripts/. A line goes into retro-log.md beside the review log: date, proposal, the number to watch.

Rejected proposals are logged too, with the reason, so they are not proposed again without new evidence.

The lean pass

After each milestone, one pass over what shipped. Agent-written code and comments over-explain, and no gate asks whether the result is lean. The pass deletes comments that restate the code and shortens what a newer language feature says more plainly. No behaviour change, and its own pull request.

Why a person decides

A method that rewrites itself unattended drifts toward whatever the numbers reward. Finding counts and scanner counts both fall when the review gets weaker, so neither is a target. See Measuring a Batch.