tokenmaxxing 1.1.0 → 1.1.2

package/DESIGN.md

@@ -97,13 +97,14 @@ A local Socket Mode daemon (no public URL) that turns Slack threads into Claude
 - **Serve skills** (`src/serve-plugin/`, ships in the package via `files: ["src"]`): a Claude Code plugin loaded per turn (`plugins: [{type: "local", path}]`; discovered skills are enabled by default, so no `skills` option). `tokenmaxxing:ask-the-user` teaches the decision protocol - when input is needed, tag the requester with the raw Slack mention token `<@U...>`, ask compactly, END the turn (the thread reply is the next turn); `tokenmaxxing:serve-session` documents how the session runs (shared repo checkout, resume across turns, worktree-by-default for mutating tasks, handoff). The one dynamic fact skills cannot carry - who asked - rides in per turn via a `UserPromptSubmit` hook whose `additionalContext` ("Slack relay context: ...", built by `serveTurnContext`) names the triggering message author's mention token. The mention survives the pipeline because streamed `markdown_text` deltas pass verbatim and the post-and-edit fallback's `finalize` only linkifies bare `@U...`, never escaping an already-formed `<@U...>`. Skills are independent of the system prompt choice (probe-verified 2026-07-18 under the custom-string `SLACK_SYSTEM_PROMPT`: the init message lists the plugin + both skills + the Skill tool; the skill listing arrives as a conversation system-reminder, and CLAUDE.md loads via settingSources).
 - **Socket lifecycle**: `bot.initialize()` starts the persistent auto-reconnecting SocketModeClient; the daemon then just stays alive. The leased `startSocketModeListener` API must never be looped: it returns instantly without `waitUntil` and the loop starves the event loop (live incident 2026-07-18 - connected but silent).
 - **Id mapping**: Chat SDK ids are adapter-prefixed (`thread.channelId` = `slack:C0123`, `thread.id` = `slack:C0123:<threadTs>`) while links store bare Slack ids - lookups strip the prefix via `bareChannelId`. Subscriptions live in the daemon's memory state, so every mention re-subscribes its thread; queue-skipped messages (`context.skipped`) fold into the next prompt, with the queue-entry TTL raised to 1h (expiry is silent - no app callback in chat 4.34.0 - so it must outlast a depleted-pool park plus a long turn); per-thread turn serialization is owned by the daemon itself (a promise chain per thread id), because the SDK's queue dispatch lock has a 30s TTL extended only between dispatches and every claude turn outlives it; unlinked-channel traffic logs `serve.unlinked_channel` and stays silent in Slack.
