switchroom 0.19.18 → 0.19.22

package/telegram-plugin/tests/vault-request-access-unlock-resume.test.ts

@@ -34,6 +34,19 @@ const gatewaySrc =
   // P7 PR-8 (#2996): vault pending-op intercept moved to inbound-interceptors.ts.
   readFileSync(resolve(__dirname, '..', 'gateway', 'inbound-interceptors.ts'), 'utf-8')
 
+/**
+ * #3627 extracted the prompt COPY into `buildAccessPassphrasePromptText` and
+ * the prompt SEND into `sendAccessPassphrasePrompt`, so both the first prompt
+ * and the wrong-passphrase re-prompt share one implementation. The pins below
+ * anchor on those two blocks instead of the inline text they replaced.
+ */
+const promptBuilder =
+  gatewaySrc
+    .split('export function buildAccessPassphrasePromptText')[1]
+    ?.split('export function createCallbackQueryHandlers')[0] ?? ''
+const promptSender =
+  gatewaySrc.split('async function sendAccessPassphrasePrompt')[1]?.split('\n/**')[0] ?? ''
+
 describe('vault_request_access — tap-to-unlock-and-approve UX', () => {
   it('declares the passphrase-for-access-approve PendingVaultOp variant', () => {
     // fails when: the new PendingVaultOp kind is dropped. The
@@ -54,8 +67,11 @@ describe('vault_request_access — tap-to-unlock-and-approve UX', () => {
     expect(approveBlock).toMatch(/pendingVaultOps\.set/)
     expect(approveBlock).toMatch(/passphrase-for-access-approve/)
     // Card text must invite a passphrase reply, not punt to a
-    // /vault unlock detour.
-    expect(approveBlock).toMatch(/Reply with your passphrase/i)
+    // /vault unlock detour. #3627 moved the body into the shared
+    // `buildAccessPassphrasePromptText` builder, so the copy pin lives
+    // there now; the approve block must still route into it.
+    expect(approveBlock).toMatch(/sendAccessPassphrasePrompt\(/)
+    expect(promptBuilder).toMatch(/Reply with your passphrase/i)
     // The "ask the agent to re-issue the request card" copy belonged
     // to the pre-fix path. Should be gone from the cache-miss branch.
     expect(approveBlock).not.toMatch(/ask the agent to re-issue the request card/)
@@ -67,12 +83,14 @@ describe('vault_request_access — tap-to-unlock-and-approve UX', () => {
     // edit fires no notification and stays stapled to the card's old
     // position, so a busy topic buries it and the operator never sees
     // the passphrase ask (the reported v0.16.45 admin-key miss). The
-    // prompt must be a fresh `sendRichMessage` below.
-    const approveBlock =
-      gatewaySrc.split('if (action === \'approve\')')[1]?.split('await ctx.answerCallbackQuery({ text: \'Unknown action\'')[0] ?? ''
+    // prompt must be a fresh `sendRichMessage` (#3627: from the shared
+    // `sendAccessPassphrasePrompt` helper, used by BOTH the first
+    // prompt and the wrong-passphrase re-prompt).
     // A distinct passphrase-prompt send exists (verb-tagged).
-    expect(approveBlock).toMatch(/sendRichMessage\(pending\.chat_id, richMessage\(promptText\)/)
-    expect(approveBlock).toMatch(/vault_request_access\.passphrase_prompt/)
+    expect(promptSender).toMatch(/sendRichMessage\(target\.chat_id, richMessage\(promptText\)/)
+    expect(promptSender).toMatch(/vault_request_access\.passphrase_prompt/)
+    // And it is never an in-place edit of the original card.
+    expect(promptSender).not.toMatch(/editMessageText/)
   })
 
   it('passphrase prompt renders via richMessage — no raw literal-markdown edit', () => {
@@ -86,25 +104,26 @@ describe('vault_request_access — tap-to-unlock-and-approve UX', () => {
     const approveBlock =
       gatewaySrc.split('if (action === \'approve\')')[1]?.split('await ctx.answerCallbackQuery({ text: \'Unknown action\'')[0] ?? ''
     // The prompt text is assembled once and wrapped in richMessage.
-    expect(approveBlock).toMatch(/const promptText =/)
+    expect(promptSender).toMatch(/const promptText = buildAccessPassphrasePromptText\(spec\)/)
     // Regression guard: the old raw-string admin-only edit copy is gone.
     expect(approveBlock).not.toMatch(/requires your vault passphrase to grant/)
     // Regression guard: no string-concatenated richMessage() object
-    // (the "[object Object]" bug) remains.
-    expect(approveBlock).not.toMatch(/\+\s*\n\s*richMessage\(/)
+    // (the "[object Object]" bug) remains — anywhere in the vault
+    // callback source, not just the approve block (#3627 fixed the
+    // last surviving instance, the standing-ACL resolution edit).
+    expect(gatewaySrc).not.toMatch(/\+\s*\n\s*richMessage\(/)
   })
 
   it('passphrase prompt is attention-grabbing and does NOT suppress notifications', () => {
     // fails when: the prompt loses its strong header or someone adds
     // disable_notification to it. The whole point of the fix is that
     // the operator gets PINGED — a silent prompt is the bug.
-    const approveBlock =
-      gatewaySrc.split('if (action === \'approve\')')[1]?.split('await ctx.answerCallbackQuery({ text: \'Unknown action\'')[0] ?? ''
-    expect(approveBlock).toMatch(/ACTION NEEDED: passphrase required/)
+    // #3627: 🚨 (not ⚠️) leads the header — this blocks an approval the
+    // operator already tapped, so it outranks a generic warning.
+    expect(promptBuilder).toMatch(/\*\*🚨🔐 ACTION NEEDED: passphrase required\*\*/)
+    expect(promptBuilder).not.toMatch(/⚠️🔐 ACTION NEEDED/)
     // The send options for the prompt must not carry disable_notification.
-    const promptSend =
-      approveBlock.split('const promptText =')[1]?.split('return')[0] ?? ''
-    expect(promptSend).not.toMatch(/disable_notification/)
+    expect(promptSender).not.toMatch(/disable_notification/)
   })
 
   it('passphrase intercept deletes the chat message and resumes mint', () => {
@@ -140,20 +159,22 @@ describe('vault_request_access — tap-to-unlock-and-approve UX', () => {
     expect(handlerBlock).toMatch(/editMessageText/)
   })
 
-  it('mint failure (e.g. wrong passphrase) edits the card; does not silent-drop', () => {
+  it('mint failure (non-passphrase) edits the card; does not silent-drop', () => {
     // fails when: performVaultAccessApproval's error branch returns
-    // without editing the card. Without the edit, a wrong-passphrase
+    // without editing the card. Without the edit, a failed mint
     // attempt leaves the locked-vault prompt on screen forever and
     // the operator can't tell whether the system saw their reply.
     //
     // Anchor: performVaultAccessApproval's `result.kind === 'error'`
-    // branch.
+    // branch. #3627: a PASSPHRASE-MISMATCH error now returns early for
+    // the retry loop; everything else keeps the terminal edit + drop.
     const mintHelper =
       gatewaySrc.split('async function performVaultAccessApproval')[1]?.split('async function handleVaultRequestAccessCallback')[0] ?? ''
     expect(mintHelper).toMatch(/result\.kind === 'error'/)
     // After error: card edited AND pending entry dropped (no
-    // zombie staged request).
-    expect(mintHelper).toMatch(/editMessageText[\s\S]{0,400}mint_grant failed/)
+    // zombie staged request). The edit goes through `editResolvedCard`,
+    // which falls back to a fresh message when the edit itself fails.
+    expect(mintHelper).toMatch(/editResolvedCard[\s\S]{0,400}mint_grant failed/)
     expect(mintHelper).toMatch(/pendingVaultRequestAccesses\.delete/)
   })
 })

package/telegram-plugin/tests/worker-feed-coalesce.test.ts

@@ -1,11 +1,15 @@
 import { describe, expect, it } from 'vitest'
 import {
   createWorkerActivityFeed,
+  renderWorkerActivity,
   type BotApiForWorkerFeed,
   type WorkerActivityView,
 } from '../worker-activity-feed.js'
 import { renderCombinedWorkerFeed, combinedHistoryDepth } from '../tool-activity-summary.js'
-import { STATUS_CARD_CHAR_BUDGET } from '../status-no-truncate.js'
+import { STATUS_CARD_CHAR_BUDGET, WORKER_STEP_INDENT } from '../status-no-truncate.js'
+import { COLLAPSE_SAFE_SEPARATOR } from '../card-format.js'
+import { richMessage } from '../rich-send.js'
+import { parseRichEntities, validateRichMarkdown } from './rich-markdown-oracle.js'
 import { createSendGate, isSendGateShed, type Clock } from '../send-gate.js'
 
 /**
@@ -1235,3 +1239,231 @@ describe('worker numbering — stable per-card ordinals end to end (#3298)', ()
     expect(h.edits.length).toBe(landed)
   })
 })
+
+// ── Per-worker step indent on the combined card ───────────────────────────────
+//
+// The multi-worker card put its `✓`/`→` step lines at the SAME left margin as
+// the numbered worker header lines, so where one worker ended and the next
+// began was invisible at a glance (operator report, 2026-07). Steps now nest
+// one level under their worker.
+//
+// The indent MUST be a U+2800 run. Card bodies go to Telegram as raw GFM
+// markdown (`richMessage` → `sendRichMessage` / `editMessageText({ markdown })`,
+// #2669) and are parsed server-side by a CommonMark/GFM-family parser that
+// LEFT-TRIMS a leading whitespace run — ASCII *and* Unicode. #3662 shipped three
+// U+00A0 and was inert: the bytes reached the Bot API intact and the card still
+// rendered flat, because U+00A0 is category Zs. U+2800 BRAILLE PATTERN BLANK is
+// category So — zero ink, non-zero width, not whitespace to any trimming rule —
+// and was live-verified on a phone on 2026-07-26.
+//
+// So these tests assert the indent's CHARACTER PROPERTY as well as its bytes: a
+// byte-only assertion is exactly what let #3662 ship green while broken.
+describe('combined worker card — steps indent under their worker (U+2800)', () => {
+  /** The indent glyph. */
+  const BLANK = '\u2800'
+  /** The #3666 pinned-bar collapse separator — TRAILING, structurally distinct. */
+  const NBSP = '\u00A0'
+  const rowsFor = (n: number) =>
+    Array.from({ length: n }, (_, i) => ({
+      description: `worker task ${i + 1}`,
+      elapsedMs: 60_000 * (i + 1),
+      toolCount: 3,
+      ordinal: i + 1,
+      currentStep: `w${i + 1} step b`,
+      historyLines: [`w${i + 1} step a`, `w${i + 1} step b`],
+    }))
+
+  /** Card lines as sent (the body is hard-break joined by stackCardLines). */
+  const linesOf = (body: string) => body.split('\n').map((l) => l.replace(/[ \t]+$/, ''))
+
+  it('every step line starts with the U+2800 indent; header and chrome lines do not', () => {
+    const body = renderCombinedWorkerFeed(rowsFor(3), { maxRows: 8 })!
+    const lines = linesOf(body)
+    const stepLines = lines.filter((l) => l.includes('✓ w') || l.includes('→ w'))
+    const headerLines = lines.filter((l) => /\*\*\d\. worker task/.test(l))
+
+    expect(stepLines.length).toBe(6) // 3 workers × 2 steps
+    expect(headerLines.length).toBe(3)
+    // Load-bearing: the exact indent bytes. `WORKER_STEP_INDENT` is U+2800 ×3;
+    // a plain-ASCII `'   '` indent fails this assertion, so does the U+00A0 run
+    // #3662 shipped, and so does flat output with no prefix at all.
+    for (const l of stepLines) {
+      expect(l.startsWith(WORKER_STEP_INDENT)).toBe(true)
+      expect(l.startsWith(BLANK)).toBe(true)
+      expect(l.startsWith(' ')).toBe(false)
+      expect(l.startsWith(NBSP)).toBe(false)
+    }
+    // Workers stay at the left margin so the nesting reads as nesting.
+    for (const l of headerLines) expect(l.startsWith(BLANK)).toBe(false)
+    expect(lines[0].startsWith('🛠')).toBe(true)
+  })
+
+  it('golden body — each worker header is immediately followed by ITS indented steps', () => {
+    // The assertions above are set-membership only: they count step lines and
+    // header lines and check prefixes independently, so a refactor that emitted
+    // all three headers and THEN all six steps — nesting completely destroyed —
+    // would still pass every one of them. This pins the full line ORDER, which
+    // is the actual thing the fix is for: a step must sit under its own worker.
+    const body = renderCombinedWorkerFeed(rowsFor(3), { maxRows: 8 })!
+    const I = WORKER_STEP_INDENT
+    // `S` is the pinned-bar collapse separator (#3666): every line that is
+    // followed by a hard break carries one trailing U+00A0 so the pinned-message
+    // bar (which drops the newline and substitutes nothing) does not mash the
+    // last glyph of a line into the first glyph of the next. It is TRAILING and
+    // exactly one char — structurally distinct from the LEADING three-char
+    // `WORKER_STEP_INDENT`, which is what this golden is really pinning.
+    const S = COLLAPSE_SAFE_SEPARATOR
+    expect(linesOf(body)).toEqual([
+      `🛠 **Workers** · _3 running · oldest 3m00s · 9 tools_${S}`,
+      `**1. worker task 1** _· 1m00s · 3 tools_${S}`,
+      `${I}~~_✓ w1 step a_~~${S}`,
+      `${I}**→ w1 step b**${S}`,
+      `**2. worker task 2** _· 2m00s · 3 tools_${S}`,
+      `${I}~~_✓ w2 step a_~~${S}`,
+      `${I}**→ w2 step b**${S}`,
+      `**3. worker task 3** _· 3m00s · 3 tools_${S}`,
+      `${I}~~_✓ w3 step a_~~${S}`,
+      `${I}**→ w3 step b**`, // last line: nothing follows it to collide with
+    ])
+  })
+
+  // ── The assertion that would have caught #3662 ──────────────────────────
+  //
+  // Every OTHER test in this file (and in pinned-card-collapse.test.ts) asserts
+  // the string we hand the Bot API. #3662 shipped a U+00A0 indent that passed
+  // ALL of them and still rendered dead flat on a phone, because the stripping
+  // happens SERVER-SIDE: Telegram's CommonMark-family parser left-trims an
+  // inline whitespace run at the head of a content line, and U+00A0 is Unicode
+  // whitespace (category Zs). A byte assertion cannot observe that.
+  //
+  // So assert the PROPERTY that decides the outcome instead of the bytes: the
+  // indent must not be composed of characters that ANY whitespace-trimming rule
+  // — ASCII `/\s/`, Unicode `White_Space`, or category `Zs` — can classify as
+  // whitespace. U+2800 BRAILLE PATTERN BLANK qualifies: category So (Symbol,
+  // other), zero ink, non-zero width. Live-verified on a phone 2026-07-26.
+  const isTrimmableWhitespace = (ch: string) =>
+    /\s/u.test(ch) || /\p{White_Space}/u.test(ch) || /\p{Zs}/u.test(ch)
+
+  it('WORKER_STEP_INDENT is not Unicode whitespace — a Zs indent is trimmed server-side', () => {
+    const chars = [...WORKER_STEP_INDENT]
+    // Pin the WIDTH too: a single blank char reads as near-flat on a phone and
+    // would silently undo this fix while keeping the character class green.
+    expect(chars.length).toBe(3)
+    for (const ch of chars) {
+      const cp = `U+${ch.codePointAt(0)!.toString(16).toUpperCase().padStart(4, '0')}`
+      expect(
+        isTrimmableWhitespace(ch),
+        `WORKER_STEP_INDENT contains ${cp}, which is Unicode whitespace (\\s / White_Space / Zs). ` +
+          `Telegram parses card bodies server-side and LEFT-TRIMS a leading whitespace run, so this ` +
+          `indent renders FLAT on a phone — exactly the #3662 failure this test exists to catch ` +
+          `(#3662 shipped three U+00A0; the bytes reached the Bot API intact and the card was still ` +
+          `flat). The indent must be a zero-ink glyph that is NOT whitespace-categorised: use U+2800 ` +
+          `BRAILLE PATTERN BLANK (category So), live-verified on a real phone 2026-07-26.`,
+      ).toBe(false)
+    }
+  })
+
+  it('the whitespace predicate actually rejects every plausible wrong choice', () => {
+    // A property assertion is only worth having if the property discriminates.
+    // These are the characters a future edit would reach for as "a blank-looking
+    // indent"; every one is ASCII space/tab or category Zs, and every one is
+    // left-trimmed server-side.
+    const flatOnAPhone = [
+      ' ', // ASCII SPACE
+      '\t', // TAB
+      '\u00A0', // NO-BREAK SPACE — what #3662 shipped
+      '\u2002', // EN SPACE
+      '\u2003', // EM SPACE
+      '\u2007', // FIGURE SPACE
+      '\u200A', // HAIR SPACE
+      '\u3000', // IDEOGRAPHIC SPACE
+    ]
+    for (const bad of flatOnAPhone) expect(isTrimmableWhitespace(bad)).toBe(true)
+    // …and it accepts the one we ship.
+    expect(isTrimmableWhitespace('\u2800')).toBe(false)
+  })
+
+  it('WORKER_STEP_INDENT is exactly three U+2800 BRAILLE PATTERN BLANK', () => {
+    // Byte pin, the companion to the property test above: that one says "not
+    // whitespace", this one says "the specific glyph we live-tested".
+    expect(WORKER_STEP_INDENT).toBe('\u2800'.repeat(3))
+    expect(/^[\u2800]+$/.test(WORKER_STEP_INDENT)).toBe(true)
+    // And not a GFM block-structure lead-in: a leading `·` was also tried live
+    // and Telegram promoted it to a real list bullet, which breaks the
+    // `stackCardLines` precondition that card lines are never block-structure
+    // lines (card-format.ts) — the next worker header gets absorbed as a lazy
+    // continuation.
+    expect(/^[-*+>|#·]/.test(WORKER_STEP_INDENT)).toBe(false)
+  })
+
+  it('the `starting…` placeholder line is indented too', () => {
+    const body = renderCombinedWorkerFeed(
+      [
+        { description: 'fresh worker', elapsedMs: 1000, toolCount: 0, ordinal: 1, currentStep: '' },
+        ...rowsFor(1),
+      ],
+      { maxRows: 8 },
+    )!
+    const starting = linesOf(body).find((l) => l.includes('starting…'))!
+    expect(starting).toBeDefined()
+    expect(starting.startsWith(WORKER_STEP_INDENT)).toBe(true)
+    expect(starting.startsWith(BLANK)).toBe(true)
+  })
+
+  it('the indent survives the real outbound guard chain byte-for-byte and stays parseable', () => {
+    const body = renderCombinedWorkerFeed(rowsFor(3), { maxRows: 8 })!
+    // `richMessage` is the ONE adapter every `{ markdown }` wire send funnels
+    // through (rich-send.ts) — it must not escape, strip, or rewrite the indent.
+    const wire = richMessage(body).markdown
+    expect(wire).toBe(body)
+    expect(wire.includes(`${WORKER_STEP_INDENT}**→ w1 step b**`)).toBe(true)
+    expect(wire.includes(`${BLANK}**→ w1 step b**`)).toBe(true)
+    // Adding the indent introduced no fence/emphasis corruption.
+    //
+    // Scope, deliberately understated: `validateRichMarkdown` checks fence
+    // balance, unterminated inline code/links, and emphasis pairing ONLY (see
+    // tests/rich-markdown-oracle.ts). It models NEITHER leading-whitespace
+    // stripping NOR indented code blocks, so a regression to four ASCII spaces
+    // would ALSO return `[]` here. This is NOT rendering evidence and must not
+    // be read as proof that the indent survives Telegram's parser — that
+    // question is server-side and unobservable from this repo (see the honest
+    // limit note on WORKER_STEP_INDENT in status-no-truncate.ts). The byte
+    // assertions above are what discriminate an ASCII indent.
+    expect(validateRichMarkdown(wire)).toEqual([])
+    // …and the indent stays OUTSIDE the markdown spans — it must not land
+    // inside an emphasis run (which would style the blanks). Note this checks
+    // OUR OWN capture regexes in the oracle, not Telegram's real entity
+    // offsets; it pins where we place the indent relative to the `**`/`~~`
+    // delimiters, which is the part this repo actually controls.
+    const ents = parseRichEntities(wire)
+    expect(ents.some((e) => e.type === 'bold' && e.text === '→ w1 step b')).toBe(true)
+    expect(ents.some((e) => e.type === 'strikethrough' && e.text === '_✓ w1 step a_')).toBe(true)
+    expect(ents.every((e) => !e.text.includes(BLANK))).toBe(true)
+    expect(ents.every((e) => !e.text.includes(NBSP))).toBe(true)
+  })
+
+  it('the SINGLE-worker 🛠 card is untouched (no indent on its step lines)', () => {
+    const single = renderWorkerActivity({
+      workerId: 'w1',
+      description: 'lone worker',
+      latestSummary: 'step b',
+      narrativeLines: ['step a', 'step b'],
+      elapsedMs: 60_000,
+      toolCount: 3,
+      state: 'running',
+    })
+    expect(single).toContain('~~_✓ step a_~~')
+    expect(single).toContain('**→ step b**')
+    // No LEADING indent: the single-worker card has nothing to nest under, so
+    // its step lines must sit flush at the left margin. Asserted per line on the
+    // leading edge rather than as "no U+00A0 anywhere in the card", because
+    // #3666 puts one TRAILING U+00A0 on every hard-broken line of every pinned
+    // card (this one included) as the collapse separator. A regression that
+    // leaked WORKER_STEP_INDENT onto these lines still fails here.
+    for (const l of single.split('\n')) {
+      expect(l.startsWith(BLANK)).toBe(false)
+      expect(l.startsWith(NBSP)).toBe(false)
+      expect(l.startsWith(WORKER_STEP_INDENT)).toBe(false)
+    }
+  })
+})

package/telegram-plugin/tests/worker-feed-repeat-steps.test.ts

@@ -0,0 +1,147 @@
+import { describe, it, expect } from 'vitest'
+import {
+  createWorkerActivityFeed,
+  stripRepeatSuffix,
+  repeatCountOf,
+  type WorkerActivityView,
+  type BotApiForWorkerFeed,
+} from '../worker-activity-feed.js'
+
+/**
+ * A worker whose steps all carry the SAME label must still visibly advance.
+ *
+ * The bug (observed live 2026-07-25, klanker): `description` is optional on
+ * Bash, so a sub-agent that never wrote one produced the constant label
+ * "Running a command" for every call. `accumulateNarrative` dropped every
+ * repeat as a duplicate, and the card held ONE line at a constant byte length
+ * for the whole job — editMessageText kept succeeding, so the surface looked
+ * healthy while conveying nothing. A wedged worker and a busy worker rendered
+ * identically.
+ *
+ * The fix counts repeats (`·×N`) instead of discarding them, gated on
+ * `view.toolCount` so that a re-emitted UNCHANGED view (the watcher does this
+ * every tick) never inflates the count.
+ */
+
+function view(partial: Partial<WorkerActivityView> = {}): WorkerActivityView {
+  return {
+    description: 'fix the thing',
+    lastTool: { name: 'Bash', sanitisedArg: 'x' },
+    toolCount: 1,
+    latestSummary: 'Running a command',
+    elapsedMs: 10_000,
+    state: 'running',
+    ...partial,
+  }
+}
+
+interface FakeBot extends BotApiForWorkerFeed {
+  sent: Array<{ text: string }>
+  edits: Array<{ text: string }>
+}
+
+function makeFakeBot(): FakeBot {
+  let nextId = 1000
+  const fb: FakeBot = {
+    sent: [],
+    edits: [],
+    sendMessage: async (_chatId, text) => {
+      fb.sent.push({ text })
+      return { message_id: nextId++ }
+    },
+    editMessageText: async (_chatId, _messageId, text) => {
+      fb.edits.push({ text })
+      return {}
+    },
+  }
+  return fb
+}
+
+/** Latest rendered body for the group (last edit, else the first paint). */
+function latestBody(bot: FakeBot): string {
+  return bot.edits.length > 0 ? bot.edits[bot.edits.length - 1].text : bot.sent[0].text
+}
+
+describe('worker feed — repeated step labels', () => {
+  it('renders a climbing ·×N counter instead of freezing on one line', async () => {
+    const bot = makeFakeBot()
+    let clock = 0
+    const feed = createWorkerActivityFeed({ bot, now: () => clock, minEditIntervalMs: 0 })
+
+    for (let i = 1; i <= 5; i++) {
+      clock += 10_000
+      await feed.update('w1', 'chat', view({ toolCount: i, elapsedMs: clock }))
+    }
+
+    const body = latestBody(bot)
+    expect(body).toContain('Running a command ·×5')
+    // …and the frozen single-count line is gone from the newest render.
+    expect(body).not.toMatch(/Running a command\*{0,2}\s*$/m)
+  })
+
+  it('does NOT inflate the count when the watcher re-emits an unchanged view', async () => {
+    const bot = makeFakeBot()
+    let clock = 0
+    const feed = createWorkerActivityFeed({ bot, now: () => clock, minEditIntervalMs: 0 })
+
+    // Same toolCount across many ticks = the SAME tool call, re-observed.
+    for (let i = 0; i < 6; i++) {
+      clock += 5_000
+      await feed.update('w1', 'chat', view({ toolCount: 2, elapsedMs: clock }))
+    }
+
+    const body = latestBody(bot)
+    expect(body).toContain('Running a command')
+    expect(body).not.toContain('·×')
+  })
+
+  it('starts a NEW step (no counter) when the label actually changes', async () => {
+    const bot = makeFakeBot()
+    let clock = 0
+    const feed = createWorkerActivityFeed({ bot, now: () => clock, minEditIntervalMs: 0 })
+
+    clock += 10_000
+    await feed.update('w1', 'chat', view({ toolCount: 1, elapsedMs: clock }))
+    clock += 10_000
+    await feed.update('w1', 'chat', view({ toolCount: 2, elapsedMs: clock }))
+    clock += 10_000
+    await feed.update('w1', 'chat', view({ toolCount: 3, latestSummary: 'Running git status', elapsedMs: clock }))
+
+    const body = latestBody(bot)
+    expect(body).toContain('Running a command ·×2')
+    expect(body).toContain('Running git status')
+    expect(body).not.toContain('Running git status ·×')
+  })
+
+  it('keeps the non-adjacent A,B,A dedup (no duplicate step lines)', async () => {
+    const bot = makeFakeBot()
+    let clock = 0
+    const feed = createWorkerActivityFeed({ bot, now: () => clock, minEditIntervalMs: 0 })
+
+    const steps = ['Reading alpha.ts', 'Running grep', 'Reading alpha.ts']
+    for (const [i, summary] of steps.entries()) {
+      clock += 10_000
+      await feed.update('w1', 'chat', view({ toolCount: i + 1, latestSummary: summary, elapsedMs: clock }))
+    }
+
+    const body = latestBody(bot)
+    expect((body.match(/Reading alpha\.ts/g) ?? []).length).toBe(1)
+    // Non-adjacent repeats are dropped, not counted — the A,B,A duplication
+    // guard predates this change and stays intact.
+    expect(body).not.toContain('Reading alpha.ts ·×')
+  })
+})
+
+describe('repeat-suffix helpers', () => {
+  it('round-trips the marker', () => {
+    expect(stripRepeatSuffix('Running a command ·×12')).toBe('Running a command')
+    expect(stripRepeatSuffix('Running a command')).toBe('Running a command')
+    expect(repeatCountOf('Running a command')).toBe(1)
+    expect(repeatCountOf('Running a command ·×12')).toBe(12)
+  })
+
+  it('does not mistake ordinary text for a marker', () => {
+    expect(stripRepeatSuffix('Comparing 3 ×2 grids')).toBe('Comparing 3 ×2 grids')
+    expect(repeatCountOf('Comparing 3 ×2 grids')).toBe(1)
+  })
+})