Sessionbus v0.5.7 — messages wake managed lanes
An ordinary message to an idle managed lane now starts a run automatically. This applies to fresh lanes, resumed lanes and previously stored lanes. The legacy idle_message: stage input remains readable for compatibility but is normalized to run; it no longer disables waking.
When a product can admit input safely into its current native turn, it continues to do so. When the product confirms that nothing was submitted, the daemon can retain the message in a bounded in-memory queue, acknowledge queued_for_next_turn immediately, and start the next run automatically after the current run finishes. This prevents two active lanes sending to each other from waiting indefinitely for each other's turn to end. Uncertain native writes are never retried.
A queued receipt confirms scheduled retention, not native consumption or durable storage. Scheduled inputs reserve retained-result capacity; explicit starts cannot take those reservations. Capacity exhaustion is an explicit error. Close or disconnect can discard queued inputs; native admission and loss are recorded when communication logging is enabled. Collect and acknowledge completed runs to release result capacity.
Completion notifications still wake recipients. A run started by an automatic completion notification does not emit another automatic completion notification, bounding notification loops. Explicit messages sent by the model remain ordinary messages.
Upgrade the hub, host daemons and product integrations together. Managed products must advertise message-triggered run support. Automatic completion notifications require the new negotiated federation capability; an older link refuses those notifications explicitly. Ordinary messaging retains compatibility with older links.
The matching JavaScript kit is @sessionbus/kit@0.5.7. Interactive peers own their native wake mechanism; their corresponding product releases and installed acceptance results must accompany the rollout.
This release supplies the daemon and SDK behavior. Product-specific installed acceptance and coordinated host rollout remain separate; publication alone does not establish that every installed interactive product wakes.