[adiled]

Why

Running wryme against hum's claude-cli models showed four wryme-side problems:

1. Deliveries were lost when a turn failed. A finished job's result or a window's note is recorded on the turn's assistant row as a tool call and result (due_calls). If the request failed, finish_streaming treated the row as an empty reply and deleted it. The item had already been claimed from its queue, so it was gone for good.

2. The system prompt changed every minute. Open book pages render Last inked: 7m ago into the system prompt on every request, so no two requests had the same system prompt. Prompt caches missed, and hum started a new claude session each turn.

3. Responses protocol: pages said twice, prod dropped. instructions was the first system message, which is the first page when the station has no prompt of its own. The pages were then added again as input items, so each page appeared twice, and the bookkeeping prod (already taken by api_messages) was dropped. In a warm window, the page items were also stored again on every turn.

4. Responses, full window: nothing finished was ever carried. The response.output_item.done handler read output_item, a field no server sends (the API's is item, which the output_item.added handler already reads). Reasoning, mcp_call and hosted items were never carried into the next round, and a call the server ran never showed its result. The tests passed only because their fixtures used the same wrong name. The words the model said before a tool call weren't carried at all, so within a turn a stateless endpoint never saw them and the next turn replayed them; to hum the conversation looked edited, and it began a new claude session. Argument deltas read output_item_id alone, where the API sends item_id.

5. Fixtures agreed with bugs. No test checked wryme against the specs it speaks, so problem 4 hid behind fixtures with the same wrong field name. An audit against both specs turned up more (below).

What changes

• finish_streaming keeps a turn's rows that hold tool events, so a delivered result or note stays in history after a failed turn. A turn with nothing at all is still dropped.

• The preamble shows when a page was last inked as a local time (2026-10-28 20:31), so it stays the same until the page is inked again. The book open tool result still shows the age.

• Responses: instructions is every system message joined (the station prompt, open pages, prod), the same as the chat protocol's system prompt. Pages are no longer added again as input items.

• Responses: a finished item is read from item. An assistant message is carried into the next round like reasoning, so the model's words before a call stay in the turn. Argument deltas are matched by item_id.

• Specs, pinned, in spec/: OpenAI's OpenAPI (openai/openai-openapi @ 26a2991) cut to the 392 schemas wryme's clients reach, and Open Responses (openresponses/openresponses @ 8907bc3, 2026-04-24) whole. spec/pull fetches them again.

• Tests held to them: src/spec.rs (test-only, jsonschema as a native dev-dependency) checks every fixture event, every chat chunk and every request wryme builds (full and warm windows, tools, history, deliveries) against both specs. Fixtures are built by constructors that check themselves; anything beyond both specs is marked beyond_spec. The checker's own tests prove it rejects output_item, output_item_id, a missing sequence_number and summary: "none".

• What the audit fixed:

  Spec says	wryme did	Now
  reasoning.summary is auto/concise/detailed	Hush sent "none"	Hush asks for no summary
  max_tool_calls caps built-in tools only, and is ≥ 1 in Open Responses	sent 0 at the tool depth limit, so function calls kept coming	tool_choice: "none"
  message items have type: "message" (Open Responses)	bare {role, content}	typed
  with store: false, a reasoning item needs encrypted_content, and a server id can't be resolved	would carry both as received	reasoning carried only with its encrypted content; words as a plain assistant message
  MCP argument events are response.mcp_call_arguments.*	listened for mcp_call.arguments.*	spec names
  Open Responses streams raw reasoning as response.reasoning.delta	ignored	read as Heart
  a failed mcp_call's error is an object	looked up a field that isn't there	shown as its words
  a server-run function call is reported under its call_id	under its item id	call_id

• Kept on purpose: the Open Responses effort enum lacks minimal and max (Swift and Max stations); Chat reasoning_content, multi_agent items, and function calls the provider ran are extensions beyond both specs.

Testing

• cargo test: 179 pass, twice. New tests: a_failed_turn_keeps_what_it_delivered (fails without the fix), an_open_page_is_said_the_same_until_inked_again, every_system_message_is_said_once_as_instructions, the_words_said_before_a_call_are_carried_into_the_next_round, and arguments_stream_in_by_their_item_id. Every fixture is now built by constructors checked against the specs.
• cargo clippy --all-targets and cargo check --target wasm32-unknown-unknown are clean.

Not included

• A turn's steps are still kept as one message (all words, then all calls). hum no longer depends on the shape (sigils: a conversation is found by the calls it was given, not by its words, and a call keeps claude's own id hum#102 finds a conversation by its call ids), but other providers still see the final answer ahead of the tool calls. That's a possible follow-up.
• The bookkeeping prod still changes the system prompt on the turn it appears. hum now keeps the session across that and tells claude the changed prompt (sigils: a conversation is found by the calls it was given, not by its words, and a call keeps claude's own id hum#102).