Recovery Protocols — When You're Behind, Stuck, or Burned

Build the protocols for the three failure modes every engineer hits and almost no engineer has protocols for: "I'm going to miss the deadline," "I don't know what to do next," "I'm running on empty and the work is degrading." Each gets a distinct, pre-written recovery protocol; conflating them is itself a failure mode. Recovery protocols are graceful degradation. Behind: fail explicitly (proactive communication, re-scope) rather than silently (deadline passes wordlessly) — the worst production incident is the one nobody reported. Stuck: run the smallest possible experiment to surface state instead of grinding — you already debug this way; the module is permission to debug yourself this way. Burned: reduce load before the crash, because forced cooling after thermal shutdown always costs more than the throttling would have. And the differential is class-of-condition dispatch: running the push-through handler on a depression event isn't a no-op — it's a handler that suppresses the retry logic the actual condition needs. Get the dispatch right before optimizing any handler.