docs(sessions): explain when streams take a break
Describe cursor consumption, reconnect delays, and the one-reset recovery limit.
12 unmodified lines1314151617181920212223242526272829303132333435363738394029 unmodified lines12 unmodified linesphase is display metadata, not a failed connection. before live status isknown, enter preserves the draft; superseded status replies cannot unblockit. starting a new turn does not require `/compact` to change the old phase.
## Stream failures and recovery
Session streams require the `text/event-stream` content type. Each batch carriesa nonnegative integer cursor and an event array. The CLI validates the wholebatch before consuming it and advances the cursor only after every callbacksucceeds. Unknown event kinds are ignored;missing kinds and malformed known events are protocol failures.
Transport failures, ordinary EOF, HTTP 408/429, and server errors reconnect witha delay starting at 500 milliseconds and increasing to at most five seconds.Cancellation ends the subscription quietly. Other HTTP refusals, explicit SSEfailures, and consumer callback failures end it with a visible notice. A terminalfailure also stops status polling for that attachment.
The TUI attempts one durable transcript reset per attachment after a protocolfailure. It clears partial tool arguments and requires the recovery stream tobegin with a reset. A second protocol failure ends automatic recovery; reopeningthe session starts a new attachment. Pending submissions and drafts remainavailable, and a stream failure does not claim that model execution finished.
## asynchronous persistence failures
The dispatcher logs failures to advance delivered schedule occurrences or save mail delivery errors. Undelivered mail and unadvanced schedules remain durable and retry under the existing dispatch policy. A schedule whose submission succeeded but whose advance failed can be delivered again.
29 unmodified lines