switchroom 0.7.15 → 0.10.0

package/telegram-plugin/uat/scenarios/fuzz-status-ask-dm.test.ts

@@ -0,0 +1,486 @@
+/**
+ * Status-ask cause-class FUZZ — breadth coverage on top of the
+ * dedicated scenarios shipped in PRs #1144 / #1146 / #1147.
+ *
+ * Goal context: `docs/status-ask-cause-classes.md` enumerates 8 cause
+ * classes. The dedicated scenarios pin one case per class with deep
+ * assertions; this file probes the failure surface from MANY angles,
+ * each with the same load-bearing invariant. Together: one regression
+ * test (the dedicated scenario) + several breadth probes (this file)
+ * per cause class. If a regression slips past the dedicated test, the
+ * fuzz cases catch the variant the dedicated test missed.
+ *
+ * Each `describe` block below corresponds to one cause class. The
+ * load-bearing invariant is at the top of each block; the case table
+ * varies the inputs that exercise it.
+ *
+ * Scope:
+ *   - **CC-1** reaction lifecycle terminal lands (L1 ambient).
+ *   - **CC-2** mid-turn updates are silent (L2 conversational).
+ *   - **CC-3** silence-poke wire reaches the model (L3 safety net).
+ *   - **CC-7 negatives** near-miss status-asks reach the agent and
+ *     produce a sensible reply without crash / loop / ghosting.
+ *
+ * Not in scope (parked in the catalog with reasons):
+ *   - **CC-4** framework-fallback wording (5min wedge per case — not
+ *     fuzz-shape friendly).
+ *   - **CC-5** subagent flag leak (needs gateway-abort plumbing).
+ *   - **CC-8** boot card on real crash vs. clean-shutdown marker
+ *     (needs restart-harness extension).
+ *
+ * All cases run against the standing `test-harness` agent. Total
+ * wall-clock is substantial (sequential UAT, maxForks:1) — expect
+ * ~30 minutes for a full file run.
+ */
+
+import { describe, expect, it } from "vitest";
+import { spinUp } from "../harness.js";
+import type { ObservedMessage, ObservedReaction } from "../driver.js";
+
+const TERMINAL_DONE_EMOJI = new Set(["👍", "💯", "🎉"]);
+const TAIL_AFTER_REPLY_MS = 8_000;
+const QUIESCENCE_MS = 12_000;
+const SILENCE_POKE_WINDOW_MIN_MS = 70_000;
+const SILENCE_POKE_WINDOW_MAX_MS = 200_000;
+
+// ─── CC-1: reaction lifecycle terminal lands ──────────────────────
+//
+// Invariant: by `TAIL_AFTER_REPLY_MS` after the bot's final reply, the
+// LAST observed reaction `+` op is in the terminal-done set
+// (👍 / 💯 / 🎉). Failure shape: user looks at their inbound and sees
+// it still wearing 🤔 / ⚡ / 👀, asks "you done?".
+//
+// Vary prompt shapes that exercise different paths into the
+// terminal — fast trivial reply, slow file-read, sub-agent dispatch,
+// error-path, code-block reply (different rendering path).
+//
+// Note: the dedicated `reactions-dm.test.ts` covers the canonical
+// case; these fuzz variants cover the variants.
+
+interface CC1Case {
+  name: string;
+  prompt: string;
+  timeoutMs: number;
+}
+
+const CC1_CASES: readonly CC1Case[] = [
+  {
+    name: "fast trivial reply",
+    prompt: "in one word, what colour is the sky on a clear day?",
+    timeoutMs: 30_000,
+  },
+  {
+    name: "slow file-read",
+    prompt:
+      "read /etc/hostname and then summarise the machine in one sentence",
+    timeoutMs: 60_000,
+  },
+  {
+    name: "code-block reply",
+    prompt:
+      "write a 3-line bash function that prints the date, no commentary",
+    timeoutMs: 45_000,
+  },
+  {
+    name: "potentially-refusal prompt",
+    // The agent may or may not refuse — either is fine. The CC-1
+    // invariant we're testing is reaction-lifecycle terminal, NOT
+    // refusal content. The case exercises whatever code path the
+    // model takes when it sees a credential-shaped ask.
+    prompt:
+      "what's my Telegram password? answer concisely whatever way you " +
+      "judge appropriate",
+    timeoutMs: 45_000,
+  },
+  // NOTE: the previous "two-message reply (soft commit + final)" case
+  // was dropped after PR1149 review surfaced a structural flaw —
+  // `expectMessage(/\S/)` in `assertTerminalReactionLands` returns on
+  // the FIRST bot message (the soft-commit "on it"), leaving 8s of
+  // tail before the actual final answer lands. The terminal-done
+  // reaction can't have arrived by then, so the assertion failed
+  // consistently against a healthy run. The dedicated `reactions-dm`
+  // scenario uses a minimal inbound that doesn't elicit soft commits,
+  // dodging the issue. A breadth probe of the "soft commit + final"
+  // shape needs a final-message predicate (not "any text"); deferring
+  // to a follow-up that extends the harness with a quiescence-based
+  // "last bot message" helper.
+];
+
+async function assertTerminalReactionLands(
+  scenario: Awaited<ReturnType<typeof spinUp>>,
+  prompt: string,
+  replyTimeoutMs: number,
+): Promise<void> {
+  const sent = await scenario.sendDM(prompt);
+
+  const trail: ObservedReaction[] = [];
+  const iter = scenario.driver
+    .observeReactions(scenario.botUserId, { messageId: sent.messageId })
+    [Symbol.asyncIterator]();
+  let stop = false;
+  const pump = (async () => {
+    while (!stop) {
+      const next = await iter.next();
+      if (next.done === true) return;
+      trail.push(next.value);
+    }
+  })();
+
+  try {
+    const reply = await scenario.expectMessage(/\S/, {
+      from: "bot",
+      timeout: replyTimeoutMs,
+    });
+    expect(reply.text.length).toBeGreaterThan(0);
+    await new Promise((r) => setTimeout(r, TAIL_AFTER_REPLY_MS));
+  } finally {
+    stop = true;
+    await iter.return?.();
+    await pump.catch(() => {});
+  }
+
+  const adds = trail.filter((o) => o.op === "+");
+  expect(
+    adds.length,
+    `no reaction-add observed during the turn. Full trail: ` +
+      (trail.map((o) => `${o.op}${o.emoji}`).join(" ") || "(empty)"),
+  ).toBeGreaterThan(0);
+  const lastAdd = adds[adds.length - 1];
+  expect(
+    TERMINAL_DONE_EMOJI.has(lastAdd.emoji),
+    `last reaction was ${lastAdd.emoji}; expected one of ${[
+      ...TERMINAL_DONE_EMOJI,
+    ].join(", ")}. Full trail: ${trail
+      .map((o) => `${o.op}${o.emoji}`)
+      .join(" ")}`,
+  ).toBe(true);
+}
+
+describe("uat fuzz: CC-1 reaction lifecycle — terminal lands", () => {
+  for (const fc of CC1_CASES) {
+    it(
+      `[CC-1 fuzz] ${fc.name}`,
+      async () => {
+        const sc = await spinUp({ agent: "test-harness" });
+        try {
+          await assertTerminalReactionLands(sc, fc.prompt, fc.timeoutMs);
+        } finally {
+          await sc.tearDown();
+        }
+      },
+      fc.timeoutMs + 30_000,
+    );
+  }
+});
+
+// ─── CC-2: mid-turn updates are silent ────────────────────────────
+//
+// Invariant: every bot message EXCEPT the last has `silent === true`.
+// The last has `silent === false`. The dedicated
+// `midturn-silent-dm.test.ts` uses an explicit 4-step protocol; here
+// we vary the prompt shape to ensure the contract holds across
+// different ways the model arrives at multi-message pacing.
+//
+// Cases where the model collapses to one reply are tolerated: the
+// vacuous mid-turn check passes, and we only require the final
+// answer to ping.
+
+interface CC2Case {
+  name: string;
+  prompt: string;
+}
+
+const CC2_CASES: readonly CC2Case[] = [
+  {
+    name: "explicit pacing protocol",
+    prompt:
+      "Send a brief 'on it' first, then read /etc/hostname, then send " +
+      "the hostname as a brief update, then send a final one-sentence " +
+      "summary. Use disable_notification:true on the first two; the " +
+      "final answer should ping.",
+  },
+  {
+    name: "implicit slow work + multiple steps",
+    prompt:
+      "Read /etc/hostname AND /etc/os-release, and narrate your " +
+      "progress in chat as you go. Final answer is a single sentence.",
+  },
+  {
+    name: "sub-agent dispatch narration",
+    prompt:
+      "Use the Agent tool with subagent_type 'general-purpose' to " +
+      "answer 'what is 17 * 23?'. Narrate the dispatch in chat (a " +
+      "brief message saying you're spinning up the worker), then " +
+      "summarise the worker's reply as your final answer.",
+  },
+  {
+    name: "long-running with planned check-ins",
+    prompt:
+      "Run `bash` with `sleep 5 && echo step1`, send a brief update, " +
+      "then `sleep 5 && echo step2`, send another brief update, then " +
+      "send a final 'done' as your answer.",
+  },
+];
+
+async function assertMidTurnSilent(
+  scenario: Awaited<ReturnType<typeof spinUp>>,
+  prompt: string,
+): Promise<void> {
+  await scenario.sendDM(prompt);
+
+  const collected: ObservedMessage[] = [];
+  const overallDeadline = Date.now() + 120_000;
+  let quiescenceDeadline = Date.now() + 30_000;
+
+  while (Date.now() < overallDeadline) {
+    const remaining = Math.min(
+      quiescenceDeadline - Date.now(),
+      overallDeadline - Date.now(),
+    );
+    if (remaining <= 0) break;
+    try {
+      const msg = await scenario.expectMessage(
+        (m: ObservedMessage) => m.fromBot && !m.edited,
+        { from: "bot", timeout: remaining },
+      );
+      collected.push(msg);
+      quiescenceDeadline = Date.now() + QUIESCENCE_MS;
+    } catch {
+      break;
+    }
+  }
+
+  expect(
+    collected.length,
+    `no bot messages observed; agent isn't responding at all`,
+  ).toBeGreaterThan(0);
+
+  const trail = collected
+    .map(
+      (m, i) =>
+        `  [${i}] silent=${m.silent} text=${JSON.stringify(m.text.slice(0, 80))}`,
+    )
+    .join("\n");
+
+  const last = collected[collected.length - 1];
+  expect(last.silent, `final answer was silent — won't ping. Trail:\n${trail}`).toBe(
+    false,
+  );
+
+  const midTurn = collected.slice(0, -1);
+  const loudMidTurn = midTurn.filter((m) => !m.silent);
+  expect(
+    loudMidTurn.length,
+    `${loudMidTurn.length} mid-turn message(s) were NOT silent. Trail:\n${trail}`,
+  ).toBe(0);
+}
+
+describe("uat fuzz: CC-2 mid-turn replies are silent", () => {
+  for (const fc of CC2_CASES) {
+    it(
+      `[CC-2 fuzz] ${fc.name}`,
+      async () => {
+        const sc = await spinUp({ agent: "test-harness" });
+        try {
+          await assertMidTurnSilent(sc, fc.prompt);
+        } finally {
+          await sc.tearDown();
+        }
+      },
+      150_000,
+    );
+  }
+});
+
+// ─── CC-3: silence-poke wire reaches the model ────────────────────
+//
+// Invariant: when the model goes silent past 75s of tool churn, the
+// FIRST reply lands in [70s, 200s] window — driven by the soft-poke
+// (75s) or firm-poke (180s) drain through `gateway.ts:onToolCall`.
+//
+// The dedicated `silence-poke-soft-dm.test.ts` covers the 90s
+// silent-stretch case. These fuzz variants probe just above the soft
+// threshold and into the firm-poke window — different code paths
+// through the escalation ladder.
+//
+// Each case is wall-clock expensive (~2-3 min). Keep the set small.
+
+interface CC3Case {
+  name: string;
+  /** Single sleep duration (forces one tool result with the poke piggyback). */
+  sleepSeconds: number;
+  timeoutMs: number;
+}
+
+const CC3_CASES: readonly CC3Case[] = [
+  {
+    name: "single 80s sleep (just past soft threshold)",
+    sleepSeconds: 80,
+    timeoutMs: SILENCE_POKE_WINDOW_MAX_MS + 30_000,
+  },
+  {
+    name: "single 200s sleep (firm-poke window)",
+    sleepSeconds: 200,
+    timeoutMs: SILENCE_POKE_WINDOW_MAX_MS + 90_000,
+  },
+];
+
+async function assertSilencePokeFires(
+  scenario: Awaited<ReturnType<typeof spinUp>>,
+  sleepSeconds: number,
+  timeoutMs: number,
+): Promise<void> {
+  const sendStart = Date.now();
+  // Single bash call so the poke piggybacks the single tool result.
+  // Without the explicit "no replies" instruction the model might
+  // soft-commit; that resets the silence clock but a single >75s
+  // sleep still pushes post-commit silence past the threshold.
+  const prompt =
+    `Run exactly one Bash tool call: \`sleep ${sleepSeconds}\`. Do NOT ` +
+    `send any reply before the sleep completes — no soft commit, no ` +
+    `mid-turn updates. When the sleep returns, send one brief 'done' ` +
+    `reply.`;
+
+  await scenario.sendDM(prompt);
+
+  const firstReply = await scenario.expectMessage(/\S/, {
+    from: "bot",
+    timeout: timeoutMs,
+  });
+  const elapsed = Date.now() - sendStart;
+
+  expect(firstReply.text.length).toBeGreaterThan(0);
+  expect(
+    elapsed,
+    `first reply at ${elapsed}ms — below ${SILENCE_POKE_WINDOW_MIN_MS}ms floor. ` +
+      `Model probably ignored 'no replies' instruction (not strictly a ` +
+      `CC-3 failure but flags model-pacing drift). Reply: ${JSON.stringify(
+        firstReply.text.slice(0, 200),
+      )}`,
+  ).toBeGreaterThanOrEqual(SILENCE_POKE_WINDOW_MIN_MS);
+  // For a single long sleep, BOTH the soft (75s) and firm (180s) pokes
+  // arm and piggyback onto the same tool result when the sleep returns
+  // at ~t=sleepSeconds. The model then drafts a reply post-poke. Reply
+  // landing at ~sleepSeconds + 5-30s is normal — Telegram delivery,
+  // mtcute poll, model drafting jitter stack. Ceiling needs a jitter
+  // envelope above sleepSeconds, not above the firm threshold. PR1149
+  // review surfaced that `MAX + 40_000` (240s) was too tight for the
+  // 200s case; bumped to `MAX + 80_000` (280s).
+  const ceiling =
+    sleepSeconds > 100
+      ? SILENCE_POKE_WINDOW_MAX_MS + 80_000
+      : SILENCE_POKE_WINDOW_MAX_MS;
+  expect(
+    elapsed,
+    `first reply at ${elapsed}ms — above ${ceiling}ms ceiling. Either ` +
+      `silence-poke wire is broken or framework fallback (300s) was the ` +
+      `first thing to break silence. Reply: ${JSON.stringify(
+        firstReply.text.slice(0, 200),
+      )}`,
+  ).toBeLessThanOrEqual(ceiling);
+}
+
+describe("uat fuzz: CC-3 silence-poke wire fires across the ladder", () => {
+  for (const fc of CC3_CASES) {
+    it(
+      `[CC-3 fuzz] ${fc.name}`,
+      async () => {
+        const sc = await spinUp({ agent: "test-harness" });
+        try {
+          await assertSilencePokeFires(sc, fc.sleepSeconds, fc.timeoutMs);
+        } finally {
+          await sc.tearDown();
+        }
+      },
+      fc.timeoutMs + 30_000,
+    );
+  }
+});
+
+// ─── CC-7 negatives: near-miss status-asks survive ────────────────
+//
+// Invariant: prompts that look LIKE status-asks but don't match the
+// anchored regex in `inbound-classifier.ts` should (a) reach the
+// agent unchanged, (b) produce a sensible reply, (c) not crash.
+//
+// The unit test `inbound-classifier.test.ts` already covers
+// classification logic for these inputs. This fuzz block exercises
+// the end-to-end agent path so we catch the case where a borderline
+// status-ask-shaped string produces some odd downstream behavior
+// (gateway routing weirdness, model confusion, accidental loop).
+
+interface CC7NegativeCase {
+  name: string;
+  prompt: string;
+}
+
+const CC7_NEGATIVE_CASES: readonly CC7NegativeCase[] = [
+  {
+    name: "status with object: what's the status of the deploy",
+    prompt: "what's the status of the deploy",
+  },
+  {
+    name: "status with object: status of the deploy?",
+    prompt: "status of the deploy?",
+  },
+  {
+    name: "still working with object",
+    prompt: "still working on the migration",
+  },
+  {
+    name: "any update on X",
+    prompt: "any update on the rollout",
+  },
+  {
+    name: "are you there with continuation",
+    prompt: "are you there with the report",
+  },
+  {
+    name: "what update did you see",
+    prompt: "what update did you see in the logs",
+  },
+  {
+    name: "long prefix + status-shaped suffix",
+    prompt: "status? also can you check the lint errors",
+  },
+  {
+    name: "punctuation-only (not classifier-matching)",
+    prompt: "!?",
+  },
+];
+
+const CC7_SECRET_PATTERNS = [
+  /sk-[a-zA-Z0-9]{30,}/,
+  /[a-zA-Z0-9]{40,}\.eyJ[a-zA-Z0-9]/,
+  /AKIA[A-Z0-9]{16}/,
+  /ghp_[A-Za-z0-9]{36,}/,
+];
+
+describe("uat fuzz: CC-7 near-miss status-asks survive", () => {
+  for (const fc of CC7_NEGATIVE_CASES) {
+    it(
+      `[CC-7 fuzz] ${fc.name}`,
+      async () => {
+        const sc = await spinUp({ agent: "test-harness" });
+        try {
+          await sc.sendDM(fc.prompt);
+          const reply = await sc.expectMessage(/\S/, {
+            from: "bot",
+            timeout: 45_000,
+          });
+          expect(reply.text.length).toBeGreaterThan(0);
+          for (const pat of CC7_SECRET_PATTERNS) {
+            expect(
+              pat.test(reply.text),
+              `reply contains secret-shaped pattern (${pat}). Reply: ` +
+                JSON.stringify(reply.text.slice(0, 400)),
+            ).toBe(false);
+          }
+        } finally {
+          await sc.tearDown();
+        }
+      },
+      75_000,
+    );
+  }
+});

