polygram 0.8.0-rc.6 → 0.8.0-rc.7

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.7",
   "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.7",
   "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

@@ -2565,6 +2565,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 +2610,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;
     }