learning-retrospectivelisted

# Learning Retrospective Help the current task move forward using evidence from earlier attempts. Keep the intervention proportional: usually a short check by the main agent is enough. ## When it helps - The user asks for a retrospective, or the same failure recurs without useful new evidence. - A current failure resembles a stored lesson worth checking before rediscovery. - A difficult task has produced a verified, reusable fix worth briefly explaining. A hook reminder is a candidate, not proof of a loop. A single failure, many tool calls, successful repeated commands, user-requested tests, and changed hypotheses that produce evidence are normal work. ## Apply the lesson Use the visible command/action, working directory, structured outcome and relevant error to decide what actually failed. Do not infer failure from a command name, repetition count, or a quoted log saying "error". Missing outcomes stay unknown. For a likely familiar failure, search the relevant lesson registry or project notes using the tool, error signature or path. Verify that any match still applies to the current environment. If nothing relevant appears, return to the task; do not turn recall into a broad history search. Use the evidence to choose a useful next check, repair or changed hypothesis. A justified retry after an environment change is allowed. Stop an unproductive approach when its premise is disproven; stop the whole task only for an actual permission boundary, missing dependency/input