@openbrt/weclawbotctl 0.1.16 → 0.1.18

package/README.md

@@ -83,8 +83,15 @@ possible and send them through their normal chat/media channel so the user sees
 the actual effect, not just "published".
 When the OpenClaw tool `weclawbot_publish_screen_document` is used, its return
 value contains the same `preview.pages[].path` list. The agent owns delivering
-that preview to the user; the plugin's automatic preview hook is only a
-best-effort fallback.
+that preview to the user. The optional automatic preview hook is off by default
+and exists only for legacy experiments.
+
+The purpose of sending the preview is not just proof that MQTT worked. The
+preview is the feedback surface that lets the user's agent learn the user's
+reading habits, layout taste, density tolerance, font preferences, and page
+rhythm over time. Treat "send to screen" as a two-part delivery: the device is
+updated, and the user receives the same effect image in the current chat unless
+the agent reports a concrete preview-delivery failure.
 
 To clear the current note, use the firmware clear command:
 
@@ -297,7 +304,9 @@ Before publishing, agents should inspect or otherwise self-evaluate the rendered
 pages against the user's preferences and their own learned standards when their
 runtime supports it. Regenerate the document if the bitmap does not satisfy those
 standards. After a successful publish, send the preview PNGs to the user through
-the current chat/media channel so the user can see the effect.
+the current chat/media channel so the user can see the effect and correct the
+agent's choices. Carry those corrections forward instead of resetting local
+style memory on plugin upgrades.
 
 ```bash
 weclawbotctl preview /path/to/screen-document.json

package/index.mjs

@@ -289,7 +289,7 @@ async function finishHookActivity(api, event, ctx) {
 
 async function attachScreenPreview(api, event, ctx) {
   try {
-    if (api.pluginConfig?.auto_preview === false) return;
+    if (api.pluginConfig?.auto_preview !== true) return;
     if (event?.error) return;
     const sessionKey = resolveHookSessionKey(event, ctx);
     if (!sessionKey) {

package/openclaw.plugin.json

@@ -28,7 +28,7 @@
       },
       "auto_preview": {
         "type": "boolean",
-        "description": "Best-effort fallback that attaches PNG previews after publishing. Agents should still send preview.pages[].path to users explicitly."
+        "description": "Optional legacy fallback that attaches PNG previews after publishing. Defaults off; agents should send preview.pages[].path to users explicitly."
       }
     }
   }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@openbrt/weclawbotctl",
-  "version": "0.1.16",
+  "version": "0.1.18",
   "description": "WeClawBot pairing and screen-control CLI for local AI agents.",
   "type": "module",
   "license": "MIT",

package/skills/weclawbot-curator/SKILL.md

@@ -58,7 +58,10 @@ OpenClaw Telegram/UI sessions, prefer `weclawbot_publish_screen_document`: its
 result includes `preview.pages[].path` PNG files for the exact mono1 pages. The
 agent must inspect those preview files when possible, then send the preview PNGs
 back to the user through its normal chat/media channel before or alongside the
-"已上屏" reply. If the agent used CLI instead, run `weclawbotctl preview <doc>`
+"已上屏" reply. This preview is not decoration and not merely proof of delivery:
+it is the feedback surface that lets the user and agent steadily converge on the
+user's reading habits, layout taste, density tolerance, font preferences, and
+page rhythm. If the agent used CLI instead, run `weclawbotctl preview <doc>`
 before publishing, or read the `preview` field emitted by `weclawbotctl screen`.
 Do not use OpenClaw Canvas for requests that
 mention WeClawBot, the physical screen, or “屏上”; Canvas is an OpenClaw UI
@@ -92,9 +95,12 @@ inspect images. Judge the preview against the user's preferences and the agent's
 own learned standards: legibility, margins, crowding, page count, and continuity
 across pages. If the preview does not satisfy those standards, regenerate the
 pages before publishing. After a successful publish, include the preview PNG in
-the user-visible response so the user can see what was sent. This review and
-proof loop belongs in the agent/tool layer; do not expect firmware to fix
-typography, show chat previews, or split pages after the pixels arrive.
+the user-visible response so the user can see what was sent and correct the
+agent's choices. Treat explicit comments, repeated corrections, clear requests,
+manual page changes, and acceptance without complaint as signals for future
+layout decisions. This review and feedback loop belongs in the agent/tool layer;
+do not expect firmware to fix typography, show chat previews, or split pages
+after the pixels arrive.
 
 `weclawbotctl screen` and `weclawbot_publish_screen_document` wait for the
 device status topic by default. Treat only `applied` as success. If the device

package/workspace/AGENTS.md

@@ -48,7 +48,11 @@ the tool returns `preview.pages[].path` PNG files for the exact pages. Inspect
 those preview images when possible, and send them back to the user through the
 normal chat/media channel before or alongside the success reply. If using CLI,
 run `weclawbotctl preview <document.json>` before publishing, or read the
-`preview` field emitted by `weclawbotctl screen`.
+`preview` field emitted by `weclawbotctl screen`. The preview is the user's
+feedback surface: use it to learn their reading habits, preferred density,
+layout taste, font choices, and page rhythm over time. Do not treat "上屏" as
+complete until the physical screen is updated and the user can see the same
+effect in chat, or you have clearly reported why the preview could not be sent.
 
 The firmware receives pixels. Do not send raw text to firmware, and do not
 answer that direct delivery is unavailable before checking the local