retrolisted

# Retro Use git, PR, issue, audit, and token evidence. Do not reconstruct the process from chat memory. Look for: - repeated edits to the same area or root cause; - extra inline review invocations; - audit findings that should have been caught before merge; - unreviewed or incorrectly based work; - serial founder questions that could have been batched; - parent snapshots that forced history retrieval; - horizontal issue multiplication; - token categories dominated by narration, startup payload, rereading, or mechanical execution; - claims of completion without commit, check, or acceptance evidence. Separate observed waste from hypotheses. Compare against a relevant baseline when available. Start from evidence generated since the last retro or applied correction for a given recurring signal; look further back into repository history only when that new evidence makes an older, previously insufficient or declined signal plausible again — do not reload full project history by default. Do not re-propose a correction already applied, and do not reopen a prior no-correction-needed verdict without new material evidence; cite what changed, not that time passed. Propose at most three corrections, ranked by expected validated progress per token. Each correction must name the evidence, root cause, smallest governing artifact to change, enforcement rung (advice, checklist, script, CI/gate), verification, and rollback condition. Prefer moving one proven rule up one enforcement rung