Attorneys tell us a generated draft sometimes stops in the middle of a sentence, that words show up glued together, and that the editor still says the draft is finished even when they can see it is not.
When someone asks for a draft, the server pushes the text into the editor while the model writes it, over one long-lived HTTP response. Every read from the network hands the browser whatever bytes happened to arrive, so one read can hold several events, or half an event, or the end of one event and the start of the next.
stream_client.py is the browser side of that stream. The wire format is one block per event, blocks separated by a blank line:
id: 1
event: chunk
data: {"text": "A me"}
event: done
data: {"tokens": 5, "sha256": "7c853ccf..."}
A chunk event carries one piece of the draft. Pieces are not words: a piece can be half of a long word, or a single space. The last event is done, and it carries how many pieces the whole draft had and the sha256 of the whole draft text.
solve(payload) takes {"reads": [str, ...]}, one string per read from the network, and returns {"text": str, "status": "complete" or "error", "events": int}.
Your task
- Run the tests and read what comes back for the failing ones. Four of the seven fail today.
- Work out why a draft can arrive garbled, or short, and still come out as
complete.
- Fix it. Keep the same function names and the same return shape. A response that ends without a
done event, or whose done event does not match what actually arrived, is not a finished draft.
- In your explanation, say what each of the failures had in common, what you changed, and what else you would do in the real app so an attorney never loses a draft that was half written.