Fix completion-consumption gap in agent workflow

memory/2026-03-09.md

@@ -26,3 +26,17 @@
 - Restart is being treated as a fresh evidence-gated run, not a continuation of the failed pseudo-progress loop.
 - Initial restart state is `dispatching`, with `main` explicitly owning the Milestone 2 restart until fresh visible execution evidence exists.
 - Heartbeat state was reset to track the restarted project under the new rules.
+
+## Validation + new failure mode found
+- Tao approved a minimal validation run using a single temporary worker.
+- The validation worker successfully launched, wrote `/Users/taodeng/.openclaw/workspace/main/tmp/worker-validation-2026-03-09.txt`, and returned a structured success report.
+- This confirmed the base execution-agent pipeline is functional.
+- However, the result auto-announced to Tao before main performed its own state-consumption and summary step.
+- New root-cause finding: the system is vulnerable to a `completion-consumption` bug where runtime-visible worker completion does not automatically flip main out of its local waiting posture.
+- Agreed fix direction: harden agent-workflow, project-heartbeat, and dispatch checklist rules so main must immediately consume visible worker completion/milestone/blocker and cannot continue behaving as if it is still waiting.
+
+## 07:16 watchdog result: launch failure / blocked
+- The project-heartbeat watchdog re-checked the restarted run after the 10-minute window.
+- No fresh worker/session execution evidence appeared beyond the 07:04 user-visible restart acknowledgment; active session traces showed no new milestone/work output for this project.
+- Per the new workflow rule, the restart must be treated as `blocked` with reason `launch failure`, not as silent `in_progress` work.
+- Heartbeat state was paused after reporting the blocker so Tao does not get repeated empty nudges without a new restart decision.