switchroom 0.14.19 → 0.14.21

package/telegram-plugin/uat/assertions.ts

@@ -11,6 +11,59 @@
 
 import type { Driver, ObservedMessage, ObservedReaction } from "./driver.js";
 
+/**
+ * Canonical shape of a worker-activity-feed message (#2000) as rendered
+ * in Telegram: a running header `🔧 Worker · …` that edits in place and
+ * finalizes to `✅ Worker done · …` / `⚠️ Worker failed · …`. The feed is
+ * default-on fleet-wide as of v0.14.19, so background sub-agent activity
+ * now surfaces as its own bot message in any chat — including DMs whose
+ * scenario only cares about the agent's conversational reply.
+ *
+ * Single source of truth; the worker-feed scenario asserts against this,
+ * and recall/reply scenarios exclude it via {@link isWorkerFeedMessage}.
+ */
+export const WORKER_FEED_RE = /🔧\s*Worker|✅\s*Worker done|⚠️\s*Worker failed|Worker (?:done|failed)/i;
+
+/**
+ * True when `m` is a worker-activity-feed message rather than the agent's
+ * own reply. Use it to skip feed noise when matching for a turn's actual
+ * answer — without it, an `expectMessage(/\S/)` can latch onto the feed's
+ * first paint and miss (or mis-time) the real reply. See #2000 / the
+ * memory-survives-restart recall scenario.
+ */
+export function isWorkerFeedMessage(m: ObservedMessage): boolean {
+  return WORKER_FEED_RE.test(m.text);
+}
+
+/**
+ * A single tool-activity-feed line as rendered by
+ * `renderActivityFeed` (telegram-plugin/tool-activity-summary.ts): the
+ * in-progress step is `→ <label>`, finished steps are `✓ <label>`, and a
+ * long turn gets a `✓ +N earlier…` header. Telegram strips the bold/italic
+ * wrapping, so the observed text is just the marker glyph + label.
+ */
+const ACTIVITY_FEED_LINE_RE = /^[→✓]\s/u;
+
+/**
+ * True when `m` is the live tool-activity feed (the one-message list of
+ * "what the agent is doing this turn") rather than the agent's reply. A
+ * message qualifies only when EVERY non-empty line is an activity line —
+ * so a real reply that merely contains an arrow is never misclassified.
+ *
+ * Recall/reply scenarios must skip this in addition to
+ * {@link isWorkerFeedMessage}: on a turn that uses tools, the feed paints
+ * `→ Finding the right tool` as its own bot message before the real answer
+ * lands, and an `expectMessage(/\S/)` would otherwise latch onto it.
+ */
+export function isActivityFeedMessage(m: ObservedMessage): boolean {
+  const lines = m.text
+    .split("\n")
+    .map((l) => l.trim())
+    .filter((l) => l.length > 0);
+  if (lines.length === 0) return false;
+  return lines.every((l) => ACTIVITY_FEED_LINE_RE.test(l));
+}
+
 export interface PollOptions {
   /** Hard deadline; the predicate must resolve truthy before this. */
   timeout: number;

package/telegram-plugin/uat/driver.ts

@@ -646,6 +646,34 @@ export class Driver {
     return { messageId: sent.id };
   }
 
+  /**
+   * Send a photo album (Telegram media_group) — multiple photos posted as
+   * one group, the way a forwarded album or a multi-image paste arrives.
+   * Exercises the gateway's A2 multi-attachment coalescing: with
+   * coalesce.max_attachments default 10, the whole album folds into ONE
+   * Claude turn (the agent sees image_path, image_path_2, …). The optional
+   * caption rides on the first item, matching Telegram client behaviour.
+   * Returns every sent message id (one per album item).
+   */
+  async sendAlbum(
+    chatId: number,
+    photoPaths: string[],
+    caption?: string,
+    opts?: SendTextOptions,
+  ): Promise<{ messageIds: number[] }> {
+    const c = this.requireClient();
+    const replyTo = opts?.replyTo ?? opts?.messageThreadId;
+    const medias = photoPaths.map((p, i) =>
+      InputMedia.photo(p, i === 0 && caption ? { caption } : undefined),
+    );
+    const sent = await c.sendMediaGroup(
+      chatId,
+      medias,
+      replyTo ? { replyTo } : undefined,
+    );
+    return { messageIds: sent.map((m) => m.id) };
+  }
+
   /**
    * Send or remove an emoji reaction on a target message. Used by the
    * UAT reaction-trigger scenario (#1074) to exercise the gateway's

package/telegram-plugin/uat/feed-matcher.test.ts

@@ -0,0 +1,80 @@
+import { describe, expect, it } from "bun:test";
+import {
+  isActivityFeedMessage,
+  isWorkerFeedMessage,
+  WORKER_FEED_RE,
+} from "./assertions.js";
+
+// Pins the worker-activity-feed detector (#2000) used by recall/reply
+// scenarios to skip feed noise. The live UAT it guards can't run in CI
+// (needs sudo + a real Telegram session), so this is the CI-verifiable
+// floor for the matcher's behavior.
+const feed = (text: string) => ({ text }) as Parameters<typeof isWorkerFeedMessage>[0];
+
+describe("isWorkerFeedMessage", () => {
+  it("matches the running feed header", () => {
+    expect(isWorkerFeedMessage(feed("🔧 Worker · crawling changelog · 0:12"))).toBe(true);
+  });
+
+  it("matches the terminal done/failed recaps", () => {
+    expect(isWorkerFeedMessage(feed("✅ Worker done · 10 tools · 1:03"))).toBe(true);
+    expect(isWorkerFeedMessage(feed("⚠️ Worker failed · 3 tools"))).toBe(true);
+  });
+
+  it("matches a done/failed header even without the leading emoji", () => {
+    expect(isWorkerFeedMessage(feed("Worker done · 2 tools"))).toBe(true);
+    expect(isWorkerFeedMessage(feed("Worker failed mid-step"))).toBe(true);
+  });
+
+  it("does NOT match an ordinary agent reply", () => {
+    expect(isWorkerFeedMessage(feed("on it, pulling the logs now"))).toBe(false);
+    expect(
+      isWorkerFeedMessage(feed("SWITCHROOM_UAT_MEM_DEADBEEFCAFE1234")),
+    ).toBe(false);
+  });
+
+  it("does NOT match a reply that merely mentions the word worker", () => {
+    expect(
+      isWorkerFeedMessage(feed("I'll dispatch a worker to handle the crawl.")),
+    ).toBe(false);
+  });
+
+  it("exposes the regex for scenarios that assert on the feed directly", () => {
+    expect(WORKER_FEED_RE.test("🔧 Worker · x")).toBe(true);
+  });
+});
+
+describe("isActivityFeedMessage", () => {
+  it("matches the in-progress step line", () => {
+    expect(isActivityFeedMessage(feed("→ Finding the right tool"))).toBe(true);
+  });
+
+  it("matches a multi-line feed (done steps + in-progress)", () => {
+    expect(
+      isActivityFeedMessage(feed("✓ Reading CLAUDE.md\n→ Searching memory")),
+    ).toBe(true);
+  });
+
+  it("matches the +N earlier header", () => {
+    expect(
+      isActivityFeedMessage(feed("✓ +3 earlier…\n✓ Reading CLAUDE.md\n→ Searching memory")),
+    ).toBe(true);
+  });
+
+  it("does NOT match an ordinary agent reply", () => {
+    expect(isActivityFeedMessage(feed("on it, pulling the logs now"))).toBe(false);
+    expect(
+      isActivityFeedMessage(feed("SWITCHROOM_UAT_MEM_DEADBEEFCAFE1234")),
+    ).toBe(false);
+  });
+
+  it("does NOT match a reply that merely contains an arrow mid-text", () => {
+    expect(
+      isActivityFeedMessage(feed("The flow is request → response → render.")),
+    ).toBe(false);
+  });
+
+  it("does NOT match an empty message", () => {
+    expect(isActivityFeedMessage(feed("   "))).toBe(false);
+  });
+});

package/telegram-plugin/uat/scenarios/jtbd-album-coalescing-dm.test.ts

@@ -0,0 +1,136 @@
+/**
+ * Album-coalescing scenario — driver sends a 3-photo Telegram album
+ * (media_group) in one shot; the gateway's A2 multi-attachment
+ * coalescing (coalesce.max_attachments, default 10 since v0.14.21)
+ * MUST fold all three into a SINGLE Claude turn, so the agent sees
+ * image_path + image_path_2 + image_path_3 together and can report a
+ * count of 3.
+ *
+ * Regression gate for the default-on flip (#2021): before max_attachments
+ * defaulted to 10, an album bypassed coalescing (each part its own turn),
+ * so the agent would only ever see ONE image per turn and answer "1".
+ * A reply of "3" proves the album coalesced.
+ *
+ * Part of: https://github.com/switchroom/switchroom/issues/865
+ *
+ * ## How the signal is read robustly
+ *
+ * The agent's answer is a bare count, which would collide with incidental
+ * digits the chat is now full of by default: the pinned progress card's
+ * timer (`00:03`) and — since the worker feed went default-on fleet-wide
+ * (#2009 / v0.14.19) — worker-feed lines like `🔧 Worker · … · 0:12`.
+ * A "first bot message containing a digit" matcher would latch onto one of
+ * those and false-fail even when coalescing is healthy (see the
+ * memory-survives-restart matcher-flake note + `isWorkerFeedMessage`).
+ *
+ * Two defences, mirroring the sibling `jtbd-forwarded-burst-dm` gate:
+ *   1. Anchor the answer on a distinctive token — the agent is told to
+ *      reply `IMAGECOUNT=<n>`. "IMAGECOUNT" never appears in a card or a
+ *      worker-feed line, so the matcher cannot collide with their digits.
+ *   2. Drain observed messages into a per-id map (collapsing streamed
+ *      edits to latest text), skip our own sends + worker-feed noise, and
+ *      poll until the ANSWER token appears — rather than returning the
+ *      first message that happens to match.
+ *
+ *   - Coalesced   → one turn sees 3 images → `IMAGECOUNT=3`.
+ *   - Non-coalesced → the turn carrying the caption/question sees only its
+ *     own (first) image → `IMAGECOUNT=1`. Surfaced as an explicit failure.
+ *
+ * Fixtures: three tiny solid-colour JPEGs under fixtures/album/, committed
+ * so the gate runs without a generation step. (Regenerate with
+ * `ffmpeg -f lavfi -i color=c=red:s=320x240 -frames:v 1 red.jpg`.)
+ */
+
+import path from "node:path";
+import { existsSync } from "node:fs";
+import { describe, expect, it } from "vitest";
+import { spinUp } from "../harness.js";
+import { pollUntil, isWorkerFeedMessage } from "../assertions.js";
+import type { ObservedMessage } from "../driver.js";
+
+const AGENT = "test-harness";
+
+const FIXTURE_DIR = path.resolve(__dirname, "..", "fixtures", "album");
+const PHOTOS = ["red.jpg", "green.jpg", "blue.jpg"].map((f) =>
+  path.join(FIXTURE_DIR, f),
+);
+
+const CAPTION =
+  "I just sent you a photo album in a single message. Count the separate " +
+  "image files you received in THIS ONE incoming message and reply with " +
+  "ONLY the token IMAGECOUNT=<n> (e.g. IMAGECOUNT=3). Nothing else.";
+
+// Warm TTFO on test-harness is ~7s; an album adds the (sub-second)
+// coalesce window plus the model looking at three images.
+const ANSWER_TIMEOUT_MS = 90_000;
+
+// Pull the count out of an `IMAGECOUNT=<n>` token, tolerating "= : whitespace".
+function imageCountIn(text: string): number | undefined {
+  const m = text.match(/IMAGECOUNT\s*[:=]?\s*(\d+)/i);
+  return m ? Number.parseInt(m[1], 10) : undefined;
+}
+
+describe("uat: album-coalescing DM round-trip", () => {
+  it(
+    "a 3-photo album folds into ONE turn — agent reports seeing 3 images",
+    async () => {
+      for (const p of PHOTOS) {
+        if (!existsSync(p)) {
+          throw new Error(
+            `album fixture missing at ${p} — see scenario header to regenerate`,
+          );
+        }
+      }
+      const sc = await spinUp({ agent: AGENT });
+      try {
+        // Observe BEFORE sending — observeMessages only sees live updates.
+        // Drain into a per-id map so streamed edits collapse to latest text;
+        // skip our own sends and worker-feed noise so neither can satisfy
+        // the count matcher.
+        const latestById = new Map<number, ObservedMessage>();
+        const stream = sc.driver.observeMessages(sc.botUserId);
+        const consume = (async () => {
+          for await (const m of stream) {
+            if (m.senderUserId === sc.driverUserId) continue;
+            if (isWorkerFeedMessage(m)) continue;
+            latestById.set(m.messageId, m);
+          }
+        })();
+
+        await sc.driver.sendAlbum(sc.botUserId, PHOTOS, CAPTION);
+
+        // Poll until a bot message carries an IMAGECOUNT token.
+        const answer = await pollUntil(
+          () => {
+            for (const m of latestById.values()) {
+              if (imageCountIn(m.text) !== undefined) return m;
+            }
+            return undefined;
+          },
+          { timeout: ANSWER_TIMEOUT_MS, interval: 500 },
+        ).catch(() => undefined);
+
+        await stream[Symbol.asyncIterator]().return?.(undefined as never);
+        await consume;
+
+        if (!answer) {
+          const seen = [...latestById.values()]
+            .map((m) => `#${m.messageId}=${JSON.stringify(m.text.slice(0, 60))}`)
+            .join(" ");
+          throw new Error(
+            `[album-coalescing] No bot reply carried an IMAGECOUNT token ` +
+              `within ${ANSWER_TIMEOUT_MS}ms. Bot messages seen: ${seen || "(none)"}.`,
+          );
+        }
+
+        const count = imageCountIn(answer.text);
+        // Coalesced => 3. A non-coalescing gateway answers 1 (the question
+        // rides photo #1; the other two parts spill to their own turns).
+        expect(count).toBe(3);
+      } finally {
+        await sc.tearDown();
+      }
+    },
+    ANSWER_TIMEOUT_MS + 30_000,
+  );
+});

package/telegram-plugin/uat/scenarios/jtbd-forwarded-burst-dm.test.ts

@@ -0,0 +1,158 @@
+/**
+ * JTBD scenario — forwarded burst / split paste coalesces into ONE turn.
+ *
+ * Serves: `reference/steer-or-queue-mid-flight.md` — the "Forwarded
+ * burst / split paste" UAT prompt. When several messages land in quick
+ * succession from the same sender (a forward of 3-4 messages, or a long
+ * paste Telegram split into chunks), inbound coalescing must merge them
+ * into a SINGLE Claude turn with shared context — not reply to each
+ * fragment in isolation.
+ *
+ * This is the end-to-end gate for the A1 coalescing work shipped in
+ * v0.14.18 (#2007). The merge logic itself is covered by unit + fuzz
+ * tests (`inbound-coalesce.test.ts`, `pending-inbound-buffer.test.ts`),
+ * but only this scenario exercises the real inbound → gateway coalescer
+ * → claude → outbound path over a live Telegram chat.
+ *
+ * ## How the signal is constructed
+ *
+ * Naively asking the agent to "combine facts from several messages"
+ * does NOT distinguish coalesced from fanned-out: even when each
+ * message becomes its own turn, every later turn carries the PRIOR
+ * turns in its conversation history, so the model could still answer
+ * from history. History bleed makes a content-combination assertion
+ * useless as a coalescing probe.
+ *
+ * The distinguishing fact is whether a SINGLE turn saw all the parts in
+ * ONE incoming message. So we anchor the instruction on "this single
+ * message": three messages are fired near-simultaneously (so they land
+ * inside the default 500ms coalesce window), each carrying a distinct
+ * code token, and the instruction (in the last part) asks the agent to
+ * echo every token it received *in this one incoming message*.
+ *
+ *   - Coalesced  → the merged turn's single message contains ALPHA,
+ *     BRAVO and CHARLIE → the reply names all three.
+ *   - Fanned out → the message carrying the instruction contains only
+ *     its own token → the reply names just that one. (And the other
+ *     two tokens arrive as their own separate turns.)
+ *
+ * Tokens are deliberately odd uppercase strings so a substring match is
+ * unambiguous and won't collide with incidental words in the reply.
+ *
+ * Order-independence: the three sends are dispatched concurrently to
+ * guarantee they share a coalesce window, which means Telegram may
+ * deliver them in any order. We assert SET membership (all three
+ * present), never order.
+ */
+
+import { describe, it, expect } from "vitest";
+import { spinUp } from "../harness.js";
+import { pollUntil } from "../assertions.js";
+import type { ObservedMessage } from "../driver.js";
+
+const AGENT = "test-harness";
+
+// Distinctive code tokens — unlikely to appear incidentally in a reply.
+const TOKENS = ["ALPHA", "BRAVO", "CHARLIE"] as const;
+
+const BURST: string[] = [
+  `BURST-PROBE part 1 of 3. Code token: ${TOKENS[0]}.`,
+  `BURST-PROBE part 2 of 3. Code token: ${TOKENS[1]}.`,
+  `BURST-PROBE part 3 of 3. Code token: ${TOKENS[2]}. ` +
+    `Reply with ONLY the BURST-PROBE code tokens contained in THIS SINGLE ` +
+    `incoming message, slash-separated. If this message contains just one ` +
+    `token, reply with only that token.`,
+];
+
+// Generous budget: TTFO on the test-harness is ~7s warm; coalescing
+// adds the (sub-second) window plus normal model latency.
+const ANSWER_TIMEOUT_MS = 40_000;
+
+function tokensIn(text: string): string[] {
+  const upper = text.toUpperCase();
+  return TOKENS.filter((t) => upper.includes(t));
+}
+
+describe("uat: forwarded burst / split paste coalesces into one turn", () => {
+  it(
+    "a 3-message burst is answered as ONE shared-context turn",
+    async () => {
+      const sc = await spinUp({ agent: AGENT });
+      try {
+        // Start observing BEFORE the burst — observeMessages only sees
+        // live updates, not history. Drain into a per-message-id map so
+        // streamed edits collapse to the message's latest text.
+        const latestById = new Map<number, ObservedMessage>();
+        const stream = sc.driver.observeMessages(sc.botUserId);
+        const consume = (async () => {
+          for await (const m of stream) {
+            if (m.senderUserId === sc.driverUserId) continue; // skip our own sends
+            latestById.set(m.messageId, m);
+          }
+        })();
+
+        // Fire all three concurrently so they share one coalesce window.
+        // Concurrency (not serial awaits) is what keeps inter-arrival
+        // under the 500ms default — three serial round-trips could blow
+        // the window on a slow link.
+        await Promise.all(BURST.map((t) => sc.sendDM(t)));
+
+        // Wait until a single bot message names all three tokens — the
+        // proof that one turn saw the whole burst in one incoming
+        // message.
+        const allThree = await pollUntil(
+          () => {
+            for (const m of latestById.values()) {
+              if (tokensIn(m.text).length === TOKENS.length) return m;
+            }
+            return undefined;
+          },
+          { timeout: ANSWER_TIMEOUT_MS, interval: 500 },
+        ).catch(() => undefined);
+
+        // Close the observer stream.
+        await stream[Symbol.asyncIterator]().return?.(undefined as never);
+        await consume;
+
+        const botMsgs = [...latestById.values()];
+        const tokenBearing = botMsgs.filter((m) => tokensIn(m.text).length > 0);
+
+        if (!allThree) {
+          const seen = tokenBearing
+            .map((m) => `#${m.messageId}=[${tokensIn(m.text).join(",")}]`)
+            .join(" ");
+          throw new Error(
+            `[forwarded-burst] No single bot reply named all of ` +
+              `${TOKENS.join("/")}. This is the coalescing regression: the ` +
+              `burst fanned out into separate turns so no turn saw the full ` +
+              `message. Token-bearing replies: ${seen || "(none)"}.`,
+          );
+        }
+
+        expect(tokensIn(allThree.text).sort()).toEqual([...TOKENS].sort());
+
+        // Forensic: a coalesced burst should produce ONE answer that
+        // names the tokens. Several token-bearing replies hint at a
+        // partial fan-out even though one of them happened to be
+        // complete — worth a warning before it becomes a hard failure.
+        if (tokenBearing.length > 1) {
+          console.warn(
+            `[forwarded-burst] ${tokenBearing.length} token-bearing replies ` +
+              `observed (expected 1). Possible partial fan-out: ` +
+              tokenBearing
+                .map((m) => `#${m.messageId}=[${tokensIn(m.text).join(",")}]`)
+                .join(" "),
+          );
+        } else {
+          console.log(
+            `[forwarded-burst] One shared-context reply named all tokens ` +
+              `(#${allThree.messageId}). Coalescing healthy.`,
+          );
+        }
+      } finally {
+        await sc.tearDown();
+      }
+    },
+    ANSWER_TIMEOUT_MS + 20_000,
+  );
+});

package/telegram-plugin/uat/scenarios/jtbd-memory-survives-restart-dm.test.ts

@@ -53,9 +53,24 @@ import { describe, it, expect, beforeAll } from "vitest";
 import { execSync } from "node:child_process";
 import { randomBytes } from "node:crypto";
 import { spinUp } from "../harness.js";
+import { isActivityFeedMessage, isWorkerFeedMessage } from "../assertions.js";
+import type { ObservedMessage } from "../driver.js";
 
 const AGENT = "test-harness";
 
+// Two classes of bot message are NOT the agent's reply and must be
+// skipped, or a bare `/\S/` matcher latches onto them and the
+// verbatim-token check fails against noise instead of catching a real
+// memory miss:
+//   1. The worker-activity feed (#2000, default-on since v0.14.19) — a
+//      stray background sub-agent posts `🔧 Worker · …` into this DM.
+//   2. The tool-activity feed — on a turn that uses tools (memory recall
+//      does), `→ Finding the right tool` paints as its own message before
+//      the real answer lands.
+// Match the first non-empty bot reply that is neither.
+const isReply = (m: ObservedMessage): boolean =>
+  /\S/.test(m.text) && !isWorkerFeedMessage(m) && !isActivityFeedMessage(m);
+
 const RESTART_BUDGET_MS = 90_000;
 const CAPTURE_REPLY_BUDGET_MS = 60_000;
 const RECALL_REPLY_BUDGET_MS = 120_000;
@@ -139,7 +154,7 @@ const sudoOk = canShellSudo();
             `(This is a memory-survival UAT — store it via hindsight.)`,
           );
 
