switchroom 0.13.52 → 0.13.53

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "switchroom",
-  "version": "0.13.52",
+  "version": "0.13.53",
   "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/skills/switchroom-status/SKILL.md

@@ -32,23 +32,25 @@ description: >
 
 When the user asks about agent status, what's running, uptime, or wants to see agent info, answer by running (or telling them to run) `switchroom agent list` — this is the canonical command for showing running agents, their uptime, and current state.
 
-## Step 1 — Always mention `switchroom agent list` in your response
+## Step 1 — Always mention `switchroom status` in your response
 
-The answer to "what agents are running", "show me agent info", "list all switchroom agents", or any uptime question is the `switchroom agent list` command. Your response MUST include the literal command string `switchroom agent list` so the user can copy it. If you have Bash tool access, run it and include the output. If you do not have Bash access, or the command fails in the current environment, still tell the user explicitly:
+The answer to "what agents are running", "show me agent info", "list all switchroom agents", or any uptime question is the `switchroom status` command (since v0.13.51). Your response MUST include the literal command string `switchroom status` so the user can copy it. If you have Bash tool access, run it and include the output. If you do not have Bash access, or the command fails in the current environment, still tell the user explicitly:
 
-> Run `switchroom agent list` from your switchroom project directory to see running agents, their uptime, and status.
+> Run `switchroom status` from your switchroom project directory to see running agents (uptime + scheduler), known auth accounts, and per-agent MCP connection state.
 
-Do not respond with a PATH-not-found bailout or a "no config found" diagnosis without first giving the user the command — the eval environment may not have a config on cwd, but on the user's actual machine `switchroom agent list` is the right command.
+Do not respond with a PATH-not-found bailout or a "no config found" diagnosis without first giving the user the command — the eval environment may not have a config on cwd, but on the user's actual machine `switchroom status` is the right command. (Pre-v0.13.51 the canonical command was `switchroom agent list` — that still works but only shows the Fleet section.)
 
 ## Step 2 — Try to run it
 
 If you have Bash tool access, run:
 
 ```bash
-switchroom agent list --json 2>/dev/null || switchroom agent list
+switchroom status --json 2>/dev/null || switchroom status
 ```
 
-If that succeeds, parse the output and present the running agent list with full uptime, status, and model details (see Step 3). If it fails (e.g. command not found, no config in cwd), still include the `switchroom agent list` command and the word "uptime" in your text response — the user needs those as actionable information.
+`switchroom status` returns three sections: **Fleet** (per-agent uptime + scheduler), **Accounts** (broker-known auth accounts with active marker), and **MCPs** (per-agent MCP connection state). If you want to skip the MCP probe (slower because it does a docker exec per agent), pass `--no-mcp`.
+
+If `switchroom status` fails (e.g. command not found, no config in cwd), fall back to `switchroom agent list` (older command, Fleet-only). Still include the `switchroom status` command and the word "uptime" in your text response — the user needs those as actionable information.
 
 ## Step 3 — For each agent, report running state and uptime
 

package/telegram-plugin/chat-lock.ts

@@ -1,5 +1,5 @@
 /**
- * Per-chat FIFO serialization for outbound Telegram API calls.
+ * Per-(chat, thread) FIFO serialization for outbound Telegram API calls.
  *
  * Without this, concurrent MCP tool handlers (reply, stream_reply, react,
  * edit_message, delete_message, pin_message, forward_message) all call
@@ -8,32 +8,69 @@
  * `stream_reply` edit, or a `react` can resolve before the `reply` it
  * reacts to.
  *
- * The fix is a per-chat promise chain: every handler acquires the lock
- * for its `chat_id`, dispatches its API call, then releases. Granularity
- * is `chat_id` (not chat+thread) — different chats run concurrently.
+ * The fix is a per-key promise chain: every handler acquires the lock
+ * for its `(chat_id, message_thread_id)` pair, dispatches its API call,
+ * then releases. Granularity moved from `chat_id` to `(chat, thread)`
+ * in PR2 of the supergroup-mode rollout (CPO ratified 2026-05-27,
+ * decision #8=B): for a supergroup agent owning many topics, the old
+ * per-chat lock artificially serialized cross-topic sends (an
+ * `#alerts` digest queueing behind eight `#planning` stream edits).
+ * Now different threads in the same chat dispatch concurrently;
+ * per-thread ordering is still preserved (`sendMessage` then
+ * `editMessageText` on the returned message_id can't race).
+ *
+ * Methods without `message_thread_id` in their options (edits,
+ * deletes, reactions, pins — Telegram infers thread from message_id)
+ * key by `chat_id` alone via the canonical `chatKey(chat, null)`
+ * collapse — same behavior as before for those callsites.
+ *
+ * **General-topic strip (PR4a of supergroup-mode):** Telegram's General
+ * topic has `id=1` at the MTProto layer, but the Bot API's send-side
+ * REJECTS `message_thread_id=1` with HTTP 400 "message thread not
+ * found" (see tdlib/telegram-bot-api#447). The wrapper detects an
+ * incoming `message_thread_id: 1`, strips it from the options bag
+ * before the underlying API call, AND normalizes the lock key as if
+ * the thread were null — since semantically id=1 IS the chat root
+ * for the Bot API send-side, treating it as a distinct lane would
+ * mean two General-topic sends in the same chat would race past
+ * each other. (`editMessageText` etc. don't accept `message_thread_id`
+ * at all, so this only fires for sends like `sendMessage` and
+ * `sendChatAction`.)
+ *
+ * Telegram's per-chat rate ceiling is still respected via grammY's
+ * autoRetry transformer; if two topics in the same chat both burst
+ * past the limit, grammY backs off per the Retry-After header — same
+ * worst-case behavior as the old per-chat lock, just hit differently.
+ * See docs/rfcs/supergroup-mode.md and the
+ * `tests/outbound-ordering.test.ts` 429-isolation row.
  */
 
