switchroom 0.13.23 → 0.13.25

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "switchroom",
-  "version": "0.13.23",
+  "version": "0.13.25",
   "description": "Run Claude Code 24/7 on your Claude Pro/Max subscription over Telegram. Open-source alternative to OpenClaw and NanoClaw — no API keys.",
   "type": "module",
   "bin": {

package/profiles/_shared/telegram-style.md.hbs

@@ -5,10 +5,10 @@ Telegram is a chat — replies should feel like one, not a terminal dump or a tr
 **Every turn that responds to a user message MUST end with a `reply` (or `stream_reply` with `done=true`).** The user is on Telegram — they don't see your CLI output, tool-use trace, or inline thinking. The ONLY path for words to reach them is an MCP tool call. If you have a final answer, send it via `reply`. The text in your terminal is not the conversation.
 
 **Conversational pacing — a human is on the other side.** Match the rhythm of a capable colleague messaging you back. Five beats:
-- **1 · Acknowledge first.** Unless your whole reply is a single short sentence you can send right now, your first action is a short one-liner via `reply`, persona voice, sent fast (`disable_notification: true`): *"on it — checking now"*. This holds whether the work ahead is a tool call or a paragraph of pure reasoning — if the answer will run long, ack *before* you compose it. Skip the ack only for an immediate one-sentence answer (*"what's 2+2"*). This is a beat, not filler — it's the line between a colleague and a black box.
+- **1 · Acknowledge first.** Unless your whole reply is a single short sentence you can send right now, your first action is a short one-liner via `reply`, persona voice, sent fast (`disable_notification: true`): *"On it, checking now."*. This holds whether the work ahead is a tool call or a paragraph of pure reasoning — if the answer will run long, ack *before* you compose it. Skip the ack only for an immediate one-sentence answer (*"What's 2+2?"*). This is a beat, not filler — it's the line between a colleague and a black box.
 - **2 · Then go quiet and work.** Heads-down is right — do **not** narrate every tool call. A typing indicator runs for you automatically; you don't keep it alive.
 - **3 · Surface meaningful progress** at genuine inflection points — a hard step finished, a blocker, a pivot, dispatching a sub-agent, a notably slow wait, a finding worth knowing now. One short `reply`, `disable_notification: true` (no mid-turn ping).
-- **4 · Hand back delegations with synthesis.** When a sub-agent reports back, re-enter in your own voice — what it found, what you're doing next (*"reviewer flagged the auth gap; fixing it now"*). Never let its raw report stand as your reply. A *background* worker finishes after your turn has ended — its result is delivered to you as a fresh `<channel source="subagent_handback">` turn. That turn IS your cue: synthesise it for the user right then; don't treat it as noise and don't stay silent.
+- **4 · Hand back delegations with synthesis.** When a sub-agent reports back, re-enter in your own voice — what it found, what you're doing next (*"Reviewer flagged the auth gap; fixing it now."*). Never let its raw report stand as your reply. A *background* worker finishes after your turn has ended — its result is delivered to you as a fresh `<channel source="subagent_handback">` turn. That turn IS your cue: synthesise it for the user right then; don't treat it as noise and don't stay silent.
 - **5 · Deliver the answer** as a fresh `reply` (omit `disable_notification` — pings once).
 
 The one thing to avoid is **spam**: a reply on every tool call, on a cadence, or repeating yourself. Responsive and human, never a flood. A `<system-reminder>` containing `[silence-poke]` means you've gone quiet too long — send one short `reply` and carry on; skip it only if you're within ~5s of finishing.
@@ -29,7 +29,7 @@ The 👀→🤔→🔥→👍 status reaction and the typing indicator are *ambi
 
 If both `queued` and `steering` are somehow present, `steering` wins (explicit opt-in beats default). If `prior_turn_in_progress="true"` is set without either flag (shouldn't happen but defensive), treat the message as a follow-up related to your last reply.
 
-**Self-narrate the classification.** At the top of your reply for any `steering` or `queued` message, include a brief italic one-liner so the user can correct you — e.g. `_↪️ treating as steer on the prior task_` or `_📥 queued as a new task_`.
+**Self-narrate the classification.** At the top of your reply for any `steering` or `queued` message, include a brief italic one-liner so the user can correct you — e.g. `_↪️ Treating as steer on the prior task_` or `_📥 Queued as a new task_`.
 
 **Formatting** (Telegram HTML — `reply` and `stream_reply` default to `format: "html"` and convert markdown for you):
 - Use **bold** sparingly for emphasis on key facts only
@@ -62,7 +62,7 @@ Don't use `accent` on routine conversational replies — it's for status communi
 
 **When stickers / GIFs land badly**: in lieu of an actual answer, decorating routine acknowledgements ("got it 👍 [+sticker]"), peppering a long thread, or any time the user is task-focused. If you find yourself wanting to send one to lighten an otherwise empty reply, don't — a sticker is never a substitute for an actual answer. Two stickers in a row is always wrong.
 
-**Interrupt marker.** If a user asks how to stop you mid-turn, tell them: *"Start your message with `!` — it interrupts whatever I'm doing and treats the rest as a fresh request."* For implementation detail (cgroup escape, `tmux send-keys`, doubled-bang, empty-bang gateway behavior), invoke the `/switchroom-runtime` skill. The `!` interrupt wakes a fresh `SWITCHROOM_PENDING_TURN` cycle, so the resume protocol fires on the next turn.
+**Interrupt marker.** If a user asks how to stop you mid-turn, tell them: *"Start your message with `!` to interrupt whatever I'm doing and treat the rest as a fresh request."* For implementation detail (cgroup escape, `tmux send-keys`, doubled-bang, empty-bang gateway behavior), invoke the `/switchroom-runtime` skill. The `!` interrupt wakes a fresh `SWITCHROOM_PENDING_TURN` cycle, so the resume protocol fires on the next turn.
 
 **Wake audit on fresh boot.** If `$TELEGRAM_STATE_DIR/.wake-audit-pending` exists when you start your first turn, invoke the `/switchroom-runtime` skill before answering the user. That skill runs the three-check audit (owed replies, orphan sub-agents, stale todos) with dedup against re-firing on `--continue` respawns. If all three checks come back clean, say nothing about the audit and just answer.
 

package/telegram-plugin/answer-stream.ts

@@ -233,6 +233,34 @@ export function createAnswerStream(config: AnswerStreamConfig): AnswerStreamHand
     }
   }
 
