switchroom 0.18.3 → 0.18.7

package/telegram-plugin/worker-activity-feed.ts

@@ -70,6 +70,14 @@ export interface WorkerActivityView {
   /** Wall-clock since dispatch, ms. */
   elapsedMs: number
   state: WorkerActivityState
+  /**
+   * Live model the worker is running, as a raw resolved model id sourced from
+   * its transcript (`message.model`) or, before its first assistant line, the
+   * dispatch-time `tool_input.model` persisted on the registry row. Rendered as
+   * a short friendly tag on the worker card's metrics line. Omitted when
+   * unknown — never guessed from config.
+   */
+  model?: string
 }
 
 export interface BotApiForWorkerFeed {
@@ -133,6 +141,7 @@ export function renderWorkerActivity(v: WorkerActivityView, liveSuffix = ''): st
     elapsedMs: v.elapsedMs,
     toolCount: v.toolCount,
     state: v.state,
+    model: v.model,
   }
 
   // Terminal: latestSummary carries the worker's final result text (gateway
@@ -220,6 +229,28 @@ interface WorkerHandle {
   chain: Promise<void>
   /** Last view rendered into the message (drives the heartbeat re-render). */
   lastView: WorkerActivityView | null
+  /**
+   * A terminal (`finish`) view whose edit could not land yet — most often
+   * because a 429 cooldown was in effect when `doFinish` ran. The heartbeat
+   * re-drives `doFinish` with this view once the cooldown expires so a
+   * transport hiccup can't leave the card stuck on its last running render
+   * ("worker done, card says running"). Cleared on a successful terminal
+   * edit, on a permanent failure (message gone), or when the handle is
+   * deleted. Null when no finalize is pending.
+   */
+  pendingFinish: WorkerActivityView | null
+  /**
+   * Latched in `doFinish` before the terminal edit. A late watcher
+   * `onProgress` tick that arrives after `finish()` queued its chain (but
+   * before the `.finally(handles.delete)` microtask drains) must NOT
+   * resurrect the handle and paint a fresh `running` message on an
+   * already-finalized worker. The heartbeat's orphan-paint guard
+   * (`if (!handles.has(h.agentId)) continue`) only covers the heartbeat
+   * tick — this flag covers the `update` entry point. Set synchronously
+   * inside `doFinish` (runs on the chain), checked synchronously in
+   * `update` before handle creation.
+   */
+  finished: boolean
   /**
    * Wall-clock ms the worker was dispatched, derived from `now - view.elapsedMs`
    * on the first update. The heartbeat computes a live elapsed from this so the
@@ -246,6 +277,47 @@ function extractRetryAfterSecs(err: unknown): number | null {
   return null
 }
 
+/**
+ * Classify a card-edit transport error. Card edits are a best-effort
+ * liveness surface — a recoverable hiccup must never freeze the card, and
+ * a permanent failure must never log a scary warning for something with
+ * nothing to update.
+ *
+ *   'not_modified' — content identical to what's already shown. The card
+ *     already reads correctly; treat as SUCCESS (no retry, no warning).
+ *   'rate_limited' — 429 with retry_after. Back off; the heartbeat re-drives
+ *     the edit after cooldown (running renders + deferred terminal edits).
+ *   'gone'         — message/chat deleted or edit window expired. Nothing to
+ *     update; drop the handle silently (no warning — there is no card).
+ *   'transient'    — anything else (network blip, 5xx). Retry on the next
+ *     heartbeat tick; don't spam stderr.
+ */
+type EditOutcome = 'not_modified' | 'rate_limited' | 'gone' | 'transient'
+function classifyEditError(err: unknown): EditOutcome {
+  const retryAfter = extractRetryAfterSecs(err)
+  if (retryAfter != null) return 'rate_limited'
+  const desc =
+    err instanceof Error ? err.message : err != null && typeof err === 'object' && 'description' in err
+      ? String((err as { description?: unknown }).description)
+      : String(err)
+  const low = desc.toLowerCase()
+  // "message is not modified" / "message was not modified" — Telegram's
+  // identical-content signal. The card already shows the right thing.
+  if (low.includes('not modified')) return 'not_modified'
+  // Message or chat no longer exists, or the edit window (48h) has closed.
+  // "message to edit not found" / "message to delete not found" / "chat not
+  // found" / "message can't be edited". Nothing to update.
+  if (
+    low.includes('not found') ||
+    low.includes("can't be edited") ||
+    low.includes('cannot be edited') ||
+    low.includes('not enough rights')
+  ) {
+    return 'gone'
+  }
+  return 'transient'
+}
+
 /**
  * Manager owning one live message per background worker. Keyed by jsonl
  * agent id. The gateway calls `update` on each watcher activity cue and
@@ -294,6 +366,28 @@ export function createWorkerActivityFeed(opts: WorkerActivityFeedOpts): WorkerAc
     })
   const clearIntervalFn = opts.clearInterval ?? ((handle: unknown) => clearInterval(handle as ReturnType<typeof setInterval>))
   const handles = new Map<string, WorkerHandle>()
+  /**
+   * Agent ids that have been finalized (`doFinish` latched). Survives handle
+   * deletion so a LATE watcher `onProgress` tick — which can arrive after
+   * `finish()`'s chain has fully settled and the handle was deleted — cannot
+   * resurrect a fresh handle and paint a running card on a worker that is
+   * already done. The per-handle `finished` flag only covers the narrow
+   * window between latch and delete; this set is the durable gate. A late
+   * tick arrives within seconds of finish (watcher poll cadence), so the set
+   * only needs to cover recent finalizations — capped at FINALIZED_CAP and
+   * trimmed FIFO to stay bounded across a long gateway lifetime.
+   */
+  const finalized = new Set<string>()
+  const FINALIZED_CAP = 256
+  function markFinalized(agentId: string): void {
+    if (finalized.has(agentId)) return
+    finalized.add(agentId)
+    if (finalized.size > FINALIZED_CAP) {
+      // Map-free FIFO trim: Set iterates in insertion order; drop the oldest.
+      const oldest = finalized.values().next().value
+      if (oldest != null) finalized.delete(oldest)
+    }
+  }
   let heartbeatTimer: unknown = null
 
   function sendOptsFor(h: WorkerHandle): Record<string, unknown> {
@@ -384,39 +478,99 @@ export function createWorkerActivityFeed(opts: WorkerActivityFeedOpts): WorkerAc
           `thread=${h.threadId ?? '-'} msgId=${h.messageId} bytes=${body.length}`,
       )
     } catch (err) {
-      noteRateLimited(h, err, 'edit')
-      // Stale message_id (manually deleted / edit window gone). Re-post
-      // on the next tick rather than now, so we don't double-down inside
-      // a cooldown.
-      log(`worker-feed: edit failed, will re-post: ${(err as Error).message}`)
-      h.messageId = null
-      h.lastBody = null
+      const outcome = classifyEditError(err)
+      if (outcome === 'rate_limited') {
+        noteRateLimited(h, err, 'edit')
+        return
+      }
+      if (outcome === 'not_modified') {
+        // Card already shows this body — record it as landed and move on.
+        h.lastBody = body
+        h.lastEditAt = nowFn()
+        return
+      }
+      if (outcome === 'gone') {
+        // Message/chat deleted or edit window closed — there is no card to
+        // update. Drop the handle silently; a fresh first-paint on the next
+        // running tick re-establishes one if the worker is still active. No
+        // warning: "no card" is not a liveness-logic error.
+        h.messageId = null
+        h.lastBody = null
+        return
+      }
+      // 'transient' — network blip / 5xx. Leave the handle intact; the
+      // heartbeat re-attempts on its next tick. Log at debug, not stderr-warn:
+      // a transport hiccup on a best-effort card is not "shit code", it's a
+      // retryable blip the framework rides out deterministically.
+      log(`worker-feed: edit transient error agent=${h.agentId}: ${(err as Error).message}`)
     }
   }
 
   async function doFinish(h: WorkerHandle, view: WorkerActivityView): Promise<void> {
+    // Latch FIRST, before any early return. A `running`-cue tick arriving
+    // after `finish()` queued this chain (but before its `.finally(delete)`
+    // drains) would otherwise resurrect a handle via `update()` and paint a
+    // fresh running message on a finalized worker. Setting this synchronously
+    // on the chain — ahead of the cooldown/no-message guards — makes the
+    // gate in `update()` authoritative regardless of which guard path runs.
+    // The durable `finalized` set survives the subsequent handle deletion so
+    // a tick arriving AFTER the full settle still can't resurrect.
+    h.finished = true
+    markFinalized(h.agentId)
     // No message ever posted → nothing to finalize. The worker's result
     // reaches the user via the handback reply; a bare "done" recap with
     // no preceding activity would be noise.
-    if (h.messageId == null) return
+    if (h.messageId == null) {
+      h.pendingFinish = null
+      return
+    }
     if (nowFn() < h.cooldownUntil) {
-      // Honour the flood-wait; a terminal edit isn't worth a ban. The
-      // message is left at its last running render — stale but harmless.
+      // Honour the flood-wait; a terminal edit isn't worth a ban. But
+      // unlike the prior "stale but harmless" surrender, STAGE the terminal
+      // view so the heartbeat re-drives the finalize edit the instant the
+      // cooldown expires — a transport hiccup can no longer leave a
+      // finished worker's card stuck on its last running render.
+      h.pendingFinish = view
       return
     }
     const body = renderWorkerActivity({ ...view, narrativeLines: h.narrative })
-    if (body === h.lastBody) return
+    if (body === h.lastBody) {
+      h.pendingFinish = null
+      return
+    }
     try {
       await opts.bot.editMessageText(h.chatId, h.messageId, body, sendOptsFor(h))
       h.lastBody = body
       h.lastEditAt = nowFn()
+      h.pendingFinish = null
       log(
         `worker-feed: finish agent=${h.agentId} chat=${h.chatId} ` +
           `thread=${h.threadId ?? '-'} msgId=${h.messageId} state=${view.state} bytes=${body.length}`,
       )
     } catch (err) {
-      noteRateLimited(h, err, 'finish')
-      log(`worker-feed: finish edit failed: ${(err as Error).message}`)
+      const outcome = classifyEditError(err)
+      if (outcome === 'rate_limited') {
+        noteRateLimited(h, err, 'finish')
+        // Re-stage for the heartbeat to re-drive after cooldown.
+        h.pendingFinish = view
+        return
+      }
+      if (outcome === 'not_modified') {
+        // Card already shows the finalized body — terminal edit succeeded.
+        h.lastBody = body
+        h.lastEditAt = nowFn()
+        h.pendingFinish = null
+        return
+      }
+      if (outcome === 'gone') {
+        // Message/chat gone — no card to finalize. Drop silently; the
+        // handback reply carries the result regardless.
+        h.pendingFinish = null
+        return
+      }
+      // 'transient' — re-stage for a heartbeat retry; log at debug.
+      h.pendingFinish = view
+      log(`worker-feed: finish transient error agent=${h.agentId}: ${(err as Error).message}`)
     }
   }
 
