`installCli()` used to look for the CLI source at a fixed path relative
to the plugin checkout: either `./HarborForge.Cli` or `../HarborForge.Cli`.
That breaks any install layout where the plugin lives on its own — the
script just logs "Skipping CLI installation" and returns. Same anti-
pattern installManagedMonitor had already fixed for the monitor binary.
Mirror the monitor flow:
1. git clone --depth 1 --branch <cliBranch> CLI_REPO_URL → /tmp/<dir>
2. go build -ldflags Version=<date>+<branch>-<sha> -o $openclaw/bin/hf
3. chmod 755 + delete tmp dir on success or failure
Adds `--cli-branch <name>` (default: main) for parity with --monitor-branch.
Also stamps the binary with a real version string (was 'dev' before this
patch) so `hf version` is informative for debugging.
`pushMetaToMonitor` and `resolveAgentId` were both calling
`api.runtime?.config?.loadConfig?.()` to read the agent list. That
deprecated path (openclaw warns at gateway start:
"plugin runtime config.loadConfig() is deprecated; use config.current()")
synchronously rebuilds the full plugin-metadata snapshot — realpathSync
walks every plugin's package.json + manifest + source up the directory
tree, hashWatchedFiles fingerprints every watched plugin file, and
discoverInDirectory re-scans every `dist/extensions/<plugin>` (~100 of
them on prod t2). Each rebuild costs ~6-7s of gateway CPU.
`pushMetaToMonitor` fires every `reportIntervalSec` (default 30s)
from `hooks/gateway-start.js`. With 100 plugins that put the gateway
into a chronic ~22-30% CPU baseline even with zero agent activity. V8
profile 2026-05-27 08:14:00 60s window (0 turns, 2 metadata pushes
during): lstat 44.2%, statSync(buildInstalledManifestRegistryIndexKey)
6.9%, hashWatchedFiles via memo key 1.7%, all routed through
`readPersistedInstalledPluginIndexInstallRecordsSync` -> per-plugin
`discoverInDirectory`.
Switching to `(api as any).config ?? api.runtime?.config?.loadConfig?.()`
reads from the snapshot cache the gateway already maintains — the same
pattern already used elsewhere in this file (e.g. the calendar wakeAgent
dispatcher at line 284). Same change applied to `resolveAgentId` (only
runs once at start, but same anti-pattern).
This is a plugin-side perf workaround. The underlying openclaw bug is
that `loadConfig()` rebuilds the snapshot rather than returning the
cached one — a chronic 'all sync cache validity checks pay the full
discovery cost' design issue worth pushing upstream separately (the
walks per-call cost we measured here is unrelated to and amplifies any
agent-turn-triggered walk path).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
Cross-plugin accessor for "does agent have on_call slot covering this
window?" — first consumer is Dialectic.OpenclawPlugin signup pre-check
(its hf-precheck.ts has been degrading to "skipped" since Phase 3
ship pending this).
v1 honest scope: same-day windows only (scheduleCache is today-only
from /calendar/sync). Cross-day or empty-cache windows return undefined
which the caller treats as "skipped" (Dialectic backend stores
pre_validated:false as audit signal — same as before, just now we
actually validate when we can).
Logic: for each cached slot where slot_type=on_call AND status not in
{aborted,cancelled}, parse scheduled_at (HH:MM:SS or full ISO) and
estimated_duration to compute end; return true iff start<=from AND
end>=to. Returns false (not undefined) when cache has slots for the
agent on this date but none covers — that means "actually no coverage"
vs "I dont know".
Pairs with Dialectic.OpenclawPlugin/src/hf-precheck.ts which already
calls hf.hasOnCallCovering and handles all 3 return shapes.
No backend change required.
Cross-plugin agent-status accessor for use by Fabric.OpenclawPlugin's
presence-sync loop (and any future plugin needing 'is agent X busy
right now'). Backed by CalendarBridgeClient.getAgentStatus() with a
30s in-memory TTL cache to avoid hammering the HF backend.
Returns one of 'idle' | 'on_call' | 'busy' | 'exhausted' | 'offline'
or undefined when the agent isn't known to HF. Cache miss + bridge
failure returns the last cached value (stale-data better than no
data for delivery-decision use cases).
Part of DIALECTIC-V2 Phase 1 (Fabric announce channel + busy-discard).
See /home/hzhang/arch/DIALECTIC-V2-DESIGN.md sections 7+8.
OpenClaw's Codex tool dispatcher (thread-lifecycle:255) expects every
tool execute() to return { content: [...] } and calls result.content.reduce()
to compute total text length. All 9 harborforge_* tools returned bare
objects ({ running, processing, currentSlot, ... }) which has no
.content field — so .reduce of undefined threw, and the agent saw the
cryptic 'Cannot read properties of undefined (reading reduce)' on
every call. This silently blocked every calendar slot transition on
prod for hours: agents could call harborforge_calendar_complete but
it always errored, so slots never moved out of not_started.
Fix is at the registerTool boundary: api.registerTool is wrapped once
to coerce every tool's execute return through ensureMcpContentShape.
Tools that already return the correct shape are unchanged. No per-tool
edits needed.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
E2e showed the old wakeup text trapped agents in an ack-only loop:
> "You have due slots. Follow the `hf-wakeup` workflow of skill
> `hf-hangman-lab` to proceed. Only reply `WAKEUP_OK` in this session."
The two clauses contradicted each other — "follow the workflow" vs
"only reply WAKEUP_OK". MiniMax-M2.5 prioritised the literal "only"
and never proceeded past the ack; the scheduler then re-woke every 30s
because the slot stayed `not_started`, and the agent kept re-acking
forever (verified: 3 consecutive WAKEUP_OK-only replies across slot 7).
Rewrites the wakeup message to be explicit:
- first line MUST be `WAKEUP_OK` (the ack token the plugin looks for)
- then continue IN THE SAME session: drive calendar_status → task
fetch → sub-workflow → calendar_complete/abort
- flags the loop trap so the agent knows what to avoid
Bumps version 0.3.3 → 0.3.4.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Trying the prior multi-agent-handle fix in dind-t2 surfaced a second bug
that PR #7 didn't reach: `harborforge_calendar_status` still returned
`Calendar scheduler not running` even though the gateway log showed the
scheduler had started 30+ seconds before the agent's call.
## Root cause
`register()` is invoked once per agent — `grep -c "HarborForge plugin
registered" /tmp/gw-stdout.log` reports 5 for a 5-agent claw. Every
invocation creates its own `let calendarScheduler` closure binding. But
`gateway_start` fires once and we only call `startCalendarScheduler()`
through that single hook, so exactly one of the five closures sees the
handle and the other four keep their bindings at `null`.
The host's tool router picks one of the five duplicate
`harborforge_calendar_status` registrations to dispatch to — most of the
time it's one of the four "null" closures, which is why every wakeup the
agent saw `Calendar scheduler not running`.
## Fix
Lift `let calendarScheduler` out of `register()` and into module scope.
All five register-call closures now reference the same binding; once the
single `gateway_start` initialises it, every tool sees it.
`startCalendarScheduler()` now early-returns when `calendarScheduler` is
already set, so duplicate `gateway_start` firings (if the host ever does
that) don't double-install intervals.
Bumps version 0.3.2 → 0.3.3.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
In multi-agent sync mode every harborforge_calendar_* tool was returning
`calendarScheduler.<method> is not a function`. The cause: index.ts replaced
`calendarScheduler` (typed `CalendarScheduler | null`) with a `{ stop() }`
stub right after wiring the runSync/runCheck intervals, so `isRunning()`,
`getCurrentSlot()`, `completeCurrentSlot()`, `abortCurrentSlot()`,
`pauseCurrentSlot()`, `resumeCurrentSlot()`, `getState()`,
`isRestartPending()` and `getStateFilePath()` all blew up at call time.
Replaces the stub with a `MultiAgentSchedulerHandle` that:
- tracks the last slot dispatched per agent (recorded by `wakeAgent`)
- exposes status/complete/abort/pause/resume taking the calling agentId
- resolves the implicit "current slot" via woken-cursor first then a
cache scan over not_started/deferred/ongoing slots
- PATCHes via `bridge.updateSlotAs(agentId, …)` so audit headers reflect
the real caller (bridge constructor agentId is 'unused' in multi-agent)
- mirrors the legacy `isRunning/isProcessing/getState/...` surface so
the single-agent fallback (`CalendarScheduler`) keeps working unchanged
Each calendar tool factory now takes `OpenClawPluginToolContext`, reads
`ctx.agentId`, and dispatches through the handle. Single-agent path
(when `calendarScheduler` is a real `CalendarScheduler`) is preserved
behind `instanceof` checks.
Drops the dead `trackSessionCompletion` poll loop (only definition, no
caller) which referenced the removed `completeCurrentSlot`. Bumps
plugin version 0.2.0 → 0.3.2.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three issues making HF→agent wakeup unusable in practice, surfaced by
DinD sim end-to-end test (recruiter agent + slot for 招募 manager task):
1. **Plugin re-woke the same slot every 30s.** The inline runCheck only
destructured agentId from scheduleCache.getAgentsWithDueSlots() and
dropped the slots array, then called wakeAgent without recording the
wake. The simplified inline scheduler also never PATCHes slot status
server-side from not_started→ongoing, so the next 30s check sees the
slot still due and wakes again. After 4 wakes the agent's wakeup
session was full of WAKEUP_OK noise.
Fix: keep slots in runCheck, add an in-memory wakedSlotKeys set
keyed by (agentId, slotId|virtual_id|scheduled_at). Dedupe on this
set; clear it inside the sync interval (fresh wake budget per sync).
Server-side slot transition still TODO (requires re-introducing the
CalendarScheduler class path or PATCH /calendar/slots/.../agent-update
here); the dedupe at least stops the wake spam.
2. **Wakeup message had no slot context.** The wakeup body just said
'follow hf-wakeup workflow' with no slot id/event_data/task_code.
The agent then had to call harborforge_calendar_status to learn
anything — which itself is broken in the simplified scheduler (it
queries a CalendarScheduler instance that never gets created).
Fix: pass dueSlots into wakeAgent and inline the highest-priority
slot's {slot_id, scheduled_at, priority, slot_type, event_data} as
a JSON block in the wakeup message. The agent reads event_data.
task_code directly and routes via workflow_lookup without any
round-trip. Per PLG-CAL-001 docs in hf-hangman-lab SKILL.md, this
is the documented contract; we are bringing the message in line.
3. **contracts.tools listed 5 of the 9 registered tools.** Manifest had
harborforge_status/telemetry/monitor_telemetry/calendar_status/
calendar_complete. Code also registers calendar_abort, calendar_pause,
calendar_resume, harborforge_restart_status. With the new OpenClaw
plugin host enforcement (same gotcha that bit Meridian — see
zhi/Meridian#2), undeclared tools are silently dropped from the
agent's tool list, so abort/pause/resume cannot be called by the
agent. plugin doctor was emitting:
'plugin tool is undeclared (harbor-forge): harborforge_calendar_abort'
for each missing tool.
Fix: add the 4 missing tool names to contracts.tools.
Also use api.config as the primary config source in wakeAgent (current
public API), falling back to runtime.config.loadConfig() for older
hosts — same pattern as the Meridian fix.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Verified against current code; fixed stale/inaccurate sections and
documented previously-undocumented features/flags/endpoints. Added a
"Part of the HarborForge platform" reference and role/port.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The .gitignore was set up to skip tsc's compiled .d.ts output but it also
matched the hand-written ambient declarations file added in the previous
commit. Add a negation rule so that one file is tracked.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ESM conversion:
- plugin/package.json: add "type": "module".
- plugin/tsconfig.json: switch module/moduleResolution to "nodenext"; bump
target to ES2022.
- All relative imports across plugin/ now carry .js extensions as required
by Node ESM (nodenext module resolution).
- plugin/index.ts: replace `require('./calendar/schedule-cache')` with a
proper top-level import; switch `from 'os'` to `from 'node:os'`.
Plugin SDK convention update:
- Wrap default export with definePluginEntry({ id, name, description,
register }) per the current openclaw plugin authoring contract.
- Modernize plugin/openclaw.plugin.json: drop entry/version, add
activation.onStartup so gateway_start fires for this plugin at boot,
declare contracts.tools listing the five harborforge_* tools.
- Add a local plugin/openclaw-sdk.d.ts with ambient declarations for the
focused subpaths (openclaw/plugin-sdk/plugin-entry,
openclaw/plugin-sdk/core). We deliberately do NOT add openclaw as an
npm devDependency: the installer's `npm install --omit=dev` step trips
over openclaw's own (deeply nested) dependency graph when listed via
file:.../openclaw, and the runtime contract is provided by the gateway
loader anyway.
- The local PluginAPI interface is preserved (broader than the standard
OpenClawPluginApi — it surfaces `version`/`runtime`/`spawn`); the
register function is cast at the definePluginEntry boundary.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1. ScheduleCache: local cache of today's schedule, synced every 5 min
from HF backend via new getDaySchedule() API
2. Wakeup prompts updated to reference daily-routine skill workflows
(task-handson, plan-schedule, slot-complete)
3. Agent wakeup via dispatchInboundMessageWithDispatcher (in-process)
- Same mechanism as Discord plugin
- Creates unique session per slot: agent:{agentId}:hf-calendar:slot-{slotId}
- No WebSocket, CLI, or cron dependency
- Verified working on test environment
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Use api.runtime.version for openclaw version and
api.runtime.config.loadConfig() for agent list. Eliminates the
periodic openclaw agents list subprocess that caused high CPU usage.
Spawning a full openclaw CLI process every 30s to list agents is too
heavy — each invocation loads all plugins (~16s) and hangs until killed.
Return empty array for now until a lighter mechanism is available.
api.version returns plugin API version (0.2.0), not the openclaw release
version. Use OPENCLAW_SERVICE_VERSION env var set by the gateway instead.
Also increase listOpenClawAgents timeout from 15s to 30s since plugin
loading takes ~16s on T2.
- Add state persistence (persistState/restoreState) for recovery after restart
- Add handleScheduledGatewayRestart method that:
- Persists current scheduler state to disk
- Sends final heartbeat to backend before shutdown
- Stops the calendar scheduler (pauses scheduled tasks)
- Add isRestartPending flag to prevent new slot processing during restart
- Add isScheduledGatewayRestart helper to detect restart events
- Update scheduler to detect and handle ScheduledGatewayRestart events
- Add new tools: harborforge_restart_status, harborforge_calendar_pause/resume
- Export isRestartPending and getStateFilePath methods
- Bump plugin version to 0.3.1
- Add CalendarScheduler class to manage periodic heartbeat and slot execution
- Implement agent wakeup logic when Idle and slots are pending
- Handle slot status transitions (attended, ongoing, deferred)
- Support both real and virtual slot materialization
- Add task context building for different event types (job, system, entertainment)
- Integrate scheduler into main plugin index.ts
- Add new plugin tools: harborforge_calendar_status, complete, abort
- MonitorBridgeClient gains pushOpenClawMeta() method for POST /openclaw
- OpenClawMeta interface defines version/plugin_version/agents payload
- Plugin pushes metadata on gateway_start (delayed 2s) and periodically
- Interval aligns with reportIntervalSec (default 30s)
- Pushes are non-fatal — plugin continues if Monitor is unreachable
- Interval cleanup on gateway_stop
- Updated monitor-server-connector-plan.md with new architecture
Major changes:
- Renamed plugin id from harborforge-monitor to harbor-forge (TODO 4.1)
- Removed sidecar server/ directory and spawn logic (TODO 4.2)
- Added monitorPort to plugin config schema (TODO 4.3)
- Added --install-cli flag to installer for building hf CLI (TODO 4.4)
- skills/hf/ only deployed when --install-cli is present (TODO 4.5)
- Plugin now serves telemetry data directly via tools
- Installer handles migration from old plugin name
- Bumped version to 0.2.0
