polygram 0.8.0-rc.6 → 0.8.0-rc.8

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
   "name": "polygram",
-  "version": "0.8.0-rc.6",
+  "version": "0.8.0-rc.8",
   "description": "Telegram integration for Claude Code that preserves the OpenClaw per-chat session model. Migration target for OpenClaw users. Multi-bot, multi-chat, per-topic isolation; SQLite transcripts; inline-keyboard approvals. Bundles /polygram:status|logs|pair-code|approvals admin commands and a history skill.",
   "keywords": [
     "telegram",

package/lib/process-manager-sdk.js

@@ -470,6 +470,7 @@ class ProcessManagerSdk {
             entry.inputController.push({
               type: 'user',
               message: { role: 'user', content: head.prompt },
+              parent_tool_use_id: null,
             });
           } catch (err) {
             entry.pendingQueue.shift();
@@ -655,6 +656,7 @@ class ProcessManagerSdk {
         entry.inputController.push({
           type: 'user',
           message: { role: 'user', content: prompt },
+          parent_tool_use_id: null,
         });
       } catch (err) {
         const idx = entry.pendingQueue.indexOf(pending);
@@ -754,13 +756,30 @@ class ProcessManagerSdk {
    * Returns true if push succeeded; false if session not found or
    * input controller closed.
    */
-  steer(sessionKey, text, { shouldQuery = true } = {}) {
+  steer(sessionKey, text, { shouldQuery = false } = {}) {
     const entry = this.procs.get(sessionKey);
     if (!entry || entry.closed) return false;
     try {
+      // 0.8.0-rc.7 (per v4 plan §0 row 9 + Phase 2 step 1's original
+      // shape): push with `shouldQuery: false` so the SDK appends to
+      // the transcript without trying to terminate the in-flight turn.
+      // The previous default `shouldQuery: true` triggered the CLI
+      // binary's `m87` gate (transcript well-formedness check) which
+      // emitted `result.subtype = error_during_execution` whenever a
+      // plain-text user message arrived while the assistant was mid-
+      // tool-use. With shouldQuery=false the message merges into the
+      // next natural user turn — the in-flight tools complete first,
+      // then the assistant sees the steered context.
+      //
+      // parent_tool_use_id is required by SDKUserMessage type
+      // (sdk.d.ts:3479-3498). The SDK runtime checks `!== null` in
+      // multiple places; omitting it falls through to wrong handling
+      // branches. The SDK's own `mz.send()` and `pz` replay set it
+      // to null explicitly.
       entry.inputController.push({
         type: 'user',
         message: { role: 'user', content: text },
+        parent_tool_use_id: null,
         priority: 'now',
         shouldQuery,
       });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "polygram",
-  "version": "0.8.0-rc.6",
+  "version": "0.8.0-rc.8",
   "description": "Telegram daemon for Claude Code that preserves the OpenClaw per-chat session model. Migration path for OpenClaw users moving to Claude Code.",
   "main": "lib/ipc-client.js",
   "bin": {

package/polygram.js

@@ -2412,9 +2412,15 @@ async function handleMessage(sessionKey, chatId, msg, bot) {
   // chatConfig.autosteer === false). CLI pm always falls through
   // to the queue-FIFO path (no steer primitive on stream-json).
   //
-  // The steered message gets a 🛞 reaction so the user knows it
+  // The steered message gets a ✍ reaction so the user knows it
   // landed; no separate reply is generated (the in-flight turn's
   // response covers both messages, OpenClaw-style).
+  //
+  // Reaction emoji must be from Telegram's curated allowlist
+  // (~60 standard emoji per core.telegram.org/bots/api#availablereactions).
+  // 🛞 (steering wheel) is NOT on it — Telegram returns
+  // 400: REACTION_INVALID. ✍ ("writing/noting") is on the list and
+  // conveys "incorporating this".
   const chatAutosteer = chatConfig.autosteer != null
     ? chatConfig.autosteer
     : config.bot?.autosteer;
@@ -2432,7 +2438,7 @@ async function handleMessage(sessionKey, chatId, msg, bot) {
         tg(bot, 'setMessageReaction', {
           chat_id: chatId,
           message_id: msg.message_id,
-          reaction: [{ type: 'emoji', emoji: '🛞' }],
+          reaction: [{ type: 'emoji', emoji: '✍' }],
         }, { source: 'autosteer-ack', botName: BOT_NAME }).catch((err) => {
           console.error(`[${label}] autosteer reaction: ${err.message}`);
         });
@@ -2441,7 +2447,13 @@ async function handleMessage(sessionKey, chatId, msg, bot) {
           text_len: prompt?.length ?? 0,
         });
         stopTyping();
-        reactor.stop();
+        // 0.8.0-rc.8: clear() instead of stop() so the THINKING/QUEUED
+        // 👀 reaction set by the reactor at QUEUED-state actually
+        // disappears from the user's message. reactor.stop() only
+        // cancels timers; the visible emoji persists indefinitely
+        // without an explicit clear() — that's why production showed
+        // 👀 stuck on every steered follow-up under rc.6/rc.7.
+        await reactor.clear().catch(() => {});
         markReplied();
         return;
       }
@@ -2565,6 +2577,26 @@ async function handleMessage(sessionKey, chatId, msg, bot) {
     // those still markReplied silently.
     if (result.text === 'NO_REPLY') { markReplied(); return; }
     if (!result.text) {
+      // 0.8.0-rc.7: tool-only completion is NOT an error. Under SDK
+      // pm, a turn that ends after running tools (no closing text
+      // block) leaves result.text empty even though the bot DID
+      // respond — via tool side effects the user already saw. Don't
+      // post a "No response generated" apology in that case; it's
+      // confusing and it spams the chat. Just clear the reactor
+      // (otherwise 👀 stays stuck — reactor.stop() doesn't remove
+      // the emoji visually) and silently mark replied.
+      const toolOnlyTurn = (result.metrics?.numToolUses ?? 0) > 0
+        && (result.metrics?.numAssistantMessages ?? 0) > 0;
+      if (toolOnlyTurn) {
+        await reactor.clear().catch(() => {});
+        logEvent('tool-only-completion', {
+          chat_id: chatId, msg_id: msg.message_id, bot: BOT_NAME,
+          num_tool_uses: result.metrics?.numToolUses,
+          num_assistant_messages: result.metrics?.numAssistantMessages,
+        });
+        markReplied();
+        return;
+      }
       // 0.7.1: if the fallback send itself fails, throw rather than
       // silently markReplied — the user gets nothing AND the inbound
       // is marked replied so boot replay won't redispatch. Same
@@ -2590,6 +2622,12 @@ async function handleMessage(sessionKey, chatId, msg, bot) {
       logEvent('telegram-empty-response-fallback', {
         chat_id: chatId, msg_id: msg.message_id, bot: BOT_NAME,
       });
+      // 0.8.0-rc.7: clear the THINKING/QUEUED emoji on the user's
+      // message so 👀 doesn't stay stuck after the apology lands.
+      // reactor.stop() (in the finally block) only kills timers; it
+      // does NOT remove the visible emoji. Without this clear, the
+      // user sees 👀 next to their message indefinitely.
+      await reactor.clear().catch(() => {});
       markReplied();
       return;
     }