debrieflisted

# Debrief Close the run by learning from it. Product learnings were captured by the knowledge-maintenance actions before this; this action's subject is the process itself. ## Dispatch One synchronous `Agent`-tool call, `subagent_type: debrief`. The dispatch prompt names the run's journal location (`.kaizen/runs/<run-id>/journal.md`, per the delivery-lead's own journaling duty). ## Required inputs - The completed run's journal — one line per dispatch, checkpoint decision, and human escalation, appended live by the delivery-lead during the run. ## Required outputs (all mandatory) - A proposal list — per proposal: the observed pattern, its journal citation, the target file, the proposed minimal change, and the expected effect on future runs — OR an explicit no-proposals record naming the journal read and the patterns checked. ## Rules — the propose-only boundary - No proposal is applied without an explicit human decision on it; an unanswered proposal is not an approved one. - Applied proposals get a changelog entry recording what changed and why; rejected proposals are recorded so they are not re-raised every run. - A missing journal is a stop condition — say so plainly; never reconstruct one from memory or transcript fragments. - A proposal that would change a mandatory human-approval checkpoint or a security-related rule is flagged high-impact and requires explicit discussion, not just a yes/no. ## Result Report the proposal list (or no-proposals record), the result