2026-03-09

Geopolitical Turbulence Trapper workflow test marked failed

Tao explicitly called out that main had fallen into a loop of sending long "in progress" updates without actual advancement.
Re-check showed no live or recent execution evidence for the planned workers:
- data_worker
- strategy_worker
- dashboard_worker
subagents list returned none, no subagent sessions were visible for this work, and CURRENT_STATE.md had to be corrected from a generic blocked/in-flight framing to a clearer failure framing.
Conclusion agreed with Tao: this was not a case of one worker getting stuck mid-execution; the workflow test failed earlier because execution agents never truly launched into evidenced work.

Add a hard distinction between dispatching and in_progress.
Require evidence before claiming a task is truly underway.
Treat missing first evidence within 10 minutes as blocked: launch failure.
Main should only proactively update Tao on: actual start with evidence, milestone, blocker, or completion.
Long empty "in progress" status pages are now considered process noise, not progress.

Updated skills/agent-workflow/SKILL.md to strengthen the dispatching vs in_progress rule and require conversion to blocked on launch failure.
Updated skills/execution-agent-dispatch/SKILL.md so worker replies must include status / summary / evidence / risk / next, and so accepted does not get mistaken for meaningful execution.
Updated memory/CURRENT_STATE.md so the Geopolitical Turbulence Trapper entry is recorded as a failed workflow test rather than vague ongoing progress.

At 07:04 Tao approved restarting the project.
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.

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.

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.