PlanStream is the client-side wrapper for consuming planning lifecycle events while an
approved execution plan runs. Use it together with the IllaSDK facade methods
executePlan (start streaming a plan) and sendStepDecision (steer a step that needs a decision).
How planning fits together
- A planning-enabled chat turn returns an
ExecutionPlanon the response (response.data.plan), along withrequiresApprovalandavailableActions. - After the user approves, call
executePlan(plan)to stream the plan’s execution. - Attach handlers to the returned
PlanStreamto observe lifecycle events. - If a step fails or needs guidance, call
sendStepDecision(...)to retry, stop, or edit the request.
executePlan
ExecutionPlan and returns a PlanStream that emits real-time planning
events. Internally this opens an SSE request (Accept: text/event-stream) and hands the response
body to a new PlanStream.
sendStepDecision
StepDecision has:
string
required
ID of the plan the step belongs to.
number
required
Version of the plan (positive integer).
number
required
1-based step number the decision applies to.
'retry' | 'stop' | 'edit_request'
required
What to do with the step.
string
New intent text. Required when
action is 'edit_request'.CoreApiChatResponse is the same union a chat turn returns. Narrow success with
"status" in response && response.status === 200.
PlanStream
PlanStream parses SSE frames from a ReadableStream<Uint8Array>, validates each frame against
the shared telemetry-event schema, and dispatches planning events to typed handlers. Unknown event
types are silently ignored for forward compatibility, and stream consumption is deferred to the
next microtask so you can register handlers synchronously right after construction.
PlanStreamOptions:
() => void
Called when the stream closes normally.
(error: Error) => void
Called on a connection- or parsing-level error.
Methods
The stream returned by
executePlan is constructed without PlanStreamOptions, so it reports
server-sent problems through the error event and closes automatically when the stream ends. To
observe connection- or parsing-level failures (network drop, malformed SSE) or to run a close hook,
construct PlanStream directly with onError / onClose.Plan event vocabulary
on() accepts every planning event plus the stream-control types connected, stream_end,
and error.
Lifecycle events
plan_generating— plan generation started (messageCount)plan_generated— plan ready (planId,version,stepCount,complexity,isExecutable,autoExecutable,hasConflicts)plan_step_started— a step began (planId,stepNumber,description,operationType)plan_step_retrying— a step attempt failed and a retry is scheduled (stepNumber,attempt,maxRetries,phase)plan_step_completed— a step finished (stepNumber,status:completed|failed|skipped)plan_invalidated— the plan can no longer continue (reason,failedStepNumber)replan_started— re-planning started (previousPlanId,reason,preservedStepCount)replan_complete— re-planning produced a new plan (previousPlanId,newPlanId,newVersion)plan_execution_complete— execution finished (status:complete|partial|failed,completedSteps,totalSteps)plan_expired— the plan or planning session expired before the next resume step (subject,blockedAction,expiredAt)
plan_step_simulated— a write step was simulated (simulationSuccess,simulationSummary)plan_step_verification_passed— the verifier accepted the simulation (confidence,reason)plan_step_verification_failed— the verifier rejected the simulation (confidence,reason,conflicts,recommendedAction)plan_execution_failed— execution failed fatally (error,phase)
PlanStreamHandlerFailure
If one of your registered handlers throws while processing an event, PlanStream wraps the thrown
error in a PlanStreamHandlerFailure and forwards it to onError. The failure exposes the
eventType whose handler threw and preserves the original error as its cause, so a handler
throwing never breaks the stream or other handlers.