zhi/HarborForge.OpenclawPlugin
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(wakeup): drop WAKEUP_OK ack-token theatre from wakeup message #10

Merged
hzhang merged 1 commits from fix/drop-wakeup-ok-token into main 2026-05-26 08:13:43 +00:00
Conversation 0 Commits 1 Files Changed 1 +15 -14
hzhang commented 2026-05-26 08:11:12 +00:00
Contributor
Copy Link

What

The wakeup dispatcher's deliver callback only does logger.info(reply.slice(0,100)) — no token detection, no scheduler state change. The "first line of your reply MUST be exactly WAKEUP_OK so the plugin records the ack" instruction in wakeupMessage was prompt theatre nothing acted on.

Confirmed by:

  • plugin/index.ts:335 — deliver: async (payload) => logger.info(...) (no ack handling)
  • openclaw/dist/plugin-sdk/src/auto-reply/tokens.d.ts — declares HEARTBEAT_OK and SILENT_REPLY tokens, nothing for wakeup
  • openclaw/dist/heartbeat-runner-*.js imports HEARTBEAT_TOKEN and calls stripHeartbeatToken() — equivalent machinery for the wakeup path simply doesn't exist
  • ClawSkills' own workflows/hf-wakeup/flow.md Appendix had a wandering note: "if the plugin re-wakes you every 30s after WAKEUP_OK, this is the known plugin bug" — i.e. the doc already conceded the ack doesn't do anything

Symptom in the wild

Every wakeup turn the agent burns a token on echoing WAKEUP_OK, and prompt material gets spent explaining a no-op handshake. Worst case: when the scheduler keeps re-waking (because not_started → ongoing PATCH isn't implemented server-side either) agents loop, re-ack each wake, and never escape the noise — exactly what we observed on prod t2 2026-05-26 (272 queued messages, 1645 ReplyRunAlreadyActiveError, separate root cause: monitor.hangman-lab.top NXDOMAIN, but the WAKEUP_OK theatre amplified it).

Fix

Rewrite wakeupMessage to tell the agent the actual truth:

You have due slots. Drive the `hf-wakeup` workflow of skill `hf-hangman-lab` 
to completion in this session — read slot context, call the harborforge_calendar_* 
tools, route to the right sub-workflow, and finish with harborforge_calendar_complete 
or harborforge_calendar_abort. The scheduler keeps re-waking you every 30s until 
the slot transitions out of `not_started`, so partial work or silence just produces 
another wake.{slotBlock}

The retained WAKEUP_OK mention in index.ts:310-315 is a "this used to be a thing but isn't" comment — left in deliberately so future readers don't re-invent the convention.

Companion change

ClawSkills d0109f3 removes WAKEUP_OK from skills/hf-hangman-lab/SKILL.md + workflows/hf-wakeup/flow.md. Both repos should land together; the order doesn't matter (each is independently correct after merge).

Behaviour change

None at runtime. Plugin code path is unchanged — only the string sent to the agent is shorter and more honest. Already-running agents will pick up the new wakeupMessage on the next gateway restart that loads the new plugin.

## What The wakeup dispatcher's `deliver` callback only does `logger.info(reply.slice(0,100))` — no token detection, no scheduler state change. The "first line of your reply MUST be exactly `WAKEUP_OK` so the plugin records the ack" instruction in `wakeupMessage` was prompt theatre nothing acted on. Confirmed by: - `plugin/index.ts:335` — `deliver: async (payload) => logger.info(...)` (no ack handling) - `openclaw/dist/plugin-sdk/src/auto-reply/tokens.d.ts` — declares `HEARTBEAT_OK` and `SILENT_REPLY` tokens, **nothing for wakeup** - `openclaw/dist/heartbeat-runner-*.js` imports `HEARTBEAT_TOKEN` and calls `stripHeartbeatToken()` — equivalent machinery for the wakeup path simply doesn't exist - ClawSkills' own `workflows/hf-wakeup/flow.md` Appendix had a wandering note: *"if the plugin re-wakes you every 30s **after** WAKEUP_OK, this is the known plugin bug"* — i.e. the doc already conceded the ack doesn't do anything ## Symptom in the wild Every wakeup turn the agent burns a token on echoing `WAKEUP_OK`, and prompt material gets spent explaining a no-op handshake. Worst case: when the scheduler keeps re-waking (because `not_started` → `ongoing` PATCH isn't implemented server-side either) agents loop, re-ack each wake, and never escape the noise — exactly what we observed on prod t2 2026-05-26 (272 queued messages, 1645 `ReplyRunAlreadyActiveError`, separate root cause: monitor.hangman-lab.top NXDOMAIN, but the WAKEUP_OK theatre amplified it). ## Fix Rewrite `wakeupMessage` to tell the agent the actual truth: ``` You have due slots. Drive the `hf-wakeup` workflow of skill `hf-hangman-lab` to completion in this session — read slot context, call the harborforge_calendar_* tools, route to the right sub-workflow, and finish with harborforge_calendar_complete or harborforge_calendar_abort. The scheduler keeps re-waking you every 30s until the slot transitions out of `not_started`, so partial work or silence just produces another wake.{slotBlock} ``` The retained `WAKEUP_OK` mention in `index.ts:310-315` is a "this used to be a thing but isn't" comment — left in deliberately so future readers don't re-invent the convention. ## Companion change ClawSkills [`d0109f3`](https://git.hangman-lab.top/lyn/ClawSkills/commit/d0109f3) removes `WAKEUP_OK` from `skills/hf-hangman-lab/SKILL.md` + `workflows/hf-wakeup/flow.md`. Both repos should land together; the order doesn't matter (each is independently correct after merge). ## Behaviour change None at runtime. Plugin code path is unchanged — only the string sent to the agent is shorter and more honest. Already-running agents will pick up the new wakeupMessage on the next gateway restart that loads the new plugin.
hzhang added 1 commit 2026-05-26 08:11:12 +00:00
fix(wakeup): drop WAKEUP_OK ack-token theatre from wakeup message 65a3fb8d2d 
The wakeup dispatcher's `deliver` callback only does
`logger.info(reply.slice(0,100))` — no token detection, no scheduler
state change. The "first line of your reply MUST be exactly WAKEUP_OK
so the plugin records the ack" instruction was prompt theatre that
nothing in this plugin (or in openclaw) acted on. Confirmed by
reading openclaw/dist/plugin-sdk/src/auto-reply/tokens.d.ts which
declares HEARTBEAT_OK and SILENT_REPLY tokens but nothing for wakeup.

Symptom in the wild: agents would replay WAKEUP_OK every turn for no
gain — costing model budget on a no-op token — and the workflow doc
(`ClawSkills/workflows/hf-wakeup/flow.md`) carried a wandering
appendix explaining the ack "doesn't actually do anything anyway".

Rewrite the wakeup message to tell the agent the truth: drive the
hf-wakeup workflow to completion; the scheduler keeps re-waking
every 30s until the slot transitions out of `not_started` via
harborforge_calendar_complete or _abort. No ack token expected.

ClawSkills companion change (lyn/ClawSkills d0109f3) removes
WAKEUP_OK from skills/hf-hangman-lab/SKILL.md and
workflows/hf-wakeup/flow.md.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
hzhang merged commit 81d40ae63d into main 2026-05-26 08:13:43 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
nav orion river zhi
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: zhi/HarborForge.OpenclawPlugin#10
Delete Branch "fix/drop-wakeup-ok-token"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?