## Summary
- Restore yielded output when an observation receiver disappears before
delivery.
- Preserve pending-frontier output and tool IDs across failed delivery.
- Add dropped-observer coverage for yield and pending observations.
## Why
Canceling a wait must not consume output or a pending frontier that the
caller never received.
## Impact
A later observation can recover undelivered incremental output without
duplication.
## Validation
- Stack-tip validation: `just test -p codex-code-mode -p
codex-code-mode-protocol` (70 passed).
- Parent branch:
`cconger/code-mode-runtime-compact-03e-shutdown-hierarchy`.
## Summary
- Introduce a single cell terminal-state machine for completion and
termination.
- Make stored-value commits atomic with the winning terminal outcome.
- Buffer terminal results for later observation and cover
termination-before-commit behavior.
## Why
Completion, termination, observation, and stored-value updates must
agree on one linearized outcome under cancellation races.
## Impact
Terminal delivery becomes deterministic and terminated cells cannot
commit state after termination wins.
## Validation
- Focused terminal-state regression passed.
- Stack-tip validation: `just test -p codex-code-mode -p
codex-code-mode-protocol` (70 passed).
- Parent branch:
`cconger/code-mode-runtime-compact-03b-session-runtime`.
## Summary
- introduce a private `session_runtime` boundary for cell creation
requests, observation modes, lifecycle events, output items, and tool
metadata
- update the cell actor and in-process service to use those
transport-neutral types
- keep cell ID allocation on the owning session side
## Motivation
Cell lifecycle vocabulary currently lives inside the cell actor
implementation. That makes the service adapter and future session
runtime depend on actor-specific types, increasing the size and
complexity of the runtime ownership change.
This is the first reviewable slice of the session-runtime stack. It
separates the transport-neutral data model without moving lifecycle
ownership or changing behavior.
Later slices will move session state behind this boundary, harden
terminal and shutdown behavior, and split cell creation from
observation.
## Behavior
There are no public API or user-visible behavior changes in this PR.
In particular:
- `CodeModeSession::execute` and `wait` are unchanged
- cell IDs remain allocated by the owning session
- cell admission, observation, termination, and shutdown behavior are
unchanged
A code-mode cell is a single JavaScript execution that can produce
output, call tools, wait for asynchronous work, resume, or be
terminated. This PR extracts the existing per-cell run loop into a
dedicated actor that owns the cell’s lifecycle state. It is primarily an
ownership change rather than a new lifecycle contract: existing behavior
now has one clear implementation boundary.
### Architecture
The session service remains responsible for session-wide concerns:
allocating cell IDs, storing shared values, creating cells, and routing
requests to them.
Once a cell is created, its execution state belongs to its actor.
Callers interact with the actor through a handle. The actor receives two
kinds of input: runtime events and control requests.
A single event loop serializes these inputs and applies the lifecycle
rules. It tracks the current observer—the caller waiting for an
update—along with accumulated output, outstanding callbacks, runtime
state, yield deadlines, and termination progress. Observation,
termination, completion, and cleanup therefore have one consistent
owner.
When the runtime has no immediately runnable work and is waiting only on
timers or tool results, the actor can return accumulated output and
information about outstanding tool calls while keeping the cell
available to resume. On completion or termination, it performs the
appropriate callback cleanup before publishing the final result and
removing the cell from the session.
A small host interface connects the actor to session-owned facilities
such as tool dispatch, notifications, stored values, and final cell
removal, keeping those responsibilities outside the actor itself.
### Why
Previously, cell lifecycle state and coordination lived alongside
session management. The actor boundary makes each cell a self-contained
state machine with a single writer, while the service becomes a registry
and adapter around it.
This makes lifecycle behavior easier to reason about and test in
isolation. It also establishes a clean boundary for later changing where
cells run or how they communicate without recreating their lifecycle
rules.
Channing CongerandGitHub