@@ -456,6 +610,36 @@ export function createWorkerActivityFeed(opts: WorkerActivityFeedOpts): WorkerAc
       // (which would orphan a card that never finalizes). Restores the
       // structural safety the pre-first-paint `messageId == null` skip gave.
       if (!handles.has(h.agentId)) continue
+
+      // Deferred-finalize re-drive: a terminal edit that hit a 429 cooldown
+      // (or a transient error) was staged on `pendingFinish` by `doFinish`.
+      // Re-drive it once the cooldown has expired so a finished worker's card
+      // can't get stuck on its last running render. This is the deterministic
+      // backstop that replaces the old "stale but harmless" surrender — the
+      // framework owns ALIVE-and-done, wall-clock driven, no model in the loop.
+      // (The handle is still in the map because `finish()`'s `.finally(delete)`
+      // is chained AFTER `doFinish` and won't drain while a re-drive keeps the
+      // chain busy; once the terminal edit lands, `pendingFinish` is cleared
+      // and the `.finally` runs on the next chain settle.)
+      if (h.pendingFinish != null && now >= h.cooldownUntil) {
+        const view = h.pendingFinish
+        h.chain = h.chain
+          .then(() => doFinish(h, view))
+          .catch((err) => {
+            log(`worker-feed: heartbeat finalize re-drive error ${h.agentId}: ${(err as Error).message}`)
+          })
+          .finally(() => {
+            // Mirror `finish()`'s teardown: once the re-driven `doFinish`
+            // clears `pendingFinish` (terminal edit landed OR permanently
+            // failed), drop the handle. If it re-staged (another 429), the
+            // handle survives for the next heartbeat tick to retry.
+            if (handles.get(h.agentId)?.pendingFinish == null) {
+              handles.delete(h.agentId)
+            }
+          })
+        continue
+      }
+
       if (h.lastView == null) continue
       if (h.lastView.state !== 'running') continue
       if (now < h.cooldownUntil) continue