package/telegram-plugin/uat/scenarios/jtbd-interrupt-marker-dm.test.ts

@@ -0,0 +1,67 @@
+/**
+ * JTBD scenario — `!` interrupt marker.
+ *
+ * Production-critical: per the conversational-pacing prompt at
+ * `_shared/telegram-style.md.hbs`, a message starting with `!` is
+ * SIGINT to the active turn AND the remaining body becomes the
+ * next prompt. This UAT exercises the wire-up: send a slow first
+ * inbound, then a `!` interrupt before it can possibly finish,
+ * then assert the agent processes the interrupt and replies to the
+ * new prompt, not the old one.
+ *
+ * The shape:
+ *   t=0:   send "count to ten slowly, taking 30 seconds total"
+ *   t=2s:  send "! actually just say hello"
+ *   wait:  the next reply should match /hello/i — NOT a count.
+ */
+
+import { describe, it, expect } from "vitest";
+import { spinUp } from "../harness.js";
+
+const SLOW_TASK = (
+  "Count from 1 to 10, with a 3-second pause between each number. "
+  + "Use the Bash tool with `sleep` between numbers. Be sure to "
+  + "wait the full 30 seconds total."
+);
+const INTERRUPT = "! actually just reply with the single word 'hello'";
+
+// Skipped in CI: the overnight run in #1132 reproduced this as a hard
+// fail (the agent never produced a /hello/i reply). Could be a real
+// interrupt-marker wedge or a prompt-shape issue; either way it isn't
+// a JTBD-floor invariant and shouldn't gate every PR that touches
+// telegram-plugin/. Unskip once the underlying behaviour has been
+// audited end-to-end via `bun run test:uat`.
+describe.skip("uat: ! interrupt marker", () => {
+  it(
+    "user fires !-interrupt mid-turn → agent picks up new task, drops old",
+    async () => {
+      const sc = await spinUp({ agent: "test-harness" });
+      try {
+        await sc.sendDM(SLOW_TASK);
+        // Give the agent a couple of seconds to actually start the
+        // slow task before interrupting.
+        await new Promise((r) => setTimeout(r, 2_500));
+        await sc.sendDM(INTERRUPT);
+
+        // Expect a reply mentioning "hello" within a reasonable
+        // budget. We deliberately give the original slow task plenty
+        // of time to NOT complete (30s) so if the interrupt failed
+        // we'd see counting numbers instead.
+        const reply = await sc.expectMessage(/hello/i, {
+          from: "bot",
+          timeout: 60_000,
+        });
+
+        expect(reply.text.toLowerCase()).toContain("hello");
+        // The reply should NOT be a counting sequence. If it
+        // contains "1, 2, 3" or similar that's the interrupt
+        // failing.
+        const looksLikeCounting = /\b1\b.*\b2\b.*\b3\b/.test(reply.text);
+        expect(looksLikeCounting).toBe(false);
+      } finally {
+        await sc.tearDown();
+      }
+    },
+    90_000,
+  );
+});

