[RohanReddy44]

What changed

The client now speaks the Experience API contract for chat.

• sendUserQuery posts to {api.baseUrl}/v1/chat with the contract's body (sessionId, messageId, query, history, language, location when known) and reads the reply as events: started, delta, completed, error. completed is the answer and replaces the streamed text.
• Every failure is one ApiError with a code. From the API where it sent one. Made up where it did not: history_too_large for a bare 413, upstream_error for a stream that ends without completed or error or is not an event stream, unknown otherwise.
• The stub returns the same event stream. It hands back a Response of SSE frames, so the real parser and event handling run on every stubbed reply. Its cycle is three answers, a refusal, and a turn that failed after the DSS accepted it, so Retry can be seen with stubs on.
• The store has one turn runner where sendText and sendImage had two copies of the streaming and error code. The bubble is drawn on the first delta with the API's assistantMessageId as its id. traceId replaces qid. The "daily question limit" message for 429 is gone: 429 is busy and retryable.
• Dev proxy. npm run dev forwards the configured api.baseUrl path (/experience/api, read from the same config file) to a local Experience API (http://localhost:8078, DEV_API_URL overrides), prefix stripped as the deployment proxy does. Stubs on: nothing changes.

Not in this PR, by plan

• history is sent as []. Session id on clear chat, real history and the same messageId on retry are the next PR.
• Errors show the one generic message. Copy per error code, including "refresh the page" for history_too_large, follows after that.

Verified

• npm run lint, typecheck, knip, test (45 tests in 10 files) and build pass at each commit.
• The real call was run against the Experience API on localhost through this code and streamed started, two deltas and completed.
• A POST through the dev server at /experience/api/v1/chat reaches the API and streams back.
• Seen on the live API: its error responses are FastAPI defaults ({"detail": ...}), not yet the contract's {"error": {...}}. The client's fallback covers it and the 422 case is in the tests.

Follow-ups noted from review, pending decision

• Validate started like completed and error are, instead of String()-coercing missing ids.
• Strip a trailing slash from api.baseUrl.
• Validate completed.error and reject empty content without error.
• The suggestions block is still duplicated in sendText and sendImage.

🤖 Generated with Claude Code