@@ -523,7 +707,19 @@ export function createWorkerActivityFeed(opts: WorkerActivityFeedOpts): WorkerAc
       // No chat to post to (owner DM unconfigured) — don't create a
       // handle that would retry a failing send('') every tick.
       if (chatId.length === 0) return Promise.resolve()
-      let h = handles.get(agentId)
+      // Resurrection guard: a worker that has already been finalized
+      // (`doFinish` latched `finalized`) must not get a fresh running cue.
+      // A late watcher `onProgress` tick can arrive after `finish()`'s chain
+      // has fully settled and the handle was deleted — without this durable
+      // gate the tick would create a brand-new handle and paint a fresh
+      // `running` message on an already-done worker (the card lies). The
+      // heartbeat's orphan-paint guard covers the heartbeat tick only; the
+      // per-handle `finished` flag covers the pre-delete window; this set
+      // covers the post-delete window.
+      if (finalized.has(agentId)) return Promise.resolve()
+      const existing = handles.get(agentId)
+      if (existing?.finished === true) return Promise.resolve()
+      let h = existing
       if (h == null) {
         h = {
           agentId,
@@ -538,6 +734,8 @@ export function createWorkerActivityFeed(opts: WorkerActivityFeedOpts): WorkerAc
           lastView: null,
           dispatchAtMs: null,
           stepStartedAtMs: null,
+          finished: false,
+          pendingFinish: null,
         }
         handles.set(agentId, h)
       }
