Sessions & multi-turn¶
Since 0.8.0 a run can hold a conversation. When the planner emits
ask_user, the run parks at waiting_for_user — and the host answers it by
resuming with the reply:
The kernel stamps the reply as a durable user Message, emits a
user_message event, and continues the loop. Replies are replay-covered:
state.messages reconstructs exactly from the event log (the same is true for
kernel-injected reflection messages). Context-driven memory recall picks the
latest user message up automatically, so recall retargets to the answer.
The Session convenience¶
createSession / create_session wraps one task's lifecycle, including its
clarification turns:
After a terminal status the session is sealed (SESSION_COMPLETED) — a new
task is a new session. Approval and schedule waits are host workflows, not user
turns, so send refuses them (SESSION_NOT_AWAITING_USER).
Long-lived runs across upgrades¶
Runs persisted under an older schema version now migrate on load: the durable
stores (state-file, state-postgres) upgrade the snapshot along the known
version chain (option migrate, default on), so a run parked last month
resumes under this month's kernel. Unknown versions still fail hard — migration
is a designed path, not a guess.