polygram 0.12.0-rc.27 → 0.12.0-rc.29

package/lib/process/cli-process.js

@@ -690,6 +690,22 @@ class CliProcess extends Process {
       'as normal — only the FINAL user-visible message needs to go through',
       'the reply tool.',
       '',
+      // TEMPORARY mitigation (2026-06-08 Shumabit@UMI wedge): AskUserQuestion opens
+      // a blocking TUI selection widget the channel can't answer → the session
+      // parks until manually Esc'd. REMOVE this whole rule when the rich
+      // question→Telegram-keyboard feature ships (see docs design); claude should
+      // then use the native question tool again. Tracked so it isn't forgotten.
+      '### Asking the user a question / offering choices — HARD RULE',
+      '',
+      'NEVER use the AskUserQuestion tool or any interactive menu / selection',
+      'widget. They open a blocking terminal prompt the user on Telegram CANNOT',
+      'see or navigate — it silently wedges the entire session until it is manually',
+      'cleared. (Rich tap-to-answer choices are coming; until then this is a hard rule.)',
+      '',
+      'To ask a multiple-choice question, write the options as a numbered list',
+      'inside your `mcp__polygram-bridge__reply` text and ask the user to reply with',
+      'the number (or free text). Do the same for yes/no and any selection.',
+      '',
       '### Sending FILES (tracks, images, docs) to the user',
       '',
       'The `mcp__polygram-bridge__reply` tool takes an optional `files` array of',
@@ -1207,6 +1223,42 @@ class CliProcess extends Process {
     }
   }
 
+  /**
+   * Keep a turn alive while claude is still TOOL-working (2026-06-08 Shumabit@UMI
+   * WA-topic incident). The per-turn reply-quiet window (`quietTimer`, armed in
+   * _recordReplyForPendingTurn) is reset ONLY by reply tool calls. So a turn that
+   * replied and then kept working with NON-reply tools — claude read a follow-up
+   * screenshot, ran a Bash API check, then replied again 90s later, all inside ONE
+   * claude turn (no Stop hook until the very end) — resolved on the reply-quiet
+   * window WHILE claude was still active. Its reactor + typing tore down at the
+   * premature resolve, and the late reply fell through to the orphan
+   * autonomous-assistant-message path (no pending turn).
+   *
+   * claude's Stop hook is the AUTHORITATIVE turn-end; until it lands, a PreToolUse/
+   * PostToolUse hook means claude is still working — so push the reply-quiet window
+   * (and the idle ceiling) out. The absoluteTimer (30-min runaway cap) is left
+   * untouched as the hard backstop, and Stop still resolves normally. Turns that
+   * reply then truly stop (no intervening tool hooks) are unaffected — there's no
+   * tool activity to extend on.
+   */
+  _extendQuietOnToolActivity() {
+    for (const [turnId, pending] of this.pendingTurns) {
+      if (pending._stopGracePending) continue;   // already finalizing — don't revive
+      // Idle ceiling: tool activity IS activity (mirrors the per-reply reset at
+      // _recordReplyForPendingTurn so a long tool-heavy turn isn't idle-killed).
+      if (pending.hardTimer) {
+        clearTimeout(pending.hardTimer);
+        pending.hardTimer = setTimeout(() => pending._fireTimeout?.('idle'), this.turnTimeoutMs);
+      }
+      // Reply-quiet window: only armed AFTER the first reply — that's exactly the
+      // post-reply-still-tooling case this fixes.
+      if (pending.quietTimer) {
+        clearTimeout(pending.quietTimer);
+        pending.quietTimer = setTimeout(() => this._resolveTurn(turnId), this.turnQuietMs);
+      }
+    }
+  }
+
   // 0.12 Phase 1.7 (Finding 0.1.A): two-step turn resolution.
   //   _resolveTurn — entry point called by channel-result OR quiet-window
   //                  expiry. Schedules a stopGraceMs window during which
@@ -1799,6 +1851,15 @@ class CliProcess extends Process {
       });
     }
 
+    // 2026-06-08 (WA-topic incident): a tool hook means claude is STILL working,
+    // so keep its turn(s) alive — the reply-quiet window must not resolve a turn
+    // mid-work just because the last *reply* was a few seconds ago. See
+    // _extendQuietOnToolActivity. Reply tool calls are handled separately (their
+    // own reset in _recordReplyForPendingTurn); covering them here too is a no-op.
+    if (ev.type === 'PreToolUse' || ev.type === 'PostToolUse') {
+      this._extendQuietOnToolActivity();
+    }
+
     switch (ev.type) {
       case 'UserPromptSubmit':
         this.emit('turn-start', {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "polygram",
-  "version": "0.12.0-rc.27",
+  "version": "0.12.0-rc.29",
   "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": {