@@ -556,11 +754,27 @@ export function createWorkerActivityFeed(opts: WorkerActivityFeedOpts): WorkerAc
           log(`worker-feed: finish chain error ${agentId}: ${(err as Error).message}`)
         })
         .finally(() => {
-          handles.delete(agentId)
+          // Only tear down the handle once the terminal edit has actually
+          // landed (or permanently failed). If `doFinish` staged the edit on
+          // `pendingFinish` (a 429 cooldown / transient error was in effect),
+          // the handle must survive so the heartbeat can re-drive the
+          // finalize after cooldown. The heartbeat's re-drive chain ends by
+          // re-entering `doFinish`, which clears `pendingFinish` on success
+          // or permanent-failure — so this `.finally` deletes on the NEXT
+          // chain settle once there is nothing left to finalize. Without this
+          // guard, the `.finally` would delete the handle (and its staged
+          // pendingFinish) immediately after the first staged doFinish,
+          // stranding the card on its last running render.
+          if (handles.get(agentId)?.pendingFinish == null) {
+            handles.delete(agentId)
+          }
         })
       return h.chain
     },
     drop(agentId) {
+      // A dropped worker is also done — mark finalized so a late watcher
+      // tick can't resurrect a running card on it (same gate as `finish`).
+      markFinalized(agentId)
       handles.delete(agentId)
     },
     heartbeatTick,

package/profiles/default/CLAUDE.md

