switchroom 0.19.6 → 0.19.8

package/dist/cli/switchroom.js

@@ -2120,7 +2120,7 @@ var init_esm = __esm(() => {
 });
 
 // src/build-info.ts
-var VERSION = "0.19.6", COMMIT_SHA = "ae57dd83";
+var VERSION = "0.19.8", COMMIT_SHA = "c356d3ba";
 
 // src/cli/resolve-version.ts
 import { existsSync, readFileSync } from "node:fs";
@@ -23861,7 +23861,8 @@ function getBuiltinDefaultSkillEntries() {
     "switchroom-health",
     "switchroom-runtime",
     "mental-model-curator",
-    "dev-protocol"
+    "dev-protocol",
+    "telegram-formatting"
   ];
   return [
     ...anthropic.map((key) => ({ key, optOutKey: key, source: "anthropic" })),
@@ -29440,6 +29441,11 @@ right answer at all. Structure exists for the reader, not the writer: a two-item
 bullet list is worse than a sentence, a heading on a three-line reply is noise. When
 in doubt, shorter and plainer wins.
 
+Full palette when a rich or long message earns it \u2014 expandable blockquotes, spoilers,
+highlight, code-fence language hints, tables, escaping and chunking rules: load the
+\`telegram-formatting\` skill. Reach for it only when you're actually composing that
+message, never for everyday replies.
+
 Every turn that answers a user message ends with a user-visible \`reply\`
 \u2014 Telegram is all the user sees; your terminal output
 never reaches them.`, TELEGRAM_ENV_PLACEHOLDER = `# Set your bot token: TELEGRAM_BOT_TOKEN=your-token-here

package/dist/host-control/main.js

@@ -26663,7 +26663,7 @@ import { existsSync as existsSync9, readFileSync as readFileSync7 } from "node:f
 import { dirname as dirname4, join as join7 } from "node:path";
 
 // src/build-info.ts
-var VERSION = "0.19.6";
+var VERSION = "0.19.8";
 
 // src/cli/resolve-version.ts
 function readPackageVersion() {

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "switchroom",
   "//version": "NOT the release version — source of truth is the git tag, resolved by scripts/build.mjs:resolveVersion() (see CLAUDE.md > Standard release process). This field is stale by design and only the Layer-4 dev/non-tag fallback for build.mjs + src/cli/resolve-version.ts; do NOT bump it expecting a release to pick it up. npm-pack tarball naming needs a real version — do that as an UNCOMMITTED pack-time bump (see release step 6), never a committed one.",
-  "version": "0.19.6",
+  "version": "0.19.8",
   "description": "Run Claude Code 24/7 on your Claude Pro/Max subscription over Telegram. Open-source alternative to OpenClaw and NanoClaw — no API keys.",
   "type": "module",
   "bin": {

package/profiles/default/CLAUDE.md.hbs

@@ -72,11 +72,11 @@ The plugin's auto-retain (Stop hook) fires every turn, but in chunked mode each
 
 ### When to synthesize — concrete triggers
 
-Auto-recall and auto-retain keep the bank fed, but they never *synthesize* — that's on you, and it only happens if you act on these triggers. Each is paired with a deterministic backstop so nothing depends on you remembering:
+Auto-recall and auto-retain feed the bank but never *synthesize* — that's on you, only if you act on these triggers. Each has a backstop:
 
-- **Reflect instead of hand-assembling.** When a question needs an answer *across many past memories* — "what did we decide about X", "summarize where Y stands", "have I seen this before" — call `mcp__hindsight__reflect` rather than firing several `recall`s and stitching the fragments yourself. Rule of thumb: if you're about to make 2+ manual `recall` calls to reconstruct one answer, that's a `reflect`. (Backstop: auto-recall already injects the top hits every turn — reflect is the escalation when those aren't enough, not a replacement.)
-- **Propose a model when you keep re-deriving.** When you notice you've rebuilt the *same standing answer* two or three sessions running — the recurring state of your specialty a user keeps asking around — stop re-deriving and propose a mental model via `mcp__switchroom-telegram__mental_model_propose(name, source_query)` (or run the `mental-model-curator` skill to survey the bank and propose the earned few). One organic proposal beats ten reflexive recalls. Don't propose for a one-off fact — that's a `retain`; don't propose identity/"who is the user" — profile banks own that.
-- **Merge or retire directives when they pile up.** Directives are capped at `MAX_DIRECTIVES=15` active per bank — past that, the lowest-priority ones are silently truncated from the `<active_directives>` recall block and never reach you. When directives start overlapping or reading stale, run the `mental-model-curator` skill's directive merge/retire pass (it proposes; deletes stay operator-approved). (Backstop: `switchroom doctor` WARNs at >12 and FAILs at >15 active directives, so the pile-up surfaces on the issues card even if you don't notice it in-session.)
+- **Reflect instead of hand-assembling.** About to fire 2+ manual `recall`s for one answer ("summarize where Y stands")? Call `mcp__hindsight__reflect` instead. (Backstop: auto-recall injects the top hits every turn — reflect is the escalation.)
+- **Propose a model when you keep re-deriving.** Rebuilt the *same standing answer* across sessions? Propose a mental model via `mcp__switchroom-telegram__mental_model_propose(name, source_query)` (or run the `mental-model-curator` skill). Not for a one-off fact (`retain`) or identity (profile banks own that).
+- **Merge or retire directives when they pile up.** Directives cap at `MAX_DIRECTIVES=15` active per bank — past that the lowest-priority ones drop silently from recall. When they overlap or read stale, run the `mental-model-curator` merge/retire pass (deletes stay operator-approved). (Backstop: `switchroom doctor` WARNs at >12, FAILs at >15.)
 
 ## Sub-Agent Delegation
 

package/skills/telegram-formatting/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: telegram-formatting
+description: >
+  Use when composing a rich or long Telegram reply and you want the full
+  formatting palette with exact syntax — expandable blockquotes, spoilers,
+  highlight, code-fence language hints, GFM tables, nested lists — plus the
+  escaping rules and the framework's send-time chunking/normalizer behaviour.
+  Load it when a message genuinely needs structure, NOT for everyday short
+  replies (plain prose already wins there). Teaches judgment first: which
+  construct helps the reader vs when plain text is better. Do NOT use for
+  deciding whether to reply, or for non-Telegram output.
+---
+
+# Telegram formatting — the full palette
+
+Every outbound Switchroom message renders as raw GFM markdown over Telegram
+Bot API 10.1 rich messages (`telegram-plugin/rich-send.ts` `richMessage(md)` →
+`{ markdown }` → `sendRichMessage` / `editMessageText({ markdown })`). No HTML,
+no `parse_mode`. This skill is the depth reference behind the boot-injected
+floor card: the full construct vocabulary, correct syntax, escaping, and the
+send-time behaviour you can rely on.
+
+## Judgment first — reach for structure only when it helps the reader
+
+The floor card's stance is the law here too: **structure exists for the reader,
+not the writer.** Loading this skill does not mean "use everything below." Match
+the construct to the message.
+
+- **Short answers (a line or two): plain prose, no formatting.** "on it,
+  pulling the logs now" is already perfect. No bold, no bullets, no headings.
+  Most replies live here — don't dress them up.
+- **Default: light structure.** Bold ONLY the one key fact or answer, never
+  more. A list only for 3+ genuinely parallel items the reader will scan or
+  compare; two items or a flowing thought stay prose. `code spans` for
+  identifiers (filenames, commands, config keys, error codes) — tap-to-copy.
+- **Long / multi-section answers may add the rich constructs below** — tables,
+  headings, blockquotes, expandable blocks, fences — but only when they cut the
+  reader's effort. If the structure doesn't reduce scanning effort, drop it. A
+  two-item bullet list is worse than a sentence; a heading on a three-line reply
+  is noise. When in doubt, shorter and plainer wins.
+
+Over-bolded messages (most of the text bold, whole paragraphs/lists bolded) get
+their bold stripped at send time — so bold sparingly and deliberately.
+
+## Full rich vocabulary
+
+### Inline spans
+
+| Effect | Markdown | When / notes |
+| --- | --- | --- |
+| Bold | `**text**` | The one key fact or answer, not decoration. |
+| Italic | `*text*` or `_text_` | Light emphasis, labels, asides. |
+| Strikethrough | `~~text~~` | Retractions, "was X now Y". |
+| Spoiler | `\|\|text\|\|` | Only for an opt-in surprise or a reveal the reader chose to wait for (a punchline they want suspended) — NEVER to hide an answer someone is asking for or anxious about; when in doubt, show it plainly. Surfaces as a `spoiler` entity on the wire (live-verified 2026-07). |
+| Highlight / marked | `==text==` | Surfaces as a `marked` entity on the wire (live-verified 2026-07). `=` is an `escapeMarkdown` special, so dynamic text won't trigger it by accident. |
+| Inline code | `` `text` `` | Identifiers, tap-to-copy. Content is literal — no escaping inside. |
+| Link | `[label](https://…)` | Standard GFM link. |
+
+**Do NOT rely on these — they don't render as intended:**
+
+- **Underline** — there is NO underline token on this path. `__text__` renders
+  as **bold** (Telegram's rich-message markdown parser reads a `__…__` run
+  identically to `**…**`, live-verified against the Bot API 2026-07). Use `**`
+  for bold and don't reach for underline.
+- **Subscript** `~text~` (single tilde) and **superscript** `^text^` fall back
+  to literal text in rich messages — avoid (write "squared", not `x^2^`).
+- **Custom emoji** (premium custom-emoji entity) renders as a normal emoji for
+  non-premium viewers — don't rely on it to carry meaning.
+
+(Inline math `$…$`, HTML `<details>`/collapsible, and footnotes `[^1]` are NOT
+supported on this path — do not emit them; they degrade to literal or neutralised
+text.)
+
+### Block types
+
+- **Code fence** — ` ```lang ` … ` ``` `. Multi-line literal output (diffs,
+  logs, JSON, command blocks). The language hint (`diff`, `json`, `bash`, …)
+  sharpens syntax rendering — use it. Content inside is verbatim, never escape
+  it; the only hazard is an embedded ` ``` ` closing the block early, which the
+  framework defuses (`preBlock` in `shared/bot-runtime.ts`).
+- **Preformatted block** — a code fence with NO language, for fixed-width
+  non-code (ASCII tables, aligned columns).
+- **Bulleted list** — `- item` (also `*` / `+`). 3+ parallel items only.
+- **Numbered list** — `1. item`. Ordered steps or ranked items.
+- **Nested lists** — indent sub-items; tight (no blank lines) vs loose (blank
+  lines between items) both render. 3-level nesting is live-verified.
+- **Task list** — `- [ ] todo` / `- [x] done`.
+- **Table** — GFM pipe table (`| col | col |` + `| --- | --- |` separator),
+  optional per-column alignment (`:---`, `:---:`, `---:`). 2-D data ONLY (rows ×
+  columns) — not a substitute for prose. Chunk-safe: `splitMarkdownChunks` never
+  bisects a row.
+- **Blockquote** — `> quoted`. Quoted text or an indented continuation; the
+  right way to indent, because Telegram drops leading whitespace.
+- **Expandable blockquote** — `**> …` (Bot API 10.1). A long quote/aside the
+  reader can collapse and expand. The flagship rich construct — use it for a
+  long quotation, a stack trace, or a detailed aside you don't want dominating
+  the message. First line carries the `**> ` marker; continuation lines use `> `.
+- **Section heading** — `#` … `######`. Only in a genuinely long, multi-section
+  answer. Never on a short reply.
+- **Divider** — `---` (thematic break). Heavy horizontal rule between genuinely
+  separate sections. Use sparingly.
+- **Collage / album** — multiple images grouped in one message (media group).
+  Send via the attachment path, not markdown.
+
+## Escaping rules
+
+Dynamic content (filenames, ids, arbitrary user text) interpolated into a
+hand-built markdown card MUST be escaped so it renders LITERALLY instead of
+being parsed as formatting. Use `escapeMarkdown(value)` from
+`telegram-plugin/format.ts`.
+
+`escapeMarkdown` escapes exactly the characters that trigger INLINE formatting:
+backslash, `` ` ``, `*`, `_`, `~`, `=`, `[`, `]`, `|` — the set `` \`*_~=[]| ``.
+The backslash is escaped first so it never double-escapes a following special.
+It deliberately does **not** escape `.` `-` `+` `#` `(` `)` `{` `}` `!` `>`:
+those are only meaningful at line-start or in link/structure context, and
+escaping them mid-word would litter filenames (`foo.ts`), versions (`v1.2-rc`),
+and URLs with visible backslashes.
+
+- **Bold/italic a dynamic value:** `` `**${escapeMarkdown(value)}**` ``.
+- **Code-span a dynamic value:** `` `\`${value}\`` `` — code spans need NO
+  escaping (backtick content is already literal). This is the preferred, safest
+  way to render any identifier.
+
+## Send-time behaviour you can rely on
+
+- **Chunking.** Hard cap is `RICH_MESSAGE_MAX_CHARS = 32768` (32768 accepted,
+  32769 rejected — the single constant, never re-derive it). A longer body is
+  split by `splitMarkdownChunks(text, 32768)` in `format.ts`: it cuts at the
+  largest safe boundary (blank line → newline → space), **never bisects a fenced
+  code block** (`backOffOpenFence`) and **never bisects a table row**
+  (`backOffTableRow`). A single indivisible region larger than the cap is
+  emitted whole and re-split / hard-sliced at send time rather than hanging.
+  Long before 32768, ask whether a wall of text is the right answer at all.
+- **Typography normalizer (deterministic, every message).** Block spacing (one
+  blank line between distinct blocks), em/en dashes, and `•` bullet markers are
+  rewritten at send time. A LONE `\n` between two prose paragraphs is promoted
+  to a real visual break; runs of 3+ newlines collapse to `\n\n`; lists, tables,
+  code, and existing `\n\n` gaps are left exactly as written. Don't hand-tune
+  spacing or fight the normalizer — write the content, the gateway makes the
+  typography consistent.
+
+## The one rule that outranks everything here
+
+You loaded this skill to format a rich message well — but the best formatting is
+still the least that serves the reader. Use the palette to make a genuinely
+complex answer scannable, never to decorate a simple one.

package/telegram-plugin/dist/gateway/gateway.js

@@ -41612,6 +41612,7 @@ function shouldEmitShadowTrace(eventKind, effectCount, globalKind, verbose = gwT
 }
 
 // shared/bot-runtime.ts
+init_rich_send();
 var tgPostTagStore = new AsyncLocalStorage;
 function escapeHtmlForTg(text) {
   return text.replace(/([\\`*_~=\[\]|])/g, "\\$1");
@@ -62511,6 +62512,7 @@ import { createHash as createHash2 } from "crypto";
 import { AsyncLocalStorage as AsyncLocalStorage2 } from "async_hooks";
 init_flood_circuit_breaker();
 init_format();
+init_rich_send();
 var tgPostTagStore2 = new AsyncLocalStorage2;
 function _getTgPostTags() {
   return tgPostTagStore2.getStore();
@@ -62555,6 +62557,21 @@ function installTgPostLogger(bot) {
     }
   });
 }
+function installRichMarkdownGuard(bot) {
+  bot.api.config.use(async (prev, method, payload, signal) => {
+    if ((method === "sendRichMessage" || method === "editMessageText") && payload != null) {
+      const p = payload;
+      const rich = p.rich_message;
+      if (rich != null && typeof rich.markdown === "string") {
+        const guarded = guardAccidentalFormatting(rich.markdown);
+        if (guarded !== rich.markdown) {
+          p.rich_message = { ...rich, markdown: guarded };
+        }
+      }
+    }
+    return prev(method, payload, signal);
+  });
+}
 
 // flood-circuit-breaker.ts
 import {
@@ -74662,11 +74679,12 @@ async function sendReply(deps, req) {
     const { turn: ownerTurn, tier: ownerTier } = resolveReplyOwnerTurn(turn, chat_id, args);
     const resolvedTurnId = ownerTurn?.turnId ?? null;
     const ownerEndedAt = ownerTurn?.endedAt ?? null;
+    const gateThreadId = ownerTurn?.sessionThreadId ?? replyThreadId;
     const handbackAt = getLastSubagentHandbackAt(chat_id);
     const now = Date.now();
     const handbackCouldOwnReply = handbackAt != null && ownerEndedAt != null && handbackAt > ownerEndedAt && now - handbackAt <= DEFAULT_SUPERSEDE_TTL_MS2;
-    const replyIsOwnAnswer = ownerTier === "live" || !handbackCouldOwnReply;
-    const decision = flushedTurnSupersede.take(chat_id, replyThreadId, { liveTurnId: resolvedTurnId, replyText: text4, positiveAttribution: replyIsOwnAnswer, now });
+    const replyIsOwnAnswer = ownerTier === "live" || ownerTier === "latest-ended" && !handbackCouldOwnReply;
+    const decision = flushedTurnSupersede.take(chat_id, gateThreadId, { liveTurnId: resolvedTurnId, replyText: text4, positiveAttribution: replyIsOwnAnswer, now });
     if (decision.supersede) {
       process.stderr.write(`telegram gateway: reply: superseding flushed turn message(s) ` + `chatId=${chat_id} ids=${JSON.stringify(decision.deleteMessageIds)}
 `);
@@ -78177,13 +78195,33 @@ function resolveReplyOwnerTurnId(candidates) {
 }
 
 // gateway/subagent-handback-marker.ts
+var MAIN_THREAD_KEY = "<main>";
+
 class SubagentHandbackMarker {
-  lastAtByChat = new Map;
-  record(chatId, now) {
-    this.lastAtByChat.set(chatId, now);
+  byChat = new Map;
+  threadKey(threadId) {
+    return threadId == null ? MAIN_THREAD_KEY : String(threadId);
+  }
+  record(chatId, threadId, now) {
+    let inner = this.byChat.get(chatId);
+    if (inner == null) {
+      inner = new Map;
+      this.byChat.set(chatId, inner);
+    }
+    inner.set(this.threadKey(threadId), now);
   }
-  lastAt(chatId) {
-    return this.lastAtByChat.get(chatId) ?? null;
+  lastAt(chatId, threadId) {
+    return this.byChat.get(chatId)?.get(this.threadKey(threadId)) ?? null;
+  }
+  lastAtInChat(chatId) {
+    const inner = this.byChat.get(chatId);
+    if (inner == null || inner.size === 0)
+      return null;
+    let max = -Infinity;
+    for (const ts of inner.values())
+      if (ts > max)
+        max = ts;
+    return max === -Infinity ? null : max;
   }
 }
 
@@ -84663,6 +84701,76 @@ function buildDiffPreviewCard(input) {
   return { text: text4, reply_markup: kb };
 }
 
+// gateway/subagent-handback-marker.ts
+var INBOUND_SOURCE_CLASSIFICATION = {
+  subagent_handback: { decoupledCompletion: true },
+  cron: { decoupledCompletion: false },
+  reaction: { decoupledCompletion: false },
+  subagent_progress: { decoupledCompletion: false },
+  resume_interrupted: { decoupledCompletion: false },
+  resume_deferred: { decoupledCompletion: false },
+  resume_watchdog_timeout: { decoupledCompletion: false },
+  vault_grant_approved: { decoupledCompletion: false },
+  vault_grant_denied: { decoupledCompletion: false },
+  vault_grant_timeout: { decoupledCompletion: false },
+  vault_save_completed: { decoupledCompletion: false },
+  vault_save_discarded: { decoupledCompletion: false },
+  vault_save_failed: { decoupledCompletion: false },
+  vault_save_timeout: { decoupledCompletion: false },
+  secret_provided: { decoupledCompletion: false },
+  secret_declined: { decoupledCompletion: false },
+  secret_provide_failed: { decoupledCompletion: false },
+  secret_request_timeout: { decoupledCompletion: false },
+  mental_model_propose_timeout: { decoupledCompletion: false },
+  bridge_dead_restart: { decoupledCompletion: false },
+  obligation_represent: { decoupledCompletion: false },
+  missed_approval_retry: { decoupledCompletion: false },
+  skill_proposal_apply: { decoupledCompletion: false },
+  warmup: { decoupledCompletion: false },
+  mental_model_proposal_applied: { decoupledCompletion: false },
+  mental_model_proposal_denied: { decoupledCompletion: false },
+  mental_model_proposal_failed: { decoupledCompletion: false },
+  webhook: { decoupledCompletion: false },
+  linear: { decoupledCompletion: false }
+};
+function stampsHandbackMarker(source) {
+  if (source == null)
+    return false;
+  const known = INBOUND_SOURCE_CLASSIFICATION[source];
+  if (known == null)
+    return true;
+  return known.decoupledCompletion;
+}
+var MAIN_THREAD_KEY2 = "<main>";
+
+class SubagentHandbackMarker2 {
+  byChat = new Map;
+  threadKey(threadId) {
+    return threadId == null ? MAIN_THREAD_KEY2 : String(threadId);
+  }
+  record(chatId, threadId, now) {
+    let inner = this.byChat.get(chatId);
+    if (inner == null) {
+      inner = new Map;
+      this.byChat.set(chatId, inner);
+    }
+    inner.set(this.threadKey(threadId), now);
+  }
+  lastAt(chatId, threadId) {
+    return this.byChat.get(chatId)?.get(this.threadKey(threadId)) ?? null;
+  }
+  lastAtInChat(chatId) {
+    const inner = this.byChat.get(chatId);
+    if (inner == null || inner.size === 0)
+      return null;
+    let max = -Infinity;
+    for (const ts of inner.values())
+      if (ts > max)
+        max = ts;
+    return max === -Infinity ? null : max;
+  }
+}
+
 // gateway/pending-inbound-buffer.ts
 var DEFAULT_PENDING_INBOUND_CAP = 32;
 function redeliverBufferedInbound(buffer, agent, send, spool, onDelivered) {
@@ -84777,9 +84885,9 @@ function createPendingInboundBuffer(opts = {}) {
         }
       }
       q.push(msg);
-      if (msg.meta?.source === "subagent_handback" && opts.onHandbackEnqueue != null) {
+      if (stampsHandbackMarker(msg.meta?.source) && opts.onHandbackEnqueue != null) {
         try {
-          opts.onHandbackEnqueue(msg.chatId, msg.ts);
+          opts.onHandbackEnqueue(msg.chatId, msg.threadId, msg.ts);
         } catch {}
       }
       spool?.put(agent, msg);
@@ -93460,10 +93568,10 @@ function startGatewayHeartbeat(stateDir, intervalMs = GATEWAY_HEARTBEAT_INTERVAL
 }
 
 // ../src/build-info.ts
-var VERSION = "0.19.6";
-var COMMIT_SHA = "ae57dd83";
-var COMMIT_DATE = "2026-07-20T16:11:50Z";
-var LATEST_PR = 3476;
+var VERSION = "0.19.8";
+var COMMIT_SHA = "c356d3ba";
+var COMMIT_DATE = "2026-07-20T23:16:37Z";
+var LATEST_PR = 3483;
 var COMMITS_AHEAD_OF_TAG = 0;
 
 // gateway/boot-version.ts
@@ -96382,7 +96490,7 @@ var RECENT_TURNS_MAX = 32;
 var recentTurnsById = new Map;
 var recentTurnIdBySourceMessageId = new Map;
 var subagentHandbackMarker = new SubagentHandbackMarker;
-var getLastSubagentHandbackAt = (chatId) => subagentHandbackMarker.lastAt(chatId);
+var getLastSubagentHandbackAt = (chatId) => subagentHandbackMarker.lastAtInChat(chatId);
 function rememberRecentTurn(turn) {
   recentTurnsById.set(turn.turnId, turn);
   if (turn.sourceMessageId != null) {
@@ -99172,7 +99280,7 @@ var pendingInboundBuffer = createPendingInboundBuffer({
     const threadOpts = evThread != null ? { message_thread_id: evThread } : {};
     swallowingApiCall(() => bot.api.sendMessage(chat, "\u23F3 Messages are arriving faster than I can process them. Your messages are saved and will be handled once I finish the current turn \u2014 if any can't be picked up, I'll ask you to resend it.", { ...threadOpts }), { chat_id: chat, verb: "inbound-buffer-eviction" });
   },
-  onHandbackEnqueue: (chatId, ts) => subagentHandbackMarker.record(chatId, ts)
+  onHandbackEnqueue: (chatId, threadId, ts) => subagentHandbackMarker.record(chatId, threadId, ts)
 });
 function agentHasInFlightBackgroundWork(now) {
   if (countRunningWorkers() > 0)
@@ -106335,6 +106443,7 @@ async function initGatewayBot() {
   }
   bot = new import_grammy15.Bot(TOKEN);
   installTgPostLogger(bot);
+  installRichMarkdownGuard(bot);
   installUpdateTap(bot, (line) => process.stderr.write(line));
   bot.api.config.use(async (prev, method, payload, signal) => {
     try {

package/telegram-plugin/gateway/gateway.ts

@@ -295,7 +295,7 @@ import {
 } from '../retry-api-call.js'
 import { createSendGate, sendGateConfigFromEnv, isSendGateShed } from '../send-gate.js'
 import { createStatsLogger, createFloodWindowObserver } from '../send-gate-observability.js'
-import { installTgPostLogger, withTgPostTags } from '../shared/bot-runtime.js'
+import { installTgPostLogger, installRichMarkdownGuard, withTgPostTags } from '../shared/bot-runtime.js'
 import {
   floodStatePath,
   floodWindowsPath,
@@ -3889,12 +3889,17 @@ const recentTurnsById = new Map<string, CurrentTurn>()
 // Evicted in lock-step with recentTurnsById so it can't outgrow it.
 const recentTurnIdBySourceMessageId = new Map<number, string>()
 
-// fix/backstop-duplicate-reply — per-chat marker of the most recent
+// fix/backstop-duplicate-reply — per-chat/thread marker of the most recent
 // gateway-synthesized `subagent_handback` enqueue (logic in
 // subagent-handback-marker.ts; extracted per the gateway anti-inflation ratchet).
+// The record is thread-resolved (retains the originating topic), but the
+// content-gate READ is CHAT-WIDE (dup-audit MUST-FIX 2): the latest-ended owner
+// tier is chat-wide, so a thread-specific gate read was steerable by the reply's
+// own `message_thread_id` → silent edit-over. `lastAtInChat` makes the gate
+// un-steerable (any in-window handback in the chat keeps the content gate).
 const subagentHandbackMarker = new SubagentHandbackMarker()
 const getLastSubagentHandbackAt = (chatId: string): number | null =>
-  subagentHandbackMarker.lastAt(chatId)
+  subagentHandbackMarker.lastAtInChat(chatId)
 
 function rememberRecentTurn(turn: CurrentTurn): void {
   recentTurnsById.set(turn.turnId, turn)
@@ -9984,7 +9989,7 @@ const pendingInboundBuffer = createPendingInboundBuffer({
   // fix/backstop-duplicate-reply MUST-FIX 2 — stamp the handback marker at the
   // enqueue chokepoint so a boot-replayed handback (not just the live synthesis
   // push) populates it. Every `subagent_handback` push funnels through here.
-  onHandbackEnqueue: (chatId, ts) => subagentHandbackMarker.record(chatId, ts),
+  onHandbackEnqueue: (chatId, threadId, ts) => subagentHandbackMarker.record(chatId, threadId, ts),
 })
 
 // PR2 obligation-ledger idle sweep. Re-present an OPEN obligation only at a
@@ -22965,7 +22970,7 @@ async function initGatewayBot(): Promise<void> {
   }
 
   bot = new Bot(TOKEN)
-  installTgPostLogger(bot)
+  installTgPostLogger(bot); installRichMarkdownGuard(bot) // #3252/#3463: universal fmt guard installed after logger (composes outermost); see installRichMarkdownGuard docblock
 
   // Diagnostic update tap (#3300): one compact line per received update, logged
   // BEFORE any specific handler runs, so a routing-layer drop is diagnosable

package/telegram-plugin/gateway/outbound-send-path.ts

@@ -898,22 +898,45 @@ export async function sendReply(
     //
     // MUST-FIX 1 (silent-data-loss): the owner-resolution `quoted` / `origin`
     // tiers are derived from MODEL-SUPPLIED args (`args.reply_to` /
-    // `args.origin_turn_id`), so a background handback turn can STEER them —
-    // pass `reply_to = <the user's original msg id>` and it resolves the PRIOR
-    // flushed turn via `quoted`, which used to force the bypass and silently
-    // edit-over that turn's delivered answer (#3429-class, model-steerable). So
-    // a positive tier NEVER overrides an in-window handback; only the
-    // FRAMEWORK-owned `live` tier (the live `currentTurn`, not model-derived,
-    // and structurally unable to collide with an ended turn's flush record —
-    // `decideSupersede` requires same turnId) may bypass a handback window.
+    // `args.origin_turn_id`), so a reply can STEER itself — pass
+    // `reply_to = <another ended turn's source msg>` and it resolves THAT turn via
+    // `quoted`. Marker-absence proves "own answer" ONLY for the framework-derived
+    // `latest-ended` tier; a model-steered `quoted`/`origin` attribution with no
+    // marker is NOT evidence of ownership, so bypassing the content gate there
+    // silently edits over a different ended turn's delivered answer (the #3429
+    // double-loss, executed by Fable 2026-07-21). The `replyIsOwnAnswer`
+    // computation below therefore restricts the bypass to `live` + `latest-ended`;
+    // `quoted`/`origin` ALWAYS traverse the content gate. See that comment.
     //
-    // The content gate is therefore kept whenever a handback WAS enqueued in the
-    // window (any non-live tier): the late reply might BE that handback, so
-    // genuinely-new content sends fresh (two messages, #3429 preserved).
-    // Concurrency note: a case-A own reply coinciding with an unrelated
-    // background handback in the same ≤TTL window degrades to today's behaviour
-    // (two messages) — safe (never a silent drop/edit), just not collapsed.
+    // The content gate is therefore kept whenever a decoupled completion WAS
+    // enqueued in the window (on the latest-ended tier) OR the reply resolved via
+    // a model-steerable tier: the late reply might carry foreign content, so it
+    // sends fresh (two messages, #3429 preserved). Concurrency note: a case-A own
+    // reply coinciding with an unrelated background handback in the same ≤TTL
+    // window degrades to two messages — safe (never a silent drop/edit).
     const ownerEndedAt = ownerTurn?.endedAt ?? null
+    // MUST-FIX 2 (dup-audit / Fable 2026-07-21) — key BOTH the supersede lane and
+    // the marker-gate read on the FRAMEWORK-resolved thread (the owner turn's
+    // `sessionThreadId` — the lane the flush recorded on), NOT the raw model arg
+    // `args.message_thread_id` (`replyThreadId`). The flush records on
+    // `turn.sessionThreadId`; the owner turn resolved here IS that turn, so its
+    // thread is where its record and its handback marker live. Reading the gate on
+    // the raw arg let a reply carry `message_thread_id=<other topic>` to dodge a
+    // handback marker stamped on the real topic → silent edit-over (the regression
+    // F2's raw-arg keying introduced). The owner turn's thread is not model-
+    // derived, so it cannot be steered. Falls back to the raw arg only when no
+    // owner turn resolved (no record to clobber on the collapse path).
+    const gateThreadId = ownerTurn?.sessionThreadId ?? replyThreadId
+    // MUST-FIX 2 (dup-audit / Fable) — the content-gate READ is CHAT-WIDE, not
+    // lane-specific: `findLatestEndedTurnForChat` resolves owners chat-wide, so a
+    // handback in topic A can supersede topic B's ended turn; a thread-keyed gate
+    // read (the F2 regression) let a reply dodge that handback by carrying a
+    // different `message_thread_id`. Chat-wide makes the gate un-steerable — any
+    // in-window handback in the chat keeps the content gate (accepting the F2
+    // visible-dup in the overlap window; a self-healing dup beats a silent loss).
+    // The supersede `take()` LANE below stays thread-resolved (`gateThreadId` =
+    // the owner turn's framework thread, not the raw arg), so a handback's
+    // correction only ever touches ITS OWN topic's record.
     const handbackAt = getLastSubagentHandbackAt(chat_id)
     const now = Date.now()
     const handbackCouldOwnReply =
@@ -921,10 +944,26 @@ export async function sendReply(
       ownerEndedAt != null &&
       handbackAt > ownerEndedAt &&
       now - handbackAt <= DEFAULT_SUPERSEDE_TTL_MS
-    const replyIsOwnAnswer = ownerTier === 'live' || !handbackCouldOwnReply
+    // MUST-FIX 1 (silent-data-loss, PROVEN by Fable 2026-07-21) — restrict the
+    // content-gate BYPASS to the tiers whose attribution is NOT model-steerable:
+    //   - `live`   — the framework-owned live `currentTurn` (not model-derived,
+    //                and `decideSupersede`'s same-turnId check bars it from an
+    //                ended turn's record). Bypasses even a handback window.
+    //   - `latest-ended` — the ambiguous DM/late-reply fallback the marko fix
+    //                actually needs; bypass ONLY when no decoupled completion is
+    //                in the window (marker-absence ⇒ own answer).
+    // The `quoted` / `origin` tiers resolve from MODEL-SUPPLIED args
+    // (`args.reply_to` / `args.origin_turn_id`), so a reply can steer ITSELF onto
+    // a DIFFERENT ended turn's record — with marker-absence they used to bypass
+    // the content gate and silently edit-over that turn's delivered answer (the
+    // #3429 double-loss, executed by Fable). Those tiers therefore NEVER bypass:
+    // they always go through the content gate, so foreign content sends fresh and
+    // only a genuine same-answer reply collapses.
+    const replyIsOwnAnswer =
+      ownerTier === 'live' || (ownerTier === 'latest-ended' && !handbackCouldOwnReply)
     const decision = flushedTurnSupersede.take(
       chat_id,
-      replyThreadId,
+      gateThreadId,
       { liveTurnId: resolvedTurnId, replyText: text, positiveAttribution: replyIsOwnAnswer, now },
     )
     if (decision.supersede) {

package/telegram-plugin/gateway/pending-inbound-buffer.ts

@@ -31,6 +31,7 @@
 
 import type { InboundMessage } from './ipc-protocol.js'
 import type { InboundSpool } from './inbound-spool.js'
+import { stampsHandbackMarker } from './subagent-handback-marker.js'
 
 /** Default cap per agent. Tuned for `should fit a reasonable backlog of
  *  approval cards stacked while bridge is offline` but no more. */
@@ -82,13 +83,17 @@ export interface PendingInboundBufferOptions {
   /**
    * fix/backstop-duplicate-reply MUST-FIX 2 — called on every push of a
    * `subagent_handback` envelope (live synthesis AND boot-replay re-push),
-   * carrying the envelope's `chatId` and its own `ts` (ms). The gateway wires
-   * this to the per-chat subagent-handback marker so the supersede path can tell
-   * a flushed turn's own late reply from a background handback attributed to it
-   * — INCLUDING after a restart, where the only handback push is the replay.
-   * Best-effort: a throw here never breaks the push hot path.
+   * carrying the envelope's `chatId`, its `threadId` (the originating forum
+   * topic, or undefined for a DM), and its own `ts` (ms). The gateway wires this
+   * to the per-chat/thread subagent-handback marker so the supersede path can
+   * tell a flushed turn's own late reply from a background handback attributed to
+   * it — INCLUDING after a restart, where the only handback push is the replay.
+   * The `threadId` is passed so the marker keys on the SAME `chatId|threadId`
+   * lane the supersede registry uses (dup-audit F2): a handback in one topic must
+   * not hold the content gate open in another. Best-effort: a throw here never
+   * breaks the push hot path.
    */
-  onHandbackEnqueue?: (chatId: string, ts: number) => void
+  onHandbackEnqueue?: (chatId: string, threadId: number | undefined, ts: number) => void
 }
 
 /**
@@ -362,9 +367,17 @@ export function createPendingInboundBuffer(
       // content gate → silent edit-over-answer. Uses the envelope's own `ts`
       // (ms, `Date.now()`-derived at synthesis) so the marker reflects when the
       // handback actually happened, not the replay moment. Best-effort.
-      if (msg.meta?.source === 'subagent_handback' && opts.onHandbackEnqueue != null) {
+      // F1 (dup-audit) — the ONE chokepoint that decides which sources stamp the
+      // decoupled-completion marker, delegated to the single `stampsHandbackMarker`
+      // predicate (its membership is the invariant's only extension point). Every
+      // inbound — live synthesis AND boot-replay — funnels through this push(), so
+      // routing the decision here makes "a decoupled late-reply source stamps the
+      // marker" true BY CONSTRUCTION rather than by per-feature discipline.
+      if (stampsHandbackMarker(msg.meta?.source) && opts.onHandbackEnqueue != null) {
         try {
-          opts.onHandbackEnqueue(msg.chatId, msg.ts)
+          // F2 (dup-audit): pass the envelope's originating topic so the marker
+          // keys on the same `chatId|threadId` lane as the supersede registry.
+          opts.onHandbackEnqueue(msg.chatId, msg.threadId, msg.ts)
         } catch {
           /* marker stamp is best-effort; never break the push hot path */
         }