switchroom 0.13.52 → 0.13.54

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "switchroom",
-  "version": "0.13.52",
+  "version": "0.13.54",
   "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/_base/start.sh.hbs

@@ -239,6 +239,23 @@ export HINDSIGHT_RECALL_CACHE_TTL_SECS={{hindsightRecallCacheTtlSecs}}
 {{#if (isNumber hindsightRecallMinOverlap)}}
 export HINDSIGHT_RECALL_MIN_OVERLAP={{hindsightRecallMinOverlap}}
 {{/if}}
+# PR6 — supergroup-mode topic tagging. JSON map of {alias: thread_id}
+# parsed by retain.py + recall.py to (a) stamp chat_id/thread_id/topic_alias
+# into retained memory metadata and (b) emit a "Current topic: …" preamble
+# on recall blocks so the model self-scopes. Empty / absent for fleet-shared
+# or DM agents where the supergroup topology isn't in use.
+{{#if hindsightTopicAliasesJsonQ}}
+export HINDSIGHT_TOPIC_ALIASES_JSON={{{hindsightTopicAliasesJsonQ}}}
+{{/if}}
+# PR6 — topic filter mode for cross-topic memory recall. Default
+# "soft-preamble": all topic-tagged memories surface and the model
+# decides relevance via the preamble. "hard-filter": drop memories
+# whose source thread_id differs from the active prompt's thread_id.
+# Operators flip this when instrumentation (the active_thread_id /
+# source_topics fields in recall_log.jsonl) shows binding failures.
+{{#if hindsightTopicFilterMode}}
+export HINDSIGHT_TOPIC_FILTER_MODE={{hindsightTopicFilterMode}}
+{{/if}}
 # Wait for Hindsight API to be reachable before launching Claude, otherwise
 # the MCP server connection fails at startup with "1 MCP server failed".
 HINDSIGHT_WAIT=0

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

@@ -21,6 +21,8 @@ The 👀→🤔→🔥→👍 status reaction and the typing indicator are *ambi
 
 **Reactions ON your replies.** Sometimes you'll receive a turn whose body is wrapped in `<channel source="reaction">`. That means the user reacted to one of your earlier messages and the gateway forwarded the reaction as a synthetic turn (the message preview is included so you know which reply they reacted to). 👎 / ❌ are stop signals — pause, reconsider the approach, ask what's off. 👍 / ✅ are acknowledgements — keep going if mid-task, no extra reply needed. A brief explicit acknowledgement is fine but not required; don't ceremonially reply to every reaction. The allowlist + per-hour cap are operator-tunable (default 10/hour); other emojis you might see don't trigger turns.
 
+**Topics are organizational, you are one identity.** When you're in a supergroup, the `<channel>` envelope carries both `chat_id` and `message_thread_id` — the pair identifies a topic, and the user organizes work across topics like folders. You are still one entity that knows them all, but each topic has its own audience and its own thread of work: keep replies focused on the topic the user wrote into. Don't preface with "as I mentioned in #planning" unless the user in *this* topic brought it up; don't drag a deep-dive from one topic into a quick exchange in another. Hindsight memories and your own transcript span every topic — when recalled memories from other topics surface, use them when context genuinely transfers (the user references prior work; the topics share a project) and ignore them when they don't.
+
 **Follow-ups while a turn is in flight.** Claude Code's native FIFO queue means a follow-up Telegram message arrives AFTER your current turn ends, not during it — you can't interrupt your own turn. Every follow-up becomes the next prompt you see. The plugin enriches the `<channel>` meta so you can classify correctly:
 
 - `queued="true"` — DEFAULT for mid-turn follow-ups (no prefix). Treat as a new, independent task. Do NOT reference the in-flight work — start fresh. Also fires when the user typed `/queue ` or `/q ` (legacy alias; the prefix is stripped from the body you see).

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),
           )
         }