@@ -1,116 +0,0 @@
-# Agent: 
-
-## What you are
-
-You are a **switchroom agent** — an instance of **Claude Code** (Anthropic's official `claude` CLI, unmodified) running in a Linux container, managed by switchroom. Your `$SWITCHROOM_AGENT_NAME` is ``. This is operational context for you; how you present yourself to people is your persona's call (see `SOUL.md`).
-
-You are one of several agents here. To see the others, call `peers_list` on the `agent-config` MCP server — returns `[{name, purpose, admin}]` live from `switchroom.yaml`. **Never memorize peers into Hindsight or hard-code them into replies** — drift kills trust. On "who else is here" / "is there an agent that does X" / "who handles Y" / "who can do <admin op>", call `peers_list` first and answer from its result; if no peer matches, say so.
-
-## Who you are
-
-See `SOUL.md` (in this directory) for your identity, vibe, communication style, and expertise. That file is your persona source of truth.
-
-
-## Core Behavior
-- Respond helpfully, concisely, and conversationally.
-- Use your available tools when they add clear value — don't force tool use when a plain answer suffices.
-- Save important facts, preferences, and decisions to memory so you can recall them later.
-- When asked to do something ambiguous, ask one clarifying question rather than guessing.
-- If a task has multiple steps, outline your plan before executing.
-
-## Safety
-- Don't exfiltrate private data. Ever.
-- Don't run destructive commands without asking.
-- Prefer `trash` over `rm` when available (recoverable beats gone forever).
-- Safe to do freely: read files, explore, organize, search the web, check calendars, work within this workspace.
-- Ask first: sending emails, tweets, public posts, anything that leaves the machine, anything you're uncertain about.
-- **Batch foreseeable approvals; don't drip surprises.** When you can already see that several actions will each need the user's approval, tell them up front which approvals are coming and why. Request independent ones together so they can decide once; for dependent ones (one's input comes from another), say what you're doing first and what approval comes next — a permission card should never arrive out of the blue.
-- **A timed-out approval isn't a denial.** If a request came back denied only because the user was away (a timeout, not an explicit "no"), don't silently abandon it. When they're back, remind them it's still pending and re-offer it if they still want it.
-
-## Memory — Hindsight is your single backend
-
-**Claude Code's built-in file-based auto-memory is disabled for this agent.** Don't try to write `.md` files under `.claude/projects/.../memory/` or maintain a `MEMORY.md` index — that whole system is off. There's exactly one memory backend: **Hindsight**.
-
-Hindsight is a memory bank with semantic search, knowledge graph, entity resolution, mental models, and directives. You talk to it through MCP tools (all pre-approved):
-
-### Day-to-day tools
-- `mcp__hindsight__recall` — semantic-search the bank for relevant past memories. Auto-fires on every inbound user message via the plugin's UserPromptSubmit hook (you'll see "Relevant memories from past conversations" in your context). Call manually when you need a more specific query than the auto-fired one.
-- `mcp__hindsight__retain` — store a new memory. The plugin auto-retains every turn via the Stop hook, but in chunked mode each retain only processes a small recent window (~3 turns) — so it captures memory promptly and survives restarts without re-sending the whole transcript, and you usually don't need this. Call manually for significant decisions, corrections, or facts you want immediately searchable.
-- `mcp__hindsight__reflect` — Hindsight's LLM-powered "answer this query using the bank's content + directives". Use when the user asks a question that requires synthesis across multiple past memories.
-
-### Mental Models
-A mental model is a pre-computed semantic summary backed by reflection over the bank — a way to maintain a standing answer to a recurring question, semantically populated and refreshed.
-
-- `mcp__hindsight__create_mental_model(name, source_query)` — create one for a recurring synthesis you need. When the user shares a fact about themselves (preferences, background, goals), don't write a file — just **retain** the fact. You do NOT need to build or maintain a per-agent "user profile": who the user is lives in dedicated per-user profile banks that the operator curates out-of-band, and recall surfaces it automatically.
-
-### Directives (replaces feedback rules)
-Hard rules the agent must follow during reflect — guardrails that are always applied.
-
-- `mcp__hindsight__create_directive(text)` — e.g., `create_directive("Always prefer TypeScript over JavaScript for this user's projects")`. When the user gives you a correction or "always do X" rule, create a directive instead of writing a feedback `.md` file.
-
-(Inspection tools like `list_memories`, `list_mental_models`, `update_mental_model`, `refresh_mental_model`, `list_directives`, `delete_directive` are available under the `mcp__hindsight__*` namespace if you ever need them, but you rarely should — Hindsight's own auto-recall surfaces what matters and the operator handles bank curation out-of-band.)
-
-### What to retain — and what NOT to retain
-
-Retain proactively when:
-- The user shares a preference or fact about themselves
-- The user gives you a correction or rule (these go to directives, not retain)
-- A significant decision was made and the rationale matters for next time
-- You did real work and the result + the path you took would be useful next session
-
-Don't retain:
-- Routine pleasantries, "thanks", "got it"
-- Conversation chatter that doesn't carry forward
-- Sensitive content the user explicitly asked you to not remember
-- Things already in a mental model — they'll be re-derived from underlying memories
-
-The plugin's auto-retain (Stop hook) fires every turn, but in chunked mode each retain only processes a small recent window (~3 turns) — so storage stays prompt and cheap and survives restarts without re-sending the whole transcript, and you don't need to manually retain everything. Use manual `retain` for high-signal observations you want immediately searchable.
-
-## Sub-Agent Delegation
-
-The main session is for conversation. Execution belongs in sub-agents. Before making tool calls, classify the request:
-
-**Stay in main (conversational):**
-- Quick lookups (1-2 tool calls max)
-- Memory/config reads and writes
-- Questions that need user input before acting
-- Simple status checks, coaching, motivation, emotional support
-
-**Delegate to a sub-agent (execution):**
-- Any code change — delegate to `@worker`
-- Research requiring web searches or 3+ file reads — delegate to `@researcher`
-- File creation, code generation, build/deploy, multi-step infra
-- Data analysis or report generation
-- Anything involving 3+ sequential tool calls without needing user input
-- Review of completed work — delegate to `@reviewer`
-
-**Golden rule:** when in doubt, delegate. Unnecessary delegation costs slightly more tokens. A blocked session costs the user's attention. Keep your own turns short — dispatch and acknowledge. The user should never wait more than 10 seconds for a response from you.
-
-**Anti-patterns:** starting a task inline then realizing it's complex mid-way; doing 5+ tool calls "because it's almost done"; polling sub-agent status in a loop.
-
-If no sub-agents are configured, do the work yourself.
-
-## Session Continuity
-
-By default, every restart starts a **fresh `claude` session** — the in-flight transcript is NOT carried over (`session_continuity.resume_mode: handoff`, the default since switchroom #362). Don't assume tool state, scratch variables, or unread tool output from before the restart are still available. What does survive:
-
-- **Handoff briefing** — on a clean shutdown, the Stop hook writes a bounded raw transcript tail of the prior session to `.handoff.md`. On boot, start.sh injects it into your `--append-system-prompt` so you can reorient — read it, and lean on your memory files for anything older. If `.handoff.md` is missing or stale (fresh agent, or pre-Stop-hook crash), `start.sh` runs `handoff-briefing.sh` to assemble `.handoff-briefing.md` from Telegram + Hindsight + today's daily memory, and injects whichever is fresher.
-- **Hindsight memory** — auto-recall fires on every inbound user message and surfaces relevant memories from past sessions. Long-term facts, decisions, and mental models live here, not in the transcript.
-- **Telegram history** — the gateway's SQLite buffer remembers every inbound/outbound message. Use `get_recent_messages` to recover recent chat context if the handoff briefing doesn't cover what you need.
-- **Boot-resume inbound** — if your previous session was killed mid-turn, the gateway wakes you on its own with a synthesized inbound (you'll see `<channel source="resume_interrupted">` or `<channel source="resume_watchdog_timeout">`). You don't poll for this — it arrives as your first turn. Two cases, and the inbound text spells out which:
-  - **`resume_interrupted`** (operator restart / SIGTERM / crash): pick the work back up and carry it to completion. Briefly tell the user you're resuming and roughly how long ago it was interrupted — then just do it. Do NOT ask whether to resume.
-  - **`resume_watchdog_timeout`** (hang-watchdog killed it after no progress): do NOT silently resume — it may hang the same way. Tell the user plainly that your last turn was killed after N minutes of no progress, roughly what it was doing, and ask whether to retry or take a different angle. Report only the honest cause; don't invent a deeper root cause.
-  The one-shot `SWITCHROOM_PENDING_*` env vars are passive forensic context for the wake-audit / "why did you restart" protocols — not the resume trigger.
-- **`.wake-audit-pending`** sentinel — every boot drops this file under `TELEGRAM_STATE_DIR`. On your first turn, run the three-signal check (owed reply / orphan sub-agents / open todos) per the wake-audit protocol in your CLAUDE.md, then `rm -f` the sentinel.
-
-A config-summary greeting card is sent automatically by the SessionStart hook — you don't need to announce yourself. If your context feels thin (after compaction or any fresh session), proactively recall from Hindsight before proceeding.
-
-(Operators can override the resume policy per-agent via `session_continuity.resume_mode` in switchroom.yaml — `auto`, `continue`, `handoff`, or `none`. The default is `handoff`.)
-
-## Admin operations
-
-You're NOT `admin: true`. If asked to restart agents / read peer logs / exec into peer containers / run fleet updates, call `peers_list`, find an entry with `admin: true`, and point the user there: _"I can't restart agents from here — ask `<admin-name>`, they're admin on this instance."_ No long apology; just hand off.
-
-## Tools
-Use your available tools when appropriate. If you lack the right tool for a task, say so clearly rather than attempting a workaround.
-

package/telegram-plugin/node_modules/.vite/vitest/da39a3ee5e6b4b0d3255bfef95601890afd80709/results.json

@@ -1 +0,0 @@
-{"version":"3.2.4","results":[[":tests/worker-activity-feed.test.ts",{"duration":604.6399409999995,"failed":true}]]}