-- **Restart resilience** (0.19.0, from the 2026-07-18 dead-thread incident: a deploy restart cut a turn mid-answer and left the thread deaf to follow-ups): startup re-subscribes every `slack-threads/` record straight on the state adapter (`state.subscribe(threadId)`; message routing checks `stateAdapter.isSubscribed`, verified in chat 4.34.0), so open threads survive restarts without needing a fresh mention. SIGTERM/SIGINT drains instead of dying: new turns are dropped loudly (`serve.drain_dropped` plus a tracked in-thread notice - a log-only drop reads as the bot thinking), tracked in-flight turns get up to 300s to finish (a re-snapshotting wait, so late-added notices still flush), then `Chat.shutdown()`; a second signal forces exit; the drain also aborts any depleted-pool park so a countdown never delays a restart. The claude child spawns detached in its own process group (`detachedClaudeSpawn` via the SDK's `spawnClaudeCodeProcess` hook), because a terminal Ctrl-C signals the whole foreground group and a non-detached child died with the daemon before the drain could save the turn; the signal handlers register before `bot.initialize()` so no turn can start while the process still has default signal disposition, and a rejecting `Chat.shutdown()` is caught so the drain always reaches its exit. When a `thread.post` rejects mid-turn (e.g. Slack finalizes an idle stream: `message_not_in_streaming_state`), relayThread drops the dead segment so the rest of the turn opens fresh messages instead of vanishing.
+- **Restart resilience** (0.19.0, from the 2026-07-18 dead-thread incident: a deploy restart cut a turn mid-answer and left the thread deaf to follow-ups): startup re-subscribes every `slack-threads/` record straight on the state adapter (`state.subscribe(threadId)`; message routing checks `stateAdapter.isSubscribed`, verified in chat 4.34.0), so open threads survive restarts without needing a fresh mention. SIGTERM/SIGINT drains instead of dying: new turns are dropped loudly (`serve.drain_dropped` plus a tracked in-thread notice - a log-only drop reads as the bot thinking), tracked in-flight turns get up to 300s to finish (a re-snapshotting wait, so late-added notices still flush), then `Chat.shutdown()`; a second signal forces exit; the drain also aborts any depleted-pool park so a countdown never delays a restart. The claude child spawns detached in its own process group (`detachedClaudeSpawn` via the SDK's `spawnClaudeCodeProcess` hook), because a terminal Ctrl-C signals the whole foreground group and a non-detached child died with the daemon before the drain could save the turn; the signal handlers register before `bot.initialize()` so no turn can start while the process still has default signal disposition, and a rejecting `Chat.shutdown()` is caught so the drain always reaches its exit. When a `thread.post` rejects mid-turn (e.g. Slack finalizes an idle stream after an undocumented window: `message_not_in_streaming_state`), relayThread salvages the dead segment in TEXT space: proven-delivered text is a mirror StreamingMarkdownRenderer's committable prefix over the confirmed chunks (each pull proves the previous append landed; the adapter's renderer holds back the trailing unterminated line until its post-iteration forced flush, so chunk-granular salvage would miss a final reply with no trailing newline - the live 2026-07-21 incident), and the remainder re-posts as a fresh message split at line boundaries, plus unconfirmed cards, bounded by a futility budget that refills on delivery progress; the textLost diagnostic remains only for exhausted salvage, and ambiguous failures duplicate a tail line rather than lose it.
 - **Interrupted-turn recovery** (from the second 2026-07-18 restart incident: a redeploy killed a ship turn 8 minutes in with zero notice - drain cannot save a long turn, and a group-wide kill can take the claude child even detached): the thread record persists the claude session id the moment the init message assigns it, and every turn is wrapped in a durable `activeTurn` marker (original prompt, start time, resume count) written before the spawn and cleared when the turn returns - except that a turn failing DURING a drain keeps its marker, since that failure is presumed to be the shutdown signal killing the child. On startup, a surviving marker means a restart killed that turn: the daemon posts a notice into the thread (the chat-sdk's documented proactive handle, rebuilt with the thread's newest human message as streaming recipient context so the resumed turn keeps its native task cards, that message's author becoming the turn's requester) and auto-resumes the work - resuming the recorded session with a continuation prompt, or replaying the original prompt fresh when the kill landed before the session opened; resumed turns settle like inbound ones (outcome log + finish_thread GC). Retries cap at 3 (each spends real quota) with a loud give-up notice posted before its marker clears; a per-thread turn lock keeps a startup resume from ever racing an inbound message turn in the same cwd, every recovery branch recomputes its decision from a fresh record reload under that lock (so a resume superseded by a faster inbound turn no-ops instead of double-running), and a blocking singleton flock makes a new daemon generation wait for the previous one - drain included - to fully exit before touching any thread record. Uncatchable deaths cannot leak a working child either: SIGHUP drains like SIGTERM (its default disposition skips the exit hook that kills the detached group), and the marker records the child's group pid plus its C-locale ps start-time token at spawn, so recovery kills only an exactly-identified SIGKILL-orphaned claude (never a recycled pid) before resuming its turn.
 - **Depleted-pool recovery** (harvested from Slaude, reshaped around the pool): relayThread consumes the spawn-boundary switch decision instead of discarding it - a depleted pool with a known recovery inside the message's one 14min parking deadline (shared across chained parks, so the thread's queue slot is never held longer in total) posts a park notice and retries at the reset. A mid-turn limit - detected ONLY on errored results, since `is_error` can ride subtype `"success"` (`Claude AI usage limit reached|<epoch>`) and a successful answer discussing limits must never be re-run - is persisted into usage.json first (`recordObservedLimit`: the serve process has no statusLine tee, and the snapshot TTL would otherwise feed the retry the stale pre-limit state), then retried silently after a short beat, so a pool swap makes the hiccup invisible. Bounded recoveries; every drop the relay performs is announced in-thread.
 - **Usage-limit auto-resume** (2026-07-21, superseding the drop-beats-false-promise rule for the known-wake case): a turn that ends at a usage limit with a KNOWN recovery time defers instead of dropping. relayThread reports `deferUntil`, the thread's durable activeTurn marker keeps a `resumeAt`, and a per-thread daemon timer (cancelled on drain, re-armed from the record at startup: future wakes schedule, past wakes recover immediately) fires the same interrupted-turn recovery path - serialized chain, fresh-reload supersede check, pool-recovery notice, `resumeDecision` capping total resumes. The defer triggers: known recovery past the parking deadline or recovery budget, retries exhausted while a post-burn pool probe reports a wake, and an unclassifiable child failure (no limit phrase in the error) converted by a pool probe reporting exhaustion - the pool state is the evidence the error text did not carry. Only an unknown recovery time still posts the honest re-send drop.
 - **Slack-native output hygiene**: relayed turns run a small standalone `systemPrompt` telling the model replies render as Slack markdown, never HTML (a live turn once answered with a literal `<br>`; the SDK's default system prompt is minimal since 0.1.0, so the string replaces nothing).
 - **Slash commands** (2026-07-18): a mention-stripped thread message that starts with `/` runs as a claude slash command - the SDK delivers a string prompt as one stream-json user message and the CLI routes a leading-slash prompt through its command table, on fresh and resumed sessions alike (live-verified with free `/usage` and `/context` reads). Local command output (`num_turns` 0) arrives as a non-streamed assistant message plus `result.result`, which relayThread's no-text fallback posts; `slackstream` also maps the documented `system/local_command_output` wire subtype in case a claude update flips the emitter. `/goal` (built-in since 2.1.139) works headless and its active goal is restored on resume, so it survives the per-message resume pattern. Slack gotcha: the composer eats ANY message whose first character is `/` client-side (channels and thread replies; registered app commands cannot even dispatch from threads), so the supported forms are `@bot /usage` (mention-first) and ` /usage` (leading space, Slack's own documented workaround) - both normalize to a position-0 command via `stripLeadingMention`.
-- **Agent representation** (`src/lib/slackstream.ts`): turns stream natively (`chat.startStream`, which works in channel threads regardless of the assistant:write scope): thinking and tool calls as task cards ("Thinking"/tool name/"Turn", input summary + truncated output) that Slack groups into ONE collapsible plan block per turn (the serve edge wraps every posted segment in a `StreamingPlan` with `groupTasks: "plan"`, Slack's `task_display_mode: "plan"`; user ask 2026-07-20 "squash them into one dropdown", superseding the 2026-07-18 separate-messages shape), and reply text as native markdown with rendered code fences - so one turn streams as a single Slack message: the reply plus one dropdown of its activity. A later main text block (typically post-tool prose) opens on a `\n\n` paragraph break (`textStreamed`), restoring the separation the per-tool message split used to provide; whitespace-only deltas do not arm it. Notices still post as their own messages, and a rejected append (Slack's message cap, a finalized idle stream) opens a follow-on message via the dead-segment recovery.
+- **Agent representation** (`src/lib/slackstream.ts`): turns stream natively (`chat.startStream`, which works in channel threads regardless of the assistant:write scope): thinking and tool calls as task cards ("Thinking"/tool name/"Turn", input summary + truncated output) that Slack groups into ONE collapsible plan block per turn (the serve edge wraps every posted segment in a `StreamingPlan` with `groupTasks: "plan"`, Slack's `task_display_mode: "plan"`; user ask 2026-07-20 "squash them into one dropdown", superseding the 2026-07-18 separate-messages shape), and reply text as native markdown with rendered code fences - so one turn streams as a single Slack message: the reply plus one dropdown of its activity. Reply text also splits at `SEGMENT_TEXT_MAX` (10,000 chars): Slack rejects an over-long message with `msg_too_long` (the streamed message accumulates server-side toward the documented 12,000-char `markdown_text` envelope) and nothing in the chat stack bounds or splits text, so one over-cap append used to reject the whole post and lose the reply (live incident 2026-07-20); a break forced inside a code fence closes and reopens the fence, fence parity is tracked over the segment's accumulated text (SDK deltas do not respect markdown token boundaries), and a cut never slices through a backtick run. A later main text block (typically post-tool prose) opens on a `\n\n` paragraph break (`textStreamed`), restoring the separation the per-tool message split used to provide; whitespace-only deltas do not arm it. Notices still post as their own messages, and a rejected append (Slack's message cap, a finalized idle stream) carries its undelivered chunks into a follow-on message via the dead-segment salvage.
+- **One Slack app per daemon** (live incident 2026-07-20): Slack Socket Mode delivers each event envelope to exactly one of an app's open connections, so two serve daemons sharing one Slack app steal each other's events - mentions usually survive (Slack emits `app_mention` plus `message.channels` for one mention and the Chat SDK dedupes them per-process), but a non-mention thread follow-up rides a single envelope and silently dies when the wrong daemon receives it. No code can route Slack's load-balancing (the hello frame's `num_connections` is discarded by `@slack/socket-mode` before any event fires), so the constraint is documented (docs limitations page) and diagnosed: `serve.unlinked_channel` logs once per channel per run with the shared-app explanation. Every host needs its own Slack app with its own tokens.
 - **Todo checklist card**: TodoWrite is bookkeeping, not a real tool run, so it never opens a generic card. Instead each stream gets one stable-id "Todos" card (id `todos`, subagents `todos-<parent_tool_use_id>`) that updates in place on every TodoWrite: `✅ content` for completed, `🔄 activeForm` for the in-progress item (live narration), `⬜ content` for pending (the Chat SDK Plan object's own iconography); card status goes complete only when every item is completed. The "Todos have been modified successfully" tool_result is suppressed, but a FAILED TodoWrite flips the card to error (the optimistic checklist must not claim a state that never took effect). Card ids do not carry across messages, so a TodoWrite after a dead-segment recovery starts a fresh card in the follow-on message: accepted, the latest state is always in the newest message. claude >= 2.1.142 defaults to the structured Task tools and never emits TodoWrite, so relayThread sets `CLAUDE_CODE_ENABLE_TASKS: "0"` in the spawn env (the documented opt-out; without it the checklist card is inert).
 - **Terminal echo** (2026-07-18): the daemon registers a `log()` echo (`setLogEcho` in log.ts, off by default so hooks and the statusline keep their stdout protocols clean), so every event while it runs - serve.* plus the in-process swap/decision events from `ensureBestAccount()`/`stopHookCheck` - also prints one colored line in the foreground terminal (`formatLogLine`: dim HH:MM:SS, event painted red/yellow/cyan by structural endsWith severity, redacted fields). `serve.turn_done`/`serve.turn_failed` (with seconds) close every relayed turn, so a foreground `xx serve` is observable without tailing `tokenmaxxing.log`.
 - **Live-verified end-to-end** (2026-07-18, #tokenmaxxing-dogfooding): mention opens a session (worktree-per-thread at the time), replies stream, thread follow-ups resume with context, cards + fenced code render, segmentation and queue folding behave. Plus the hermetic suite: schemas/links, stream mapping, fail-fast paths.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "tokenmaxxing",
-  "version": "1.1.0",
+  "version": "1.1.2",
   "description": "Automatic Claude Code account switching: pool multiple accounts and hot-swap when quota fills, resuming your session on the fresh account.",
   "type": "module",
   "license": "MIT",

package/src/cli/serve.ts

@@ -18,7 +18,7 @@
 import { existsSync, realpathSync } from "node:fs";
 import { delay, omit, uniq } from "es-toolkit";
 import { z } from "zod";
-import { Chat, StreamingPlan, ThreadImpl, type StreamChunk } from "chat";
+import { Chat, ConsoleLogger, StreamingPlan, ThreadImpl, type StreamChunk } from "chat";
 import { createSlackAdapter } from "@chat-adapter/slack";
 import { createMemoryState } from "@chat-adapter/state-memory";
 import {
@@ -328,6 +328,8 @@ export function buildServeRuntime(seam: {
   // holds the restart hostage.
   const drainAbort = new AbortController();
   let draining = false;
+  // channels already diagnosed as unlinked this run (see handleTurn).
+  const unlinkedLogged = new Set<string>();
 
   /** One relayed turn with the durable activeTurn marker around it: written
    *  before the spawn, cleared when the turn returns, so a marker surviving
@@ -426,8 +428,17 @@ export function buildServeRuntime(seam: {
       // checked BEFORE the draining branch: unlinked channels are
       // contractually log-only silent, and a drain-window drop notice posted
       // into one would tell a user to resend a message that will never be
-      // served (closing-review catch).
-      log("serve.unlinked_channel", { channel: thread.channelId });
+      // served (closing-review catch). Logged once per channel per daemon run:
+      // with several daemons sharing one Slack app this fires on every
+      // load-balanced envelope for a sibling's channel (live incident
+      // 2026-07-20), and the diagnosis needs one line, not a stream.
+      if (!unlinkedLogged.has(thread.channelId)) {
+        unlinkedLogged.add(thread.channelId);
+        log("serve.unlinked_channel", {
+          channel: thread.channelId,
+          note: "not linked on this host; if another tokenmaxxing serve shares this Slack app, Slack delivers each socket event to only ONE of them and thread replies get lost - give every daemon its own Slack app",
+        });
+      }
       return; // not a linked channel - stay silent in Slack
     }
     if (draining) {
@@ -865,6 +876,11 @@ async function runDaemon(): Promise<number> {
     // @slack/web-api's fiveRetriesInFiveMinutes literal (dep not declared,
     // so the values are inlined).
     webClientOptions: { retryConfig: { retries: 5, factor: 3.86 }, timeout: 15_000 },
+    // the adapter's default logger is info-level and prints a line per
+    // redelivered socket envelope ("Processing socket mode retry") - steady
+    // noise during restart catch-up. warn matches the Chat logger below;
+    // real degradations (streaming fallback etc.) are warn-level and survive.
+    logger: new ConsoleLogger("warn", "chat-sdk").child("slack"),
   });
   // held directly (not only via Chat) so startup can re-subscribe recorded
   // threads: subscriptions live in this in-memory state and die with the

package/src/lib/slackbridge.ts

@@ -10,7 +10,7 @@ import { join } from "node:path";
 import { z } from "zod";
 import { delay } from "es-toolkit";
 import { createSdkMcpServer, query, tool, type SpawnOptions } from "@anthropic-ai/claude-agent-sdk";
-import type { StreamChunk } from "chat";
+import { StreamingMarkdownRenderer, type StreamChunk } from "chat";
 import { ensureBestAccount, pooledOptions, stopHookCheck, type SwapDecision } from "../sdk.ts";
 import { POST_SWAP_COOLDOWN_MS } from "./decide.ts";
 import { readOAuthAccount } from "./claudejson.ts";
@@ -217,23 +217,41 @@ function pushableStream(): {
   iterable: AsyncIterable<SegmentChunk>;
   push: (chunk: SegmentChunk) => void;
   end: () => void;
+  ledger: () => { chunks: SegmentChunk[]; confirmed: number };
 } {
-  const queue: SegmentChunk[] = [];
+  const chunks: SegmentChunk[] = [];
+  let cursor = 0;
+  let confirmed = 0;
   let done = false;
   let notify: (() => void) | null = null;
   return {
     push(chunk) {
-      queue.push(chunk);
+      chunks.push(chunk);
       notify?.();
     },
     end() {
       done = true;
       notify?.();
     },
+    /** Everything ever pushed plus how much of it the consumer PROVED
+     *  delivered. The Slack adapter pulls one chunk, awaits its Slack append,
+     *  then pulls the next (verified in @chat-adapter/slack 4.34.0 stream()),
+     *  so each pull confirms the append for the previous chunk landed; a
+     *  consumer that dies mid-append unwinds the for-await with an implicit
+     *  return() at the yield, leaving that chunk and everything after it
+     *  unconfirmed. */
+    ledger() {
+      return { chunks: [...chunks], confirmed };
+    },
     iterable: {
       async *[Symbol.asyncIterator]() {
         while (true) {
-          for (let next = queue.shift(); next !== undefined; next = queue.shift()) yield next;
+          while (cursor < chunks.length) {
+            const next = chunks[cursor]!;
+            cursor += 1;
+            yield next;
+            confirmed = cursor;
+          }
           if (done) return;
           await new Promise<void>((resolve) => {
             notify = resolve;
@@ -245,6 +263,23 @@ function pushableStream(): {
   };
 }
 
+/** Slack rejects an over-long message with msg_too_long, and NOTHING in chat
+ *  4.34.0 or the Slack adapter bounds, truncates, or splits reply text
+ *  (verified in-source 2026-07-20): a natively streamed message accumulates
+ *  server-side toward the 12,000-char markdown_text envelope (docs.slack.dev
+ *  documents that limit on chat.postMessage/update and all three streaming
+ *  methods), the post-and-edit fallback re-sends the FULL accumulated text as
+ *  markdown_text on every edit, and once anything rendered natively a failed
+ *  append REJECTS the whole thread.post - the reply dies (live incident
+ *  2026-07-20, three failed turns). relayThread therefore splits reply text
+ *  across Slack messages BEFORE the cap; the 2,000-char margin absorbs the
+ *  renderer's markdown normalization and mention-linkification expansion.
+ *  Tradeoff (accepted): the adapter-internal plain-text fallback edits via
+ *  chat.update `text` (hard 4,000-char cap), but it only engages when the
+ *  workspace refused native streaming outright - splitting every normal reply
+ *  3x tighter to cover that never-hit path is worse than the residual risk. */
+export const SEGMENT_TEXT_MAX = 10_000;
+
 /** Full permission name of the finish_thread tool (mcp__<server>__<tool>):
  *  it must be in allowedTools, because no one can answer a permission prompt
  *  through Slack. */
@@ -413,59 +448,262 @@ export async function relayThread(input: {
 }): Promise<TurnOutcome> {
   const outcome: TurnOutcome = { sessionId: input.sessionId, failed: false, rateLimited: false, finish: false, announcedDrop: false, resultReceived: false, deferUntil: null };
   let segment: ReturnType<typeof pushableStream> | null = null;
-  let segmentMeta: { text: boolean } | null = null;
+  // acc mirrors the segment's pushed text (bounded by SEGMENT_TEXT_MAX plus a
+  // small overshoot): fence parity must be computed over the ACCUMULATED text,
+  // never per chunk - SDK deltas do not respect markdown token boundaries, so
+  // a ``` split across two deltas would be invisible to per-chunk counting
+  // (pullfrog review catch, PR #42).
+  let segmentMeta: { text: boolean; acc: string; reopenFence: boolean } | null = null;
   let lastPost: Promise<unknown> = Promise.resolve();
-  // Reply TEXT that was pushed into a rejected segment and never re-delivered
-  // by a later text-bearing segment: the user has not seen the answer. A lost
-  // card-only segment never sets this (decoration, not the answer).
-  // Tradeoff (flagged and accepted): a later delivered text segment clears the
-  // flag even though it is a continuation, because the dominant rejection is
-  // Slack finalizing an idle stream - the streamed text WAS delivered, only
-  // the append failed - and sticky loss would fail every long turn with a
-  // spurious diagnostic; chat 4.34.0 exposes no per-chunk delivery acks to
-  // tell that apart from a swallowed first post.
+  // Reply TEXT that died with a rejected segment and was neither salvaged into
+  // a follow-on message nor re-delivered by a later text-bearing segment: the
+  // user has not seen the answer. A lost card-only segment never sets this
+  // (decoration, not the answer). Tradeoff (flagged and accepted): a later
+  // delivered text segment clears the flag even though it is a continuation,
+  // because a rejection whose text chunks were all consumed pre-append-failure
+  // was almost certainly delivered (the adapter appends per chunk) except for
+  // an unobservable renderer-held tail; sticky loss would fail every long turn
+  // with a spurious diagnostic.
   let textLost = false;
   let textLostDetail: string | null = null;
   let postedText = false;
+  // Salvage: a rejected post's undelivered chunks re-post as a fresh message
+  // (Slack finalizes an idle stream after an UNDOCUMENTED window - verified
+  // absent from the chat.startStream/appendStream docs 2026-07-21 - so
+  // recovery is reactive on any append failure, never a keepalive tuned to a
+  // guessed constant). The budget bounds FUTILITY, not recovery: a death
+  // after the message delivered something is progress and refills it (a long
+  // turn can outlive any number of idle finalizations, each losing only the
+  // gap tail), while a surface that delivers nothing (revoked channel, hard
+  // cap on the very first append) burns a strike per attempt and stops.
+  const MAX_SEGMENT_SALVAGES = 5;
+  let salvagesLeft = MAX_SEGMENT_SALVAGES;
+  const openSegment = () => {
+    const seg = pushableStream();
+    segment = seg;
+    // reopenFence: the delivered prefix of a REJECTED predecessor left a code
+    // fence open, so the first TEXT entering this salvage segment must be
+    // preceded by a reopen or it renders outside the code block. Pending
+    // rather than pushed eagerly (pullfrog catches, PR #42): a card-only
+    // salvage would otherwise either skip the reopen (later text joining the
+    // segment renders unfenced) or dangle an empty open fence at message end
+    // when no text ever follows. Materialized by BOTH text entry points.
+    const meta = { text: false, acc: "", reopenFence: false };
+    segmentMeta = meta;
+    lastPost = input.post(seg.iterable).then(
+      () => {
+        salvagesLeft = MAX_SEGMENT_SALVAGES;
+        // segments settle in order (push awaits lastPost before opening the
+        // next), so delivered text supersedes an earlier loss.
+        if (meta.text) textLost = false;
+      },
+      (e: unknown) => {
+        const detail = (e instanceof Error ? e.message : String(e)).slice(0, 300);
+        log("serve.post_error", { err: detail });
+        // the consumer is gone (e.g. Slack finalized an idle stream:
+        // message_not_in_streaming_state). Salvage runs in TEXT space, not
+        // chunk space, because the adapter's renderer buffers across chunks
+        // (it holds back the trailing unterminated line, unconfirmed table
+        // headers, and unclosed inline markers until the post-iteration
+        // finish() flush - pullfrog catch on PR #45: a reply whose last line
+        // has no trailing newline dies entirely in that forced flush, with
+        // every chunk already consumed). Proven-delivered text = the mirror
+        // renderer's committable prefix over the CONFIRMED chunks (each pull
+        // proves the previous append landed; the adapter runs the renderer
+        // with wrapTablesForAppend: false, so committable is a raw prefix and
+        // the mirror is chunking-invariant). Renderer drift would break the
+        // prefix check and degrade to a full re-post: duplication, never
+        // loss. Same tradeoff for a stop()-failure after a complete flush:
+        // the held tail re-posts once rather than risking silent loss.
+        const { chunks, confirmed } = seg.ledger();
+        if (segment === seg) segment = null;
+        const confirmedRaw = chunks
+          .slice(0, confirmed)
+          .flatMap((c) => (c instanceof Object ? [] : [c]))
+          .join("");
+        const fullRaw = chunks.flatMap((c) => (c instanceof Object ? [] : [c])).join("");
+        const mirror = new StreamingMarkdownRenderer({ wrapTablesForAppend: false });
+        mirror.push(confirmedRaw);
+        const committed = mirror.getCommittableText();
+        const deliveredLen = confirmedRaw.startsWith(committed) ? committed.length : 0;
+        const textRemainder = fullRaw.slice(deliveredLen);
+        // A confirmed card's append landed (the adapter sends a card inline
+        // in the loop body before the next pull), so unconfirmed cards are
+        // the set it never appended.
+        const deliveredCard = chunks.slice(0, confirmed).some((c) => c instanceof Object);
+        // Delivery progress means this death does not count toward the
+        // futility budget: only a message that delivered nothing burns one.
+        // The key is ACTUAL delivery (committable text or a landed card),
+        // never chunk consumption: a reply whose final line has no trailing
+        // newline is consumed whole (confirmed advances) while its only
+        // append is the post-iteration forced flush, so a consumption key
+        // would refill the budget on every persistently failing flush and
+        // salvage the same held-back text forever (vercel review catch,
+        // PR #45). deliveredLen stays 0 there, the strike is spent, and the
+        // zero-delivery case terminates.
+        if (deliveredLen > 0 || deliveredCard) salvagesLeft = MAX_SEGMENT_SALVAGES;
+        // The salvage sequence preserves STREAM ORDER (cursor review catch,
+        // PR #45: re-posting all remainder text and then all cards showed
+        // task cards after prose that originally followed them): walk the
+        // ledger in order, keeping each text chunk's undelivered suffix and
+        // each unconfirmed card at its original position. Text splits at
+        // line boundaries (rendering is unchanged: chunks concatenate) so a
+        // salvage message that dies too still confirms per line, keeping
+        // progress attribution fine-grained.
+        const lost: SegmentChunk[] = [];
+        let offset = 0;
+        for (const [i, c] of chunks.entries()) {
+          if (c instanceof Object) {
+            if (i >= confirmed) lost.push(c);
+            continue;
+          }
+          const end = offset + c.length;
+          let rest = end > deliveredLen ? c.slice(Math.max(0, deliveredLen - offset)) : "";
+          offset = end;
+          while (rest !== "") {
+            const nl = rest.indexOf("\n");
+            if (nl === -1) {
+              lost.push(rest);
+              break;
+            }
+            lost.push(rest.slice(0, nl + 1));
+            rest = rest.slice(nl + 1);
+          }
+        }
+        // A fence OPENED in the delivered prefix leaves later code fenceless
+        // in the fresh salvage message (pullfrog catches, PR #42): arm the
+        // segment's pending reopen, materialized right before the FIRST text
+        // that enters it - whether a salvaged remainder piece here or a later
+        // streamed push joining the segment (a card-only salvage must not
+        // skip the reopen, and a text-less segment must not dangle one).
+        // Fold this dying segment's OWN still-armed reopen into the parity:
+        // an armed-but-never-materialized reopenFence means the segment
+        // logically BEGAN inside an open fence (a card-only salvage that
+        // inherited one and died before any text materialized it), so that
+        // open state must propagate to the next salvage or its later text
+        // renders unfenced (vercel + cubic chained-salvage catch, PR #42).
+        // Once materialized, reopenFence is false and the reopen chunk is in
+        // fullRaw, so the XOR is a no-op; a normal segment's flag is false.
+        const deliveredFenceOpen =
+          ((fullRaw.slice(0, deliveredLen).split("```").length - 1) % 2 === 1) !== meta.reopenFence;
+        if (lost.length > 0 && salvagesLeft > 0) {
+          salvagesLeft -= 1;
+          log("serve.post_salvage", { chunks: lost.length, left: salvagesLeft });
+          // this handler runs synchronously as the post settles, so opening
+          // the salvage segment here keeps the salvaged content ordered ahead
+          // of any push still awaiting lastPost; the salvage segment's own
+          // settle then decides whether its text counts as delivered.
+          const next = openSegment();
+          next.meta.reopenFence = deliveredFenceOpen;
+          for (const c of lost) next.pushInto(c);
+        } else if (textRemainder !== "") {
+          textLost = true;
+          textLostDetail = detail;
+        }
+      },
+    );
+    const pushInto = (chunk: SegmentChunk) => {
+      // meta.text only, NEVER postedText: salvaged text was already counted
+      // at its original push, and postedText is attempt-scoped - a salvage
+      // landing after a retry reset would otherwise re-arm it and suppress
+      // the retry's `!postedText && result` fallback, silently dropping a
+      // result-only answer (adversarial-review catch on PR #45). acc still
+      // accumulates: it mirrors the segment's FULL text on every entry path,
+      // so pushText's room accounting and fence parity see salvaged text too
+      // (a salvage segment that continued via pushText could otherwise grow
+      // past the msg_too_long cap).
+      if (!(chunk instanceof Object)) {
+        if (meta.reopenFence) {
+          meta.reopenFence = false;
+          meta.acc += "```\n";
+          seg.push("```\n");
+        }
+        meta.text = true;
+        meta.acc += chunk;
+      }
+      seg.push(chunk);
+    };
+    return { seg, meta, pushInto };
+  };
   const push = async (chunk: SegmentChunk) => {
-    let seg = segment;
-    if (!seg) {
+    if (segment === null) {
       await lastPost; // strict message order: previous segment fully posted first
-      seg = pushableStream();
-      segment = seg;
-      const posted = seg;
-      const meta = { text: false };
-      segmentMeta = meta;
-      lastPost = input.post(seg.iterable).then(
-        () => {
-          // segments settle in order (push awaits lastPost before opening the
-          // next), so delivered text supersedes an earlier loss.
-          if (meta.text) textLost = false;
-        },
-        (e: unknown) => {
-          const detail = (e instanceof Error ? e.message : String(e)).slice(0, 300);
-          log("serve.post_error", { err: detail });
-          if (meta.text) {
-            textLost = true;
-            textLostDetail = detail;
-          }
-          // the consumer is gone (e.g. Slack finalized an idle stream:
-          // message_not_in_streaming_state) - drop the dead segment so the
-          // next chunk opens a fresh message instead of vanishing into it.
-          if (segment === posted) segment = null;
-        },
-      );
+      // a rejection handler may have opened a salvage segment during the wait;
+      // joining it instead of opening another keeps its post from being
+      // orphaned un-ended.
     }
+    const target = segment ?? openSegment().seg;
     if (!(chunk instanceof Object)) {
+      // materialize a salvage segment's pending fence reopen (see
+      // openSegment) before the first text from this entry point too.
+      if (segmentMeta!.reopenFence) {
+        segmentMeta!.reopenFence = false;
+        segmentMeta!.acc += "```\n";
+        target.push("```\n");
+      }
       postedText = true;
       segmentMeta!.text = true;
+      segmentMeta!.acc += chunk;
     }
-    seg.push(chunk);
+    target.push(chunk);
   };
+  // parity by occurrence count over the segment's accumulated text: an odd
+  // number of ``` markers means the segment currently sits inside a fence.
+  const fenceOpen = () => segmentMeta !== null && (segmentMeta.acc.split("```").length - 1) % 2 === 1;
   const breakSegment = () => {
     segment?.end();
     segment = null;
   };
+  /** Reply text routed through here splits across Slack messages before the
+   *  msg_too_long cap (see SEGMENT_TEXT_MAX): a break prefers the last newline
+   *  inside the remaining room, and a break forced inside a code fence closes
+   *  it and reopens it in the next message so both halves render as code. */
+  const pushText = async (text: string) => {
+    for (let rest = text; rest !== "";) {
+      const room = SEGMENT_TEXT_MAX - (segment === null ? 0 : segmentMeta!.acc.length);
+      // a fence-close suffix can nudge a segment a few chars past the cap;
+      // a full segment just breaks and the loop re-measures a fresh one.
+      if (room <= 0) {
+        breakSegment();
+        continue;
+      }
+      if (rest.length <= room) {
+        await push(rest);
+        return;
+      }
+      // prefer a newline cut only when it lands in the back half of the room:
+      // an early newline followed by one giant unbroken run would otherwise
+      // make no progress and (with the fence-reopen prefix) loop forever.
+      const nl = rest.lastIndexOf("\n", room - 1);
+      let cut = nl >= Math.floor(room / 2) ? nl + 1 : room;
+      // never slice through a backtick run: a cut inside ``` would strand a
+      // partial delimiter on each side and break both halves' rendering
+      // (cubic review catch, PR #42). Walk the cut left past the run; a run
+      // reaching position 0 keeps the original cut (progress beats rendering
+      // for pathological all-backtick input).
+      if (rest[cut - 1] === "`" && rest[cut] === "`") {
+        let backedUp = cut;
+        while (backedUp > 0 && rest[backedUp - 1] === "`") backedUp -= 1;
+        if (backedUp > 0) cut = backedUp;
+      }
+      const head = rest.slice(0, cut);
+      await push(head);
+      const reopen = fenceOpen();
+      if (reopen) await push("\n```");
+      breakSegment();
+      rest = (reopen ? "```\n" : "") + rest.slice(head.length);
+    }
+  };
+  // settle the whole post chain: a rejection handler may replace lastPost with
+  // a salvage segment's post, which still needs ending and settling.
+  const settlePosts = async () => {
+    while (true) {
+      breakSegment();
+      const settled = lastPost;
+      await settled;
+      if (lastPost === settled) return;
+    }
+  };
   // a recovery status line reads as its own Slack message, not part of a
   // streamed segment.
   const notify = async (text: string) => {
@@ -487,7 +725,7 @@ export async function relayThread(input: {
    *  its own delivery resets textLost. */
   const notifyDelivered = async (text: string) => {
     await notify(text);
-    await lastPost;
+    await settlePosts();
     return !textLost;
   };
   // false when the daemon started draining mid-sleep.
@@ -612,10 +850,13 @@ export async function relayThread(input: {
             outcome.resultReceived = true;
           }
         }
-        for (const part of agentEventChunks({ state: mapState, message })) await push(part);
+        for (const part of agentEventChunks({ state: mapState, message })) {
+          if (part instanceof Object) await push(part);
+          else await pushText(part);
+        }
       }
       // a turn that produced no streamed text (tool-only turns) still reports.
-      if (!postedText && result) await push(result);
+      if (!postedText && result) await pushText(result);
       if (!postedText && !result && outcome.failed && !outcome.rateLimited) {
         // held back until the depleted-pool probe rules: a "trying again may
         // help" line right before a deferral notice invites a manual re-send
@@ -768,12 +1009,12 @@ export async function relayThread(input: {
       break;
     }
   }
-  breakSegment();
-  await lastPost;
-  // Reply text died with a rejected segment and nothing later re-delivered it:
-  // the answer silently vanished while the outcome would report success. Fail
-  // the turn and make one best-effort fresh-message diagnostic (a fresh post
-  // is exactly what the mid-stream recovery relies on succeeding).
+  await settlePosts();
+  // Reply text died with a rejected segment, salvage could not re-deliver it
+  // (budget exhausted or the salvage posts died too), and nothing later
+  // re-delivered it: the answer silently vanished while the outcome would
+  // report success. Fail the turn and make one best-effort fresh-message
+  // diagnostic.
   if (textLost) {
     outcome.failed = true;
     const detail = textLostDetail ?? "unknown error";