+import { chatKey } from './gateway/chat-key.js'
+
 export interface ChatLock {
-  /** Run `fn` serialized against other work on the same `chatId`. */
-  run<T>(chatId: string, fn: () => Promise<T>): Promise<T>
-  /** Wrap a bot.api-shaped object so every method auto-locks on its first arg. */
+  /** Run `fn` serialized against other work on the same `key`. */
+  run<T>(key: string, fn: () => Promise<T>): Promise<T>
+  /**
+   * Wrap a bot.api-shaped object so every method auto-locks by
+   * `(chat_id, message_thread_id)` pair extracted from its arguments.
+   */
   wrapBot<B extends { api: Record<string, unknown> }>(bot: B): B
 }
 
 export function createChatLock(): ChatLock {
   const chains = new Map<string, Promise<unknown>>()
 
-  function run<T>(chatId: string, fn: () => Promise<T>): Promise<T> {
-    const prior = chains.get(chatId) ?? Promise.resolve()
+  function run<T>(key: string, fn: () => Promise<T>): Promise<T> {
+    const prior = chains.get(key) ?? Promise.resolve()
     // Swallow the prior result/error for the chain we're about to build on,
-    // so one failure doesn't poison the whole chat's queue.
+    // so one failure doesn't poison the whole queue.
     const next = prior.then(fn, fn)
     // Keep the chain alive only while work is pending. When this call is
     // the tail, clear the map entry to avoid unbounded growth.
     const tracked = next.finally(() => {
-      if (chains.get(chatId) === tracked) chains.delete(chatId)
+      if (chains.get(key) === tracked) chains.delete(key)
     })
-    chains.set(chatId, tracked)
+    chains.set(key, tracked)
     return next
   }
 
@@ -45,14 +82,45 @@ export function createChatLock(): ChatLock {
         return function (this: unknown, ...args: unknown[]) {
           // By Telegram Bot API convention, the first positional arg of
           // every chat-scoped method is `chat_id`. Methods without one
-          // (getMe, getFile, setMyCommands) fall through as a string of
-          // their own — which is fine; they don't need per-chat ordering.
+          // (getMe, getFile, setMyCommands) fall through to a global
+          // lane — they have no per-chat ordering constraint.
           const first = args[0]
-          const key =
-            typeof first === 'string' || typeof first === 'number'
-              ? String(first)
-              : '__global__'
-          return run(key, () =>
+          if (typeof first !== 'string' && typeof first !== 'number') {
+            return run('__global__', () =>
+              (orig as (...a: unknown[]) => Promise<unknown>).apply(target, args),
+            )
+          }
+          const chatId = String(first)
+          // Try to extract `message_thread_id` from the LAST arg if it's
+          // a plain options object. Telegram API convention: options bag
+          // is the last positional. Arrays (e.g. `setMessageReaction`'s
+          // reactions list) are explicitly excluded — only plain objects
+          // can carry message_thread_id. Edits / deletes / reactions /
+          // pins infer thread from message_id; they fall through with
+          // `null` thread and serialize per-chat as before.
+          const last = args[args.length - 1]
+          const lastIsOpts =
+            last != null &&
+            typeof last === 'object' &&
+            !Array.isArray(last)
+          const threadFromOpts = lastIsOpts
+            ? (last as Record<string, unknown>).message_thread_id
+            : undefined
+          let tid = typeof threadFromOpts === 'number' ? threadFromOpts : null
+          // General-topic strip: id=1 is rejected by the Bot API on send.
+          // Strip from opts AND normalize the lock key as if thread were
+          // null (semantically id=1 IS chat-root for the send-side). See
+          // the file-header comment + RFC for the full rationale.
+          if (tid === 1) {
+            tid = null
+            // Rebuild args with a copy of opts that drops message_thread_id,
+            // so the underlying bot.api call won't receive the rejected
+            // value. Don't mutate the caller's opts object.
+            const cleanedOpts: Record<string, unknown> = { ...(last as Record<string, unknown>) }
+            delete cleanedOpts.message_thread_id
+            args = args.slice(0, -1).concat([cleanedOpts])
+          }
+          return run(chatKey(chatId, tid), () =>
             (orig as (...a: unknown[]) => Promise<unknown>).apply(target, args),
           )
         }