Commit db3be62

This is the proposed V2 model for prompt admission, visible transcript history,

and optimistic TUI rendering.

Before the embedded V2 runner slice, a new prompt was written directly into

visible transcript history. The loop reloaded history and inferred whether work

remained by comparing the latest user and assistant messages.

This made accepted input and model-visible history the same thing. It also made

message ID ordering carry more responsibility than it should.

V2 separates accepted input from visible transcript history:

The two sequence fields answer different questions:

| Field | Meaning |

| --------------------- | -------------------------------------------------------------------------- |

| `session_input.seq` | In what order did OpenCode accept pending inputs? |

| `session_message.seq` | At what durable Session event position did this row enter visible history? |

`session_message.seq` is immutable. Later text, tool, or settlement events may

update a projected assistant row without moving it through the transcript.

seq: integer().notNull()

A default `steer` input joins the active activity at the next safe provider-turn

boundary. The TUI can show it inline immediately as pending, then reconcile that

same row in place when promotion assigns the canonical transcript `seq`.

Breadboard sketch while the assistant is still streaming:

After the checkpoint, the row stays where it appeared:

The stable input ID lets the TUI replace pending state with the promoted

`session_message` row instead of inserting a second bubble.

An explicit `queue` input belongs to a future activity. The TUI should show it in

a queue tray until the current activity settles. Only then does the runner promote

one queued input into visible transcript history.

After the current activity settles, promote one queued input:

IDs identify rows. Timestamps describe authored time. Neither is canonical

visible-history order once admission and promotion are separate.

Storing the creator event sequence directly on the `session_message` projection:

- keeps context assembly and pagination indexed on the smaller transcript table

- keeps compaction boundaries aligned with durable Session order

- avoids scanning the denser event log before every provider turn

- lets future event retention differ from transcript retention

The pending inbox is not a complication caused by transcript `seq`. It is the

domain model: accepted input and model-visible history are separate lifecycle

stages.

Historical experimental builds could write `session_message` rows without durable

creator events. Those rows cannot be assigned truthful transcript order.

Before V2 launch, reset only that experimental projection before adding `seq`:

DELETE FROM session_message;

ALTER TABLE session_message ADD COLUMN seq INTEGER NOT NULL;

Canonical V1 history remains in `message` and `part`.

The storage split should stay internal. A TUI-facing snapshot can combine both

lanes explicitly:

type SessionTimeline = {

messages: SessionMessage[]

pendingInputs: SessionInputReceipt[]

}

See [`session-inbox-ordering.md`](./session-inbox-ordering.md) for the proposed

prompt inbox, transcript ordering, and optimistic TUI rendering model.