refactor(core): simplify request preparation

.changeset/share-session-model-request.md

@@ -0,0 +1,5 @@
+---
+"@opencode-ai/core": patch
+---
+
+Apply shared Session model-request preparation to transient generation.

.opencode/command/ai-deps.md

@@ -2,7 +2,7 @@
 description: "Bump AI sdk dependencies minor / patch versions only"
 ---
 
-Please read @package.json and @packages/core/package.json.
+Please read @package.json and @packages/opencode/package.json.
 
 Your job is to look into AI SDK dependencies, figure out if they have versions that can be upgraded (minor or patch versions ONLY no major ignore major changes).
 

.opencode/command/commit.md

@@ -6,7 +6,15 @@ subtask: true
 
 commit and push
 
-Use `type(scope): summary` with one of these types: `feat`, `fix`, `docs`, `chore`, `refactor`, or `test`. The scope is optional.
+make sure it includes a prefix like
+docs:
+tui:
+core:
+ci:
+ignore:
+wip:
+
+For anything in the packages/web use the docs: prefix.
 
 prefer to explain WHY something was done from an end user perspective instead of
 WHAT was done.

.opencode/command/rmslop.md

@@ -2,7 +2,7 @@
 description: Remove AI code slop
 ---
 
-Check the diff against `origin/v2`, and remove all AI generated slop introduced in this branch.
+Check the diff against dev, and remove all AI generated slop introduced in this branch.
 
 This includes:
 

.opencode/skills/effect/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: effect
-description: Work with Effect v4 TypeScript code in this repo
+description: Work with Effect v4 / effect-smol TypeScript code in this repo
 ---
 
 # Effect
@@ -9,10 +9,10 @@ This codebase uses Effect for typed, composable TypeScript services, schemas, an
 
 ## Source Of Truth
 
-Use the current Effect v4 source, not memory or older Effect v2/v3 examples.
+Use the current Effect v4 / effect-smol source, not memory or older Effect v2/v3 examples.
 
-1. If `.opencode/references/effect` is missing, clone `https://github.com/Effect-TS/effect` there. Do this in the project, not in the skill folder.
-2. Search `.opencode/references/effect` for exact APIs, examples, tests, and naming patterns before answering or implementing Effect-specific code.
+1. If `.opencode/references/effect-smol` is missing, clone `https://github.com/Effect-TS/effect-smol` there. Do this in the project, not in the skill folder.
+2. Search `.opencode/references/effect-smol` for exact APIs, examples, tests, and naming patterns before answering or implementing Effect-specific code.
 3. Also inspect existing repo code for local house style before introducing new patterns.
 4. Prefer answers and implementations backed by specific source files or nearby repo examples.
 
@@ -27,12 +27,12 @@ Use the current Effect v4 source, not memory or older Effect v2/v3 examples.
 - Keep layer composition explicit. Avoid broad hidden provisioning that makes missing dependencies hard to see.
 - In tests, prefer the repo's existing Effect test helpers and live tests for filesystem, git, child process, locks, or timing behavior.
 - Do not introduce `any`, non-null assertions, unchecked casts, or older Effect APIs just to satisfy types.
-- Do not answer from memory. Verify against `.opencode/references/effect` or nearby code first.
+- Do not answer from memory. Verify against `.opencode/references/effect-smol` or nearby code first.
 
 ## Testing Patterns
 
-- Use `testEffect(...)` from `packages/core/test/lib/effect.ts` for tests that exercise Effect services, layers, runtime context, scoped resources, or platform integrations.
+- Use `testEffect(...)` from `packages/opencode/test/lib/effect.ts` for tests that exercise Effect services, layers, runtime context, scoped resources, or platform integrations.
 - Use `it.live(...)` for filesystem, git repositories, HTTP servers, sockets, child processes, locks, real time, and other live platform behavior.
-- Run tests from package directories such as `packages/core`; never run package tests from the repo root.
+- Run tests from package directories such as `packages/opencode`; never run package tests from the repo root.
 - Prefer explicit test layers over ad hoc managed runtimes. Keep dependency provisioning visible in the test file.
 - Use scoped fixtures and finalizers for resources that must be cleaned up, including temporary directories, flags, databases, fibers, servers, and global state.

AGENTS.md

@@ -1,6 +1,6 @@
-- After changing the public Protocol or Server `HttpApi`, run `bun run generate` from `packages/client`. Do not edit generated client files directly.
+- After changing the public Protocol or Server `HttpApi`, run `bun run generate` from `packages/client`. Do not edit `src/generated` or `src/generated-effect` directly.
 - Keep runtime dependencies directed from Schema to Core and Protocol, then from Core and Protocol to Server. Client runtime code may depend on Schema and Protocol but never Core or Server; `sdk-next` composes Client, Core, and Server.
-- Current implementation changes belong in `packages/core`, `packages/cli`, `packages/server`, `packages/protocol`, `packages/schema`, and related generated client surfaces when required.
+- Do not modify `packages/opencode` unless the user explicitly asks for V1 work. `packages/opencode` is the V1 implementation and is present for reference only. New implementation changes should land in the V2 package set: `packages/core`, `packages/cli`, `packages/server`, `packages/protocol`, `packages/schema`, and related generated client surfaces when required.
 - The default branch in this repo is `v2`.
 - Base all new branches and worktrees on `v2`, or `origin/v2` when the local `v2` ref is unavailable. Do not base them on `dev`.
 - Local `main` ref may not exist; use `v2` or `origin/v2` for diffs.
