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.

memory/CURRENT_STATE.md

@@ -1,13 +1,10 @@
 # CURRENT_STATE
 
-_Last updated: 2026-03-08 11:13 Australia/Brisbane_
+_Last updated: 2026-03-09 07:47 Australia/Brisbane_
 
 ## In Flight
-- [in_progress] anti-silence workflow hardening — main — project-heartbeat runtime state + heartbeat hook added
+- [in_progress] anti-silence workflow hardening — main — workflow rules hardened again after finding a completion-consumption bug: runtime worker results can reach Tao before main updates state and summarizes them
-
+- [blocked] Geopolitical Turbulence Trapper restart — main — no fresh execution evidence appeared within the 10-minute dispatch window after the 07:04 restart; treating as launch failure / blocked pending Tao’s direction
-## In Flight
-- [in_progress] anti-silence workflow hardening — main — project-heartbeat runtime state + heartbeat hook added
-- [dispatching] Geopolitical Turbulence Trapper restart — main — restarting under the new evidence-gated workflow; main owns Milestone 2 restart and will only claim `in_progress` after fresh, visible execution evidence
 
 ## Blocked / Waiting
 - [failed] Geopolitical Turbulence Trapper workflow test — main — previous flow test failed: planned workers (`data_worker`, `strategy_worker`, `dashboard_worker`) never produced launch/execution evidence, yet main reported progress as if work were underway

skills/agent-workflow/SKILL.md

@@ -97,6 +97,20 @@ When a worker reports milestone/completion/blocker:
 
 If there is no evidence point yet, do not claim the work has already started; say it is about to start.
 
+## Completion-consumption rule
+If a worker completion/milestone/blocker has already been emitted by runtime or is visible in session history, main must treat that as a consumed-state obligation immediately.
+
+Main must not remain in a "still waiting" posture after worker completion is already visible.
+
+Required steps:
+1. read/confirm the worker result
+2. update task state / CURRENT_STATE
+3. send the user a normal main-authored update (`who / status / output / next`)
+
+Important:
+- runtime auto-announce does not replace main's supervisory duty
+- user seeing the worker result before main summarizes it is a main-process failure, not an acceptable steady state
+
 ## Blocked reasons
 Prefer a short blocked reason label:
 - `launch failure`

skills/execution-agent-dispatch/CHECKLIST.md

@@ -58,3 +58,10 @@ Before main says the task is done:
 - [ ] Basic verification happened when relevant
 - [ ] Caveats/blockers are disclosed
 - [ ] Tao has been updated
+
+## H. Completion-consumption gate
+If worker completion/milestone/blocker already exists in runtime/session history:
+- [ ] Main has explicitly read/confirmed the worker result
+- [ ] CURRENT_STATE reflects the new state
+- [ ] Tao has received a main-authored summary (`who / status / output / next`)
+- [ ] Main is no longer behaving as if it is still waiting for a reply

skills/project-heartbeat/SKILL.md

@@ -97,6 +97,8 @@ If multiple sub-tasks belong to the same project, keep the heartbeat open until
 - Do not keep the heartbeat alive after project closure.
 - Do not claim progress without evidence.
 - Silence is a process problem, not a neutral state.
+- If the latest check finds no new evidence since the previous user-visible update, do not dress that up as `in_progress`; report `blocked`, `launch failure`, or `no change` plainly.
+- Do not keep re-broadcasting stale `CURRENT_STATE` text as if it were fresh execution progress.
 
 ## References
 - For task-state rules and evidence gates: read `../agent-workflow/references/state-machine.md`