test(integration): MCP-functional tier 2 — multi-turn, history/info tools, streaming deltas

[claudiusthebot]

Summary

Batch 2 of the MCP-functional test expansion queue from PR #136 (Dylan: "you should work on it during heartbeats").

4 new describe suites, 11 new test cases in talon-mcp-functional-2.test.ts. Each suite has its own RecordingHandler with a distinct seed (2000–5000) to avoid message_id collisions.

Multi-turn session state (2 tests)

• Turns counter increments across two sequential runTalonTurn calls on the same chatId without session reset — catches any accidental resetSession inside handleMessage. Asserts getSession(chatId).turns === 1 after turn 1, === 2 after turn 2 (same chatId, no reset).
• resetSession: true actually clears state — seeds session.turns = 99, confirms it's 1 after a fresh turn.

History and info tool dispatch (3 tests)

• read_chat_history routes through the full SDK→MCP→bridge→gateway chain; recording handler captures action body + limit param; protocol log confirms MCP dispatch.
• get_chat_info routes correctly (if it were missing from mcp-server.ts's registry, dispatch would fail with a schema error).
• Multi-read turn: read_chat_history + get_chat_info + end_turn in one assistant message — all three captured in order. Sequence assertion: read_chat_history.seq < get_chat_info.seq.

Streaming text deltas (2 tests)

• Text block before end_turn appears in turn.streamDeltas — proves onStreamDelta callback is wired through the real handler and SDK end-to-end.
• Pure text turn (no tool_use): streamDeltas captured, recording handler gets nothing (no MCP dispatch — confirms the recording handler isn't called for scratchpad-only turns).

Additional messaging tool dispatch (4 tests)

Fills coverage gaps from batch 1 (unpin_message, stop_poll, forward_message, list_pinned were never exercised in the MCP-functional tier):

• unpin_message — ok-only action, message_id propagated correctly
• stop_poll — ok-only action, message_id propagated correctly
• forward_message — ok-only action, source_chat_id + message_id propagated correctly
• list_pinned — read-path action, recording handler returns {ok: true, items: []}

Test plan

• typecheck ✅ (tsc --noEmit clean)
• format:check ✅ (prettier --check clean)
• CI: integration tier will run these on Ubuntu/macOS/Windows × Node 22 (requires stub binary to be built — skipIf(!stubReady) gates correctly if not)

What's next in the queue

From PR #136's description (not in this PR — scope cut for follow-ups):

• Cross-tool dedup (same tool called twice in one turn → recording handler only sees one)
• Flow-violation re-prompt path (model emits prose without end_turn, then retries)
• Plugin MCP server dispatch (non-telegram MCP server in the chain)
• Member/admin tools (kick, ban, promote)

🤖 Generated with Claude Code