docs(core): refresh session architecture

AGENTS.md

@@ -175,14 +175,14 @@ const table = sqliteTable("session", {
 ## V2 Session Core
 
 - Keep durable events minimal: record irreducible new facts and do not repeat state derivable by folding the ordered aggregate history. Enrich projections and read models with previous or derived state when consumers need self-contained views.
-- Keep durable prompt admission separate from model execution. `SessionV2.prompt(...)` admits one durable `session_pending` row before scheduling advisory `SessionExecution.wake(sessionID)` unless `resume: false` requests admit-only behavior. The serialized runner promotes admitted inputs into visible user messages at safe boundaries, consuming the pending row in the same event transaction; `session_pending` stores only unconsumed work.
-- Reusing a Session ID adopts the existing Session. Reusing a prompt message ID reconciles an exact retry only when Session, prompt, and delivery mode match; conflicting reuse fails. Retry of an already-promoted input reconciles against the projected message and the durable admitted event rather than a retained row.
+- Keep durable prompt admission separate from model execution. `Session.prompt(...)` publishes `session.inbox.enqueued`, whose projection inserts one durable `session_inbox` row, before scheduling advisory `SessionExecution.wake(sessionID)` unless `resume: false` requests admit-only behavior. Delivery publishes `session.inbox.delivered`; its projection consumes the inbox row and inserts the visible message in the same transaction. `session_inbox` stores only unconsumed work.
+- Reusing a Session ID adopts the existing Session. While a user or synthetic inbox item is pending, reusing its ID reconciles only when Session, type, complete payload, metadata, and delivery match; conflicting reuse fails. Once delivered, retry reconciliation for those message-producing items uses the projected message and does not require retained enqueue history or the original delivery mode. Control items keep their operation-specific conflict behavior.
 - Keep `SessionExecution` process-global and Session-ID based. Its local implementation owns the process-local Session coordinator and discovers placement through `SessionStore` plus `LocationServiceMap.get(session.location)` only when a drain starts; no layer should take a Session ID. V2 interruption targets the active process-local ownership chain for that Session; interruption of a known but idle or locally unowned Session is a no-op, while the public API rejects an unknown Session.
 - Keep `SessionRunner`, model resolution, tool registry, permissions, and filesystem Location-scoped. Omitted `Location.workspaceID` means implicit-local placement; explicit workspace identity remains reserved for future placement semantics.
-- Preserve one explicit `llm.stream(request)` call per Physical Attempt and reload projected history before durable continuation. Most Steps have one Physical Attempt; overflow-triggered compaction recovery may rebuild one Step for a second attempt. Do not bridge through legacy `SessionPrompt.loop(...)` or delegate orchestration to an in-memory tool loop.
-- Keep local Session drains process-local until clustering is implemented. `SessionRunCoordinator` joins explicit same-Session resumes, coalesces prompt wakeups, and allows different Sessions to run concurrently. Advisory wakes drain eligible durable inbox rows only; post-crash continuation recovery requires a separate explicit design before it may retry provider work. A drain has no durable identity or transcript boundary.
-- Keep delivery vocabulary explicit. Prompts steer by default and promote at the next safe step boundary while the current drain requires continuation. An explicit `queue` input remains pending until the Session would otherwise become idle; promote one queued input at that boundary, then reevaluate continuation before promoting another. Promoting any new user input resets the selected agent's step allowance; a batch of steers resets it once.
+- Preserve one explicit `llm.stream(request)` call per Physical Attempt and reload projected history before durable continuation. A logical Step may use generic pre-output retries, one full-context retry after continuation rejection, incomplete-stream continuation, or one overflow-compaction rebuild. Generic retries retain the logical step number and do not consume another agent-step allowance. Do not bridge through legacy `SessionPrompt.loop(...)` or delegate orchestration to an in-memory tool loop.
+- Keep local Session drains process-local until clustering is implemented. `SessionRunCoordinator` joins explicit same-Session resumes, coalesces prompt wakeups, and allows different Sessions to run concurrently. A write-ahead execution claim marks a process-local busy period for restart recovery: terminal completion, failure, or user interruption releases it, while shutdown interruption and process death preserve it. Startup recovery resumes claimed top-level Sessions with durable per-execution attempt accounting. The claim is a recovery marker, not clustered ownership, fencing, or an exactly-once guarantee.
+- Keep delivery vocabulary explicit. Prompts steer by default. Steers deliver in enqueue order at safe step boundaries, stopping before compaction or move control items. At an idle boundary, steers take priority; otherwise exactly one queued item delivers before the runner reevaluates continuation. Inbox items may be cancelled or changed between queue and steer before delivery. Promoting new user input resets the selected agent's step allowance; a batch of steers resets it once.
 - One step is one logical LLM call; its durable record covers only the model-visible span. Do not write "provider turn", and do not use bare "turn" for a single call: "turn" is reserved for the future assistant-turn unit containing all steps from prompt promotion until the session would go idle.
-- Keep EventV2 replay owner claims separate from clustered Session execution ownership.
+- Keep event replay ownership separate from clustered Session execution ownership.
 - Keep the Instructions algebra and built-ins in `src/instructions`; keep instruction producers with their observed domains, and keep Session History selection plus `InstructionState` and `InstructionEntry` persistence Session-owned. `InstructionDiscovery` observes ambient global and upward-project instructions. The runner composes built-ins, discovery, guidance, and entries explicitly in `loadInstructions`; there is no instruction registry.
-- `session.instructions.updated` stores only changed source keys and content hashes. Blob values live once in `instruction_blob`; `instruction_state` is a rebuildable fold cache, never primary state. Render initial instructions and chronological updates from values during request assembly. Completed compaction moves the instruction epoch; Session movement retains it so destination instruction changes are chronological, while committed revert clears it. Unavailable sources retain the last value and block only the initial complete delta.
+- `session.instructions.updated` stores changed source keys and content hashes and may freeze rendered chronological update text. Blob values live once in `instruction_blob`; the projected `instruction_state` row is the normal boundary-processing source of current and initial values. Request assembly renders the epoch baseline from stored values, while later frozen updates enter history as durable System messages. Completed compaction moves the instruction epoch; Session movement retains it so destination instruction changes are chronological, while committed revert clears it. Forks adopt the parent's newest instruction values even when copied message history ends at an earlier boundary. Unavailable sources retain the last value and block only the initial complete delta.

docs/design/service-lifecycle.md

@@ -27,8 +27,9 @@ exits before expensive server boot. The design does not require clients to
 agree on a single initiator.
 
 This proposal does not introduce a supervisor process, warm candidate server,
-protocol negotiation, idle background restart, or general execution-recovery
-framework.
+protocol negotiation, idle background restart, or clustered or exactly-once
+execution recovery. Session execution separately provides bounded local recovery
+through durable write-ahead claims.
 
 ## Architecture at a Glance
 
@@ -176,9 +177,9 @@ This design gives each concept one authority.
 - Adding a permanent steward, proxy, or supervisor process.
 - Zero-downtime worker handoff or automatic rollback.
 - Application protocol negotiation or automatic TUI self-restart.
-- General hard-crash recovery for active Sessions.
-- Defining recovery semantics for provider attempts, tools, shells, sub-agents,
-  permissions, questions, or background jobs.
+- Exactly-once recovery for provider attempts, tools, shells, sub-agents,
+  permissions, questions, or background jobs. Top-level Session continuation
+  after process death is handled separately through durable execution claims.
 - Automatically killing a frozen owner.
 - Bounding concurrent location cold boots after clients reconnect.
 - Multi-machine or clustered service placement.
@@ -202,9 +203,10 @@ This design gives each concept one authority.
    diagnosed, non-retryable cause.
 8. **Clients do not kill an unresponsive owner automatically.** Destructive
    recovery requires the explicit `service restart` command.
-9. **Lifecycle does not promise execution semantics.** Graceful replacement
-   invokes Session suspension and resumption hooks, but tool-level continuity
-   belongs to a separate design.
+9. **Lifecycle does not promise exactly-once execution.** A successor invokes
+   the Session execution-claim sweep, which resumes from durable history.
+   Provider-attempt identity and tool-side-effect fencing belong to separate
+   designs.
 
 ## System Model
 
@@ -485,23 +487,20 @@ The UI derives text from status:
 | `failed`                 | Actionable failure message          |
 | `ready`                  | Normal TUI                          |
 
-## Graceful Session Continuity
+## Session Continuity
 
-Version-mismatch replacement uses the existing graceful Session suspension and
-resumption hooks:
+Every process-local Session busy period writes a durable execution claim before
+its runner starts. Success, failure, and user interruption release the claim;
+shutdown interruption and process death leave it intact. The
+successor sweeps claimed top-level Sessions, durably counts a recovery attempt,
+appends a continuation instruction, and resumes from projected history. The same
+mechanism covers graceful replacement, crash, SIGKILL, and runtime eviction.
 
-1. The old server snapshots active Session IDs during graceful teardown.
-2. The successor schedules those Sessions for continuation.
-3. The runner reloads durable Session history before continuing.
-
-This lifecycle design does not define what an interrupted physical provider
-attempt or tool invocation means. It does not promise that external side effects
-did not occur, replay the exact interrupted tool, preserve an in-memory form, or
-recover process-local background work.
-
-Those concerns require a separate execution-continuity design covering tools,
-shells, sub-agents, permissions, questions, provider attempts, and hard-crash
-recovery.
+Recovery fails stale running tool projections before further model work, but it
+does not prove whether an interrupted provider request or external operation
+already took effect. It does not replay the exact interrupted tool, preserve an
+in-memory form, recover process-local background work, or guarantee exactly-once
+provider or tool behavior.
 
 ## Unresponsive Owner
 
@@ -531,13 +530,15 @@ Automatic frozen-owner recovery is deferred.
 
 1. The old service installs vNext but keeps running.
 2. A fresh vNext TUI finds the healthy vOld service and requests graceful stop.
-3. The old service reports `stopping`, suspends active Sessions, and exits.
+3. The old service reports `stopping` and exits. Shutdown interruption preserves
+   the execution claims already written by active Sessions.
 4. Open TUIs enter their indefinite status loops.
 5. One or more clients spawn contenders.
 6. One contender acquires the service lock. Losers exit before heavy boot.
 7. The winner binds and registers the lifecycle shell as `starting`.
 8. Clients stop spawning and wait on the observable winner.
-9. The winner initializes the application and reports `ready`.
+9. The winner initializes the application, sweeps orphaned execution claims,
+   and reports `ready`.
 10. TUIs rebuild clients, reconcile state, and resume.
 
 ### Server crashes while ready
@@ -546,7 +547,9 @@ Automatic frozen-owner recovery is deferred.
 2. Clients call `ensureRunning`.
 3. Process death has released the service lock.
 4. One contender wins, replaces registration, and starts normally.
-5. Detailed active-execution recovery is outside this design.
+5. Application startup sweeps orphaned top-level execution claims and resumes
+   them with bounded attempt accounting. External side effects remain
+   potentially ambiguous.
 
 ### Winner crashes during startup
 
@@ -650,8 +653,9 @@ was the observed incident cost.
    `packages/client` with `bun run generate`.
 6. **Codify launch versus reconnect.** Fresh launch enforces installed version;
    reconnect never activates replacement.
-7. **Integrate graceful replacement.** Preserve current background-install and
-   fresh-launch activation behavior while invoking Session continuity hooks.
+7. **Integrate Session continuity.** Preserve current background-install and
+   fresh-launch activation behavior while invoking startup execution-claim
+   recovery.
 8. **Harden explicit recovery.** Verify exact process identity during explicit
    `service restart`; never automatically kill an unresponsive owner.
 9. **Run the full multi-process suite.** Include repeated restart cycles and
@@ -677,7 +681,8 @@ was the observed incident cost.
 
 - Idle background update activation with an admission fence.
 - Application protocol compatibility and automatic local TUI re-exec.
-- Durable execution recovery for provider attempts and tools.
+- Stronger execution recovery with provider-attempt identity, tool-side-effect
+  idempotency or fencing, and clustered ownership.
 - Shell, sub-agent, permission, question, and background-job continuity.
 - Automatic recovery for a positively identified frozen owner.
 - Cold-boot concurrency limits and interaction-prioritized location loading.

packages/www/content/docs/(Configure)/compaction.mdx

@@ -119,17 +119,18 @@ not included in model context.
 ## Compaction advances the instruction epoch
 
 Conversation compaction and instruction synchronization are separate. Before
-promoting pending input, V2 compares live instruction sources with the latest
-admitted values. Ordinary changes become durable value deltas; their
-model-facing System messages are derived during request assembly rather than
-persisted.
+each physical model attempt, V2 compares live instruction sources with the
+latest admitted values, before delivering pending input for that attempt.
+Ordinary changes become durable value deltas. Later changes freeze their
+model-facing text when admitted and project it as chronological System messages;
+request assembly renders only the epoch baseline from stored values.
 
 Completed compaction advances the instruction epoch at the exact ended-event
 sequence and makes the currently admitted values initial. It does not reread
-sources or publish an instruction event. Session movement and committed revert
-clear the instruction fold so the next safe boundary requires one complete
-source read. See [Instructions](/instructions) for source ordering and update
-behavior.
+sources or publish an instruction event. Session movement retains instruction
+state so destination changes become chronological updates. Committed revert
+clears instruction state so the next model attempt requires one complete source
+read. See [Instructions](/instructions) for source ordering and update behavior.
 
 ## Current limitations
 

packages/www/content/docs/(Configure)/instructions.mdx

@@ -102,8 +102,9 @@ than part of the initial instructions.
 
 ## Changes
 
-Before promoting pending input, V2 compares live instruction sources with the
-latest admitted source values:
+Before each physical model attempt, V2 compares live instruction sources with
+the latest admitted source values. This comparison happens before pending input
+is delivered for that attempt:
 
 - A new or changed ambient `AGENTS.md` aggregate is announced as a system update
   that replaces the previous ambient aggregate.
@@ -115,10 +116,13 @@ latest admitted source values:
 - Completed conversation compaction advances the instruction epoch, making the
   currently admitted values initial without rereading sources or authoring an
   instruction event.
-- Moving a session or committing a revert clears the instruction fold. The next
-  safe boundary requires one complete source read before promoting input.
-
-The durable event stores changed source keys and value hashes, not rendered
-prose. During request assembly, OpenCode renders the epoch's initial values and
-interleaves later changes as chronological System messages. Clients see changed
-keys but never the privileged value bodies.
+- Moving a session retains instruction state, so destination changes become
+  chronological updates. Committing a revert clears instruction state; the next
+  model attempt requires one complete source read before delivering input.
+
+The durable event stores changed source keys and value hashes. Initial baseline
+events contain no rendered prose. Later changes render once when admitted and
+freeze that optional text in the event, which projects it as a chronological
+System message. During request assembly, OpenCode renders the epoch's initial
+values and reuses projected update messages verbatim. Clients see changed keys
+but never the privileged value bodies.

specs/v2/README.md

@@ -27,12 +27,11 @@ Generated clients follow the assembled public `HttpApi`. GitHub issues own activ
 
 ## Decisions And Proposals
 
-| Document                                                          | Status                     | Job                                                                          |
-| ----------------------------------------------------------------- | -------------------------- | ---------------------------------------------------------------------------- |
-| [Event stream](./event-stream-architecture.md)                    | Accepted and implemented   | Record why public events use one encoded feed with independent queues.       |
-| [Managed restart continuation](./session-restart-continuation.md) | Accepted and implemented   | Record why graceful managed-service restart uses private Session suspension. |
-| [Instruction sync](./instruction-sync-proposal.md)                | Accepted and implemented   | Record why instruction state is value deltas plus derived rendering.         |
-| [Provider policy](./provider-policy.md)                           | Proposed and unimplemented | Explore provider authorization independently from provider configuration.    |
+| Document                                                          | Status                     | Job                                                                         |
+| ----------------------------------------------------------------- | -------------------------- | --------------------------------------------------------------------------- |
+| [Event stream](./event-stream-architecture.md)                    | Accepted and implemented   | Record why public events use one encoded feed with independent queues.      |
+| [Managed restart continuation](./session-restart-continuation.md) | Superseded decision record | Preserve the graceful-only design replaced by write-ahead execution claims. |
+| [Provider policy](./provider-policy.md)                           | Proposed and unimplemented | Explore provider authorization independently from provider configuration.   |
 
 ## Historical Context
 

specs/v2/instruction-sync-proposal.md

@@ -1,154 +0,0 @@
-# Instruction Sync: V2 Architecture
-
-Status: implemented on `instruction-sync-v2` (2026-07-10).
-
-## Principle
-
-The model is a replica that OpenCode can write but cannot read or edit. The transcript is the one-way channel. Instruction sync keeps mutable privileged context (`AGENTS.md`, guidance, API entries, date, and environment) current over that channel without rewriting text that was already sent.
-
-**The durable log stores only irreducible facts: which source values changed, and when. Everything else is a function of the log and current renderer code.**
-
-## Durable Fact
-
-```typescript
-"session.instructions.updated.2" {
-  sessionID: Session.ID
-  delta: Record<Instructions.Key, Instructions.Hash | "removed">
-}
-```
-
-A hash overwrites one source value. The literal `"removed"` removes it (chosen over JSON `null` because record-value nullability does not survive every client generator; it cannot collide with a 64-hex hash). The event stores no rendered text, mode, baseline, or snapshot.
-
-Each hash body is canonical JSON stored once in the machine-local `instruction_blob` table. Hashes are local pointers, not cross-machine promises.
-
-## Epochs And Folds
-
-An instruction epoch is the span between completed compactions. `epochStart` is the sequence of the last `session.compaction.ended`, or the initial complete v2 delta when no epoch exists.
-
-Folding deltas in durable sequence order derives:
-
-```text
-values through epochStart  -> renderInitial -> initial instructions
-each delta after epochStart -> renderUpdate  -> chronological System message
-final values                                  -> next boundary comparison state
-```
-
-Completed compaction moves the epoch by copying current hashes to initial hashes at the exact ended-event sequence. It does not read sources or publish an instruction event.
-
-Session movement and committed revert clear the fold. The next boundary must establish one complete delta before input promotion.
-
-## Projection Cache
-
-```text
-instruction_state
-  session_id
-  epoch_start
-  through_seq
-  initial_values
-  current_values
-```
-
-This row is derived state. The boundary compares `through_seq` with the latest relevant durable sequence. A missing or stale row folds the log and rewrites the cache without publishing an event.
-
-The relevant reducer inputs are:
-
-- `session.instructions.updated.2`: apply the delta; the first one establishes an epoch, including an empty complete delta.
-- `session.compaction.ended.1`: make current values initial and move `epochStart`.
-- `session.moved.1`: clear values.
-- `session.revert.committed.1`: clear values.
-- `session.forked.2`: derive from parent ancestry through its frozen `parentSeq`.
-
-## Sources
-
-```typescript
-interface Source {
-  readonly key: Key
-  readonly read: Effect<Json | Unavailable | Removed>
-  readonly initial: (value: Json) => string | undefined
-  readonly changed: (previous: Json, current: Json) => string | undefined
-  readonly removed: (previous: Json) => string | undefined
-}
-
-namespace Source {
-  interface Definition<A> {
-    readonly key: Key
-    readonly codec: Schema.Codec<A, Json>
-    readonly read: Effect<A | Unavailable | Removed>
-    readonly render: {
-      readonly initial: (value: A) => string
-      readonly changed: (previous: A, current: A) => string
-      readonly removed?: (previous: A) => string
-    }
-  }
-}
-
-type Instructions = ReadonlyArray<Source>
-
-declare function make<A>(definition: Source.Definition<A>): Instructions
-```
-
-Producers author a typed `Source.Definition<A>`. `make` captures its codec and renderers in one JSON-level `Source`, the representation used for heterogeneous composition, durable values, and historical rendering. `Instructions` is an ordered collection of those sources; combining collections preserves order and rejects duplicate keys.
-
-`read` runs once per source at the safe boundary, never at layer construction or request assembly. Codecs must be canonical: object keys are canonicalized by the hash function, while source-owned collections must have deterministic order and values must not contain observation timestamps.
-
-`Unavailable` means the read failed temporarily. The initial complete delta blocks while any source is unavailable; later boundaries retain its prior hash silently.
-
-`Removed` is an observed absence. If the key currently has a value, the next delta stores `"removed"` and assembly calls the source's removal renderer. A source that disappears from a software upgrade does not imply removal; its retained value becomes invisible while its renderer is absent.
-
-## Safe Boundary
-
-Once per physical attempt, before input promotion:
-
-1. Load the selected agent and compose built-ins, discovery, skill guidance, reference guidance, MCP guidance, and API entries in fixed order.
-2. Read every source concurrently exactly once.
-3. Encode and hash values; compare with `instruction_state.current_values`.
-4. At the initial v2 boundary, require a complete read and admit one complete delta, including `{}` for a truly empty set.
-5. For later boundaries, insert new blobs and admit one delta only when a hash or explicit removal changed.
-6. Promote pending input.
-7. Read projected messages, epoch values, blobs, and post-epoch deltas in one database transaction.
-8. Render initial instructions and interleave derived update messages by durable sequence.
-
-`MoveSession` interrupts any active drain and awaits idle before publishing `session.moved`, matching the best-effort ordering used by Session removal.
-
-The blob inserts, durable event, and fold-cache advance share the event transaction.
-
-## Forks
-
-`session.forked.2` carries `parentSeq`, the authoritative parent event cutoff. For a fork before message N, the cutoff is `message.seq - 1`, so instruction changes admitted immediately before that message are inherited while later parent state is not.
-
-The child stores the cutoff as `session.fork_seq`. Its virtual instruction log is the parent's ancestry through that cutoff followed by child events. Child event sequence reservation begins after the cutoff, preserving chronological interleaving with copied message rows. Replay accepts the intentional fork gap because the fork projector reserves the inherited prefix before later child events replay.
-
-## API Entries
-
-Each visible entry is one `api/<key>` source. DELETE marks the row as a hidden tombstone rather than physically removing it, preserving the renderer needed to admit and narrate the removal; list responses hide tombstones. The nullable value column preserves JSON `null`, while the separate tombstone flag distinguishes removal. A later PUT revives the same source.
-
-PUT measures encoded JSON in UTF-8 and rejects values larger than 8KB with `InstructionEntryValueTooLargeError` (HTTP 413). Values are never truncated.
-
-## Content-Addressed Storage
-
-The blob store grows by one row per distinct encoded value. No GC ships initially. This is an at-rest deduplication policy; deleting a Session does not remove values only that Session referenced, so clients must not put secrets in API entries.
-
-If retention becomes necessary, add mark-and-sweep: walk live v2 deltas for referenced hashes and delete the rest. No schema change or eager reference counter is required.
-
-The blob store is machine/tenant scoped and must never deduplicate across tenants.
-
-**Storage format is not wire format.** Any future V2 sync, export, share, or workspace-transfer boundary must hydrate referenced values, verify each body against its hash on ingestion, and insert blobs before replaying the event. Current V2 has no cross-machine durable replay surface; hashes are sufficient for local event logs and key-only clients.
-
-## Client Projection
-
-Instruction deltas do not project `session_message` rows. The TUI derives a non-model-facing notice from event keys, for example `Instructions updated: core/date, api/plan`. Model-facing update prose exists only during runner assembly and is excluded from compaction summaries.
-
-## Migration
-
-Migration deletes pre-beta `session.instructions.updated.1` events and their event-derived System rows, then drops `instruction_checkpoint`. It leaves unrelated events and System messages intact. The next safe boundary establishes one complete v2 delta.
-
-Existing `session.forked.1` rows migrate to v2 with the event prefix reserved by their original projection as `parentSeq`.
-
-## Accepted Costs
-
-- Renderer changes can change request bytes for identical stored values, causing one provider-cache miss. They do not create an instruction delta.
-- Rendered text is not retained verbatim.
-- Source additions or software removals are silent unless a source explicitly reads `Removed`.
-- Clients display changed keys, not privileged prose.
-- Blob GC is deferred.
-- Pre-beta instruction events are deleted during migration; logs with resulting sequence gaps are not guaranteed to replay into a blank database.

specs/v2/session-restart-continuation.md

@@ -2,12 +2,25 @@
 
 | Field          | Value                                                        |
 | -------------- | ------------------------------------------------------------ |
-| Status         | Accepted and implemented                                     |
+| Status         | Superseded by write-ahead execution claims                   |
 | Author         | Kit Langton                                                  |
 | Date           | 2026-07-08                                                   |
+| Superseded     | 2026-08-14                                                   |
 | Tracking issue | [#35646](https://github.com/anomalyco/opencode/issues/35646) |
 
-## Summary
+## Current Decision
+
+Session execution now writes a durable claim when a process-local busy period starts. Success, failure, and user interruption release the claim. Shutdown interruption and process death preserve it, so graceful restart, crash, SIGKILL, and runtime eviction have the same durable recovery signature.
+
+On startup, managed Node and fetch runtimes sweep claimed top-level Sessions. Recovery increments a durable attempt counter, appends a continuation instruction, and resumes from projected history. The claim remains until a terminal event releases it, so another process death remains recoverable. After ten automatic recovery attempts by default, the next sweep records terminal failure instead of creating a restart loop.
+
+The historical `time_suspended` column now stores this execution claim, and `resume_attempts` counts automatic recovery attempts against the runtime's configured budget. A claim is a recovery marker, not live status, a lock, clustered ownership, or an exactly-once guarantee. Recovery fails stale running tool projections before further model work, but it cannot prove whether an interrupted provider request or external side effect already took effect.
+
+See the current [Session contract](./session.md) and the implementation in `packages/core/src/session/execution.ts` and `packages/core/src/session/execution/restart.ts`.
+
+## Original Summary
+
+The remainder of this document records the graceful-only suspension design that first implemented issue #35646. It is retained as design history and does not describe the current recovery mechanism.
 
 When the managed OpenCode server shuts down gracefully, active Sessions continue automatically the next time the managed server starts.
 

specs/v2/session.md

@@ -1,12 +1,12 @@
 # V2 Session Contract
 
-Status: **Current semantic overview.** Protocol owns public operations, Schema owns public shapes and durable events, and Core owns execution and persistence behavior. [CONTEXT.md](../../CONTEXT.md) defines the canonical terms used here.
+Status: **Current semantic overview.** Protocol owns public operations, Schema owns public shapes and durable events, and Core owns execution and persistence behavior.
 
 ## Prompt Admission Precedes Execution
 
-`SessionV2.prompt(...)` records one durable `session.input.admitted` fact and one `session_pending` row before advisory execution begins. Pending input remains outside model-visible Session History until promotion. The promotion transaction publishes `session.input.promoted`, projects the visible message, and consumes the pending row atomically.
+`Session.prompt(...)` publishes one durable `session.inbox.enqueued` fact whose projection inserts one `session_inbox` row before advisory execution begins. An inbox item remains outside model-visible Session History until delivery. The `session.inbox.delivered` projection consumes the row and inserts a visible user or synthetic message atomically; compaction and move control items are consumed without becoming transcript messages.
 
-Reusing a Session ID adopts the existing Session. Reusing a prompt message ID reconciles an exact retry only when Session, prompt, and delivery mode match; conflicting reuse fails. A retry of an already-promoted input reconciles against projected history and its durable admission event.
+Reusing a Session ID adopts the existing Session. While a user or synthetic item remains pending, reusing its ID reconciles only when Session, item type, complete payload, metadata, and delivery match; conflicting reuse fails. After delivery, retry reconciliation for those message-producing items uses the projected message and does not require enqueue history or the original delivery mode. Compaction and move controls retain operation-specific conflict behavior.
 
 `resume` controls scheduling, not durability:
 
@@ -15,12 +15,12 @@ Reusing a Session ID adopts the existing Session. Reusing a prompt message ID re
 
 Delivery is explicit:
 
-- `steer` is the default. Steers promote together at the next Safe Step Boundary while the current Session Drain still requires continuation.
-- `queue` remains pending while the Session can continue. When the Session would otherwise become idle, one queued input promotes; the runner then reevaluates continuation before promoting another.
+- `steer` is the default. Steers deliver in enqueue order at the next Safe Step Boundary. Delivery stops before a compaction or move control item.
+- `queue` remains pending while the Session can continue. At an idle boundary, steers still take priority; otherwise one queued item delivers, followed by any steers that arrived during delivery. The runner then reevaluates continuation before another queued item.
 
 Promoting new user input resets the selected agent's step allowance. A batch of steers resets it once.
 
-Manual compaction uses the same pending store as one coalesced barrier. The barrier blocks later input promotion until compaction ends or fails, then is consumed.
+Manual compaction and Session movement use the same inbox as control items. Each request has its own inbox identity and delivery mode. A control item forms a delivery boundary so later steers do not cross it.
 
 ## Execution Is Process-Local
 
@@ -35,37 +35,37 @@ Manual compaction uses the same pending store as one coalesced barrier. The barr
 
 The public interrupt operation verifies that the durable Session exists. An unknown Session fails with `SessionNotFoundError`; a known Session that is idle, settled, or not locally owned is a no-op.
 
-`sessions.active()` snapshots foreground drains currently owned by this process. Durable execution events are historical observations, not liveness or ownership records.
+`sessions.active()` snapshots busy periods currently owned by this process. Durable execution events and claims are historical and recovery records, not proof that this process is still live.
 
-The managed server provides graceful restart continuity through private Session suspension. Shutdown marks active Sessions before interrupting them; the next managed server atomically consumes each suspension and schedules at most one resume. Hard-crash recovery and exactly-once provider or tool execution remain out of scope. See [Managed restart continuation](./session-restart-continuation.md).
+Execution commits a write-ahead claim when a process-local busy period starts. Success, failure, and user interruption release the claim; shutdown interruption and unclean process death preserve it. On startup, managed Node and fetch runtimes resume claimed top-level Sessions, append a durable continuation instruction, and count recovery attempts. Recovery is bounded per claimed execution but does not guarantee exactly-once provider requests or tool effects. See [Session restart recovery](./session-restart-continuation.md).
 
-## One Step Owns One Logical LLM Call
+## One Step May Have Several Physical Attempts
 
-Before each Step, the runner reloads Session History, resolves the selected agent and model, prepares instructions, and materializes tools. Most Steps make one Physical Attempt; overflow-triggered compaction recovery may rebuild the same Step for one additional provider request.
+Before each Step, the runner reloads Session History, resolves the selected agent and model, prepares instructions, and materializes tools. Most Steps make one Physical Attempt. Generic retry, continuation-state rejection, incomplete-stream continuation, or overflow-triggered compaction may make another attempt without promoting input again.
 
 Each complete local tool call is durable before side effects begin. Local calls start eagerly and may run concurrently, but terminal outcome publication remains serialized. Every local and hosted call reaches durable success or failure before the Step publishes its single terminal ended or failed event.
 
-Tool calls belong to their assistant message. `callID` is unique only within that Step, so durable tool events also carry `assistantMessageID`.
+Tool calls belong to their assistant message. A tool-call `id` is unique only within that Step, so durable tool events also carry `assistantMessageID`.
 
-Before `runStep` assembles its provider request, orphan reconciliation fails tool calls still projected as streaming or running from an earlier process. It preserves the original assistant attribution and never replays ambiguous side effects.
+At drain start, orphan reconciliation fails tool calls still projected as streaming or running from an earlier process before further model work. It preserves the original assistant attribution and never directly replays ambiguous side effects.
 
 After a local outcome, continuation reloads projected history and begins a new Step. The runner never delegates orchestration to an in-memory tool loop.
 
 ## Retry Is Narrow And Observable
 
-Core retries typed rate-limit, provider-internal, and transport failures only before durable assistant content, tool-call, tool-output, or tool-execution evidence exists. The initial request plus at most four retries use exponential backoff, increased when the provider supplies a longer retry delay.
+Generic scheduled retry covers rate-limit and provider-internal failures, transport failures that are unsent or have unknown delivery, and provider output classified as an incomplete stream. The initial request plus at most four retries use jittered exponential backoff, increased when the provider supplies a longer retry delay.
 
-Each retry attempt is a distinct Step, consumes the selected agent's allowance, and reuses the assistant message ID while no durable output exists. `session.retry.scheduled` records the next attempt and absolute retry time. A later Step start or terminal failure clears projected retry state. Surviving retry history never triggers post-crash recovery by itself.
+Before durable output, generic retries retain the logical step number and assistant message ID and do not consume another agent-step allowance. An incomplete stream after durable output instead preserves the failed partial assistant, adds a synthetic continuation instruction, and continues with a new assistant message ID under the same retry budget. Provider continuation rejection permits one immediate full-context rebuild without a scheduled-retry event. `session.retry.scheduled` records generic backoff; later activity or a terminal execution event clears projected retry state.
 
 A normalized content-filter finish fails the Step. Any partial streamed content remains visible.
 
 ## Instructions Are Value Deltas
 
-Instruction sync persists values, never rendered privileged prose. The only durable fact is `session.instructions.updated { delta }`, mapping each changed source key to a SHA-256 content hash, with the literal `"removed"` for observed absence. Canonical JSON bodies live once in the machine-local `instruction_blob` store; `instruction_state` is a rebuildable fold cache, never primary state. The runner explicitly combines built-ins, ambient discovery, selected-agent skill guidance, references, MCP guidance, and API-managed instruction entries. There is no instruction registry.
+Instruction sync persists content-addressed values and may freeze rendered chronological prose. `session.instructions.updated { delta, text? }` maps each changed source key to a SHA-256 content hash, with the literal `"removed"` for observed absence. Canonical JSON bodies live once in the machine-local `instruction_blob` store. The projected `instruction_state` row supplies current and epoch-initial values during normal boundary processing. The runner explicitly combines built-ins, ambient discovery, selected-agent skill guidance, references, MCP guidance, and API-managed instruction entries. There is no instruction registry.
 
-At each Safe Step Boundary the runner reads every source concurrently exactly once, hashes encoded values, and admits one delta atomically with its new blobs before input promotion. The initial delta must be complete; an unavailable source blocks only that initial delta and otherwise silently retains the stored value. Initial instructions and chronological update messages are rendered from stored values during request assembly and are never persisted; clients display changed keys.
+Before each Physical Attempt that reaches model execution, the runner reads every source concurrently exactly once, hashes encoded values, and admits one delta atomically with its new blobs before input delivery. The initial delta must be complete; it carries no update text. An unavailable source blocks only that initial delta and otherwise silently retains the stored value. Request assembly renders the epoch baseline from stored values. Later changes render once at admission, freeze optional `text` in the durable event, and project that text as a chronological System message; clients display changed keys rather than privileged prose.
 
-An instruction epoch spans completed compactions. `session.compaction.ended` moves the epoch start to its exact sequence, making current values initial, without reading sources or authoring an instruction event. Session movement and committed revert clear the fold. Forks record an authoritative parent sequence and derive values from the parent's ancestry through that cutoff. Model selection affects request assembly but is not itself an instruction source. See the [instruction sync design](./instruction-sync-proposal.md).
+An instruction epoch spans completed compactions. `session.compaction.ended` moves the epoch start to its exact sequence, making current values initial, without reading sources or authoring an instruction event. Session movement retains state so destination changes become chronological updates; committed revert clears state so the next boundary establishes a fresh baseline. A fork copies messages only through its selected boundary but adopts the parent's newest instruction values as its baseline. Model selection affects request assembly but is not itself an instruction source.
 
 ## Compaction Rebuilds Active History
 
@@ -85,6 +85,6 @@ There is no separate finite Session-history endpoint. Request/response consumers
 
 ## Recovery Boundaries Stay Explicit
 
-An advisory wake does not infer that ambiguous provider work is safe to retry after input promotion. Explicit resume may continue from durable projected history, but automatic hard-crash continuation requires a separate design covering provider-dispatch ambiguity, tool idempotency, retry budgets, and future clustered ownership.
+An advisory wake is not itself crash recovery. Crash recovery is driven by a write-ahead execution claim that survives without a releasing terminal. Startup recovery resumes claimed top-level Sessions from durable projected history with bounded attempt accounting. It fails stale running tool projections before continuing, but it cannot prove whether an interrupted external operation already took effect and does not guarantee exactly-once provider or tool behavior.
 
 Event replay ownership is separate from Session execution ownership. Local execution remains process-owned until clustering introduces an explicit placement and fencing protocol.