switchroom 0.13.51 → 0.13.53

package/package.json

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

@@ -568,16 +568,29 @@ for f in \
   fi
 done
 
+# Fleet directory — epic #1850 / issue #1852. Extends Claude Code's
+# native CLAUDE.md auto-discovery to `~/.switchroom/fleet/` so every
+# agent reads the release-pinned `switchroom-invariants.md` (lane 1)
+# and operator-owned `CLAUDE.md` (lane 2) from there. Guarded on the
+# directory existing so a fresh-install or a half-applied state
+# doesn't fail boot — `switchroom apply`'s ensureHostMountSources
+# creates the dir + seeds the files.
+SR_FLEET_DIR="$HOME/.switchroom/fleet"
+SR_FLEET_ARG=""
+if [ -d "$SR_FLEET_DIR" ]; then
+  SR_FLEET_ARG="--add-dir $SR_FLEET_DIR"
+fi
+
 {{#if useSwitchroomPlugin}}
 if [ -n "$APPEND_PROMPT" ]; then
-  exec claude $CONTINUE_FLAG --dangerously-load-development-channels server:switchroom-telegram --plugin-dir "{{securityPluginDir}}"{{#if hindsightEnabled}} --plugin-dir "{{agentDir}}/.claude/plugins/hindsight-memory"{{/if}}{{#if modelQ}} --model {{{modelQ}}}{{/if}}{{#if thinkingEffort}} --effort {{thinkingEffort}}{{/if}}{{#if permissionMode}} --permission-mode {{permissionMode}}{{/if}}{{#if fallbackModelQ}} --fallback-model {{{fallbackModelQ}}}{{/if}} --append-system-prompt "$APPEND_PROMPT"{{#if dangerousMode}} --dangerously-skip-permissions{{/if}}{{#if extraCliArgs}}{{{extraCliArgs}}}{{/if}}
+  exec claude $CONTINUE_FLAG --dangerously-load-development-channels server:switchroom-telegram --plugin-dir "{{securityPluginDir}}"{{#if hindsightEnabled}} --plugin-dir "{{agentDir}}/.claude/plugins/hindsight-memory"{{/if}} $SR_FLEET_ARG{{#if modelQ}} --model {{{modelQ}}}{{/if}}{{#if thinkingEffort}} --effort {{thinkingEffort}}{{/if}}{{#if permissionMode}} --permission-mode {{permissionMode}}{{/if}}{{#if fallbackModelQ}} --fallback-model {{{fallbackModelQ}}}{{/if}} --append-system-prompt "$APPEND_PROMPT"{{#if dangerousMode}} --dangerously-skip-permissions{{/if}}{{#if extraCliArgs}}{{{extraCliArgs}}}{{/if}}
 else
-  exec claude $CONTINUE_FLAG --dangerously-load-development-channels server:switchroom-telegram --plugin-dir "{{securityPluginDir}}"{{#if hindsightEnabled}} --plugin-dir "{{agentDir}}/.claude/plugins/hindsight-memory"{{/if}}{{#if modelQ}} --model {{{modelQ}}}{{/if}}{{#if thinkingEffort}} --effort {{thinkingEffort}}{{/if}}{{#if permissionMode}} --permission-mode {{permissionMode}}{{/if}}{{#if fallbackModelQ}} --fallback-model {{{fallbackModelQ}}}{{/if}}{{#if dangerousMode}} --dangerously-skip-permissions{{/if}}{{#if extraCliArgs}}{{{extraCliArgs}}}{{/if}}
+  exec claude $CONTINUE_FLAG --dangerously-load-development-channels server:switchroom-telegram --plugin-dir "{{securityPluginDir}}"{{#if hindsightEnabled}} --plugin-dir "{{agentDir}}/.claude/plugins/hindsight-memory"{{/if}} $SR_FLEET_ARG{{#if modelQ}} --model {{{modelQ}}}{{/if}}{{#if thinkingEffort}} --effort {{thinkingEffort}}{{/if}}{{#if permissionMode}} --permission-mode {{permissionMode}}{{/if}}{{#if fallbackModelQ}} --fallback-model {{{fallbackModelQ}}}{{/if}}{{#if dangerousMode}} --dangerously-skip-permissions{{/if}}{{#if extraCliArgs}}{{{extraCliArgs}}}{{/if}}
 fi
 {{else}}
 if [ -n "$APPEND_PROMPT" ]; then
-  exec claude $CONTINUE_FLAG --channels plugin:telegram@claude-plugins-official --plugin-dir "{{securityPluginDir}}"{{#if hindsightEnabled}} --plugin-dir "{{agentDir}}/.claude/plugins/hindsight-memory"{{/if}}{{#if modelQ}} --model {{{modelQ}}}{{/if}}{{#if thinkingEffort}} --effort {{thinkingEffort}}{{/if}}{{#if permissionMode}} --permission-mode {{permissionMode}}{{/if}}{{#if fallbackModelQ}} --fallback-model {{{fallbackModelQ}}}{{/if}} --append-system-prompt "$APPEND_PROMPT"{{#if dangerousMode}} --dangerously-skip-permissions{{/if}}{{#if extraCliArgs}}{{{extraCliArgs}}}{{/if}}
+  exec claude $CONTINUE_FLAG --channels plugin:telegram@claude-plugins-official --plugin-dir "{{securityPluginDir}}"{{#if hindsightEnabled}} --plugin-dir "{{agentDir}}/.claude/plugins/hindsight-memory"{{/if}} $SR_FLEET_ARG{{#if modelQ}} --model {{{modelQ}}}{{/if}}{{#if thinkingEffort}} --effort {{thinkingEffort}}{{/if}}{{#if permissionMode}} --permission-mode {{permissionMode}}{{/if}}{{#if fallbackModelQ}} --fallback-model {{{fallbackModelQ}}}{{/if}} --append-system-prompt "$APPEND_PROMPT"{{#if dangerousMode}} --dangerously-skip-permissions{{/if}}{{#if extraCliArgs}}{{{extraCliArgs}}}{{/if}}
 else
-  exec claude $CONTINUE_FLAG --channels plugin:telegram@claude-plugins-official --plugin-dir "{{securityPluginDir}}"{{#if hindsightEnabled}} --plugin-dir "{{agentDir}}/.claude/plugins/hindsight-memory"{{/if}}{{#if modelQ}} --model {{{modelQ}}}{{/if}}{{#if thinkingEffort}} --effort {{thinkingEffort}}{{/if}}{{#if permissionMode}} --permission-mode {{permissionMode}}{{/if}}{{#if fallbackModelQ}} --fallback-model {{{fallbackModelQ}}}{{/if}}{{#if dangerousMode}} --dangerously-skip-permissions{{/if}}{{#if extraCliArgs}}{{{extraCliArgs}}}{{/if}}
+  exec claude $CONTINUE_FLAG --channels plugin:telegram@claude-plugins-official --plugin-dir "{{securityPluginDir}}"{{#if hindsightEnabled}} --plugin-dir "{{agentDir}}/.claude/plugins/hindsight-memory"{{/if}} $SR_FLEET_ARG{{#if modelQ}} --model {{{modelQ}}}{{/if}}{{#if thinkingEffort}} --effort {{thinkingEffort}}{{/if}}{{#if permissionMode}} --permission-mode {{permissionMode}}{{/if}}{{#if fallbackModelQ}} --fallback-model {{{fallbackModelQ}}}{{/if}}{{#if dangerousMode}} --dangerously-skip-permissions{{/if}}{{#if extraCliArgs}}{{{extraCliArgs}}}{{/if}}
 fi
 {{/if}}

package/profiles/_shared/agent-self-service.md.hbs

@@ -22,6 +22,9 @@ tools is to let you do the edit yourself.
 | "what other agents are running here?" / "is there an agent that does X?" / "who handles Y?" | `peers_list` |
 | "install the foo skill" / "give yourself the foo skill" | `skill_install` with `source: "bundled:foo"` |
 | "drop the foo skill" / "remove the foo skill" | `skill_remove` with `name: "foo"` |
+| "is there a skill for X?" | `skill_search` with `query: "X"` |
+| **YOU find a bug in a skill you're using** | `skill_clone_to_personal` then `skill_edit_personal` — fork-and-fix yourself |
+| "write me a custom skill that does X" | `skill_init_personal` |
 
 ### Tools
 
@@ -66,6 +69,8 @@ tools is to let you do the edit yourself.
   Does NOT remove skills the operator wrote directly into
   `switchroom.yaml` — those are removed by the operator only.
 
+- **`skill_search` / `skill_init_personal` / `skill_edit_personal` / `skill_remove_personal` / `skill_list_personal` / `skill_clone_to_personal`** — author/fork your own. `files` is `{path: content}` JSON; allowlist `SKILL.md`, `scripts/*.{sh,py}`, `references/*.md`.
+
 ### Safety rails — what gets rejected
 
 The broker hard-rejects writes that would violate these limits. Anticipate
@@ -79,28 +84,13 @@ the rails will block:
 - **20 entries per agent maximum.** `E_QUOTA_EXCEEDED`. If you're near the
   cap, `cron_list` first; if full, prompt the user to remove an old one
   before adding the new one.
-- **No `secrets:` on agent-authored entries.** `E_OVERLAY_SECRETS_REQUIRES_APPROVAL`.
-  If the user's task needs a credential (e.g. "use the GitHub API to
-  check…"), the cron fires the prompt and YOU at runtime go through the
-  normal `vault_request_access` flow on first execution — don't bake the
-  `secrets:` allowlist into the schedule entry.
-- **Cross-agent writes.** You can only manage your OWN schedule. The
-  broker pins identity via the `$SWITCHROOM_AGENT_NAME` env var the
-  gateway sets when spawning your CLI — calls passing
-  `agent: "<other-agent>"` that doesn't match the pin are rejected. If
-  the user wants to set something up on a different agent, tell them
-  which agent to ask.
-
-### Skills — self-service is live (#1163 Phase 2)
-
-You can `skill_list` to inventory, `skill_install` to add, and
-`skill_remove` to drop. v1 source format is `bundled:<name>` only — the
-skill must exist in the host's bundled-skills pool (run `skill_list` on
-the host to see what's available, or pass an obvious slug like
-`webapp-testing`, `pdf`, `mcp-builder`). git+https sources are designed
-but not yet shipped; if the user asks for an arbitrary URL, tell them
-the operator needs to drop it under `~/.switchroom/skills/<name>/` and
-run `switchroom apply`.
+- **No `secrets:` on agent-authored entries** (`E_OVERLAY_SECRETS_REQUIRES_APPROVAL`). Cron fires the prompt; you go through `vault_request_access` at runtime.
+- **Cross-agent writes rejected** — you manage only your own schedule. The broker pins identity via `$SWITCHROOM_AGENT_NAME`; if the user wants something on a different agent, tell them which agent to ask.
+
+### Skills — self-service
+
+- **Install** — `skill_install` (`bundled:<name>`) / `skill_remove`. git+https deferred.
+- **Fix a skill yourself** — `skill_clone_to_personal` → `skill_edit_personal` → use `personal-<name>`. Fork is durable + auto-mirrors to `~/.switchroom-config/` when present.
 
 ### Honest confirmation pattern
 

package/profiles/coding/CLAUDE.md.hbs

@@ -34,7 +34,7 @@ You are a senior software engineering agent. You write, review, debug, and archi
 - Clear commit messages in imperative mood explaining the why.
 - Atomic commits. PR descriptions explain what, why, and how to test.
 
-{{> telegram-style}}
+{{!-- telegram-style now in ~/.switchroom/fleet/switchroom-invariants.md --}}
 
 ## Memory — Hindsight
 

package/profiles/default/CLAUDE.md.hbs

@@ -39,7 +39,14 @@ How you should decide what to do next. These are procedural rules, not vibe.
 - **Weak or empty tool result is not a conclusion.** Vary the query, path, command, or source before deciding the thing isn't there.
 - **Non-final turn:** use tools to advance, or ask the one clarifying question that unblocks safe progress. One question, not five.
 
-{{> telegram-style}}
+{{!--
+  Telegram-style guidance (the 5-beat pacing contract) lives in the
+  fleet invariants file at `~/.switchroom/fleet/switchroom-invariants.md`
+  and reaches the agent via Claude Code native CLAUDE.md discovery
+  (`--add-dir ~/.switchroom/fleet`). Do not re-include the
+  `{{> telegram-style}}` partial here — that would re-introduce the
+  session-level duplication the prompt redesign removed.
+--}}
 
 ## Memory — Hindsight is your single backend
 

package/profiles/executive-assistant/CLAUDE.md.hbs

@@ -33,7 +33,7 @@ You help the user stay organized, prepared, and focused on high-leverage work. Y
 - **Anticipate, don't just react.** Flag gaps proactively.
 - **Be concise.** Lead with essentials. Details on request.
 
-{{> telegram-style}}
+{{!-- telegram-style now in ~/.switchroom/fleet/switchroom-invariants.md --}}
 
 ## Memory — Hindsight
 

package/profiles/health-coach/CLAUDE.md.hbs

@@ -27,7 +27,7 @@ You are a health and fitness coaching agent — an accountability partner, not a
 ## Boundaries
 Recommend the user consult a professional for: persistent pain/injury, medical conditions, specialized nutrition plans, symptoms of overtraining or disordered eating. Say it plainly: "That's outside my lane — worth checking with your doctor."
 
-{{> telegram-style}}
+{{!-- telegram-style now in ~/.switchroom/fleet/switchroom-invariants.md --}}
 
 ## Memory — Hindsight
 

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