+  /**
+   * Clear the in-progress sendMessageDraft (#1704). When the answer
+   * stream was using draft transport (DMs), Telegram leaves the draft
+   * sitting in the user's compose area until something replaces or
+   * clears it. On Telegram Desktop this blocks the user from typing —
+   * the compose field is occupied by the bot's draft preview.
+   *
+   * Every terminal path on the stream (materialize / stop / retract)
+   * must clear the draft. Best-effort: a failed clear is logged but
+   * not re-thrown — the worst case is a transient stale draft that
+   * Telegram's own 30 s draft expiry eventually mops up.
+   */
+  async function clearDraftBestEffort(): Promise<void> {
+    if (!usesDraftTransport || draftApi == null || draftId == null) return
+    try {
+      const params: { message_thread_id?: number } = {}
+      if (threadId != null) params.message_thread_id = threadId
+      await draftApi(
+        chatId,
+        draftId,
+        '',
+        Object.keys(params).length > 0 ? params : undefined,
+      )
+    } catch {
+      // Best-effort cleanup
+    }
+  }
+
   async function sendDraft(text: string): Promise<boolean> {
     if (!draftApi || draftId == null) return false
     try {
@@ -406,20 +434,7 @@ export function createAnswerStream(config: AnswerStreamConfig): AnswerStreamHand
       }
 
       // Clear draft so Telegram input area doesn't show stale text
-      if (usesDraftTransport && draftApi != null && draftId != null) {
-        try {
-          const clearParams: { message_thread_id?: number } = {}
-          if (threadId != null) clearParams.message_thread_id = threadId
-          await draftApi(
-            chatId,
-            draftId,
-            '',
-            Object.keys(clearParams).length > 0 ? clearParams : undefined,
-          )
-        } catch {
-          // Best-effort cleanup
-        }
-      }
+      await clearDraftBestEffort()
 
       // The text we want to materialize. Prefer pendingText (most recent
       // snapshot from the model) over lastSentText (what last reached the
@@ -528,6 +543,10 @@ export function createAnswerStream(config: AnswerStreamConfig): AnswerStreamHand
     stop(): void {
       stopped = true
       cancelScheduled()
+      // #1704: clear the compose-box draft. stop() is sync — fire and
+      // forget. A dropped clear falls back on Telegram's own 30 s
+      // draft expiry; the worst case is a transient stale preview.
+      void clearDraftBestEffort()
     },
 
     async retract(): Promise<void> {
@@ -539,6 +558,12 @@ export function createAnswerStream(config: AnswerStreamConfig): AnswerStreamHand
       if (inFlight) {
         try { await inFlight } catch { /* ignore */ }
       }
+      // #1704: clear the compose-box draft when this stream was using
+      // draft transport. Without this, Telegram Desktop leaves the
+      // draft sitting in the user's input area and blocks them from
+      // typing until the 30 s draft expiry. Awaited so a follow-up
+      // sendMessage on the same chat doesn't race a stale draft edit.
+      await clearDraftBestEffort()
       // Delete the preliminary message if one was sent and deleteMessage
       // is wired. Best-effort: failures are logged but not re-thrown.
       const msgId = streamMsgId