tokenmaxxing 1.1.0 → 1.1.1

package/DESIGN.md

@@ -97,13 +97,13 @@ 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. 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.
 - **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.1",
   "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/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;
@@ -415,57 +433,168 @@ export async function relayThread(input: {
   let segment: ReturnType<typeof pushableStream> | null = null;
   let segmentMeta: { text: 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;
+    const meta = { text: 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);
+          }
+        }
+        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();
+          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).
+      if (!(chunk instanceof Object)) meta.text = true;
+      seg.push(chunk);
+    };
+    return { seg, 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)) {
       postedText = true;
       segmentMeta!.text = true;
     }
-    seg.push(chunk);
+    target.push(chunk);
   };
   const breakSegment = () => {
     segment?.end();
     segment = null;
   };
+  // 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 +616,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.
@@ -768,12 +897,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";