Repository navigation
feat: hold the conversation in the client and send it with every turn - #22
Merged
Merged
Conversation
Clearing the chat emptied the messages but kept the session id, so the next question went to the DSS under the old conversation's id. The contract ties the two together: the session id lives exactly as long as the history does, and clear chat is one of the two things that ends it, the other being a refresh (§3). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Every turn went out with an empty history, so the DSS saw each question on its own and a follow-up like "and tomorrow?" had nothing to refer to. The API stores nothing by design (contract §1), so the client is the only place the conversation exists, and it has to send the whole of it each time. buildHistory() reads it off the message list with one rule: a user text message counts when the next message is an assistant card that is not an error. That gives §4.1 exactly. A failed turn and its question stay out, so Retry sends the question once. The question being sent now has no answer yet and stays out; it goes as `query`. Refusals and questions back stay in, because the DSS needs the question it asked to read the reply. The list is read after the new user message is appended, at which point nothing is streaming, so every card body is the final text. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Retry re-entered sendText, which minted a fresh user message and with it a fresh messageId, so the API and DSS saw two unrelated ids for one question. The contract wants one: a retry of the same message reuses its messageId and gets a new transactionId from the API, so the two attempts can be told apart in traces while still being one message (§3). Retry now takes the id from the user message it removes and passes it back into sendText. Nothing else calls sendText with an id. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
Phase 3 of the Experience API work: the client is now a conversation, not a series of one-off questions.
buildHistoryreads it off the message list with one rule: a user text message counts when the next message is an assistant card that is not an error. That gives §4.1 exactly. Failed turns and their questions stay out, so Retry sends the question once. Refusals and questions back stay in. The question being sent now stays out and goes asquery. Six tests.messageId, however many attempts (§3).How to check
npm run devagainst the local API, or stubs on:historygrows by two entries each time.messageIdas the failed attempt.sessionId, empty history.Verified
🤖 Generated with Claude Code