@@ -166,11 +166,11 @@ const table = sqliteTable("session", {
 
 - Avoid mocks as much as possible, you shouldn't be using globalThis.\* at all unless it's the only option.
 - Test actual implementation, do not duplicate logic into tests
-- Tests cannot run from repo root (guard: `do-not-run-tests-from-root`); run from package directories such as `packages/core`.
+- Tests cannot run from repo root (guard: `do-not-run-tests-from-root`); run from package dirs like `packages/opencode`.
 
 ## Type Checking
 
-- Always run `bun typecheck` from package directories (for example, `packages/core`), never `tsc` directly.
+- Always run `bun typecheck` from package directories (e.g., `packages/opencode`), never `tsc` directly.
 
 ## V2 Session Core
 
@@ -179,7 +179,7 @@ const table = sqliteTable("session", {
 - 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. 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 delegate orchestration to an in-memory tool loop.
+- 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.

docs/design/v1-v2-database-migration.md

@@ -0,0 +1,298 @@
+# V1 to V2 Database Migration
+
+## Approach
+
+- Use the `dev` branch database schema and migration registry as the V1 baseline.
+- Remove migrations that exist only on the V2 branch.
+- Generate one canonical migration from the `dev` schema to the final V2 schema.
+- Keep the canonical migration focused on schema changes and dropping obsolete tables.
+- Run the V1 history backfill through an experimental server endpoint invoked by the CLI before it opens the TUI.
+- Show committed session progress while the endpoint runs.
+
+Expose `GET /api/experimental/migration/v1` for status and a blocking `POST /api/experimental/migration/v1` to run or
+resume the backfill. The status is `required`, `running`, or `completed`. On startup, the CLI checks status first and
+renders no migration UI when it is already complete. For required or running status, it shows a spinner and waits for the
+blocking POST without a request timeout. While migration runs, poll GET once per second and render completed and total
+session counts. GET derives total from all session rows and completed from rows through the stored cursor; the count
+advances only after a session transaction commits. The POST returns `{ status: "completed" }`. Do not add a background
+job or streaming progress protocol. Interrupted calls resume from the stored cursor.
+Initially, only interactive TUI startup performs this check; noninteractive run, ACP, raw API, service, health, version,
+and help flows do not trigger the backfill.
+
+Keep migration behavior in Core: status, semaphore, checkpointing, V1 decoding, transformation, and database writes.
+Protocol owns the experimental GET/POST contracts, Server handlers delegate to Core, and the interactive CLI owns only
+the status check and spinner presentation.
+
+Guard the endpoint with one process-local Effect `Semaphore`. Concurrent callers wait; after the active call completes,
+waiting callers acquire the permit, observe the completion key, and return immediately. No distributed lock is required
+for the current single elected server process.
+
+## Preserve
+
+The canonical V1 data remains in its existing tables. In particular, preserve `session`, `message`, and `part` rows.
+
+Preserve `workspace` rows and existing `session.workspace_id` values unchanged. The migration must not clear or rebuild
+workspace relationships.
+
+Preserve existing non-null `session.agent` and `session.model` selections. Fill missing values from the latest ordinary
+V1 user message ordered by `time_created` and `id`, excluding compaction and subtask-only messages. Copy agent, provider
+ID, model ID, and variant, normalizing an absent variant to `default`.
+
+Recompute session usage aggregates from all canonical V1 assistant messages, including compaction or other internal
+assistants omitted from the V2 projection. Overwrite session cost and input, output, reasoning, cache-read, and
+cache-write token totals with those sums.
+
+Clear persisted `session.revert` state. A staged revert is transient operational state and may refer to omitted projection
+rows or unavailable snapshots; it must not resume automatically after upgrading. Preserve the underlying messages,
+parts, and file history.
+
+Clear `session.time_compacting`, leave the new `time_suspended` column as `NULL`, and preserve session creation, update,
+and archive timestamps. Preserve project `time_initialized`; it is unrelated durable state.
+
+Keep the legacy `todo` table and its data physically unchanged, but do not include it in the final V2 Drizzle schema.
+After generation, remove the generated `DROP TABLE todo` statement from the canonical migration so the table remains as
+unmanaged legacy storage.
+
+## Per-Session Replacement
+
+Do not truncate `event`, `event_sequence`, or `session_message` globally before the backfill. A whole-table delete can
+hold SQLite's writer lock long enough to block the running TUI.
+
+Replace each legacy session's V2 state inside that session's checkpointed migration transaction. Delete `event` rows for
+the session aggregate, delete its `session_message` rows, rebuild its projection from canonical V1 `message` and `part`
+rows, and overwrite its `event_sequence` watermark. If migration of that session fails, all replacements roll back and
+the durable cursor remains at the previously committed session. Rows owned by sessions outside the legacy migration set
+remain untouched.
+
+## Message Backfill
+
+Backfill canonical V1 history from `message` and `part` into `session_message`. This is the main data transformation in
+the migration. Preserving the V1 tables alone keeps the data safe but does not make existing history visible through the
+V2 session APIs, which read `session_message`.
+
+Do not fail the whole migration when a V1 message or part payload cannot be decoded. Skip an undecodable message's V2
+projection and log its session and message IDs. Skip an undecodable part while continuing to map its message, and perform
+special-message pairing only with decoded rows. Assign sequences after filtering. Leave every malformed source row
+untouched in the V1 tables.
+
+Skip and log orphan parts whose source message does not exist and parts with unknown or unsupported types. Continue
+migrating the owning message and other valid parts. Include session, message, part ID, and observed type in warnings, and
+leave skipped source rows unchanged.
+
+Reuse each V1 `message.id` as the corresponding `session_message.id`. Stable IDs keep the migration deterministic and
+avoid rewriting other persisted state that may refer to a message.
+
+For ordinary user and assistant rows, preserve source `message.time_created` and `message.time_updated`. Entirely
+synthetic messages preserve their source timestamps, and synthetic rows split from mixed messages use the source user
+timestamps. A collapsed compaction uses the compaction user creation time and the later update time of the compaction
+user and summary assistant. Keep payload creation/completion times consistent with row timestamps.
+
+Within each session, order V1 messages by `time_created` and then `id`, matching the existing V1 message index. Assign
+contiguous `session_message.seq` values starting at `0`.
+
+Map ordinary V1 messages one-to-one by role. Each ordinary V1 user message becomes one V2 `user` row, and each ordinary
+V1 assistant message becomes one V2 `assistant` row. Fold the source message's ordered V1 parts into that row's V2
+payload.
+
+Keep ordinary messages even when their transformed payload becomes empty after filtering. Preserve an empty V2 user row
+with `text: ""` and an empty V2 assistant row with `content: []` so IDs, chronology, and conversation structure remain
+stable. Omit only explicitly dropped internal concepts and undecodable messages.
+
+Handle semantic marker parts before applying the ordinary mapping. In particular, a V1 user message containing a
+`compaction` part and its paired assistant summary represent one compaction operation, not two ordinary messages. Special
+part mappings must be decided explicitly before implementing the backfill.
+
+Do not carry the V1 subtask concept into the V2 projection. Omit user messages containing only `subtask` parts and omit
+the paired assistant task-tool messages generated from those markers. For mixed user messages, ignore the `subtask`
+parts while preserving ordinary content, and still omit assistant task-tool messages generated by the skipped subtasks.
+Keep all source rows unchanged in the V1 `message` and `part` tables.
+
+Map ordinary V1 assistant `text` and `reasoning` parts into the V2 assistant `content` array in part order. Preserve text,
+including empty assistant text parts used as structural separators. Map V1 part metadata to optional V2 provider state.
+For reasoning, map `time.start` to `time.created` and optional `time.end` to `time.completed`.
+
+Preserve V1 tool parts that are `pending` or `running`, but convert them to terminal V2 tool error states. Preserve the
+call ID, tool name, parsed input, metadata, and available start time. Use the assistant message creation time when the V1
+state has no start time. Set the error to type `tool.interrupted` with message
+`Tool execution was interrupted before V2 migration`. Never resume migrated tool executions.
+
+For a completed V1 tool part, use `callID` as the V2 tool content ID and preserve the tool name and parsed input. Set the
+state to `completed`. Convert V1 output into the first text content item and convert stored output attachments into
+following file content items with their URI, MIME type, and filename. Preserve state metadata. Map `time.start` to
+`time.created` and `time.end` to `time.completed`. When `time.compacted` exists, use
+`[Old tool result content cleared]` as the only output and omit attachments.
+
+For a failed V1 tool part, preserve the call ID, tool name, parsed input, metadata, and timestamps, and set the V2 state
+to `error`. Convert the V1 error string to a structured error with type `tool.execution`. If V1 metadata contains a string
+`output`, preserve it as optional V2 text content. Map `time.start` to `time.created` and `time.end` to `time.completed`.
+
+For an ordinary V1 assistant message, preserve agent, provider ID, model ID, optional variant, creation and completion
+times, cost, and input/output/reasoning/cache token counts. Use `default` when the V1 variant is absent. Ignore V1
+`tokens.total` because it is derivable and V2 does not persist it.
+
+Use V1 assistant `parentID` only while pairing compactions and skipped subtasks with their originating user messages. Do
+not persist it in ordinary V2 assistant rows; V2 uses ordered history rather than user/assistant parent links.
+
+Ignore the optional V1 assistant `structured` output value. V2 has no equivalent top-level assistant field, and visible
+text and tool content are migrated separately. Retain the original structured value only in the V1 `message` row.
+
+Ignore V1 assistant `mode` and historical `path` (`cwd` and `root`). Mode is redundant with the preserved assistant
+agent, and historical filesystem paths do not belong to the V2 assistant message contract. Retain them only in the V1
+`message` row.
+
+For assistant finish reasons, preserve `stop`, `length`, `tool-calls`, `content-filter`, `error`, and `unknown`. Map every
+other nonempty V1 finish value to `unknown`, and leave the field absent when V1 omitted it. Do not retain unrecognized raw
+finish values in metadata.
+
+Map V1 assistant errors into the current V2 `{ type, message }` storage shape. Normalize Auth, content-filter, context
+overflow, structured-output, output-length, aborted, API, and unknown errors to the established V2 string conventions,
+preserve the message, and discard V1-only retryability and raw provider details.
+
+Ignore V1 `retry` parts. Do not populate the V2 assistant `retry` field during migration; historical retry state is not
+useful enough to preserve. The original retry rows remain in the V1 `part` table.
+
+Do not emit V2 assistant content for V1 `step-start` and `step-finish` parts. Use the first available
+`step-start.snapshot` as `assistant.snapshot.start` and the last available `step-finish.snapshot` as
+`assistant.snapshot.end`. Continue to source finish, cost, and tokens from the assistant message itself. Ignore step
+markers without snapshots.
+
+Do not emit assistant content for standalone V1 `snapshot` or `patch` parts. If no start snapshot came from `step-start`,
+use the first standalone snapshot value, then the first patch hash as a final fallback. Only `step-finish.snapshot` may
+populate the end snapshot. Merge patch file lists into `assistant.snapshot.files` in first-seen order with duplicates
+removed.
+
+V2 follow-up: replace the open `SessionError.Error` string shape with a properly typed persisted error union. This is not
+a blocker for the V1 migration, which should target the current storage contract.
+
+V1 synthetic content is represented by user text parts with `synthetic: true`, not by a separate message role. A V1 user
+message whose visible text parts are all synthetic should become a V2 `synthetic` message. If a V1 user message mixes
+ordinary and synthetic content, preserve the ordinary content in the V2 `user` row and emit the synthetic content as an
+adjacent V2 `synthetic` row. Ignore text parts marked `ignored`, matching V1 model-history behavior.
+
+For an ordinary V2 user message, take visible V1 text parts that are neither ignored nor synthetic, preserve part order,
+and join their text with `"\n\n"`. Use an empty string when the message contains attachments but no ordinary text.
+
+Ignore the optional V1 user-message `system` override. Do not create a V2 system message or preserve the override in
+metadata. The original value remains in the V1 `message` row.
+
+Ignore the optional V1 user-message `tools` map. It represented request-time tool enablement for a historical step and
+must not affect future V2 execution. The original value remains in the V1 `message` row.
+
+Ignore the optional V1 user-message `format` field and its schema. It controlled structured-output behavior for a
+historical request and must not affect future V2 runs. Preserve visible assistant text normally; retain the original
+format only in the V1 `message` row.
+
+Ignore V1 user-message `summary` metadata, including title, body, and diffs. V2 user messages have no equivalent field,
+and session-level summary data is already persisted separately. Retain the original summary only in the V1 `message`
+row.
+
+Map V1 `agent` parts into the V2 user message's `agents` array in part order. Preserve `name`. When the V1 part has
+`source`, map its `value`, `start`, and `end` into the V2 attachment's `mention.text`, `mention.start`, and `mention.end`.
+Omit `agents` when there are no agent parts.
+
+Do not read the filesystem or network while migrating V1 file attachments. Attachment migration must be deterministic
+from database contents alone. Convert persisted `data:` URLs; represent non-embedded `file:`, HTTP, and other external
+URLs with deterministic text rather than fetching them. Keep the original V1 `part` rows unchanged.
+
+For a V1 file backed by a `data:` URL, decode the URL and normalize its payload to base64 for the V2 attachment's `data`.
+Preserve `mime` and optional `filename` as `name`. Use a V2 `uri` source with the original URI for a V1 resource source;
+otherwise use an `inline` source. When V1 source text metadata exists, map its `value`, `start`, and `end` into the V2
+attachment mention. Leave `description` unset and preserve file-part order in the V2 `files` array.
+
+For a non-embedded V1 file, do not create a V2 file attachment. Append
+`[Attachment unavailable after migration: <name-or-url> (<mime>)]` to the V2 user text in original part order, separated
+by blank lines. Prefer the V1 filename, then resource URI, then part URL for the label. The original URL remains only in
+the preserved V1 `part` row.
+
+For a synthetic row split from a mixed user message, derive a generated-looking ID from the source message ID. Preserve
+the source ID's 12-character timestamp component and replace its 14-character random component with a deterministic
+base-62 encoding of a hash of `v1-synthetic:` plus the source message ID. If that candidate collides with an existing or
+derived message ID, deterministically retry with an incrementing salt. Place the synthetic row immediately after its
+source user row. Entirely synthetic messages continue to reuse their original message ID.
+
+Use the V1 compaction user message ID as the ID of the collapsed V2 compaction message. This matches V2's use of the
+admitted compaction input ID and preserves references to the initiating message.
+
+For a completed compaction, create one V2 `compaction` row with `status: "completed"`. Set `reason` from the V1
+compaction part's `auto` flag, join the paired summary assistant's nonempty text parts with blank lines for `summary`, and
+serialize the retained V1 tail beginning at `tail_start_id` for `recent`. Use an empty `recent` value when no tail was
+retained, and use the compaction user message creation time. Do not emit the paired summary assistant as a separate V2
+assistant row.
+
+Do not project incomplete or failed V1 compactions into `session_message`. Omit both the internal compaction user marker
+and its paired summary assistant when no successful summary was completed. Assign final sequence numbers after filtering
+so omitted compactions leave no gaps. Their source rows remain preserved in the V1 `message` and `part` tables.
+
+After rebuilding a session's `session_message`, replace its `event_sequence` watermark with that session's maximum
+backfilled `session_message.seq`. This prevents new V2 events from reusing sequence numbers or sorting before migrated
+history. The migrated session's prior `event` rows are removed in the same transaction.
+
+## Drop
+
+Drop these pre-launch V2 tables without preserving or transforming their rows:
+
+- `session_input`
+- `session_context_epoch`
+- `data_migration`
+
+Do not transfer `session_input` rows into `session_pending`.
+
+## Create Empty
+
+Let the generated migration create these tables empty:
+
+- `instruction_blob`
+- `instruction_entry`
+- `instruction_state`
+- `session_pending`
+- `kv`
+
+V1 has no canonical data to backfill into these tables. V2 initializes their state as it runs.
+
+## Fork Storage
+
+V1 has no fork-boundary state to backfill. New V2 forks use a required message boundary and persist it in
+`session.fork_boundary`. The durable fork event contains no parent sequence. Its resolved boundary is one of:
+
+- `before`: copy messages before the identified message.
+- `through`: copy messages through the identified message.
+
+Forking an empty session is not supported. `session.fork_seq` and `session.fork_message_id` are not part of the final V2
+schema.
+
+New nullable session columns, including `fork_session_id`, `fork_boundary`, and `time_suspended`, require no explicit
+backfill. Existing rows naturally receive `NULL` when the generated migration adds the columns.
+
+## Execution
+
+Before transforming V1 rows, look for `opencode-next.db` in the data directory. This file was used by pre-launch V2
+builds. Open it read-only with Bun SQLite and copy its `project`, `session`, and `session_message` rows directly into the
+current `project`, `session_v2`, and `session_message` tables. Existing current projects and Sessions win ID collisions.
+Do not copy its durable events or runtime caches; initialize each imported Session's `event_sequence` watermark from its
+maximum message sequence. Commit each imported Session independently and leave the source database untouched.
+
+The previous V2 import is part of this migration and uses the same completion marker. It needs no source-specific cursor:
+the destination Session row is the per-Session idempotency boundary, so a retry skips transactions that already committed.
+
+Store V1 backfill state in `kv`; do not retain a dedicated `data_migration` table. Store the last successfully migrated
+session ID under `migration.v1-v2.session.cursor` and write `migration.v1-v2.completed` with value `true` after every
+session finishes. Delete the cursor key on completion and return immediately on later calls when the completion key
+exists.
+
+Absence of the completion key means migration is required, including on a fresh database. Running the endpoint against a
+database with no sessions completes immediately and writes the completion key; fresh database initialization does not
+seed migration state specially.
+
+Process sessions in stable ID order. Rebuild one session in one transaction, including its `session_message` rows,
+session-level backfills, `event_sequence` watermark, and cursor update. If interrupted during a session, that transaction
+rolls back and the next endpoint call retries the same session. If it committed, the next call continues after the stored
+cursor. Mark the migration complete after the final session and return immediately on later calls.
+
+Ensure the global project exists using the current platform's filesystem root as its worktree. Process every `session`
+row, including archived, root, child, and empty sessions, as well as sessions whose messages are all skipped or internal.
+Reassign beta and V1 Sessions whose referenced project row is missing to the global project and log a warning. Each
+successfully committed session advances the cursor.
+
+## Testing
+
+Detailed migration test design is deferred until after the canonical migration is implemented.

packages/ai/AGENTS.md

@@ -23,9 +23,14 @@ Per-type constructors live on the type, not as top-level re-exports. Use `Messag
 
 This package is an Effect Schema-first LLM core. The Schema classes in `src/schema/` are the canonical runtime data model. Convenience functions in `src/llm.ts` are thin constructors that return those same Schema class instances; they should improve callsites without creating a second model.
 
-Session integration lives in `packages/core/src/session`: `runner/llm.ts` owns orchestration, `model-request.ts` lowers Session state into `LLMRequest`, and `model-transport.ts` selects transport behavior.
+Primary in-repo integration point:
 
-Keep this package independent of Session concerns. Session auth, permissions, plugins, telemetry headers, and runtime selection belong in Core.
+- `packages/opencode/src/session/llm.ts` is the session-owned orchestration layer that decides whether a request uses AI SDK or this package's native route runtime.
+- `packages/opencode/src/session/llm/native-request.ts` is the lowering adapter from opencode's session/AI SDK-shaped data into this package's `LLMRequest` model.
+- `packages/opencode/src/session/llm/native-runtime.ts` is the execution adapter that calls raw `LLMClient.stream(request)` and bridges one provider turn of opencode tool calls through this package's typed dispatcher.
+- `packages/opencode/src/session/llm/ai-sdk.ts` keeps the default AI SDK path compatible by converting AI SDK stream parts into this package's shared `LLMEvent`s.
+
+Keep this package independent of session concerns. Session auth, permissions, plugins, telemetry headers, and runtime selection belong in `packages/opencode/src/session/llm.ts` and its local adapters.
 
 ### Request Flow
 

packages/app/AGENTS.md

@@ -11,7 +11,7 @@
 
 - `opencode dev web` proxies `https://app.opencode.ai`, so local UI/CSS changes will not show there.
 - For local UI changes, run the backend and app dev servers separately.
-- Backend (from the repository root): `bun dev serve --port 4096`
+- Backend (from `packages/opencode`): `bun run --conditions=browser ./src/index.ts serve --port 4096`
 - App (from `packages/app`): `bun dev -- --port 4444`
 - Open `http://localhost:4444` to verify UI changes (it targets the backend at `http://localhost:4096`).
 

packages/cli/AGENTS.md

@@ -1,4 +1,7 @@
-# CLI and TUI development guide
+# V2 CLI and TUI development guide
 
-- Use `@opencode-ai/client` and the location-scoped data in `packages/tui/src/context/data.tsx` instead of adding dependencies on legacy sync state.
+## Migration context
+
+- The TUI is being ported from legacy APIs to the new V2 APIs. New and migrated TUI behavior should use `sdk.client.v2` and the location-scoped data in `packages/tui/src/context/data.tsx` instead of adding dependencies on legacy sync state.
 - Preserve established TUI behavior unless the task intentionally changes it.
+- Load the `opencode-dev` skill before interactively running, debugging, or verifying opencode's V2 CLI, TUI, or server.

packages/core/src/session/generate-node.ts

@@ -1,85 +1,54 @@
 export * as SessionGenerateNode from "./generate-node.js"
 
-import { LLM, LLMClient, Message, SystemPart } from "@opencode-ai/ai"
+import { LLMClient, Message } from "@opencode-ai/ai"
 import { Effect, Layer } from "effect"
 import { Database } from "../database/database.js"
 import { makeLocationNode } from "@opencode-ai/util/effect/app-node"
-import { App } from "../app.js"
 import { llmClient } from "../effect/app-node-platform.js"
-import { PluginHooks } from "../plugin/hooks.js"
 import { SessionContext } from "./context.js"
 import { SessionGenerate } from "./generate.js"
 import { SessionHistory } from "./history.js"
-import { SessionModelHeaders } from "./model-headers.js"
-import { SessionPromptCacheKey } from "./prompt-cache-key.js"
+import { SessionModelRequest } from "./model-request.js"
 import { SessionRunnerModel } from "./runner/model.js"
-import { SessionSystemPrompt } from "./system-prompt.js"
-import { toLLMMessages } from "./runner/to-llm-message.js"
 
 export const layer = Layer.effect(
   SessionGenerate.Service,
   Effect.gen(function* () {
     const context = yield* SessionContext.Service
     const database = yield* Database.Service
-    const hooks = yield* PluginHooks.Service
     const llm = yield* LLMClient.Service
     const models = yield* SessionRunnerModel.Service
-    const app = yield* App.Metadata
+    const modelRequests = yield* SessionModelRequest.Service
 
     return SessionGenerate.Service.of({
       generate: Effect.fn("SessionGenerate.generate")(function* (input) {
         const selection = yield* context.select(input.sessionID)
         const model = yield* models.resolve(selection.session)
         const history = yield* SessionHistory.preview(database.db, selection.session.id, selection.instructions)
-        const providerMetadataKey = model.model.route.providerMetadataKey ?? model.model.provider
-        const tools = selection.tools
-        const toolDefinitions = tools.definitions
-        const toolsByName = new Map(toolDefinitions.map((tool) => [tool.name, tool]))
-        const contextEvent = yield* hooks.trigger("session", "context", {
-          sessionID: selection.session.id,
-          agent: selection.agent.id,
-          model: model.ref,
-          system: [
-            selection.agent.info.system
-              ? selection.agent.info.system
-              : SessionSystemPrompt.make(toolDefinitions.map((tool) => tool.name)),
-            history.initial,
-          ]
-            .filter((part) => part.length > 0)
-            .map(SystemPart.make),
-          messages: [
-            ...toLLMMessages(history.messages, model.ref, providerMetadataKey),
-            ...(history.instructionUpdate ? [Message.system(history.instructionUpdate)] : []),
-            Message.user(input.prompt),
-          ],
-          tools: Object.fromEntries(
-            toolDefinitions.map((tool) => [
-              tool.name,
-              { description: tool.description, input: { ...tool.inputSchema } },
-            ]),
-          ),
+        const transcript = SessionModelRequest.baseTranscript({
+          agent: selection.agent.info,
+          model,
+          tools: selection.tools,
+          initial: history.initial,
+          messages: history.messages,
         })
-        const hookedTools = Object.entries(contextEvent.tools).flatMap(([name, tool]) => {
-          const registered = toolsByName.get(name)
-          return registered
-            ? [Object.assign({}, registered, { description: tool.description, inputSchema: tool.input })]
-            : []
+        const prepared = yield* modelRequests.prepare({
+          scope: { session: selection.session, agentID: selection.agent.id, model, tools: selection.tools },
+          transcript: {
+            system: transcript.system,
+            messages: [
+              ...transcript.messages,
+              ...(history.instructionUpdate ? [Message.system(history.instructionUpdate)] : []),
+              Message.user(input.prompt),
+            ],
+          },
         })
         yield* Effect.logInfo("sending session generation request", {
           sessionID: selection.session.id,
           providerID: model.ref.providerID,
           modelID: model.ref.id,
         })
-        const response = yield* llm.generate(
-          LLM.request({
-            model: model.model,
-            http: { headers: SessionModelHeaders.make(selection.session, app) },
-            promptCacheKey: SessionPromptCacheKey.make(selection.session.id),
-            system: contextEvent.system,
-            messages: contextEvent.messages,
-            tools: hookedTools,
-          }),
-        )
+        const response = yield* llm.generate(prepared.request, prepared.options)
         yield* Effect.logInfo("session generation usage diagnostic", { usage: response.usage })
         return response.text
       }),
@@ -90,5 +59,5 @@ export const layer = Layer.effect(
 export const node = makeLocationNode({
   service: SessionGenerate.Service,
   layer,
-  deps: [SessionContext.node, Database.node, PluginHooks.node, SessionRunnerModel.node, App.node, llmClient],
+  deps: [SessionContext.node, Database.node, SessionModelRequest.node, SessionRunnerModel.node, llmClient],
 })

packages/core/src/session/model-request.ts

@@ -12,15 +12,16 @@ import { Permission } from "../permission.js"
 import { PluginHooks } from "../plugin/hooks.js"
 import { QuestionTool } from "../tool/plugin/question.js"
 import { Tool } from "../tool.js"
-import { SessionContext } from "./context.js"
 import { SessionModelHeaders } from "./model-headers.js"
 import { SessionModelHttp } from "./model-http.js"
 import { SessionModelTransport } from "./model-transport.js"
 import { SessionPromptCacheKey } from "./prompt-cache-key.js"
-import { PromptCacheDiagnostics } from "./prompt-cache-diagnostics.js"
-import { MAX_STEPS_PROMPT } from "./runner/max-steps.js"
+import { SessionRunnerModel } from "./runner/model.js"
+import { SessionSchema } from "./schema.js"
 import { SessionSystemPrompt } from "./system-prompt.js"
 import { toLLMMessages } from "./runner/to-llm-message.js"
+import type { SessionMessage } from "./message.js"
+import type { Agent } from "../agent.js"
 
 const IMAGE_BYTES_TRIGGER = 25 * 1024 * 1024 // 25 MiB
 const IMAGE_BYTES_TARGET = 15 * 1024 * 1024 // 15 MiB
@@ -47,20 +48,49 @@ const declineDefect = (cause: Cause.Cause<Tool.Error>) => {
 interface Prepared {
   readonly request: LLMRequest
   readonly options: StreamOptions
-  /** False when Session HTTP hooks require the request to remain on HTTP. */
-  readonly webSocketEligible: boolean
   /**
-   * One request-scoped execution operation. Unknown, hook-removed, and
-   * step-limit-violating calls fail individually through the same seam.
+   * One request-scoped execution operation. Unknown and hook-removed calls
+   * fail individually through the same seam.
    */
   readonly executeTool: (input: Parameters<Tool.Snapshot["execute"]>[0]) => Effect.Effect<Tool.Result, ExecuteError>
-  /** True when this request is the final Step; violating calls are rejected and no continuation follows. */
-  readonly stepLimitReached: boolean
 }
 
 interface PrepareInput {
-  readonly context: SessionContext.Loaded
-  readonly step: number
+  readonly scope: {
+    readonly session: SessionSchema.Info
+    readonly agentID: Agent.ID
+    readonly model: SessionRunnerModel.Resolved
+    readonly tools: Tool.Snapshot
+  }
+  readonly transcript: {
+    readonly system: Array<SystemPart>
+    readonly messages: Array<Message>
+  }
+  readonly toolChoice?: LLM.RequestInput["toolChoice"]
+  /** Stateful Session WebSocket channels require an explicit durable-runner opt-in. */
+  readonly webSocket?: "session"
+}
+
+export const baseTranscript = (input: {
+  readonly agent: Agent.Info
+  readonly model: SessionRunnerModel.Resolved
+  readonly tools: Tool.Snapshot
+  readonly initial: string
+  readonly messages: ReadonlyArray<SessionMessage.Info>
+}) => {
+  const providerMetadataKey = input.model.model.route.providerMetadataKey ?? input.model.model.provider
+  return {
+    providerMetadataKey,
+    system: [
+      input.agent.system
+        ? input.agent.system
+        : SessionSystemPrompt.make(input.tools.definitions.map((tool) => tool.name)),
+      input.initial,
+    ]
+      .filter((part) => part.length > 0)
+      .map(SystemPart.make),
+    messages: toLLMMessages(input.messages, input.model.ref, providerMetadataKey),
+  }
 }
 
 const mimeToModality = (mime: string) => {
@@ -174,30 +204,11 @@ export const layer = Layer.effect(
       Config.withDefault(false),
       Effect.orDie,
     )
-    const diagnostics = yield* Config.boolean("OPENCODE_PROMPT_CACHE_DIAGNOSTICS").pipe(
-      Config.withDefault(false),
-      Effect.orDie,
-    )
-    const promptCacheSnapshots = diagnostics ? new Map<string, PromptCacheDiagnostics.Snapshot>() : undefined
-
     const prepare = Effect.fn("SessionModelRequest.prepare")(function* (input: PrepareInput) {
-      const session = input.context.session
-      const agent = input.context.agent
-      const resolved = input.context.model
+      const session = input.scope.session
+      const resolved = input.scope.model
       const model = resolved.model
-      const providerMetadataKey = model.route.providerMetadataKey ?? model.provider
-      const stepLimitReached = agent.info.steps !== undefined && input.step >= agent.info.steps
-      // The final Step keeps definitions available to protocols with native "none",
-      // preserving their prompt cache prefix. Calls are still rejected at execution.
-      const tools = input.context.tools
-      const system = [
-        agent.info.system ? agent.info.system : SessionSystemPrompt.make(tools.definitions.map((tool) => tool.name)),
-        input.context.initial,
-      ]
-        .filter((part) => part.length > 0)
-        .map(SystemPart.make)
-      const history = toLLMMessages(input.context.messages, resolved.ref, providerMetadataKey)
-      const messages = stepLimitReached ? [...history, Message.assistant(MAX_STEPS_PROMPT)] : history
+      const tools = input.scope.tools
       const registry = new Map(tools.definitions.map((tool) => [tool.name, tool]))
       // The definition objects we hand to hooks, mapped back to their tools. Hooks rename a
       // tool by moving its definition to a new key; recognizing the object recovers the tool.
@@ -209,10 +220,10 @@ export const layer = Layer.effect(
       // Hooks mutate this record in place: edit descriptions and schemas, rename, or remove.
       const context = yield* hooks.trigger("session", "context", {
         sessionID: session.id,
-        agent: agent.id,
+        agent: input.scope.agentID,
         model: resolved.ref,
-        system,
-        messages,
+        system: input.transcript.system,
+        messages: input.transcript.messages,
         tools: Object.fromEntries(Array.from(given, ([definition, tool]) => [tool.name, definition])),
       })
       // Match each surviving entry back to its tool, by recognizing a moved definition or
@@ -235,7 +246,7 @@ export const layer = Layer.effect(
         system: context.system,
         messages: boundImages(unsupportedParts(context.messages, resolved.capabilities)),
         tools: Array.from(hooked, ([name, tool]) => ({ ...tool, name })),
-        toolChoice: stepLimitReached ? "none" : undefined,
+        toolChoice: input.toolChoice,
       })
       const webSocketEligible =
         !(yield* hooks.has("session", "http.request")) && !(yield* hooks.has("session", "http.response"))
@@ -243,37 +254,20 @@ export const layer = Layer.effect(
         ? undefined
         : SessionModelHttp.middleware(hooks, {
             sessionID: session.id,
-            agent: agent.id,
+            agent: input.scope.agentID,
             model: resolved.ref,
           })
       const options: StreamOptions = {
         ...(http ? { http } : {}),
-        ...(webSocket &&
+        ...(input.webSocket === "session" &&
+        webSocket &&
         webSocketEligible &&
         resolved.ref.providerID === Provider.ID.openai &&
         model.route.id === "openai-responses"
           ? { webSocket: transport.bind(session.id) }
           : {}),
       }
-      if (promptCacheSnapshots) {
-        const current = PromptCacheDiagnostics.snapshot(request)
-        const comparison = PromptCacheDiagnostics.compare(promptCacheSnapshots.get(session.id), current)
-        promptCacheSnapshots.delete(session.id)
-        promptCacheSnapshots.set(session.id, current)
-        const oldest = promptCacheSnapshots.keys().next().value
-        if (promptCacheSnapshots.size > 100 && oldest !== undefined) promptCacheSnapshots.delete(oldest)
-        yield* Effect.logInfo("prompt cache prefix").pipe(
-          Effect.annotateLogs({
-            sessionID: session.id,
-            toolCount: current.tools.length,
-            systemParts: current.system.length,
-            messageCount: current.messages.length,
-            ...comparison,
-          }),
-        )
-      }
       const executeTool: Prepared["executeTool"] = (input) => {
-        if (stepLimitReached) return new Tool.Error({ message: "Tools are disabled after the maximum agent steps" })
         const tool = hooked.get(input.call.name)
         // A registered tool absent from the hooked set was removed or renamed by a hook.
         if (!tool && registry.has(input.call.name))
@@ -285,9 +279,7 @@ export const layer = Layer.effect(
       return {
         request,
         options,
-        webSocketEligible,
         executeTool,
-        stepLimitReached,
       }
     })
 

packages/core/src/session/runner/llm.ts

@@ -4,11 +4,12 @@ import {
   LLMClient,
   AIError,
   LLMEvent,
+  Message,
   isContextOverflowFailure,
   type ProviderErrorEvent,
   type ToolCall,
 } from "@opencode-ai/ai"
-import { Cause, Data, Effect, Exit, Fiber, FiberSet, Layer, Option, Pull, Schedule, Stream } from "effect"
+import { Cause, Config, Data, Effect, Exit, Fiber, FiberSet, Layer, Option, Pull, Schedule, Stream } from "effect"
 import { Database } from "../../database/database.js"
 import { Bus } from "../../bus.js"
 import { Permission } from "../../permission.js"
@@ -34,6 +35,9 @@ import { toSessionError } from "../to-session-error.js"
 import { SessionRunnerRetry } from "./retry.js"
 import { SessionUsage } from "../usage.js"
 import { ToolOutput } from "../../tool-output.js"
+import { Tool } from "../../tool.js"
+import { PromptCacheDiagnostics } from "../prompt-cache-diagnostics.js"
+import { MAX_STEPS_PROMPT } from "./max-steps.js"
 
 /** How one model call ended: settled, awaiting retry/recovery, or restarted by compaction. */
 type CallOutcome = Data.TaggedEnum<{
@@ -116,6 +120,32 @@ const layer = Layer.effect(
     const compaction = yield* SessionCompaction.Service
     const title = yield* SessionTitle.Service
     const toolOutput = yield* ToolOutput.Service
+    const diagnostics = yield* Config.boolean("OPENCODE_PROMPT_CACHE_DIAGNOSTICS").pipe(
+      Config.withDefault(false),
+      Effect.orDie,
+    )
+    const promptCacheSnapshots = diagnostics ? new Map<string, PromptCacheDiagnostics.Snapshot>() : undefined
+    const diagnosePromptCache = Effect.fn("SessionRunner.diagnosePromptCache")(function* (
+      sessionID: SessionSchema.ID,
+      request: Parameters<typeof PromptCacheDiagnostics.snapshot>[0],
+    ) {
+      if (!promptCacheSnapshots) return
+      const current = PromptCacheDiagnostics.snapshot(request)
+      const comparison = PromptCacheDiagnostics.compare(promptCacheSnapshots.get(sessionID), current)
+      promptCacheSnapshots.delete(sessionID)
+      promptCacheSnapshots.set(sessionID, current)
+      const oldest = promptCacheSnapshots.keys().next().value
+      if (promptCacheSnapshots.size > 100 && oldest !== undefined) promptCacheSnapshots.delete(oldest)
+      yield* Effect.logInfo("prompt cache prefix").pipe(
+        Effect.annotateLogs({
+          sessionID,
+          toolCount: current.tools.length,
+          systemParts: current.system.length,
+          messageCount: current.messages.length,
+          ...comparison,
+        }),
+      )
+    })
     // Title generation starts once input is visible and must not delay model execution.
     // The in-flight set coalesces overlapping prompts while title presence records success durably.
     const titlesRunning = new Set<SessionSchema.ID>()
@@ -278,10 +308,32 @@ const layer = Layer.effect(
           return CallOutcome.Restart({ step: currentStep, recoveredOverflow: false })
         return yield* new StepFailedError({ error: compacted.error })
       }
-      const prepared = yield* modelRequests.prepare({
-        context: loaded,
-        step: currentStep,
+      const stepLimitReached = agent.info.steps !== undefined && currentStep >= agent.info.steps
+      const transcript = SessionModelRequest.baseTranscript({
+        agent: agent.info,
+        model: resolved,
+        tools: loaded.tools,
+        initial: loaded.initial,
+        messages: loaded.messages,
       })
+      const prepared = yield* modelRequests.prepare({
+        scope: { session, agentID: agent.id, model: resolved, tools: loaded.tools },
+        transcript: {
+          system: transcript.system,
+          messages: stepLimitReached
+            ? [...transcript.messages, Message.assistant(MAX_STEPS_PROMPT)]
+            : transcript.messages,
+        },
+        // The final Step keeps definitions available to protocols with native "none",
+        // preserving their prompt cache prefix. Calls are still rejected at execution.
+        toolChoice: stepLimitReached ? "none" : undefined,
+        webSocket: "session",
+      })
+      yield* diagnosePromptCache(session.id, prepared.request)
+      const executeTool = (input: Parameters<typeof prepared.executeTool>[0]) => {
+        if (stepLimitReached) return new Tool.Error({ message: "Tools are disabled after the maximum agent steps" })
+        return prepared.executeTool(input)
+      }
       // Every local tool call forked here is owned until it reaches one durable settlement.
       const toolRuns: Array<{
         readonly call: ToolCall
@@ -295,7 +347,7 @@ const layer = Layer.effect(
         // The selected catalog identity, not model.id: route-level ids are provider API
         // model ids (for example gpt-5.5-fast resolves to api id gpt-5.5).
         model: resolved.ref,
-        providerMetadataKey: model.route.providerMetadataKey ?? model.provider,
+        providerMetadataKey: transcript.providerMetadataKey,
         snapshot: startSnapshot,
         assistantMessageID,
       })
@@ -356,7 +408,7 @@ const layer = Layer.effect(
               call: event,
               fiber: yield* Effect.uninterruptibleMask((restore) =>
                 restore(
-                  prepared.executeTool({
+                  executeTool({
                     sessionID: session.id,
                     agent: agent.id,
                     messageID: assistantMessageID,
@@ -504,7 +556,7 @@ const layer = Layer.effect(
             // A local call or malformed tool input requires another model step, unless
             // this step already exhausted the agent's allowance.
             needsContinuation:
-              !prepared.stepLimitReached &&
+              !stepLimitReached &&
               record.calls.some((call) => !call.providerExecuted && (call.called || call.settled)),
             step: currentStep,
           })

packages/core/test/session-generate.test.ts

@@ -9,6 +9,7 @@ import {
   type LLMRequest,
 } from "@opencode-ai/ai"
 import { OpenAIChat } from "@opencode-ai/ai/protocols"
+import type { StreamOptions } from "@opencode-ai/ai/route"
 import { Agent } from "@opencode-ai/core/agent"
 import { Database } from "@opencode-ai/core/database/database"
 import { AppNodeBuilder } from "@opencode-ai/core/effect/app-node-builder"
@@ -51,15 +52,17 @@ import { Effect, Layer, Schema, Stream } from "effect"
 import { testEffect } from "./lib/effect"
 
 const requests: LLMRequest[] = []
+const options: Array<StreamOptions | undefined> = []
 let instruction: string | Instructions.Unavailable = "Initial context"
 const sessionID = SessionSchema.ID.make("ses_generate_test")
 
 const model = LanguageModel.make({ id: "generate-model", provider: "test", route: OpenAIChat.route })
 const client = Layer.mock(LLMClient.Service)({
   stream: () => Stream.die(new Error("unused")),
-  generate: (request) =>
+  generate: (request, requestOptions) =>
     Effect.sync(() => {
       requests.push(request)
+      options.push(requestOptions)
       const response = LLMResponse.fromEvents([
         LLMEvent.stepStart({ index: 0 }),
         LLMEvent.textStart({ id: "generate" }),
@@ -221,6 +224,7 @@ const setup = Effect.gen(function* () {
 it.effect("generates from fresh settled Session context without durable mutation", () =>
   Effect.gen(function* () {
     requests.length = 0
+    options.length = 0
     instruction = "Initial context"
     const { db, bus, instructions } = yield* setup
     yield* InstructionState.prepare(db, bus, instructions, sessionID)
@@ -292,6 +296,7 @@ it.effect("generates from fresh settled Session context without durable mutation
         if (event.tools.lookup) event.tools.lookup.description = "Hooked lookup"
       }),
     )
+    yield* hooks.register("session", "http.request", () => Effect.void)
 
     const generate = yield* SessionGenerate.Service
     const result = yield* generate.generate({ sessionID, prompt: "Summarize privately" })
@@ -321,6 +326,8 @@ it.effect("generates from fresh settled Session context without durable mutation
     ).toEqual(["Settled partial answer"])
     expect(requests[0]?.tools).toMatchObject([{ name: "lookup", description: "Hooked lookup" }])
     expect(requests[0]?.toolChoice).toBeUndefined()
+    expect(options[0]?.http).toBeFunction()
+    expect(options[0]?.webSocket).toBeUndefined()
     expect(yield* durableState(db, sessionID)).toEqual(before)
   }),
 )

packages/core/test/session-runner.test.ts

@@ -1004,9 +1004,16 @@ describe("SessionRunnerLLM", () => {
       const database = yield* Database.Service
       const bus = yield* Bus.Service
       yield* InstructionState.prepare(database.db, bus, selected.instructions, sessionID)
+      const loaded = yield* context.load(selected)
       const prepared = yield* modelRequests.prepare({
-        context: yield* context.load(selected),
-        step: 1,
+        scope: {
+          session: loaded.session,
+          agentID: loaded.agent.id,
+          model: loaded.model,
+          tools: loaded.tools,
+        },
+        transcript: { system: [], messages: [] },
+        webSocket: "session",
       })
       const http = prepared.options.http ?? (yield* Effect.die("Expected Session HTTP middleware"))
 
@@ -1015,7 +1022,7 @@ describe("SessionRunnerLLM", () => {
         return Effect.succeed(HttpClientResponse.fromWeb(request, new Response("network")))
       })
 
-      expect(prepared.webSocketEligible).toBe(false)
+      expect(prepared.options.webSocket).toBeUndefined()
       expect(response.headers["x-response-hook"]).toBe("active")
       expect(requestTriggers).toBe(1)
       expect(responseTriggers).toBe(1)

packages/schema/AGENTS.md

@@ -14,7 +14,7 @@
 - Current contracts are unversioned: use names like `Session`, `Permission`, `Question`, and identifiers like `Permission.Request`.
 - Legacy contracts retained for active compatibility, persistence, or migration are explicitly `V1`: use names like `SessionV1`, `PermissionV1`, and identifiers like `PermissionV1.Request`.
 - Do not preserve `V2` as the permanent name for the replacement architecture. Remove `V2` from current namespaces, brands, and identifiers as the contracts are normalized.
-- Retained V1 contracts live under `src/v1/`. New/current code must not depend on that subtree.
+- Retained V1 contracts should live under a dedicated `src/v1/` subtree once the V1 isolation PR runs. New/current code must not depend on that subtree.
 - V1 coexistence is temporary. Keep compatibility entrypoints only where migration requires them, and delete the V1 subtree when the legacy runtime is retired.
 - `@opencode-ai/protocol` and `@opencode-ai/sdk-next` are current `/api/...` surfaces.
 

packages/tui/src/context/session-tabs.tsx

@@ -247,12 +247,6 @@ export const { use: useSessionTabs, provider: SessionTabsProvider } = createSimp
     onCleanup(event.on("session.execution.succeeded", (evt) => markUnread(evt.data.sessionID, "activity")))
     onCleanup(event.on("session.execution.interrupted", (evt) => markUnread(evt.data.sessionID, "activity")))
     onCleanup(event.on("session.execution.failed", (evt) => markUnread(evt.data.sessionID, "error")))
-    onCleanup(
-      event.on("session.moved", (evt) => {
-        if (!enabled() || !state().tabs.some((tab) => tab.sessionID === root(evt.data.sessionID))) return
-        void Promise.allSettled([data.location.syncInfo(evt.data.location), data.location.vcs.sync(evt.data.location)])
-      }),
-    )
     onCleanup(
       event.on("session.inbox.enqueued", (evt) => {
         if (!enabled() || evt.data.item.type !== "user") return

packages/tui/test/context/session-tabs.test.tsx

@@ -197,32 +197,6 @@ test("loads VCS metadata for each persisted tab location", async () => {
   }
 })
 
-test("loads location metadata when an open session moves", async () => {
-  const destination = `${directory}/moved-worktree`
-  const setup = await renderSessionTabs("first")
-
-  try {
-    await wait(() => setup.locations.includes(directory) && setup.vcsLocations.includes(directory))
-    setup.emit({
-      id: "evt_moved",
-      created: 1,
-      type: "session.moved",
-      durable: { aggregateID: "first", seq: 1, version: 1 },
-      data: {
-        sessionID: "first",
-        location: { directory: destination },
-        projectID: "project",
-      },
-    })
-
-    await wait(() => setup.data.session.get("first")?.location.directory === destination)
-    await wait(() => setup.locations.includes(destination))
-    await wait(() => setup.vcsLocations.includes(destination))
-  } finally {
-    await setup.destroy()
-  }
-})
-
 test("stores session tabs for the current working directory by default", async () => {
   const setup = await renderSessionTabs("first")
 

packages/www/AGENTS.md

@@ -9,7 +9,7 @@
 - Use parenthesized content folders for sidebar groups that must not add a URL segment. Keep ungrouped top-level pages directly under `content/docs/`.
 - Put static files in `public/` and reference them with root-relative paths.
 - The API reference is generated from `openapi.json`; do not duplicate endpoint documentation as hand-written MDX.
-- Keep documentation aligned with the current packages.
+- Keep documentation aligned with the V2 packages. Do not use `packages/opencode` as the source of truth unless the task explicitly concerns V1.
 
 ## Local development
 

specs/project.md

@@ -0,0 +1,64 @@
+## project
+
+The goal is to let a single instance of OpenCode run sessions for multiple projects and different worktrees per project.
+
+### api
+
+```
+GET /project -> Project[]
+
+POST /project/init -> Project
+
+
+GET /project/:projectID/session -> Session[]
+
+GET /project/:projectID/session/:sessionID -> Session
+
+POST /project/:projectID/session -> Session
+{
+  id?: string
+  parentID?: string
+  directory: string
+}
+
+DELETE /project/:projectID/session/:sessionID
+
+POST /project/:projectID/session/:sessionID/init
+
+POST /project/:projectID/session/:sessionID/abort
+
+POST /project/:projectID/session/:sessionID/share
+
+DELETE /project/:projectID/session/:sessionID/share
+
+POST /project/:projectID/session/:sessionID/compact
+
+GET /project/:projectID/session/:sessionID/message -> { info: Message, parts: Part[] }[]
+
+GET /project/:projectID/session/:sessionID/message/:messageID -> { info: Message, parts: Part[] }
+
+POST /project/:projectID/session/:sessionID/message -> { info: Message, parts: Part[] }
+
+POST /project/:projectID/session/:sessionID/revert -> Session
+
+POST /project/:projectID/session/:sessionID/unrevert -> Session
+
+POST /project/:projectID/session/:sessionID/permission/:permissionID -> Session
+
+GET /project/:projectID/session/:sessionID/find/file -> string[]
+
+GET /project/:projectID/session/:sessionID/file -> { type: "raw" | "patch", content: string }
+
+GET /project/:projectID/session/:sessionID/file/status -> File[]
+
+POST /log
+
+// These are awkward
+
+GET /provider?directory=<resolve path> -> Provider
+GET /config?directory=<resolve path> -> Config // think only tui uses this?
+
+GET /project/:projectID/agent?directory=<resolve path> -> Agent
+GET /project/:projectID/find/file?directory=<resolve path> -> File
+
+```

specs/storage/effect-sqlite-package.md

@@ -0,0 +1,145 @@
+# Effect Drizzle SQLite Package
+
+## Goal
+
+Create a small workspace package that vendors the Drizzle `effect-sqlite` adapter shape for our repo. This is not an opencode storage abstraction. It is a local package that ports the Drizzle Effect SQLite implementation so we can use it before/independently of upstream release timing.
+
+`packages/opencode` will use it internally, but the package itself should be generic: Drizzle + Effect + SQLite. No opencode paths, migrations, tables, transaction hooks, post-commit behavior, or domain language should live in this package.
+
+## Package Shape
+
+Add a package similar in style to `packages/http-recorder`:
+
+- `packages/effect-drizzle-sqlite/package.json`
+- `packages/effect-drizzle-sqlite/src/index.ts`
+- `packages/effect-drizzle-sqlite/src/effect-sqlite/*`
+- `packages/effect-drizzle-sqlite/src/sqlite-core/effect/*`
+- `packages/effect-drizzle-sqlite/test/sqlite.test.ts`
+
+Package name:
+
+- `@opencode-ai/effect-drizzle-sqlite`
+
+Initial exports:
+
+```ts
+export { EffectLogger } from "drizzle-orm/effect-core"
+export * from "./effect-sqlite/driver"
+export * from "./effect-sqlite/session"
+export { migrate } from "./effect-sqlite/migrator"
+export * as EffectDrizzleSqlite from "."
+```
+
+The package should follow Drizzle's adapter naming and semantics as closely as possible. Think of it as a vendored `drizzle-orm/effect-sqlite` package surface, not as a new storage service API.
+
+## Upstream References
+
+Use these as implementation references instead of inventing a custom API:
+
+- Drizzle Effect Postgres current RC:
+  - `/Users/kit/code/open-source/drizzle-orm-rc4-pr/drizzle-orm/src/effect-core/query-effect.ts`
+  - `/Users/kit/code/open-source/drizzle-orm-rc4-pr/integration-tests/tests/pg/effect-sql.test.ts`
+- SQLite Effect branch/reference:
+  - `/Users/kit/code/open-source/drizzle-orm-beta16/drizzle-orm/src/up-migrations/effect-sqlite.ts`
+  - `/Users/kit/code/open-source/drizzle-orm-beta16/integration-tests/tests/sqlite/effect-sql.test.ts`
+  - `/Users/kit/code/open-source/drizzle-orm-beta16/drizzle-orm/type-tests/sqlite/effect.ts`
+- Effect SQLite client source of truth:
+  - `/Users/kit/code/open-source/effect-smol/packages/sql/sqlite-bun/src/SqliteClient.ts`
+  - `/Users/kit/code/open-source/effect-smol/packages/sql/sqlite-node/test/Client.test.ts`
+  - `/Users/kit/code/open-source/effect-smol/packages/sql/sqlite-node/test/SqliteMigrator.test.ts`
+
+Important API patterns from those references:
+
+- Drizzle queries are Effect-yieldable: `yield* db.select().from(table)`.
+- Transactions are Effect values: `yield* db.transaction((tx) => Effect.gen(...), { behavior: "immediate" })`.
+- SQLite clients come from Effect layers such as `SqliteClient.layer({ filename })`.
+- Migrations can run through Effect SQL/SQLite migrator mechanisms or Drizzle's `effect-sqlite/migrator` when available.
+
+## Public Surface
+
+Do not invent an `Interface<TDatabase>` abstraction unless the Drizzle port already has one. The public surface should mirror Drizzle's Effect adapters:
+
+```ts
+const db = yield * EffectDrizzleSqlite.make({ relations }).pipe(Effect.provide(EffectDrizzleSqlite.DefaultServices))
+
+yield * db.select().from(users)
+yield *
+  db.transaction(
+    (tx) =>
+      Effect.gen(function* () {
+        yield* tx.insert(users).values({ name: "Ada" })
+      }),
+    { behavior: "immediate" },
+  )
+```
+
+Notes:
+
+- `make` / `makeWithDefaults` should match the Drizzle Effect SQLite branch as much as possible.
+- `DefaultServices` should provide Drizzle's default logger/cache services, same as Effect Postgres.
+- The package should depend on Effect SQL SQLite clients (`@effect/sql-sqlite-bun` and/or node) the same way the Drizzle branch does.
+- Opencode-specific path/channel selection stays in `packages/opencode`.
+
+## Opencode Adoption Notes
+
+These are not package requirements, but they matter for the later opencode adoption PR.
+
+The current `packages/opencode/src/storage/db.ts` has two non-obvious semantics that the opencode wrapper must preserve when it consumes this adapter:
+
+- Nested `Database.use` inside `Database.transaction` sees the current transaction, not the root client.
+- `Database.effect` queues post-commit side effects while inside a transaction, and runs immediately outside a transaction.
+
+The opencode wrapper can implement that using Effect context instead of `LocalContext`:
+
+- A private transaction context holding `{ tx, afterCommit }`.
+- `withDb`/`db` methods read the current transaction context if present, otherwise use the root db.
+- `transaction` installs a transaction context around the effect.
+- Nested transactions can either reuse the existing tx initially, matching current behavior, or later use explicit savepoints if needed.
+
+Do not remove this behavior while moving opencode to Effect SQLite. `SyncEvent.run` depends on transaction composability and `behavior: "immediate"` for sequencing correctness.
+
+## Migration Strategy
+
+1. Add `@opencode-ai/effect-drizzle-sqlite` with a minimal in-memory/file SQLite test schema.
+2. Port the Drizzle Effect SQLite adapter from the SQLite branch into the package, preserving upstream names and API shape.
+3. Test adapter-level guarantees:
+   - query builders are yieldable Effect values,
+   - `transaction(..., { behavior: "immediate" })` commits successful writes,
+   - failed transaction rolls back,
+   - migrations run once and in order,
+   - close finalizer closes the underlying SQLite database.
+4. Add `@opencode-ai/effect-drizzle-sqlite` as a dependency of `packages/opencode`.
+5. Port `packages/opencode/src/storage/db.ts` to be a thin compatibility wrapper over the adapter plus opencode-specific transaction/post-commit context.
+6. Keep existing call sites working first:
+   - `Database.Client()`
+   - `Database.use(...)`
+   - `Database.transaction(...)`
+   - `Database.effect(...)`
+7. After compatibility is stable, migrate call sites from callback-style `Database.use` to yielding Effect Drizzle queries directly.
+8. Only then build domain stores like session/message/project stores on top of opencode's storage wrapper.
+
+## Why This Is Cleaner Than Starting With SessionStorage
+
+`SessionStorage` is a useful domain seam, but it does not answer the core adapter problem: how to make Drizzle SQLite Effect-native in this repo.
+
+An Effect Drizzle SQLite package lets us vendor the adapter once. Then opencode can build its own storage wrapper on top, and `SessionStorage`, `MessageStorage`, event store, and projector writes can all share the same transaction and migration model.
+
+## Open Questions
+
+- Which client should the first package target: `@effect/sql-sqlite-bun`, `@effect/sql-sqlite-node`, or both behind separate layers?
+- How much source should we copy from the Drizzle branch versus import from catalog `drizzle-orm` internals?
+- What is the update path once Drizzle upstream ships `effect-sqlite`?
+- Should `afterCommit` stay opencode-specific until event publishing moves? Default answer: yes.
+- Should the compatibility wrapper preserve synchronous return types temporarily, or should the migration intentionally force Effect call sites?
+- Do CLI/admin raw SQL and sqlite shell stay in `packages/opencode`, or does the storage package expose backend capabilities for them?
+
+## Recommended First PR
+
+Make the first PR package-only and intentionally boring:
+
+- Add `packages/effect-drizzle-sqlite`.
+- Use a tiny test schema, not opencode domain tables.
+- Prove Effect Drizzle SQLite queries, transactions, and migrations.
+- Do not migrate `packages/opencode` yet except possibly adding the dependency if needed for typechecking.
+
+That gives us a focused place to validate the Effect SQLite approach before disturbing opencode's current database runtime.

specs/storage/remove-opencode-db.md

@@ -0,0 +1,234 @@
+# Remove `packages/opencode/src/storage/db.ts`
+
+## Goal
+
+Remove all production usages of the legacy `packages/opencode/src/storage/db.ts` module.
+
+This means eliminating imports from `@/storage/db` or `./storage/db`, including:
+
+- `Database.use(...)`
+- `Database.transaction(...)`
+- `Database.effect(...)`
+- `Database.Client()`
+- `Database.getPath()`
+- `Database.TxOrDb` / `Database.Transaction`
+- drizzle helpers re-exported from `@/storage/db`, such as `eq`
+
+This does not mean removing SQLite or Drizzle everywhere in one step. The smaller target is deleting the opencode legacy wrapper by moving call sites onto deeper modules or onto the core/effect database adapter directly.
+
+## Current Inventory
+
+Production imports from `packages/opencode/src/storage/db.ts` are concentrated in 21 source files:
+
+- `packages/opencode/src/account/repo.ts`
+- `packages/opencode/src/cli/cmd/db.ts`
+- `packages/opencode/src/cli/cmd/import.ts`
+- `packages/opencode/src/cli/cmd/stats.ts`
+- `packages/opencode/src/control-plane/workspace.ts`
+- `packages/opencode/src/index.ts`
+- `packages/opencode/src/node.ts`
+- `packages/opencode/src/permission/index.ts`
+- `packages/opencode/src/project/project.ts`
+- `packages/opencode/src/server/projectors.ts`
+- `packages/opencode/src/server/routes/instance/httpapi/handlers/sync.ts`
+- `packages/opencode/src/server/shared/fence.ts`
+- `packages/opencode/src/session/message-v2.ts`
+- `packages/opencode/src/session/projectors.ts`
+- `packages/opencode/src/session/prompt.ts`
+- `packages/opencode/src/session/session.ts`
+- `packages/opencode/src/share/share-next.ts`
+- `packages/opencode/src/storage/db.ts`
+- `packages/opencode/src/sync/index.ts`
+- `packages/opencode/src/worktree/index.ts`
+
+There are 63 direct API/type references in those files. The references fall into the groups below.
+
+## Group 1: Database Runtime And Startup
+
+Status: Completed. Startup, the public node export, and database CLI tooling no longer import the legacy opencode database wrapper; `packages/opencode/src/storage/db.ts` has been deleted.
+
+Files:
+
+- `packages/opencode/src/storage/db.ts`
+- `packages/opencode/src/index.ts`
+- `packages/opencode/src/node.ts`
+- `packages/opencode/src/cli/cmd/db.ts`
+
+Current usage:
+
+- `storage/db.ts` opens the singleton database, applies pragmas, exposes callback-style access, holds ambient transaction context, and queues post-commit effects.
+- `index.ts` no longer performs the removed JSON-to-SQLite migration during startup.
+- `node.ts` publicly re-exports `Database` from the legacy module.
+- `cli/cmd/db.ts` uses `Database.getPath()` to print the path, open a readonly Bun SQLite handle, run `sqlite3`, and vacuum.
+
+Why this group comes first:
+
+- These call sites define the seam currently used by every other group.
+- Deleting `storage/db.ts` requires an explicit replacement for database path, client acquisition, migration startup, and close/finalization.
+
+Target shape:
+
+- Move database path and client startup behind the core/effect database module rather than the opencode wrapper.
+- Replace `Database.Client()` with an Effect-provided database service or a narrow startup-only adapter.
+- Replace the public `node.ts` re-export with either no export or a stable non-legacy database capability.
+- Keep `cli/cmd/db.ts` as an admin/raw SQLite tool, but make it ask the replacement database path provider instead of importing `@/storage/db`.
+
+## Group 2: Sync Event Transaction Boundary
+
+Status: Completed. `SyncEvent` and the opencode projector boundary were removed; session/message event projection now lives in core EventV2/projector infrastructure.
+
+Files:
+
+- `packages/opencode/src/sync/index.ts`
+- `packages/opencode/src/session/projectors.ts`
+- `packages/opencode/src/server/projectors.ts`
+
+Current usage:
+
+- `SyncEvent.run` uses `Database.transaction(..., { behavior: "immediate" })` to allocate event sequence numbers safely.
+- `SyncEvent.process` wraps projector execution, event sequence writes, event log writes, and post-commit publishing in `Database.transaction(...)`.
+- `Database.effect(...)` queues publish side effects until after the transaction commits.
+- Projector functions accept `Database.TxOrDb` so they can write through either a root client or the active transaction.
+
+Why this group is critical:
+
+- It depends on the most non-obvious legacy behavior: nested `Database.use` inside a transaction must see the active transaction, and `Database.effect` must not publish until commit.
+- It is the central seam for session, message, permission, workspace, and server projection writes.
+
+Target shape:
+
+- Replace `Database.TxOrDb` with an explicit projector transaction type from the replacement database adapter.
+- Move transaction context and after-commit behavior into an Effect-native sync event implementation.
+- Preserve immediate transaction behavior for sequence allocation.
+- Convert projector registration to accept the new transaction interface before converting every projector body.
+
+Suggested first step:
+
+- Create a narrow internal module for sync projection execution, then migrate `SyncEvent.project(...)` and projector type signatures to that module. Keep the implementation backed by the new database adapter until all projector users are moved.
+
+## Group 3: Domain Repositories Already Behind Services
+
+Status: Completed. These services no longer import the legacy opencode database wrapper.
+
+Files:
+
+- `packages/opencode/src/account/repo.ts`
+- `packages/opencode/src/project/project.ts`
+- `packages/opencode/src/control-plane/workspace.ts`
+- `packages/opencode/src/share/share-next.ts`
+
+Current usage:
+
+- These modules already expose Effect services or Effect functions, but internally wrap `Database.use` with local `db(...)` helpers or `Effect.try`.
+- `account/repo.ts` uses both `Database.use` and `Database.transaction` through a repository interface.
+- `project/project.ts` has the largest mixed usage: Effect service methods use a local `db(...)` helper, while legacy top-level functions still call `Database.use` directly.
+- `control-plane/workspace.ts` and `share/share-next.ts` have local Effect wrappers around `Database.use`.
+
+Why this group is tractable:
+
+- The public interfaces are already deeper than the database calls.
+- Most callers should not need to know whether these modules use Drizzle, files, or core services internally.
+
+Target shape:
+
+- Inject the replacement database service into each Effect layer and yield Effect Drizzle queries directly.
+- Replace local callback wrappers with direct Effect queries.
+- Move remaining synchronous top-level helpers either behind the existing service interface or onto core modules.
+
+Suggested order:
+
+- Start with `account/repo.ts`; it has a clear repository interface and few call sites.
+- Then migrate `share/share-next.ts` and `control-plane/workspace.ts` local wrappers.
+- Leave `project/project.ts` for last in this group because it mixes project resolution, VCS, global bus emission, migration, and legacy top-level helpers.
+
+## Group 4: Session And Message Read Models
+
+Status: Completed. Session/message reads and projector writes have moved off the legacy opencode database wrapper.
+
+Files:
+
+- `packages/opencode/src/session/session.ts`
+- `packages/opencode/src/session/message-v2.ts`
+- `packages/opencode/src/session/prompt.ts`
+- `packages/opencode/src/session/projectors.ts`
+
+Current usage:
+
+- `session/session.ts` uses `Database.use` for session reads, list queries, children, part lookup, and global list helpers.
+- `session/message-v2.ts` uses `Database.use` to page messages, hydrate parts, fetch one message, and fetch parts.
+- `session/prompt.ts` imports `eq` from `@/storage/db` and reads current prompt-related session/message rows directly.
+- `session/projectors.ts` uses `TxOrDb` for session/message usage projection helpers.
+
+Why this group should be split:
+
+- Reads can move independently from projector writes.
+- Message hydration is used by model prompt construction and session APIs, so changing it without a stable read module would spread query details across callers.
+- Projector writes are tied to Group 2's transaction type.
+
+Target shape:
+
+- Create or use a session/message read module with Effect-native methods for `get`, `list`, `page`, `parts`, and prompt assembly reads.
+- Convert `session/projectors.ts` only after Group 2 defines the replacement projector transaction type.
+
+Suggested order:
+
+- Migrate `session/message-v2.ts` reads first because the module already centralizes message pagination and hydration.
+- Migrate `session/session.ts` read helpers next.
+- Migrate `session/prompt.ts` after message/session reads exist, and import drizzle operators from `drizzle-orm` if any direct SQL remains temporarily.
+
+## Group 5: Legacy CLI And One-Off Admin Reads
+
+Status: Completed. Remaining one-off CLI/admin reads and writes now use core database services or domain services instead of the legacy opencode database wrapper.
+
+Files:
+
+- `packages/opencode/src/cli/cmd/import.ts`
+- `packages/opencode/src/cli/cmd/stats.ts`
+- `packages/opencode/src/server/shared/fence.ts`
+- `packages/opencode/src/server/routes/instance/httpapi/handlers/sync.ts`
+- `packages/opencode/src/worktree/index.ts`
+- `packages/opencode/src/permission/index.ts`
+
+Current usage:
+
+- `cli/cmd/import.ts` writes imported sessions/messages/parts directly with `Database.use`.
+- `cli/cmd/stats.ts` reads all sessions directly.
+- `server/shared/fence.ts` queries sessions for fence context.
+- `handlers/sync.ts` reads event rows for HTTP sync endpoints.
+- `worktree/index.ts` looks up a project row for worktree behavior.
+- `permission/index.ts` reads permission rows directly.
+
+Why this group is mostly cleanup:
+
+- Most usages are small and can either call an existing domain service or be given a narrow query function.
+- They are not defining shared transaction semantics.
+
+Target shape:
+
+- Replace direct database reads with existing services where possible.
+- For admin/import commands, prefer dedicated import/stat modules rather than direct database access from command handlers.
+- For HTTP sync reads, move the event log query behind the sync event module.
+- For permission and worktree reads, call the permission/project services if available; otherwise add narrow repository methods.
+
+## Recommended Migration Sequence
+
+All migration groups are complete or superseded. `packages/opencode/src/storage/db.ts` has been deleted.
+
+## Superseded: Data Migrations
+
+Status: Superseded. No opencode data-migration group remains.
+
+The previous opencode `data-migration.ts` service only backfilled session usage from message rows. That work is now covered by core database migration `packages/core/src/database/migration/20260510033149_session_usage.ts`, so there is no separate opencode data-migration group.
+
+## Invariants To Preserve
+
+- Nested reads inside a transaction must use the active transaction, not the root client.
+- `SyncEvent.run` sequence allocation must keep immediate transaction behavior.
+- Post-commit publish effects must not run before the transaction commits.
+- Existing schema ownership remains in `packages/core/src/**/*.sql.ts`; do not move table definitions back into `packages/opencode`.
+
+## Verification Commands
+
+- `rg "@/storage/db|./storage/db|Database\.(use|transaction|effect|Client|getPath)|\bTxOrDb\b|\bTransaction\b" packages/opencode/src`
+- `bun typecheck` from `packages/opencode`
+- Relevant package tests from `packages/opencode`, not the repo root

specs/tui-package.md

@@ -0,0 +1,641 @@
+# TUI Package Extraction
+
+## Goal
+
+Move the canonical OpenCode terminal application from
+`packages/opencode/src/cli/cmd/tui` into a self-contained workspace package while
+the legacy CLI and the new CLI continue to use the same implementation.
+
+Target package:
+
+```text
+packages/tui
+name: @opencode-ai/tui
+```
+
+Target dependency graph:
+
+```text
+packages/opencode ---\
+                      > @opencode-ai/tui -> @opencode-ai/sdk
+packages/cli --------/
+```
+
+The TUI may directly depend on terminal and UI infrastructure such as
+`@opentui/core`, `@opentui/solid`, `@opentui/keymap`, `solid-js`, Effect, and
+generic presentation libraries. It must not depend on `packages/opencode`,
+`packages/cli`, or `@opencode-ai/core`.
+
+The SDK is the TUI's OpenCode boundary. Missing backend data or operations must
+be added to the server API and generated SDK rather than imported from backend
+implementation modules.
+
+## Migration Rules
+
+- Keep one canonical implementation of every TUI feature. Do not copy the full
+  TUI into `packages/cli` and synchronize two trees.
+- Land each section below independently and commit it before starting the next
+  section.
+- Keep each intermediate commit buildable and type-safe.
+- Continue integrating team changes into whichever location is canonical for a
+  file at that point in the migration.
+- Use temporary compatibility re-exports only when they materially reduce the
+  size or conflict risk of a section. Mark them for removal in a later section.
+- Do not preserve private imports by creating aliases from `packages/tui` back
+  into `packages/opencode`.
+- Do not replace private `packages/opencode` imports with `@opencode-ai/core`
+  imports merely to make the package compile.
+- Keep tool rendering tolerant of unknown tools and wire-format changes. Local
+  checks over `unknown` input and metadata are acceptable; importing backend
+  tool implementations for type safety is not.
+- Keep legacy CLI command parsing, server startup, worker management,
+  authentication, and config discovery outside `@opencode-ai/tui`.
+
+## Ownership Boundary
+
+### `@opencode-ai/tui` Owns
+
+- OpenTUI renderer lifecycle shared by both CLI hosts
+- Solid application composition
+- Components, routes, dialogs, themes, keymaps, and UI primitives
+- SDK client synchronization and event consumption
+- Tool-call and tool-result presentation
+- TUI-facing plugin contracts and presentation slots
+- Resolved TUI configuration types, defaults, and pure validation
+- Terminal behavior such as selection, clipboard integration, and local editor
+  launching when it is not host-specific
+- TUI-local persistence such as prompt history, stash, frecency, selected model,
+  and selected theme
+- Presentation utilities such as locale formatting, error display, record
+  checks, duration formatting, and layout helpers
+
+### CLI Hosts Own
+
+- Command definitions and argument parsing
+- Starting, locating, and stopping servers and workers
+- Authentication and transport construction
+- Process-level signal policy
+- Config file discovery, precedence, migration, and environment substitution
+- Plugin package discovery, installation, and backend activation
+- Upgrade checks and installation metadata
+- Executable build wiring and worker path defines
+
+### Server And SDK Own
+
+- OpenCode domain data displayed by the TUI
+- Session, message, workspace, file, provider, model, agent, and permission
+  operations
+- Retry, revert, fork, share, and other backend actions
+- Stable wire shapes for tool parts and plugin metadata
+- Server capabilities needed to conditionally expose UI behavior
+
+## Current Boundary
+
+The canonical implementation currently lives under:
+
+```text
+packages/opencode/src/cli/cmd/tui
+```
+
+Its private dependency on `packages/opencode` is primarily expressed through
+the `@/*` TypeScript alias, which resolves to `packages/opencode/src/*`.
+`@tui/*` imports are internal to the TUI and are not themselves a package
+boundary problem.
+
+The main private dependency groups are:
+
+- `@/util/*`: presentation helpers plus filesystem/process/RPC helpers
+- `@/tool/*`: backend tool implementations used by renderers
+- `@/session/*`, `@/provider/*`, and `@/reference/*`: backend data and actions
+- `@/config/*`: config discovery, parsing, variables, and plugin resolution
+- `@/plugin/*`: plugin loading and installation
+- `@/cli/*`: yargs adapters, network setup, errors, and CLI presentation
+- `@/server/*`: authentication and embedded server behavior
+- `Global.Path`, `Flag`, and process environment reads
+
+The initial extraction should reduce these dependencies in place before moving
+the application root.
+
+## Section 1: Create The Package Skeleton
+
+Status: Completed. The private `@opencode-ai/tui` workspace package now has an
+independent OpenTUI Solid JSX configuration, narrow root export, package-local
+alias, and in-memory render smoke test. Neither CLI consumes the package yet.
+
+Create `packages/tui` without moving the application root yet.
+
+Tasks:
+
+- Add `packages/tui/package.json` with the name `@opencode-ai/tui`.
+- Add a package `tsconfig.json` configured for OpenTUI Solid JSX.
+- Add `bunfig.toml` with the OpenTUI Solid preload for package-local development
+  and tests.
+- Add package scripts for `typecheck` and package-local tests.
+- Add direct dependencies used by the TUI. Do not rely on workspace hoisting.
+- Add a narrow package export, initially only the package root and any explicit
+  testing entrypoint needed by migrated tests.
+- Establish a package-local import convention. A local alias such as `@tui/*`
+  is acceptable, but it must resolve entirely inside `packages/tui`.
+- Add a minimal package entrypoint and smoke test proving OpenTUI Solid TSX can
+  typecheck and render.
+- Do not make either CLI consume the package yet.
+
+Exit criteria:
+
+- `packages/tui` typechecks independently.
+- Its test command runs from `packages/tui`.
+- The package has no dependency on `opencode`, `@opencode-ai/cli`, or
+  `@opencode-ai/core`.
+
+Checkpoint commit:
+
+```text
+feat(tui): add standalone package skeleton
+```
+
+## Section 2: Move Presentation Utilities And Leaf UI
+
+Status: Completed. Presentation utilities, bundled themes and their pure theme
+engine, keybinding/keymap mechanics, and low-coupling border, link, and spinner
+primitives now live in `@opencode-ai/tui`. The legacy host consumes explicit
+package exports and retains only integration wrappers or compatibility
+re-exports where backend and process concerns have not moved yet.
+
+Move low-coupling code first so subsequent team changes land in the new package
+without waiting for the application root migration.
+
+Tasks:
+
+- Move TUI presentation utilities into `packages/tui/src/util`, including the
+  portions of locale, error display, record checks, duration formatting, and
+  small functional helpers used by TUI code.
+- Move pure TUI utilities already under the old TUI directory.
+- Move themes and bundled theme JSON files.
+- Move UI primitives and leaf components that have no private backend imports.
+- Move pure keybinding schemas and keymap helpers that do not read host flags.
+- Move related unit and snapshot tests.
+- Update remaining old-tree consumers to import the new canonical modules.
+- Use temporary compatibility re-exports from old TUI paths only if needed to
+  avoid a large unrelated import rewrite.
+- Do not move `Filesystem`, `Process`, `Rpc`, worker startup, or config discovery
+  as generic utilities in this section.
+
+Exit criteria:
+
+- Moved files have no `@/...` imports.
+- Tests for moved code run from `packages/tui`.
+- Existing legacy TUI behavior and typecheck remain unchanged.
+
+Checkpoint commit:
+
+```text
+refactor(tui): move presentation utilities and primitives
+```
+
+## Section 3: Remove Backend Tool Implementation Imports
+
+Status: Completed. Legacy and V2 tool renderers now dispatch on SDK wire names,
+accept `Record<string, unknown>` input and metadata, and use local guards for
+nested presentation data. Web-search labels and structured metadata extraction
+are TUI-owned, unknown tools retain the generic fallback, and no TUI source
+imports backend tool implementations. The route components remain in the legacy
+tree until the SDK state and route move in Section 6.
+
+Make tool rendering depend only on SDK wire data and local presentation logic.
+
+Tasks:
+
+- Remove imports from `@/tool/*` in TUI routes and feature plugins.
+- Key built-in renderers by SDK tool name strings such as `read`, `write`,
+  `edit`, `apply_patch`, `grep`, `glob`, `bash`, `question`, and `task`.
+- Treat tool input, output metadata, and plugin-defined fields as `unknown` at
+  the package boundary.
+- Add small local type guards only where a renderer needs a particular field.
+- Preserve a generic fallback renderer for unknown and plugin-provided tools.
+- Keep renderer failures local: malformed metadata must not crash the entire
+  session view.
+- Replace backend-derived labels or IDs with TUI-owned presentation constants or
+  SDK-provided values.
+- Move the affected tool presentation components and tests to `packages/tui`.
+
+Exit criteria:
+
+- No TUI source imports `@/tool/*`.
+- Unknown tools render through the generic fallback.
+- Existing built-in tool snapshots remain equivalent unless intentionally
+  updated and reviewed.
+
+Checkpoint commit:
+
+```text
+refactor(tui): decouple tool rendering from backend tools
+```
+
+## Section 4: Make Runtime Inputs Explicit
+
+Status: Completed for the shared runtime contract and legacy host. The TUI now
+receives immutable launch-directory, path, capability, terminal/editor, startup,
+and build inputs through `@opencode-ai/tui/runtime`. Movable app, component,
+route, and feature-plugin code no longer reads OpenCode globals or process state;
+command, config, plugin-loading, custom-theme discovery, editor/clipboard, and
+Windows lifecycle adapters remain host-owned. `packages/cli` does not consume
+this contract yet; that integration remains deferred to Section 9.
+
+Replace process-global OpenCode state with resolved TUI inputs.
+
+Define narrow inputs rather than one unstructured host object. Expected groups
+include:
+
+```ts
+type TuiCapabilities = {
+  mouse: boolean
+  copyOnSelect: boolean
+  terminalTitle: boolean
+  workspaces: boolean
+  showTimeToFirstDraw: boolean
+}
+
+type TuiPaths = {
+  home: string
+  state: string
+  config: string
+  data: string
+}
+
+type TuiBuildInfo = {
+  version: string
+  channel?: string
+}
+```
+
+Tasks:
+
+- Inventory direct reads of `Flag`, `Global.Path`, and relevant environment
+  variables in movable TUI code.
+- Pass resolved capabilities into the application/provider tree.
+- Pass local path roots or a narrow TUI storage capability into persistence
+  contexts.
+- Pass build/version information explicitly.
+- Keep environment reads needed by legacy command or worker startup in
+  `packages/opencode` adapters.
+- Give `packages/tui` sensible host-neutral defaults only when behavior is truly
+  local to a terminal client.
+- Move contexts and components after their global dependencies are removed.
+
+Exit criteria:
+
+- Movable TUI code does not import `Flag` or `Global`.
+- TUI tests can supply deterministic capabilities and storage paths.
+- The legacy host constructs the required input through the public package API;
+  the new CLI integration remains deferred to Section 9.
+
+Checkpoint commit:
+
+```text
+refactor(tui): make runtime capabilities explicit
+```
+
+## Section 5: Separate Resolved TUI Config From Host Config Loading
+
+Status: Completed for the package config contract and legacy host adapter.
+`@opencode-ai/tui/config` now owns schemas, defaults, keybind resolution, the
+resolved config type, and the Solid config provider. The legacy host retains
+file discovery, precedence, JSONC parsing, substitutions, migration,
+source-relative sound paths, plugin origins, dependency installation, and
+Effect services. `packages/cli` remains untouched until Section 9.
+
+Move config semantics needed by rendering while retaining filesystem discovery
+and migration in the legacy host.
+
+Tasks:
+
+- Move TUI config schemas, keybind schemas, defaults, and pure resolution to
+  `packages/tui`.
+- Define the resolved config accepted by the public TUI entrypoint.
+- Keep config path discovery, project/global precedence, migration, variable
+  expansion, and plugin package installation in `packages/opencode` initially.
+- Make the legacy host produce the same resolved config shape.
+- Add a new CLI adapter that can initially provide defaults or its own resolved
+  configuration.
+- Update schema-generation imports to use the package's explicit config export
+  if schema generation still needs TUI schemas.
+- Move pure config tests; retain discovery and migration integration tests in
+  `packages/opencode`.
+
+Exit criteria:
+
+- `packages/tui` does not import `@/config/*`.
+- Config discovery can change without changing TUI rendering code.
+- The old CLI still honors existing config precedence and migration behavior.
+
+Checkpoint commit:
+
+```text
+refactor(tui): separate config resolution from loading
+```
+
+## Section 6: Move SDK State, Routes, And Backend Operations
+
+Status: Completed for the SDK/domain boundary. SDK, project, event, legacy sync,
+V2 sync, local model state, prompt persistence, and pure prompt helpers are now
+canonical in `@opencode-ai/tui`. Configured references resolve through the new
+generated `reference.list` SDK operation; prompt payloads rely on optional
+server-assigned IDs; local attachment reads use the package platform contract.
+Legacy route files remain in place until the plugin slot boundary and app-root
+move, but their only private dependencies are plugin presentation or local host
+adapters rather than OpenCode domain implementations.
+
+Make the SDK the only OpenCode domain boundary used by the TUI.
+
+Tasks:
+
+- Move SDK client providers, event synchronization, routes, prompt UI, and
+  session views into `packages/tui`.
+- Replace direct imports from `@/session/*`, `@/provider/*`, `@/reference/*`,
+  `@/lsp/*`, and other backend domains with SDK data or TUI-owned presentation
+  helpers.
+- Replace direct backend actions such as retry with SDK calls.
+- For each missing operation, add or adjust the server endpoint, regenerate the
+  JavaScript SDK with `./packages/sdk/js/script/build.ts`, and consume the
+  generated SDK API.
+- Keep transport creation outside the package. Accept a base URL, headers,
+  custom fetch, event source, or constructed SDK client as appropriate.
+- Keep local-only UI state in the TUI package rather than adding it to the
+  server API.
+- Move affected tests and fixtures. Use real SDK/server integration where
+  practical instead of mocking backend modules.
+
+Exit criteria:
+
+- Domain-facing TUI code imports OpenCode data and operations only from
+  `@opencode-ai/sdk`.
+- No TUI source imports private session, provider, reference, LSP, server, or
+  core domain implementations.
+- SDK generation is clean after any API changes.
+
+Checkpoint strategy:
+
+This section may be split into multiple commits when an SDK gap is substantial.
+Each commit must leave both the old TUI host and package tests working. Suggested
+commit pattern:
+
+```text
+feat(sdk): expose <operation> for tui clients
+refactor(tui): move <area> to sdk boundary
+```
+
+Final section checkpoint:
+
+```text
+refactor(tui): move sdk state and routes into package
+```
+
+## Section 7: Isolate Plugin Presentation From Plugin Loading
+
+Status: Completed. Plugin slots, route registration, TUI-facing APIs, runtime
+presentation state, and built-in feature plugins now live in
+`@opencode-ai/tui`. The legacy host injects a narrow plugin host that retains
+discovery, installation, manifest/config mutation, external module execution,
+pure-mode filtering, and cleanup ownership. Missing or failing plugin hosts
+degrade to the base TUI without blocking startup.
+
+Keep plugin UI extensibility without importing the legacy plugin installer and
+loader into the TUI package.
+
+Tasks:
+
+- Move plugin presentation slots, route contracts, and TUI-facing APIs into
+  `packages/tui` or the existing public plugin TUI contract package.
+- Keep package discovery, installation, manifest resolution, backend activation,
+  and process lifecycle in the host.
+- Define the serialized or runtime plugin presentation data the TUI requires.
+- Prefer SDK-delivered plugin metadata when the behavior must also work for a
+  remote server.
+- Make plugin absence or incompatibility degrade gracefully.
+- Move plugin rendering tests to `packages/tui`; retain installation/loading
+  integration tests in `packages/opencode`.
+
+Exit criteria:
+
+- `packages/tui` does not import `@/plugin/*` or the old TUI plugin runtime.
+- Remote and local TUI clients have a defined plugin behavior.
+- Plugin UI failures cannot prevent the base TUI from starting.
+
+Checkpoint commit:
+
+```text
+refactor(tui): separate plugin presentation from loading
+```
+
+## Section 8: Move The Application Root And Renderer Lifecycle
+
+Status: Completed. `packages/tui` now owns the canonical application root,
+provider composition, routes, components, parser presentation, renderer
+configuration, and renderer lifecycle. Process mutation, Windows console
+handling, backend worker startup, config loading, plugin loading, native audio,
+and legacy platform implementations remain injected host adapters. Old source
+paths are temporary compatibility re-exports for the legacy command host.
+
+Move the canonical app composition after its dependencies have already crossed
+the package boundary.
+
+Tasks:
+
+- Move `app.tsx`, remaining providers, routes, components, attention handling,
+  keymaps, and renderer lifecycle to `packages/tui`.
+- Export a narrow public API such as:
+
+```ts
+export type TuiInput = {
+  url: string
+  directory?: string
+  headers?: RequestInit["headers"]
+  fetch?: typeof fetch
+  config: TuiConfig.Resolved
+  capabilities: TuiCapabilities
+  paths: TuiPaths
+}
+
+export function run(input: TuiInput): TuiHandle
+export function createRenderer(config: TuiConfig.Resolved): Promise<CliRenderer>
+```
+
+- Preserve the existing lifecycle guarantees: readiness, waiting until exit,
+  idempotent cleanup, renderer destruction, SIGHUP handling where appropriate,
+  and terminal restoration.
+- Keep Windows process adapters outside the package if they mutate host process
+  state; invoke them from CLI adapters around the package lifecycle.
+- Keep OpenTUI parser-worker embedding in executable build scripts.
+- Move app lifecycle and rendering tests to `packages/tui`.
+
+Exit criteria:
+
+- `packages/tui` contains the canonical application root.
+- The package has no imports from `packages/opencode`, `packages/cli`, or
+  `@opencode-ai/core`.
+- The package public API is sufficient for both old and new CLI adapters.
+
+Checkpoint commit:
+
+```text
+refactor(tui): move application root into package
+```
+
+## Section 9: Convert Both CLIs To Thin Adapters
+
+Status: Completed. The legacy thread and attach commands now lazily invoke the
+public `@opencode-ai/tui` root while retaining worker/server/config/plugin and
+process adapters. The new CLI default command launches the same package against
+its authenticated daemon transport with a minimal local platform/host. Missing
+legacy provider/config APIs currently degrade to the shared provider-connect
+screen; source and compiled new-CLI behavior match, while named commands remain
+outside the TUI path.
+
+Make both executable packages consume the same TUI package.
+
+Tasks:
+
+- Keep the legacy yargs commands corresponding to current `thread.ts` and
+  `attach.ts` in `packages/opencode`.
+- Keep the legacy embedded worker and server startup in `packages/opencode`.
+- Change those adapters to load config, create transport inputs, and call the
+  public `@opencode-ai/tui` API.
+- Change `packages/cli`'s default command handler to call the same public API.
+- Remove the temporary `packages/cli/src/tui` shell after the shared package is
+  integrated.
+- Remove duplicated OpenTUI lifecycle code from both hosts.
+- Ensure non-TUI subcommands remain lazily isolated from OpenTUI startup.
+- Update executable build scripts to bundle the shared package, parser worker,
+  assets, and any retained host worker.
+
+Exit criteria:
+
+- Both CLIs launch the same package implementation.
+- There is no duplicate TUI source tree in `packages/cli`.
+- Legacy attach and local-worker modes still work.
+- Named non-TUI commands do not launch or eagerly initialize the TUI.
+
+Checkpoint commit:
+
+```text
+refactor(cli): share tui package across command hosts
+```
+
+## Section 10: Remove Compatibility Paths And Finish Ownership
+
+Status: Completed. Package source imports are self-contained, package exports
+are narrowed to active host contracts, package-owned tests and snapshots live
+under `packages/tui`, and the obsolete compatibility tree has been removed.
+Legacy command, worker, config, plugin-loader, process, editor, audio, and event
+adapters now live in explicit host-owned locations outside `src/cli/cmd/tui/`.
+
+Delete migration scaffolding only after both hosts consume the package.
+
+Tasks:
+
+- Remove old TUI compatibility re-exports and the obsolete directory tree under
+  `packages/opencode/src/cli/cmd/tui`.
+- Retain and relocate only true host adapters such as legacy commands, worker,
+  transport setup, and config loading.
+- Remove obsolete `@tui/*` path mappings from `packages/opencode`.
+- Remove stale test fixtures and update all imports to package exports.
+- Narrow `@opencode-ai/tui` exports to intentional public entrypoints.
+- Verify package manifests list every direct dependency and no accidental
+  dependency is supplied only by workspace hoisting.
+- Update repository documentation describing TUI ownership and development.
+
+Exit criteria:
+
+- No production import references the old TUI source location.
+- No source under `packages/tui` imports `@/...`, `@opencode-ai/core`, or either
+  executable package.
+- The old TUI directory contains no canonical implementation files.
+- The dependency graph has no cycle.
+
+Checkpoint commit:
+
+```text
+refactor(tui): complete standalone package extraction
+```
+
+## Invariants To Preserve
+
+- There is one canonical TUI implementation at every migration stage.
+- Legacy TUI behavior remains available until its host is intentionally removed.
+- The default new CLI command launches the TUI, while named subcommands continue
+  to route to their own handlers.
+- Renderer cleanup restores the terminal on normal exit, interruption, startup
+  failure, and renderer destruction.
+- TUI package imports do not reach into executable or backend implementation
+  packages.
+- SDK wire data is treated as the source of truth for OpenCode domain state.
+- Unknown tools and plugin data render safely without backend type imports.
+- Remote-server use remains possible; the TUI must not require an in-process
+  backend implementation.
+- TUI-local persistence remains local and does not become server state unless
+  there is an explicit product requirement.
+- Team changes should be moved with their canonical file, not manually copied
+  between old and new implementations.
+
+## Verification Gates
+
+Run verification after every section, adding narrower tests for the area being
+moved.
+
+Package checks:
+
+```text
+cd packages/tui && bun typecheck
+cd packages/tui && bun test
+cd packages/opencode && bun typecheck
+cd packages/cli && bun typecheck
+```
+
+Dependency checks:
+
+```text
+rg "from ['\"]@/" packages/tui/src
+rg '@opencode-ai/core|packages/opencode|packages/cli' packages/tui
+rg 'src/cli/cmd/tui|@tui/' packages/opencode/src packages/opencode/test
+```
+
+SDK checks when server APIs change:
+
+```text
+./packages/sdk/js/script/build.ts
+git diff --check
+```
+
+Interactive smoke checks should run in `tmux` so the terminal can be captured
+and cleaned up reliably:
+
+- Start the legacy local TUI and confirm initial render.
+- Start legacy attach mode against a server.
+- Start the new CLI default command and confirm it renders the same package.
+- Exit each mode with Ctrl-C and verify the process and terminal are restored.
+- Run representative named commands in both CLIs and verify they do not launch
+  the TUI.
+
+Compiled checks:
+
+- Build the current-platform `packages/opencode` binary.
+- Build the current-platform `packages/cli` binary.
+- Run TUI and non-TUI smoke checks against both compiled binaries.
+- Verify theme JSON, audio assets, OpenTUI parser worker, and retained backend
+  worker assets are included.
+
+## Progress Tracking
+
+- [x] Section 1: Create the package skeleton
+- [x] Section 2: Move presentation utilities and leaf UI
+- [x] Section 3: Remove backend tool implementation imports
+- [x] Section 4: Make runtime inputs explicit
+- [x] Section 5: Separate resolved TUI config from host config loading
+- [x] Section 6: Move SDK state, routes, and backend operations
+- [x] Section 7: Isolate plugin presentation from plugin loading
+- [x] Section 8: Move the application root and renderer lifecycle
+- [x] Section 9: Convert both CLIs to thin adapters
+- [x] Section 10: Remove compatibility paths and finish ownership
+
+Update each section's status and this checklist in the same commit that completes
+the section.

specs/v2/README.md

@@ -25,13 +25,13 @@ Generated clients follow the assembled public `HttpApi`. GitHub issues own activ
 | [Session](./session.md) | Explain prompt admission, execution, instructions, compaction, and recovery boundaries. |
 | [Tools](./tools.md)     | Explain tool construction, registration, execution, and outcome laws.                   |
 
-## Decision Records
+## 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) | Superseded decision record | Preserve the graceful-only design replaced by write-ahead execution claims. |
-| [Provider policy](./provider-policy.md)                           | Accepted and implemented   | Record provider authorization independently from provider configuration.    |
+| [Provider policy](./provider-policy.md)                           | Proposed and unimplemented | Explore provider authorization independently from provider configuration.   |
 
 ## Historical Context