BhangeeF16 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 (pass / pass_with_risks / blocked / failure), and blocking questions as an explicit list (empty list stated explicitly).