@karmaniverous/jeeves-meta-openclaw 0.8.3 → 0.9.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -4,7 +4,7 @@ OpenClaw plugin for [jeeves-meta](../service/). A thin HTTP client that register
4
4
 
5
5
  ## Features
6
6
 
7
- - **Seven interactive tools** — `meta_list`, `meta_detail` (with cross-ref status), `meta_trigger`, `meta_preview`, `meta_seed` (with cross-refs), `meta_unlock`, `meta_config`
7
+ - **Eight interactive tools** — `meta_list`, `meta_detail` (with cross-ref status), `meta_trigger`, `meta_preview`, `meta_seed` (with cross-refs and steer), `meta_unlock`, `meta_config`, `meta_queue` (list/clear/abort)
8
8
  - **MetaServiceClient** — typed HTTP client delegating all operations to the running service
9
9
  - **TOOLS.md injection** — periodic refresh of entity stats via `ComponentWriter` from `@karmaniverous/jeeves` (73-second prime interval)
10
10
  - **Dependency health** — shows warnings when watcher/gateway are degraded
@@ -56,7 +56,7 @@ The `configRoot` setting tells `@karmaniverous/jeeves` core where to find the pl
56
56
  ## Documentation
57
57
 
58
58
  - **[Plugin Setup](guides/plugin-setup.md)** — installation, config, lifecycle
59
- - **[Tools Reference](guides/tools-reference.md)** — meta_list, meta_detail, meta_trigger, meta_preview, meta_seed, meta_unlock, meta_config
59
+ - **[Tools Reference](guides/tools-reference.md)** — meta_list, meta_detail, meta_trigger, meta_preview, meta_seed, meta_unlock, meta_config, meta_queue
60
60
  - **[Virtual Rules](guides/virtual-rules.md)** — watcher inference rules
61
61
  - **[TOOLS.md Injection](guides/tools-injection.md)** — dynamic prompt generation
62
62
 
@@ -65,6 +65,8 @@ At minimum, always brief sub-agents on:
65
65
 
66
66
  **Anything important enough to have a permanent cron/heartbeat entry is important enough to be codified into the data flow.**
67
67
 
68
+ **HEARTBEAT efficiency:** When HEARTBEAT fires with multiple component alerts, resolve them all in a single conversation. Walk the user through each component in dependency order. Each heartbeat cycle is a full LLM session — resolve all alerts in one pass.
69
+
68
70
  ## Messaging Dispatch
69
71
 
70
72
  **Same-channel replies:** Don't use the `message` tool. It fires immediately, jumping ahead of streaming narration. Just write text as your response. Use `message` only for **cross-channel** sends (sending to a different channel or DM than the one you're responding in).
@@ -73,7 +75,7 @@ At minimum, always brief sub-agents on:
73
75
 
74
76
  ## Heartbeat Discipline
75
77
 
76
- **Default state of HEARTBEAT.md is EMPTY** (comments only). Every heartbeat loads the full system prompt. An empty heartbeat that returns HEARTBEAT_OK still costs a full LLM session.
78
+ **Default state of HEARTBEAT.md is effectively empty** the `# Jeeves Platform Status` section contains only headings when all components are healthy or declined. No list content, no LLM cost. User heartbeat items (above the platform status section) follow the same transient/termination rules as before.
77
79
 
78
80
  Heartbeat items are for **transient, session-requiring work-in-progress ONLY**. Each item must include its own termination condition.
79
81
 
@@ -134,14 +136,11 @@ When discovering a new data source, integrate it into the existing data flow pip
134
136
 
135
137
  ## Bootstrap Protocol
136
138
 
137
- When you detect that a Jeeves platform component is missing or not configured:
139
+ **Proactive platform status:** HEARTBEAT.md is loaded every session. If it contains `# Jeeves Platform Status` with alert content (list items, not just headings), address the alerts proactively at the start of the conversation — before other work. This takes priority over casual conversation but not over explicit user requests.
138
140
 
139
- 1. **Identify** the gap (service not responding on expected port, plugin not registered, config file missing)
140
- 2. **Inform** the user what's missing and what it provides
141
- 3. **Guide** them through installation using the component's CLI install command
142
- 4. **Verify** the installation succeeded (probe the port, check the plugin registration)
141
+ **Follow the instructions:** Explain the component, ask for consent, execute the command, verify. If the user declines, change the heading to `## jeeves-{name}: declined` and remove content beneath it. Do not prompt for declined components. Do not improvise the HEARTBEAT instructions are authoritative.
143
142
 
144
- Don't silently work around missing components. The user should know what's available and what isn't.
143
+ When resolving multiple component alerts, walk the user through each in dependency order (watcher before meta, runner and server independent) within a single conversation rather than one per heartbeat cycle.
145
144
 
146
145
  ## Em-Dash Discipline
147
146