From ea325f6bcb416f81636915d7de568caaabd9d350 Mon Sep 17 00:00:00 2001 From: dtzp555 Date: Mon, 9 Mar 2026 07:48:39 +1000 Subject: [PATCH] Fix completion-consumption gap in agent workflow --- memory/2026-03-09.md | 14 ++++++++++++++ memory/CURRENT_STATE.md | 9 +++------ skills/agent-workflow/SKILL.md | 14 ++++++++++++++ skills/execution-agent-dispatch/CHECKLIST.md | 7 +++++++ skills/project-heartbeat/SKILL.md | 2 ++ 5 files changed, 40 insertions(+), 6 deletions(-) diff --git a/memory/2026-03-09.md b/memory/2026-03-09.md index 1ded323..846b555 100644 --- a/memory/2026-03-09.md +++ b/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. diff --git a/memory/CURRENT_STATE.md b/memory/CURRENT_STATE.md index 15406e3..cb20640 100644 --- a/memory/CURRENT_STATE.md +++ b/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 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 +- [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 ## 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 diff --git a/skills/agent-workflow/SKILL.md b/skills/agent-workflow/SKILL.md index 45884f5..da338e8 100644 --- a/skills/agent-workflow/SKILL.md +++ b/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` diff --git a/skills/execution-agent-dispatch/CHECKLIST.md b/skills/execution-agent-dispatch/CHECKLIST.md index a29ce4a..3c74b63 100644 --- a/skills/execution-agent-dispatch/CHECKLIST.md +++ b/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 diff --git a/skills/project-heartbeat/SKILL.md b/skills/project-heartbeat/SKILL.md index 45f472a..28ded1a 100644 --- a/skills/project-heartbeat/SKILL.md +++ b/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`