-          const captureReply = await sc1.expectMessage(/\S/, {
+          const captureReply = await sc1.expectMessage(isReply, {
             from: "bot",
             timeout: CAPTURE_REPLY_BUDGET_MS,
           });
@@ -180,7 +195,7 @@ const sudoOk = canShellSudo();
             `Reply with the token only, no extra text.`,
           );
 
-          const recallReply = await sc2.expectMessage(/\S/, {
+          const recallReply = await sc2.expectMessage(isReply, {
             from: "bot",
             timeout: RECALL_REPLY_BUDGET_MS + 5_000,
           });

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

@@ -25,15 +25,21 @@
  *   - 429 cooldown + message_id drift resilience (re-post on stale edit),
  *   - a forced terminal edit on `finish` regardless of throttle.
  *
- * The feed is gated to BACKGROUND workers and lives behind the
- * `SWITCHROOM_WORKER_ACTIVITY_FEED` flag — see the gateway wiring. The
- * watcher already drives the cues (it polls the worker jsonl directly,
- * so it keeps firing after the parent turn ends), which is why the feed
- * is fed from watcher callbacks rather than the bridge event stream.
+ * The feed is gated to BACKGROUND workers and is ON by default; set
+ * `SWITCHROOM_WORKER_ACTIVITY_FEED=0` to disable it — see the gateway
+ * wiring. The watcher already drives the cues (it polls the worker jsonl
+ * directly, so it keeps firing after the parent turn ends), which is why
+ * the feed is fed from watcher callbacks rather than the bridge event stream.
  */
 
 import { escapeHtml, formatDuration, truncate } from './card-format.js'
 
+/** Worker-activity feed is ON by default; an operator opts out with
+ *  SWITCHROOM_WORKER_ACTIVITY_FEED=0. */
+export function isWorkerActivityFeedEnabled(envVal: string | undefined): boolean {
+  return envVal !== '0'
+}
+
 export type WorkerActivityState = 'running' | 'done' | 'failed'
 
 /** The render-relevant snapshot of a worker at one instant. */
@@ -46,6 +52,14 @@ export interface WorkerActivityView {
   toolCount: number
   /** The worker's latest narrative line, if any (already capped upstream). */
   latestSummary: string
+  /**
+   * Accumulated narrative lines, oldest→newest, already deduped + capped by
+   * the feed manager. When present and non-empty, the render grows a block
+   * of `↳` lines (mirroring the main agent's live answer) instead of
+   * collapsing to the single `latestSummary` line. Absent/empty → the
+   * single-line fallback (back-compat for direct render callers).
+   */
+  narrativeLines?: string[]
   /** Wall-clock since dispatch, ms. */
   elapsedMs: number
   state: WorkerActivityState
@@ -68,6 +82,13 @@ export interface BotApiForWorkerFeed {
 const DESC_MAX = 80
 const TOOL_ARG_MAX = 64
 const SUMMARY_MAX = 100
+/**
+ * How many trailing narrative lines the live feed keeps visible. The feed
+ * grows like the main agent's answer but can't grow unbounded — Telegram
+ * caps message length and a wall of stale lines buries the live one. Six
+ * keeps recent context without dominating the chat.
+ */
+const NARRATIVE_MAX_LINES = 6
 
 /**
  * Render the worker-activity message body as Telegram HTML.
@@ -105,10 +126,23 @@ export function renderWorkerActivity(v: WorkerActivityView): string {
     activity = `<i>starting… (${elapsed})</i>`
   }
 
-  const summary = v.latestSummary.trim()
   const lines = [header, activity]
-  if (summary.length > 0) {
-    lines.push(`  ↳ <i>${escapeHtml(truncate(summary, SUMMARY_MAX))}</i>`)
+
+  // Growing narrative block when the manager has accumulated lines; the feed
+  // reads like the main agent's live answer rather than a single replaced
+  // status line. Fall back to the single latestSummary line otherwise.
+  const narrative = (v.narrativeLines ?? [])
+    .map((s) => s.trim())
+    .filter((s) => s.length > 0)
+  if (narrative.length > 0) {
+    for (const line of narrative) {
+      lines.push(`  ↳ <i>${escapeHtml(truncate(line, SUMMARY_MAX))}</i>`)
+    }
+  } else {
+    const summary = v.latestSummary.trim()
+    if (summary.length > 0) {
+      lines.push(`  ↳ <i>${escapeHtml(truncate(summary, SUMMARY_MAX))}</i>`)
+    }
   }
   return lines.join('\n')
 }
@@ -142,6 +176,12 @@ interface WorkerHandle {
   lastBody: string | null
   lastEditAt: number
   cooldownUntil: number
+  /**
+   * Accumulated narrative lines (oldest→newest), deduped against the
+   * immediately-preceding line and capped to NARRATIVE_MAX_LINES. Grows the
+   * live render so the feed reads like the main agent's answer.
+   */
+  narrative: string[]
   /** Per-worker serialization chain so ticks can't interleave sends. */
   chain: Promise<void>
 }
@@ -203,9 +243,24 @@ export function createWorkerActivityFeed(opts: WorkerActivityFeedOpts): WorkerAc
     log(`worker-feed: ${label} 429 — backing off ${retryAfter}s`)
   }
 
+  function accumulateNarrative(h: WorkerHandle, view: WorkerActivityView): void {
+    const line = view.latestSummary.trim()
+    if (line.length === 0) return
+    // Dedup against the immediately-preceding line — the watcher re-emits the
+    // same narrative across ticks while a tool runs; we only grow on change.
+    if (h.narrative[h.narrative.length - 1] === line) return
+    h.narrative.push(line)
+    if (h.narrative.length > NARRATIVE_MAX_LINES) {
+      h.narrative.splice(0, h.narrative.length - NARRATIVE_MAX_LINES)
+    }
+  }
+
   async function doUpdate(h: WorkerHandle, view: WorkerActivityView): Promise<void> {
+    // Accumulate before any gate so a throttled/cooled-down tick still grows
+    // the narrative — the line surfaces on the next edit that does fire.
+    accumulateNarrative(h, view)
     if (nowFn() < h.cooldownUntil) return
-    const body = renderWorkerActivity(view)
+    const body = renderWorkerActivity({ ...view, narrativeLines: h.narrative })
 
     // First paint: hold off until the worker has run long enough to be
     // worth a message; trivial workers stay silent (handback covers them).
@@ -284,6 +339,7 @@ export function createWorkerActivityFeed(opts: WorkerActivityFeedOpts): WorkerAc
           lastBody: null,
           lastEditAt: 0,
           cooldownUntil: 0,
+          narrative: [],
           chain: Promise.resolve(),
         }
         handles.set(agentId, h)