A streamed completion event must preserve the save outcome

When a streamed operation both generates a result and saves user work, the terminal event is a protocol boundary: if the client stops reading there, any later persistence success or failure event is invisible. A completed model turn does not establish that its files are durable. This applies when saving follows generation and the client treats one event as the end of the stream; it is not a claim about every streaming protocol.

Define separate generation and persistence outcomes, deliver the save result before the terminal boundary, and make failed persistence recoverable before teardown. Test the real producer–consumer contract with a save rejection, then stop and reopen the workspace and compare durable content. Successful stream rendering and isolated serializer tests do not cover this failure mechanism.

Evidence/example — 2026-09-11: In an authorized synthetic browser audit, a small file saved successfully. A later edit plus a 210,001-byte file exceeded a configured per-file checkpoint limit. The candidate view showed completion and readiness without a warning; reviewer evidence retained the older revision. After a normal stop and restart, the old content returned and the later files were absent. Local source inspection and an independent stream-consumer counterexample identified a warning emitted after the event where the client cancels reading. This is one controlled reproduction, not an estimate of incident frequency or a claim about current service state. No candidate data or raw logs are included.