Harden workflow evidence gates after failed agent test

memory/2026-03-09.md

@@ -0,0 +1,22 @@
+# 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.
+
+## Workflow corrections agreed with Tao
+- 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.
+
+## Documentation updated
+- 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.

memory/CURRENT_STATE.md

@@ -3,11 +3,10 @@
 _Last updated: 2026-03-08 11:13 Australia/Brisbane_
 
 ## In Flight
-- [in_progress] Geopolitical Turbulence Trapper — main — Milestone 2: brief + schema + module/page draft in progress
 - [in_progress] anti-silence workflow hardening — main — project-heartbeat runtime state + heartbeat hook added
 
 ## Blocked / Waiting
-- none
+- [failed] Geopolitical Turbulence Trapper workflow test — main — 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
 
 ## Recently Finished
 - promo_worker packaging pass completed — added MIT LICENSE to execution-agent-planner and gh-pr-release-flow, added README related-project links across OCM/clawkeeper/skill repos, merged OCM PR #12, published clawkeeper v0.1.0

memory/project-heartbeat-state.json

@@ -2,15 +2,15 @@
   "version": 1,
   "activeProject": {
     "name": "Geopolitical Turbulence Trapper",
-    "state": "armed",
+    "state": "failed",
     "timeoutMin": 10,
-    "lastUserVisibleUpdateAt": "2026-03-08T19:04:00+10:00",
-    "lastCheckAt": null,
+    "lastUserVisibleUpdateAt": "2026-03-09T06:51:00+10:00",
+    "lastCheckAt": "2026-03-09T06:51:00+10:00",
     "trackedWorkers": [
       "data_worker",
       "strategy_worker",
       "dashboard_worker"
     ],
-    "notes": "Use project-heartbeat rules. If timeout expires with no meaningful update, inspect worker traces / CURRENT_STATE / blocker state and send a user-visible update. Close when project is done, paused, failed, or cancelled."
+    "notes": "Heartbeat check at 06:51 found the project still active but with no worker launch evidence: subagents list empty, no subagent sessions visible, and CURRENT_STATE.md still shows Milestone 2 brief + schema + module/page draft under main with no recorded blocker. Tao also explicitly complained at 06:45 that progress updates were looping without real advancement. Sent one concise anti-silence update to Tao framing the work as blocked on lack of execution evidence and reset the timer from 06:51."
   }
-}
+}

skills/agent-workflow/SKILL.md

@@ -25,6 +25,11 @@ Use these states only:
 - `reviewing`
 - `done`
 
+Important:
+- `dispatching` is not a cosmetic alias for `in_progress`.
+- Use `dispatching` only while delegation is being launched and there is still no execution evidence.
+- If execution evidence never appears, do not quietly leave the task in `dispatching`; convert it to `blocked` with reason `launch failure`.
+
 ## State meaning
 - `planned`: task exists and has been defined
 - `dispatching`: main has initiated delegation, but does not yet have enough evidence that the worker truly launched

skills/execution-agent-dispatch/SKILL.md

@@ -50,11 +50,16 @@ Tell the worker what first checkpoint matters and when main expects the first up
 ## Worker response format
 
 Execution agents should respond compactly with:
-- `status:` ok | blocked | failed
-- `changed:` files changed/created, commands run, or "none"
-- `notes:` short summary
+- `status:` accepted | milestone | blocked | failed | done
+- `summary:` short summary
+- `evidence:` files changed/created, commands run, session/log proof, or `none`
+- `risk:` key caveat or `none`
 - `next:` next action or handoff need
 
+Important:
+- A reply without `evidence` is not enough for main to claim the task is truly `in_progress`.
+- `accepted` means the worker has seen the handoff; it does not automatically mean meaningful execution has started.
+
 ## Escalate immediately when
 
 A worker should report back to main instead of silently stalling when: