StreamSubmitOptions

Command shape widened to the v1 surface + protocol-v2 additions.

• resume — dispatches to thread.input.respond targeting the most recent root-namespace interrupt (honoured today).
• goto — routes execution to a specific node (planned, forwarded via /run.start metadata).
• update — merges a partial state update into the thread's values before resuming (planned, forwarded via /run.start).

Only resume is currently executed by the controller; goto / update are accepted by the type surface so callers can migrate without breakage once the server work lands (plan-roadmap.md §5.3 R2.4).

Fork the run from an explicit checkpoint instead of the thread's latest. Emits a forkFrom field on the /run.start request that the API layer forwards to graph.streamEvents(input, { version: "v3", forkFrom }).

See plan-roadmap.md §5.3 R2.4.

Behaviour when a run is already in-flight on the thread.

• "rollback" (default) — abort the active run client-side and start the new one immediately.
• "interrupt" — server-side cancel of the in-flight run, then start the new one (requires API support, roadmap A0.3).
• "enqueue" — do NOT abort the active run; the new submission lands in StreamController.queueStore and is forwarded once the current run terminates.
• "reject" — error out client-side when a run is already in flight.

Only "rollback" is honoured client-side today; the other three are accepted on the type surface so callers can start migrating ahead of the matching server work (plan-roadmap.md §5.3 R2.3 and A0.3).

Per-submit error callback. Invoked when the run errors out — either before the first event lands (network/dispatch failure) or mid-stream. Does NOT suppress the error from being written to RootSnapshot.error; the callback is a local hook for showing toasts or routing the submission error to a component state slot, letting the rest of the UI keep using stream.error for render-level error display.

Per-submit thread-id override. When provided, the controller rebinds to this thread before dispatching the run; subsequent submits stick with the new id unless the hook's threadId prop changes. Useful when you want to start a new thread without unmounting the component (e.g. "New Chat" buttons).