-
…ea4d-main-checkout-drift
-
…d9ae-main-checkout-drift
-
Found for real: a work_graph_execute.WorkGraphExecuteError ("API Error: Response stalled mid-stream") wasn't in _ROUTABLE_EXCEPTIONS, so it propagated uncaught and crashed the calling process entirely -- leaving the task neither running nor blocked_pending_human, just stuck with blocked_reason=NULL. run_scheduler_once's own try/except only protects OTHER goals in the same batch from one goal's failure; it never applied the task-level blocked_pending_human consequence either. Add a catch-all mirroring task_execution._mark_blocked's existing fallback for its own (Start-button) entry point, so both ways of running a task now guarantee it always lands on a real terminal-ish status with the real error message persisted, never a caller-crashes-and-the-task-is-just-stuck outcome nothing can manual_resume from. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -
…0a72-main-checkout-drift
-
…2b85-main-checkout-drift
-
…f2cf-main-checkout-drift
-
Second real self-fix (after order 2) -- 12 skills migrated verbatim from ~/.hermes/profiles/, Validator caught and redacted a leaked Feishu API token in 3 of them via byte-diff against source. Also records two operational lessons from actually running it (a real network blip, and my own mistake killing a daemon thread by running it from a one-shot script) and a flaky supervisor test failure that didn't reproduce on independent recheck. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
Auto-continuation after a successful manual_resume only fired for blocked_reason in ('user_paused', 'user_stopped'). A real transient network blip ("API Error: Unable to connect to API (ENOTFOUND)") blocks a task with blocked_reason='execution_error' the same way any other unroutable exception does -- resuming it only flipped the status field back, with no path to actually re-trigger execution (/execute requires status='queued', but a resumed task lands on 'planning_brd_prd_sdd'/'coding' instead). Clicking "resume" was a dead end a second click couldn't fix. The user has already made the judgment call to retry by clicking resume at all. Withholding continuation only made sense for the two reasons with their own dedicated resume path requiring a different action first: budget_exceeded (must raise the limit) and loop_limit_reached (excluded by name, not just by its usual restored status). Every other blocked_reason now auto-continues on a successful resume to a resumable status. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -
Unlike order 1 (fixed by editing code directly), this one was resolved by actually running graphlemon's own Planner->Coder->Validator loop against its own repo (task 43dc7333, see 3bebe3b onward) -- the first real self-fix demonstration this doc's task list produced. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
