[Juliusolsson05]

Problem

Orchestration MCP outputs were bounded by message COUNT only — nothing capped size (#373):

• 5x/7x duplication: one child answer of N chars appeared five times in a single orchestration_read_agent response — output.messages[last].text, output.agent.latestAssistantText, output.agent.finalAssistantText, output.latestAssistantText, output.finalAssistantText. finalAssistantText was never independently computed; it was always a verbatim alias of latestAssistantText. Closed agents in orchestration_wait_agents hit seven times (two more copies in agents[i]).
• No char caps anywhere: visibleMessageSummary capped count (maxMessages, default 20) but messages[].text and the live-turn text were full entryTextContent — one pasted diff or giant tool dump in a child message blew the parent's context.
• Tombstones stored verbatim: OrchestrationBridge.noteClosed kept the entire pre-close output in main's memory for up to 24h x 500 agents; limitOutputMessages count-sliced only.
• Tail-ring blowup: AgentTranscriptReader pushed RAW untruncated items into the tail ring (tail schema max 10,000) while streaming; per-item truncation only happened afterwards in boundItems.

Fix

Renderer (orchestrationMcp.ts) — maxCharsPerMessage (default 4000) on every extracted text including the live turn; maxCharsPerAgent running budget (default 24000) across the message tail, oldest dropped first (newest-first scan, mirroring the transcript reader's budget semantics); per-message and per-output truncated flags + totalChars original-size estimates. Truncation marker matches truncateItemText (…\n[truncated]). The record-level latestAssistantText/finalAssistantText mirrors become 400-char excerpts; exactly ONE full (per-message-capped) copy remains at output.latestAssistantText. Lifecycle hazard preserved: hasDurableOutput still sees non-empty text — truncation shortens, never drops, so completed children cannot regress to waiting.

MCP tools (createBuiltInMcpServer.ts) — orchestration_read_agent, orchestration_read_run_outputs, orchestration_wait_agents accept maxCharsPerMessage/maxCharsPerAgent (ranges match the agent_transcript_* tools); the two multi-agent tools add maxTotalChars (default 120,000) enforced in the handler: over budget, outputs degrade summary-first — every agent keeps status/lifecycle/counts plus a short excerpt, then leftover budget restores full outputs in order — with top-level truncated: true. No agent is ever dropped entirely.

Bridge (OrchestrationBridge.ts) — noteClosed byte-clamps stored tombstones (MAX_CLOSED_AGENT_CHARS = 262,144 message budget + 16,384 per mirror field, defense-in-depth against uncapped senders); limitOutputMessages honors caller char caps for tombstone serving; the new cap params joined the cachedReadRunOutputs cache key so differently-capped reads can't collide in the 250ms polling cache.

Transcript reader (AgentTranscriptReader.ts) — the tail ring now stores per-item truncated clones (idempotent; boundItems stays the final pass), and the final-projection re-add check now guards against the ring holding clones instead of raw references (pre-existing duplicate-final edge case).

Plumbing — request types in orchestrationTypes.ts, renderer handler pass-through in workspace/hook/index.ts.

Verification

• npx tsc -b tsconfig.node.json — clean
• npx tsc --noEmit -p tsconfig.web.json — 0 errors
• NODE_ENV=test npx vitest run — 467 passed; only the pre-existing agent-voice-dictation hotkeyBinding suite failure (present on main)
• Scratch harness exercised the pure cap logic: per-message truncation + flags, oldest-first budget drops, latest-assistant survival under starvation, summary-first total-budget degradation (no agent dropped, result fits budget), under-budget passthrough

Closes #373

🤖 Generated with Claude Code