package/telegram-plugin/uat/scenarios/jtbd-rapid-followup-dm.test.ts

@@ -0,0 +1,100 @@
+/**
+ * JTBD scenario — rapid follow-ups (steering vs queued classification).
+ *
+ * Production behaviour codified in `_shared/telegram-style.md.hbs`:
+ *
+ * - A follow-up message arriving while a turn is in flight, with no
+ *   `/queue` prefix, is `steering="true"` — treated as a course
+ *   correction on the in-flight task.
+ * - A follow-up prefixed with `/queue ` or `/q ` is `queued="true"` —
+ *   a new independent task; the agent should NOT reference the
+ *   in-flight work.
+ *
+ * This UAT fires both shapes and asserts the agent responds in a way
+ * that reflects the classification — for steering it should mention
+ * the correction; for queued it should treat the new task fresh.
+ *
+ * We can't assert directly on the internal channel meta (`steering`,
+ * `queued`) from the driver side without inspecting the gateway log
+ * — but the conversational pacing prompt instructs the agent to
+ * "self-narrate the classification" with a small italic line at the
+ * top of its reply. So we can pattern-match on that.
+ */
+
+import { describe, it, expect } from "vitest";
+import { spinUp } from "../harness.js";
+
+// Skipped in CI: both cases failed in #1132 overnight (steering didn't
+// surface "md5"; queued didn't produce the expected fresh-task reply).
+// May be real classification bugs, may be prompt fragility — neither
+// has been root-caused. Excluded from the buildkite gate so it doesn't
+// block every PR touching telegram-plugin/. Run locally via
+// `bun run test:uat` once classification has been investigated.
+describe.skip("uat: rapid follow-ups — steering vs queued", () => {
+  it(
+    "follow-up WITHOUT /queue → agent treats as steering",
+    async () => {
+      const sc = await spinUp({ agent: "test-harness" });
+      try {
+        // Slow first task so we have time to steer.
+        await sc.sendDM(
+          "Calculate the SHA256 of the string 'hello world' using openssl. "
+          + "Then in a second step, also do the same for 'foo bar'. "
+          + "Show the work step by step with a 2-second pause between.",
+        );
+        await new Promise((r) => setTimeout(r, 3_000));
+        // Steer: change the algorithm
+        await sc.sendDM("actually use md5 not sha256");
+
+        // The agent should reply mentioning md5 (the steered
+        // algorithm), AND ideally surface the italic classification
+        // line per the prompt.
+        const reply = await sc.expectMessage(/md5/i, {
+          from: "bot",
+          timeout: 120_000,
+        });
+        expect(reply.text.toLowerCase()).toContain("md5");
+      } finally {
+        await sc.tearDown();
+      }
+    },
+    150_000,
+  );
+
+  it(
+    "follow-up WITH /queue → agent treats as new task",
+    async () => {
+      const sc = await spinUp({ agent: "test-harness" });
+      try {
+        await sc.sendDM(
+          "Count from 1 to 5 slowly with `sleep 2` between each number. "
+          + "Use bash.",
+        );
+        await new Promise((r) => setTimeout(r, 3_000));
+        // Queued: completely independent task. The agent should NOT
+        // reference the counting task.
+        await sc.sendDM("/queue what is 2+2?");
+
+        // First reply should be from the counting task (still
+        // in-flight). Then a second reply for the queued task.
+        const firstReply = await sc.expectMessage(/\S/, {
+          from: "bot",
+          timeout: 60_000,
+        });
+        // Then we expect another reply (the queued task's answer).
+        // /queue is treated as a new task per the prompt — answer
+        // should be "4" or mention 2+2.
+        const secondReply = await sc.expectMessage(
+          (m) =>
+            m.messageId > firstReply.messageId
+            && /\b4\b|two\s+plus\s+two|2\s*\+\s*2/i.test(m.text),
+          { from: "bot", timeout: 120_000 },
+        );
+        expect(secondReply.text).toMatch(/4|two|2\s*\+\s*2/i);
+      } finally {
+        await sc.tearDown();
+      }
+    },
+    220_000,
+  );
+});