Stop → Continue: resume truncated or aborted assistant turns

[vahid-ahmadi]

Summary

A long policy analysis that hits the 16k `max_tokens` cap, or one the user kills with Stop, currently dies there — they have to start a new chat and re-explain context. This PR adds a Continue affordance below those messages that resumes from exactly where the answer stopped.

Closes #44.

Behaviour

• Truncation detection (backend): `backend/routes/chatbot.py` captures `final.stop_reason` from each Anthropic stream and propagates it on the `done` SSE event. `stop_reason === "max_tokens"` means truncated; `"end_turn"` / `"stop_sequence"` mean the model finished naturally.
• Manual stop detection (frontend): existing `AbortController` flow now also tags the in-progress message with `stopped: true` before flushing.
• Continue button: renders below the cost line on assistant messages where `stop_reason === "max_tokens" || stopped`, hidden if any tool in the message is still pending (avoids orphan tool calls).
• Resume in place: `continueMessage(idx)` posts the conversation up to and including the partial assistant turn back to `/chat/message`. Anthropic's assistant-prefill behaviour means the model continues the same logical turn — no extra "continue from where you stopped" user nudge needed. Streamed deltas append into the same bubble. Cost is summed onto the existing `cost_gbp`.
• Persistence: `stop_reason` / `stopped` / `cost_gbp` are now serialised by `saveConversation` and restored by `loadConversation`, so the Continue affordance survives a page reload.
• Per the issue's "out of scope": re-truncation is allowed (button reappears), but no auto-looping — every continuation requires a user click.

Implementation notes

• No structural backend changes — same loop, same tools, same prompt cache.
• `continueMessage` deliberately reuses the streaming protocol but skips the typewriter drain animation: resumed text dumps directly into the message rather than animating, which felt right (the user already read the prefix).
• Tools complication: the partial assistant might have triggered tool calls in the original turn. The new request only carries serialized text (existing pattern for `apiMessages`); the model continues from the text alone. That's lossy but consistent with how the project already handles multi-turn conversations.

Test plan

• `docker-compose up`. Ask a question that produces a long answer (e.g. "Walk through the entire UK income tax code with examples"). Watch for max_tokens truncation → Continue appears → click → answer resumes inline, cost sums up.
• Mid-stream click Stop → partial text preserved, Continue appears, click → resumes from exactly where it stopped.
• Click Stop while a tool is pending → Continue button is hidden for that message (orphan-tool guard).
• Reload the page (or open from history) → Continue affordance is still there on truncated/stopped messages.
• Plan-mode replies don't show Continue (they end with `stop_reason: "end_turn"`).
• Existing chat tests (`pytest backend/tests/test_api.py`) still pass — the only backend change is an additive field on the `done` event.

Out of scope

• "Continue indefinitely" auto-looping — explicitly user-driven only.
• Reconstructing tool_use / tool_result blocks across the request boundary (would let the model continue with full tool context but is a bigger refactor).

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
policyengine-uk-chat	Ready	Preview, Comment	May 6, 2026 11:47am

[github-actions]

Beta preview is ready.

• Frontend: open preview
• Backend: open backend