@kodax-ai/kodax 0.7.96 → 0.7.97-alpha.2

package/public_docs/sdk/embedder-guide.md

@@ -1,48 +1,129 @@
-# KodaX SDK — Embedder Integration Guide
-
-Beta.3 repairs Windows WFP probe allocation in KodaX doctor and the bundled ASRT 0.0.65 dependency. SDK installs with `--ignore-scripts` receive the repair. Authenticated credential/Host Tool bridge takeover retires the old RPC connection so clients can reconnect and resume live scoped leases without replaying dispatched tools. Production and source-test TypeScript checks are separate; public SDK entry points remain unchanged.
-
-> Audience: host applications embedding `@kodax-ai/kodax` (and its
-> subpaths) as a substrate — e.g. KodaX Space's desktop wrapper, IDE
-> extensions, custom CLIs. If you are an end-user running the `kodax`
-> command-line tool, see the root [README.md](../../README.md) instead.
-
-This guide tracks the `v0.7.96` release; npm publication remains a
-separate manual maintainer step. The SDK
-advertises Windows `sandboxRuntime:11`, `runtimeAutoModeGuardrail:6`,
-`sharedSessionSettings:2`, `runtimeExitSettlement:2`, and
-`crashOutcomeModel:2`;
-trusted text transactions are split from platform shell containment
-(cross-Runtime per-file kernel locking, revision CAS, flushed atomic
-replacement, and a native restricted-token Windows shell runner behind
-native shell protocol version 10/setup generation 10 with no command-lifetime
-global admission lock), and local tool-result capacity overflow
-records bounded `capacityDebt` and commits through a bounded recovery ladder
-instead of aborting the Run. On top of v0.7.95: per-command Windows sandbox
-runner/pipe/Job lifecycles, setup-only machine migration and recovery, rolling
-failed-broker replacement without an ordinary command lock or queue, stale learning-lock
-reclamation with fullscreen terminal teardown, exact-input Explicit Skill
-execution, and coding-result finalization before the public completion
-signal, on top of concurrent sandboxed text mutations,
-Session-persisted and Git-backlink-validated KodaX worktree roots (including
-strict `core.worktree` identity for a real submodule Session root),
-authorized-root git trust (`gitSafeDirectory: authorized-repo-roots`),
-scheduled shutdown failure reporting, missing-workspace Run start,
-`conversationHistory:2`, independent explicit Skill invocation, diagnosed
-invalid `allowed-tools` / malformed hook JSON, observed text-helper stdin
-failures, byte-bounded git-metadata reads, observed
-Run-finalization and process-cleanup rejections, typed disconnect facts,
-structured credential-safe Runtime failure details, and exact-`runId` recovery
-after reconnect
-on top of v0.7.93 failed-exit fast settlement, previous-boot ACL recovery, and
-isolated Anthropic/OpenAI abort classification, plus the v0.7.92
-filesystem-effect operation-token coordinator, recorded-release owners,
-managed Session-before-completion ordering, and canonical-first resume
-reconstruction. v0.7.91 still supplies bounded owner-scoped interactions,
-stale prepared-Session recovery, crash-resumable Runtime exit settlement,
-effective live output segments, and standalone lazy provider dependency
-bundling.
+# KodaX SDK — Product Client and Host Integration
+
+This page describes the current FEATURE_298/299 development tree, whose package
+baseline is `0.7.97-alpha.1`. Some seam additions are newer than that baseline; this does not
+claim that this contract is already published to npm. Check the installed
+package exports and the connected Host's capabilities when migrating.
+
+For applications sharing KodaX sessions, use `KodaXProductClient` from
+`@kodax-ai/kodax/client`. The Host owns execution, configuration and persistence;
+clients submit intent, answer interactions and render Host facts. The old
+`KodaXClient` / `Client` classes and low-level Runtime facade are different
+objects, not alternate names for this contract.
+
+- [Product integration](#product-client-integration): connection and lifecycle.
+- [Migration guide](../../docs/SDK_MIGRATION.md): old-to-new calls, ownership,
+  errors, history, cancellation and acceptance checklist (Chinese).
+- [Complete Client contract](../../docs/CLIENT_CONTRACT.md): normative behavior
+  and method inventory; [types](../../packages/coding/src/client-contract.ts).
+- [Removed surfaces](#migrating-to-v0797): breaking changes and replacements.
+- [Space Host seams](../../docs/SPACE_SDK_SEAMS.md): trusted Main authorization,
+  canonical Fork/Retry/Rewind, Host configuration, attachments, statistics and lifecycle limits.
+- Numbered sections below retain low-level library/Host guidance and historical
+  release context. They are not instructions for a product UI to create its own
+  execution owner or write the shared Host's files.
+
+## Product Client integration
+
+### Choose the connection entry
+
+| Need | Entry | Ownership |
+| --- | --- | --- |
+| Start or attach a local compatible Host | `ensureKodaXClient(options)` | Uses the shared launcher; updates only an eligible idle Host |
+| Attach without starting or replacing a Host | `connectKodaXClient(options)` | Passive Node connection |
+| Browser/UI contract types | `import type` from `/client` or `@kodax-ai/coding/client-contract` | No running Host or browser transport is provided by types |
+| Trusted Host bootstrap, scoped credentials, Host Tools, explicit embedding | `/runtime` | Separate low-level authority; never a fallback after product connection failure |
+| Independent Agent/LLM/coding library | `/agent`, `/llm`, `/coding` | Independently usable; not a shared-Session product client |
+
+Both product constructors return `Promise<KodaXProductClient>`. The `/client`
+subpath is ESM; CommonJS hosts use `await import('@kodax-ai/kodax/client')`.
+It is not a root-entry re-export. `endpoint` is a local named pipe/Unix socket,
+not an HTTP/WebSocket address. A browser application needs its own supported
+bridge; do not import the Node connector into browser code.
+
+`homeDir` is the base directory containing `.kodax`, not `.kodax` itself.
+`connect` additionally accepts `endpoint` and `token`; `ensure` accepts
+`daemonStartupTimeoutMs`. Both accept `profile` and `clientInfo`. Presentation
+metadata such as `clientInfo.name` grants no authority. Configure provider
+credentials at the Host, rather than passing API keys in input submissions.
+
+### Observe, submit, and settle
+
+The following helper uses an existing Client and Session. The application owns
+connection/session selection and supplies renderers that replace the displayed
+view and answer `view.interactions` through `client.interactions.respond`.
+Without an interaction UI, a Run can legitimately wait for an answer. This
+example neither auto-approves requests nor infers completion from rendering.
 
+```ts
+import type {
+  KodaXProductClient, ClientSessionView, ClientObservationStatus,
+} from '@kodax-ai/kodax/client';
+
+export async function submitImmediate(
+  client: KodaXProductClient,
+  sessionId: string,
+  inputId: string,
+  text: string,
+  render: (view: ClientSessionView) => void,
+  showConnection: (status: ClientObservationStatus) => void,
+) {
+  const observation = await client.sessions.observe(sessionId, render, {
+    onStatus: showConnection,
+  });
+  try {
+    const accepted = await client.inputs.submit({
+      sessionId, inputId, text, delivery: 'immediate',
+    });
+    if (accepted.state !== 'submitted' || !accepted.runId) {
+      throw new Error(`Input ${inputId} is ${accepted.state}; inspect its receipt before continuing.`);
+    }
+    return await client.runs.await(accepted.runId);
+  } finally {
+    observation.close(); // Detaches this observer; does not stop the Run.
+  }
+}
+```
+
+Keep `inputId`, original text and artifacts before calling this helper. After a
+lost response query `inputs.read(sessionId, inputId)` on the same Host; never
+silently create a new ID and resubmit. This helper handles only immediate
+submission; queued, steer and redirect flows must follow their acceptance state.
+
+Create/select sessions using `client.sessions.create({projectPath})` or
+`list/read`. Use `client.sessions.updateSettings` for execution choices, then
+submit input. On application disposal call `client.disconnect()`; use
+`runs.stop` or `sessions.cancel` for explicit Stop, and `host.shutdown()` only
+for an explicit request to close an idle Host. `phase: 'unknown'` from
+`runs.await` is an uncertain outcome, not success, even on a healthy connection.
+
+### Replace the consumption model
+
+| Concern | Product surface | Consumer responsibility |
+| --- | --- | --- |
+| Current UI | `sessions.observe` | Replace each view; bounded items are not a complete transcript |
+| Full display item | `sessions.readItem` | Keep the observed ID; validate paginated original text/input |
+| History/search | `readHistory`, `readHistoryEntry`, `searchHistory` | Keep page revision and distinct history IDs; no cross-revision splicing |
+| Settings and discovery | `sessions.*Settings`, `config.*`, `catalog.*` | Distinguish saved overrides/defaults from effective settings |
+| User questions and permissions | `interactions.list/respond`, `view.interactions` | Reply to the exact request; use only Host-provided grant suggestions |
+| Commands/Skills/review | `commands.*`, `inputs.submit`, `review.start` | Host prepares trusted execution; returned Run IDs are followed, not resubmitted |
+| Command feedback | `sessions.appendNotice` | Durable client-only notices; report failures without re-running commands |
+| MCP/Agents/Memory/Learning/Workflow | `mcp`, `registrations`, `agents`, `memory`, `learning`, `workflows` | Use domain operations; keep executable modules and local owners out of UI code |
+
+Observation connection errors, pending interactions and Run terminal outcomes
+are separate facts. Workflow/Learning subscription `ready` confirms registration,
+not snapshot synchronization; rebuild a failed subscription and read its current
+snapshot. Reconnect does not authorize replaying mutations. See the complete
+Client contract for nullable reads, revision conflicts, lifecycle error handling,
+and feature-specific Host compatibility checks.
+
+## Low-level reference and release history
+
+The sections below describe independent libraries, trusted Host capabilities and
+past release decisions. Their examples are scoped to those layers. Product UI
+migrations follow the entry and lifecycle above; retained low-level exports do
+not mean every low-level capability has a Product Client equivalent. Historical
+capability versions and removed APIs must be read with the migration table.
 This guide documents the SDK surfaces a host integrator needs that
 are NOT obvious from inspecting the type definitions alone:
 
@@ -62,7 +143,7 @@ are NOT obvious from inspecting the type definitions alone:
 14. [Media input artifacts — `@kodax-ai/kodax/media`](#14-media-input-artifacts--kodax-aikodaxmedia-feature_239-v0756)
 15. [Space v0.7.57 follow-up ledger](#15-space-v0757-follow-up-ledger)
 16. [SDK agent-profile surface — `KodaXAgentProfile`](#16-sdk-agent-profile-surface--kodaxagentprofile-feature_247-v0758)
-17. [Runtime SDK, Worker isolation, and local daemon](#17-runtime-sdk-worker-isolation-and-local-daemon-feature_253-feature_257)
+17. [Runtime SDK and local daemon](#17-runtime-sdk-and-local-daemon-feature_253-feature_257)
 18. [External-agent executor plane](#18-external-agent-executor-plane-feature_258-v0767)
 19. [Session surface filtering and cursor pagination](#19-session-surface-filtering-and-cursor-pagination-feature_261-v0767)
 20. [Cost-disciplined workflow routing and telemetry](#20-cost-disciplined-workflow-routing-and-telemetry-feature_259-v0767)
@@ -77,6 +158,7 @@ are NOT obvious from inspecting the type definitions alone:
 29. [Evidence-gated background Skill learning](#29-evidence-gated-background-skill-learning-feature_263-v0778)
 30. [Standalone sandbox SDK](#30-standalone-sandbox-sdk-v0778)
 - [Learned Skill promotion reference](#learned-skill-promotion-reference-v0778)
+- [Migrating to v0.7.97](#migrating-to-v0797)
 
 §1–§3 (and the Phase-7/8 MCP-popout surface in §1) land in v0.7.42
 under FEATURE_186 (see [ADR-032](../../docs/ADR.md#adr-032-sdk-embedder-surface-closure-feature_186-v0742)).
@@ -95,6 +177,9 @@ under FEATURE_186 (see [ADR-032](../../docs/ADR.md#adr-032-sdk-embedder-surface-
 
 ## 1. MCP server management — `McpManager` runtime API
 
+> Independent MCP library reference. Product clients use `client.mcp` and
+> `client.catalog`; they do not instantiate a manager or edit the Host's JSON.
+
 ### Why this exists
 
 `@kodax-ai/kodax/mcp` re-exports `McpCapabilityProvider`, which is the
@@ -723,6 +808,9 @@ subpaths in a follow-up release.
 
 ## 6. Session persistence — wiring `runKodaX` to disk
 
+> Independent in-process library ownership only. Product clients use
+> `client.sessions` and never attach a `SessionStorage` to a shared Host.
+
 ### The trap
 
 ```ts
@@ -1028,14 +1116,13 @@ lineage tail, or concurrent durable write fails with
 `SessionReadError.code === 'data_changed'`. Reload, obtain a fresh boundary,
 and rebuild the tail before retrying.
 
-Host-owned Ink sessions follow the same rule: their prepared-tail persistence helper
+Standalone Session owners follow the same rule: the prepared-tail persistence helper
 falls back to `appendSessionDelta(id, data)` after `data_changed`, so the
 authoritative full snapshot merges the newest UI/session state. Background
 write failures are emitted as structured diagnostics; they are not swallowed
 and a stale tail is never retried unchanged.
-Runtime-owned Ink sessions instead save host display/settings state and adopt
-the Runtime's durable lineage, as described in
-[transcript ownership](#unreleased-interrupted-run-recovery-and-transcript-ownership).
+Product Ink sessions use the Host Client API and never save a competing local
+transcript or lineage; see [transcript ownership](#unreleased-interrupted-run-recovery-and-transcript-ownership).
 
 A non-null fulfilled append result is the reusable successor boundary. A
 fulfilled `null` means the tail did commit exactly once, but the successor
@@ -1580,6 +1667,9 @@ and your Node / OS / SDK version.
 
 ## 10. Model capabilities — context window, reasoning, descriptors
 
+> Product consumers query `client.catalog` and effective Host settings. Direct
+> provider construction and credential access below belong to library/Host code.
+
 ### Why this exists
 
 A popout-style UI typically wants to list every provider/model KodaX
@@ -1828,6 +1918,9 @@ metadata, we can promote the snapshot to derive from it.
 
 ## 11. Workflow process events and lifecycle controls (FEATURE_229, v0.7.50)
 
+> Product consumers use `client.workflows` with declarative inputs. The lower
+> level runner/module interfaces below remain Host integration mechanisms.
+
 FEATURE_229 makes dynamic workflow progress a reusable SDK process surface
 instead of terminal-only text. Hosts can observe and control workflows without
 parsing `/workflow` output, replaying slash commands, or depending on Ink view
@@ -2559,9 +2652,9 @@ ambiguous call instead of risking cross-session delivery. Low-level child-Actor
 producers may continue to pass an explicit `agentId`.
 
 `enqueueWithArtifacts()` is an in-process queue helper for direct/inline runs.
-Runtime Worker and daemon clients must use `runtime.runs.submitInput(...)` (with
+Daemon clients must use `runtime.runs.submitInput(...)` (with
 the same `sessionId` and `afterRunId`) because a process-local MessageQueue
-cannot cross those transport boundaries. Use `delivery:'after_turn'` to create
+cannot cross the transport boundary. Use `delivery:'after_turn'` to create
 a continuation Run after the current Run ends, or `delivery:'interrupt'` to
 inject into the current active Actor Run at its next safe Runner boundary.
 
@@ -2682,18 +2775,25 @@ runKodaX({
 
 ---
 
-## 17. Runtime SDK, Worker isolation, and local daemon (FEATURE_253-FEATURE_257)
+## 17. Runtime SDK and local daemon (FEATURE_253-FEATURE_257)
 
 `@kodax-ai/kodax/runtime` is the stable host-facing runtime facade for
 applications that want KodaX as a substrate instead of only as a terminal CLI.
 It wraps the same coding/session engine used by the REPL and exposes it through
-one interface in three deployment shapes:
+one interface in two deployment shapes:
 
 - **embedded / inline**: in-process runtime owned by the caller;
-- **embedded / worker**: private caller-owned runtime in a disposable V8 Worker;
 - **daemon**: local-only runtime owner reached through a named pipe on Windows or
   a Unix domain socket on Linux/macOS.
 
+The v0.7.96 Worker-hosted embedded runtime (`isolation: 'worker'`, the
+`dist/runtime-worker.js` sidecar, and the `requirements.hardDispose` gate) was
+removed in v0.7.97. Loading the configured A2A plane is owner wiring, not
+Runtime magic: call `createConfiguredA2ARuntimeIntegration({ configHome })`
+(exported from `@kodax-ai/kodax/a2a`) and pass its `runtimeOptions` as
+`externalAgents` — exactly what the CLI does for both its embedded sessions
+and the daemon Host it launches.
+
 The daemon is not a separate product engine. It hosts the embedded runtime behind
 a process boundary, so REPL, Space, IDE adapters, ACP, and custom SDK clients can
 share the same profile runtime without reimplementing sessions, permissions,
@@ -2701,13 +2801,16 @@ events, config, MCP, catalogs, artifacts, or diagnostics.
 
 ### Which shape to use
 
+Product UI and shared-Session automation should use `/client` as described at
+the top of this guide. This table also identifies explicit low-level ownership.
+
 | Host scenario | Recommended shape | Why |
 |---|---|---|
 | Unit tests, one-off scripts, short-lived SDK tools | `createKodaXRuntime()` | No daemon lifecycle; easiest cleanup. |
 | A single app owns all KodaX state in one process | `createKodaXRuntime({ mode: 'embedded' })` | Direct in-process calls and no IPC. |
-| A single app needs private state plus hard V8 disposal | `createKodaXRuntime({ mode: 'embedded', isolation: 'worker' })` | Same services over MessagePort; `close()` escalates to Worker termination. |
-| REPL + Space + IDE should share sessions/status/permissions | `createKodaXRuntime({ mode: 'daemon' })` | Starts or reuses the local profile daemon. |
-| Attach to an already-started daemon only | `connectKodaXRuntime({ profile, homeDir })` | Attach-only by default; fails if no daemon is ready. |
+| REPL + Space + IDE product clients | `ensureKodaXClient({ profile, homeDir })` | Starts or reuses the Host and returns the Product contract. |
+| Product attach-only client | `connectKodaXClient({ profile, homeDir })` | Passive; fails if no compatible Host is ready. |
+| Trusted low-level daemon integration | `ensureKodaXRuntime` / `connectKodaXRuntime` | Runtime services rather than Product business methods. |
 | Test/CI isolated daemon namespace | pass `homeDir` and `profile` | Keeps state/config/sessions out of the user's home daemon. |
 
 ### Public construction contract
@@ -2728,26 +2831,21 @@ The important creation options are:
 | Option | Default | Contract |
 |---|---|---|
 | `mode` | `'embedded'` | Chooses private ownership or a shared daemon process. |
-| `isolation` | `'inline'` | Embedded-only. `'worker'` creates a private Runtime Worker; daemon rejects any explicit isolation because it is already process-isolated. |
-| `worker.resourceLimits` | unset | Optional V8 heap/stack limits; requires `isolation: 'worker'`. |
-| `worker.shutdownTimeoutMs` | `2000` | Grace before the parent terminates the Runtime Worker. |
-| `worker.configuredA2A` | `false` | Explicitly lets the Worker owner load and reconcile `<homeDir>/.kodax/integrations/a2a.json`; installs the full list/describe/spawn/task plane inside the Worker. |
-| `requirements.hardDispose` | `false` | Rejects inline and daemon forms; prevents an accidental weaker ownership form. |
 | `homeDir` | unset | When omitted, use the exact resolved `KODAX_HOME`. When set, this is the base directory that owns `.kodax`, with the same meaning as CLI `daemon --home`; daemon state/config live under `<homeDir>/.kodax`. |
 | `profile` | `'default'` | Daemon uniqueness and runtime configuration namespace. |
 | `sessionsDir` | `<homeDir>/.kodax/sessions` | Explicit session storage override. |
 | `daemonStartupTimeoutMs` | `60000` | Total cold-start/concurrent-owner wait budget. |
 | `daemonConnectTimeoutMs` | `2000` | Per-socket connection timeout. |
 | `autoStartDaemon` | conditional | For `createKodaXRuntime({mode:'daemon'})`, true only when no explicit endpoint/transport is supplied. |
-| `execPolicy` | unset | Trusted host-owned administrator rules and canonical trusted-project roots. Inline and Worker owners receive it directly; daemon mode accepts it only while auto-starting a new owner. |
+| `execPolicy` | unset | Trusted host-owned administrator rules and canonical trusted-project roots. The inline owner receives it directly; daemon mode accepts it only while auto-starting a new owner. |
 | `autoReview` | unset | Trusted host-owned administrator/model guidance for Auto review. It follows the same owner-only transport contract as `execPolicy`. |
 | `externalAgents` | unset | Host-installed executor factories, dispatch policy, optional credential/artifact policies, and default dispatch context. Inline owner only; see §18. |
 | `requirements.externalAgents` | `false` | Reject a Runtime/daemon connection that does not advertise an installed external-agent plane. |
 
-KodaX rejects contradictory options. Worker settings without Worker isolation,
-`requirements.hardDispose` on inline/daemon forms, and any explicit isolation
-on daemon mode are errors. Options are never silently ignored to select a
-weaker isolation form.
+The former `isolation`, `worker.*`, and `requirements.hardDispose` options were
+removed with the Worker facade in v0.7.97; supplying them is now a plain unknown-
+option error. Options are never silently ignored to select a weaker ownership
+form.
 
 ### Basic embedded usage
 
@@ -2811,10 +2909,11 @@ try {
 }
 ```
 
-`createKodaXRuntime({ mode: 'daemon' })` is the high-level convenience API: when
+This is a low-level Runtime example, not the default product integration.
+`createKodaXRuntime({ mode: 'daemon' })` is a retained convenience API: when
 no explicit `daemonEndpoint` or `daemonTransport` is supplied it starts or reuses
-the local profile daemon. `connectKodaXRuntime()` is attach-only unless
-`autoStart: true` is passed.
+the local profile daemon. `connectKodaXRuntime()` is passive and rejects
+`autoStart: true`; use `ensureKodaXRuntime()` for low-level startup/update.
 
 Trusted `execPolicy` and `autoReview` options are owner bootstrap inputs, not
 client connection settings. For a new daemon, KodaX transfers them through a
@@ -2861,11 +2960,11 @@ verified shutdown and is not silently upgraded in place. Stop it explicitly and
 relaunch it before requiring the capability. The CLI's `kodax daemon stop
 --json` follows the same daemon-plus-supervisor boundary.
 
-The daemon-owned slice does not close the Worker-owned child lifetime gap in
-Issue 256; that owner-lease work remains open after v0.7.87, without a
-replacement target assigned by this release. Worker and
-executor cleanup still use identity-checked evidence and fail closed when a
-descendant cannot be proven gone.
+The daemon-owned slice does not carry the former Runtime Worker's
+child-lifetime gap (Issue 256); that owner-lease work remains open after
+v0.7.87 only for constructed-handler workers, without a replacement target
+assigned by this release. Executor cleanup still uses identity-checked
+evidence and fails closed when a descendant cannot be proven gone.
 
 ### Actor settlement recovery (v0.7.84)
 
@@ -2886,12 +2985,16 @@ duplicate outcome. A no-op quiesce does not rewrite the Session.
 
 ### v0.7.85 Runtime and Memory release boundaries
 
-The v0.7.85 SDK adds Session-scoped Runtime Event Journals. Persist the full
-`{ sessionId, journalEpoch, seq }` cursor and always replay with `sessionId` or
-`runId`; numeric Runtime-global sequences are not resumable cursors. A2A binds
-one Runtime Session to each Task, and daemon clients require
-`sessionEventJournal:1`. Corrupt journal indexes, cursor scope mismatches, and
-ambiguous retention evidence fail closed.
+The v0.7.85 SDK originally added Session-scoped durable Runtime Event Journals;
+v0.7.97 removes that surface. Events are now a live in-process stream only:
+each envelope is `{ id, seq, time, sessionId, runId, turnId?, type, payload }`,
+where `seq` is a per-Session in-process ordering hint. It starts at `1`, resets
+when a Session is deleted and recreated, and is not comparable across restarts
+or Sessions. There is no durable `event.replay` RPC, no
+`{ sessionId, journalEpoch, seq }` cursor, and no `sessionEventJournal:1`
+capability; remote consumption reuses `session.observe` notifications, and the
+SDK `runtime.events.subscribe()` facade delivers the same live stream. A2A
+binds one Runtime Session to each Task.
 
 Memory management is conversation-first for explicit remember, correction,
 forget, recall, and exceptional-decision requests. Safe explicit mutations are
@@ -2899,8 +3002,8 @@ host-governed and immediate; ambiguous or inferred changes remain reviewable.
 F289/F290 bound review draining and lesson/verdict admission, and the
 experimental Memory SDK exposes the additive management facade only when the
 supplied controller supports it. Terminal Runs with authoritative status and
-no queued interrupt input are restored at startup without replaying complete
-event journals. The semantic repo-intelligence Worker retires after its idle
+no queued interrupt input are restored at startup without replaying event
+history. The semantic repo-intelligence Worker retires after its idle
 warm-cache window, while later cache misses start a fresh Worker.
 
 ### v0.7.86 Runtime ownership and sandbox lifecycle boundaries
@@ -3016,59 +3119,6 @@ materialization point to `{ type: 'object', properties, required? }`; only
 string names remain in `required`. This keeps the schema shown to the model and
 the provider wire contract aligned across daemon and embedded hosts.
 
-### Worker-hosted embedded usage
-
-```ts
-import { createKodaXRuntime } from '@kodax-ai/kodax/runtime';
-
-const runtime = await createKodaXRuntime({
-  mode: 'embedded',
-  isolation: 'worker',
-  worker: {
-    resourceLimits: { maxOldGenerationSizeMb: 1024 },
-    shutdownTimeoutMs: 2000,
-    configuredA2A: true,
-  },
-  requirements: { externalAgents: true },
-});
-
-try {
-  console.log(runtime.identity.isolation);      // 'worker'
-  console.log(runtime.identity.workerThreadId); // Node Worker thread id
-  // runtime.sessions/runs/events/... are identical to inline and daemon.
-} finally {
-  await runtime.close();
-}
-```
-
-`mode` describes ownership and sharing; `isolation` describes where a private
-embedded owner executes. Inline is the lowest-latency default. Worker is useful
-for Electron/Space-style hosts that need private state and deterministic V8
-disposal. Daemon is for durable multi-client sharing and already uses an OS
-process, so daemon + worker is rejected.
-
-Worker `resourceLimits` bound parts of the V8 heap only. They do not cover every
-kind of native/external memory and do not make Node code safe to treat as
-untrusted. Worker isolation is a fault boundary, not a security sandbox.
-
-Configured A2A is loaded by the Worker owner, not serialized from a parent
-factory closure. `worker.configuredA2A` is therefore an explicit opt-in. When
-enabled, the Worker reconciles the same user document as the CLI/daemon path,
-advertises `externalAgents`, and backs `listDispatchable`, `describe`,
-`preflight`, and external Actor dispatch with one real executor plane.
-
-Callers that cannot accept a silent fallback can require the capability:
-
-```ts
-await createKodaXRuntime({
-  mode: 'embedded',
-  isolation: 'worker',
-  requirements: { hardDispose: true },
-});
-```
-
-Daemon hosts advertise `hardDispose: false`; Worker hosts advertise true.
-
 ### Close, abort, and ownership semantics
 
 The same method name deliberately has deployment-specific ownership effects:
@@ -3076,17 +3126,24 @@ The same method name deliberately has deployment-specific ownership effects:
 | Form | `runtime.close()` | Run abort | After owner crash/termination |
 |---|---|---|---|
 | embedded / inline | Cancels owned runs and permissions and closes private runtime state. It cannot recover a host event loop blocked by arbitrary inline code. | `runs.abort(runId)` settles the Runtime handle and forwards cancellation to coding. | The embedding process owns recovery. |
-| embedded / Worker | Requests shutdown, waits up to `shutdownTimeoutMs`, then always terminates the Worker. | Same Runtime abort API; closing the Runtime is the hard-disposal escalation for the whole isolate. | Pending transport requests reject; create a new Runtime explicitly. |
 | daemon client | Detaches only this client transport. Other REPL/Space/SDK clients and runs remain owned by the daemon. | Aborts only the addressed run. | The client connection rejects; reconnect explicitly after the daemon is healthy. |
 
 `close()` is idempotent. It is not a shared-daemon stop command. Use
 `kodax daemon stop`, `kodax daemon restart`, or an authenticated low-level
 `runtime.shutdown` request for administrative shutdown. KodaX does not
-automatically retry or replay an in-flight run after a Worker/daemon owner dies,
+automatically retry or replay an in-flight run after a daemon owner dies,
 because provider and tool side effects may already have happened.
 
-`runtime.shutdown` and `stopForInline()` responses mean the fenced stop was
-accepted; host-close logging and owner-lock release are also intermediate
+`runtime.shutdown` performs a real idle shutdown: it takes the draining fence,
+rechecks preflight, and stops the daemon only when no active or queued run,
+Workflow, Agent turn, pending permission/user input, other logical client, or
+in-flight mutation exists; otherwise it fails with a structured `conflict`
+error and the daemon keeps running. Shutdown never changes the owner mode
+implicitly — a daemon-to-inline ownership change goes only through an explicit
+`setKodaXRuntimeOwnerMode()` call, or owner-lock release followed by
+`acquireKodaXInlineOwner()`; the former `stopForInline()` rollback and the
+crash-resumable exit-settlement transaction were removed in v0.7.97. Host-close
+logging and owner-lock release are still intermediate
 progress boundaries. A successful `kodax daemon stop` / `restart` additionally
 waits for the original daemon PID to disappear and verifies a shutdown-success
 outcome bound to that exact Runtime ID and PID. Before that process exits, the
@@ -3179,7 +3236,6 @@ kodax daemon status --profile default --json
 kodax daemon logs --profile default --lines 100
 kodax daemon stop --profile default --json
 kodax daemon restart --profile default
-kodax --runtime-mode daemon
 ```
 
 Inside the REPL, `/status runtime` reports embedded/daemon mode, profile,
@@ -3187,14 +3243,14 @@ runtime id, endpoint/health when applicable, and active/queued counters.
 
 ### Runtime services
 
-Every `KodaXRuntime` exposes the same service set in inline, Worker, and daemon mode:
+Every `KodaXRuntime` exposes the same service set in inline and daemon mode:
 
 | Service | Purpose |
 |---|---|
-| `identity` | Runtime id, mode, isolation, profile, started time, package version, optional Worker thread id. |
+| `identity` | Runtime id, mode, isolation (`inline` for embedded, `process` for daemon), profile, started time, package version. |
 | `sessions` | Create/load/list/fork/transcript/settings/notice/rewind/compact/archive/delete. |
 | `runs` | Start/await/get/list/abort runs; update provider/model/reasoning for supported phases. |
-| `events` | Subscribe to live events and replay persisted bounded events. |
+| `events` | Subscribe to the live in-process event stream (one `seq` ordering hint per Session). |
 | `permissions` | Request/list/respond to tool permissions across clients. |
 | `workflows` | Observe workflow process snapshots/events and lifecycle controls. |
 | `config` | Read/patch/reload daemon or embedded profile config. |
@@ -3202,7 +3258,6 @@ Every `KodaXRuntime` exposes the same service set in inline, Worker, and daemon
 | `mcp` | MCP server CRUD, validation, reload, and tool catalog listing. |
 | `artifacts` | Create/get/delete runtime artifact references for file/image/video inputs. |
 | `status` | Runtime snapshot with sessions, runs, permissions, workflows, and daemon counters. |
-| `diagnostics` | Latest context-budget and tool-exposure decisions for GUI/debug surfaces. |
 | `admin.agentRegistrations` | List/upsert, atomically set `enabled` while preserving the full registration, or remove redacted external-agent registrations. Owner/revision-conditional mutation prevents a stale manager from changing a same-ID replacement. With no plane, list is empty and mutations fail clearly. |
 | `agents` | Check `enabled`, list/describe policy-filtered dispatchable agents, and preflight a selected route. |
 | `agentTasks` | Start/list/get/wait/continue/cancel/reconcile durable external-agent tasks and read their ordered event stream. |
@@ -3439,50 +3494,53 @@ bundles.
 - Preserve an unknown-code/default UI path at transport boundaries so a newer
   Runtime cannot turn a diagnostic extension into a failed host UI.
 
-### Session-scoped event cursors
+### Session-scoped live event ordering
 
 Runtime event order is defined inside one Session, not across the Runtime.
-Every event exposes a cursor:
+Since v0.7.97 the event surface is a live in-process stream; the durable
+journal, `events.replay()`, and the `{ sessionId, journalEpoch, seq }` cursor
+were removed. Every event envelope is:
 
 ```ts
-type RuntimeSessionCursor = {
+type RuntimeEventEnvelope = {
+  id: string;
+  seq: number; // per-Session in-process ordering hint; starts at 1
+  time: string;
   sessionId: string;
-  journalEpoch: string;
-  seq: number;
+  runId: string;
+  turnId?: string;
+  type: RuntimeEventType;
+  payload: unknown;
 };
 ```
 
-Persist the whole cursor and resume in the same Session or Run scope:
+`seq` is an ordering hint, not a durable cursor. It starts at `1` within one
+Session, resets when that Session is deleted and recreated, and is not
+comparable across restarts or between Sessions — do not persist it as a
+resume point. Consumption is subscription-shaped and always scoped:
 
 ```ts
-const page = await runtime.events.replay({ sessionId: session.id });
-const after = page.at(-1)?.cursor;
-const next = await runtime.events.replay({
-  sessionId: session.id,
-  ...(after ? { after } : {}),
-});
+const sub = runtime.events.subscribe(
+  { sessionId: session.id }, // runId optionally narrows to one Run
+  (event) => renderLiveEvent(event),
+);
+await sub.ready; // daemon handshake; absent for local subscriptions
+sub.close();
 ```
 
-This is a breaking replacement for unscoped `events.subscribe()` /
-`events.replay()` and numeric `sinceSeq`. A scope is always required. Cursors
-from another Session or an earlier journal epoch return `resync_required`; get
-a fresh Session observation/replay instead. Separate Sessions may both contain
-`seq: 1`, which is intentional and removes cross-Session lock contention.
-Supplying both `sessionId` and `runId` validates their ownership before either
-subscribe or replay, even when the Run has no retained event rows. Malformed
-cursors return `invalid_argument`. Reusing a deleted Session ID starts
-a new epoch and invalidates the earlier cursor. Persistence backpressure is
-also isolated per Session, so a blocked Session journal does not stop unrelated
-Sessions using the same embedded Runtime or home directory. Runs retain a small
-journal-identity index independently of bounded event rows; if a retention
-watermark becomes unreadable after child rows are trimmed, only cursors for a
-journal known to that Run are forced to resync when the index is valid. A
-missing or corrupt index cannot prove that an old trimmed journal is unrelated,
-so that ambiguous migration case also requires a fresh snapshot.
-
-### Run options across Worker/daemon boundaries
-
-`runs.start({ options })` is a DTO boundary in Worker and daemon forms. Do not
+Remote event consumption reuses `session.observe` notifications: an
+observation snapshot carries a `seq` high-water, every event with
+`seq <= snapshot.seq` is already reflected in the snapshot, and live listener
+events for that observation have strictly greater `seq`. Separate Sessions may
+both contain `seq: 1`; that is intentional. Supplying both `sessionId` and
+`runId` validates their ownership before the subscription is installed.
+Deleting and recreating a Session invalidates outstanding observations with
+reason `runtime_changed`; acquire a fresh observation instead of reusing a
+stale projection or sequence number.
+
+### Run options across the daemon boundary
+
+`runs.start({ options })` is a DTO boundary in daemon form. Do not
 pass process-local objects such as `extensionRuntime`, callbacks, `AbortSignal`,
 LSP services, class instances, or cyclic structures. KodaX rejects them before
 transport instead of silently dropping fields.
@@ -3509,9 +3567,9 @@ For daemon mode, extension and MCP ownership follows daemon configuration.
 Configure extensions in the daemon profile and call
 `runtime.catalog.reloadExtensions()` or the matching config service. A CLI
 `--extension <path>` is intentionally rejected in daemon mode because that
-process-local object cannot become part of a durable shared owner. Worker mode
-has the same DTO rule; use owner-readable config/module descriptors or inline
-mode for host-created extension objects.
+process-local object cannot become part of a durable shared owner. Use
+owner-readable config/module descriptors or inline mode for host-created
+extension objects.
 
 ### Permissions across clients
 
@@ -3565,7 +3623,7 @@ argument, `{ signal }`; abort the visible prompt when it fires.
 `createKodaXRuntime({ userInputTimeoutMs })` and daemon auto-start use an
 independent AskUser deadline (300,000 ms by default). The value must be a
 positive integer no greater than 2,147,483,647 and is validated before
-embedded, Worker, or daemon startup. The same bound applies to
+embedded or daemon startup. The same bound applies to
 `permissionTimeoutMs`, except that its existing value `0` disables the
 permission timer. On expiry, the Runtime accepts only a model-supplied default that is
 valid for the rendered options and selection bounds; otherwise it dismisses
@@ -3638,25 +3696,22 @@ engine:
   bridge discovery resident;
 - tool-search/describe/call-style bridge semantics keep tools reachable;
 - repo-intelligence schemas remain discoverable under pressure;
-- context-aware tool result budgets and compaction pressure events are surfaced
-  as bounded diagnostics.
-
-Hosts that set `capabilities.contextDiagnostics: true` can read:
-
-```ts
-const budget = await runtime.diagnostics.latestContextBudget({ sessionId });
-const exposure = await runtime.diagnostics.latestToolExposure({ sessionId });
-const cache = await runtime.diagnostics.latestProviderCacheDiagnostic({ sessionId });
-```
-
-Pass `{ sessionId, contextKind: 'child', agentId }` to query one logical child
-even though its physical transcript uses an isolated Session. Diagnostic
-payloads carry `contextId` and, for children, `parentContextId`; reconnecting
-hosts can use the same latest APIs instead of fabricating identity fields.
-These diagnostics are designed for status panels and debugging. Budget
-snapshots contain counts, and cache diagnostics contain hashes plus
-Provider-reported usage; they do not contain raw prompt or sensitive tool
-input/output.
+- context-aware tool result budgets and compaction pressure surface as bounded
+  diagnostic events.
+
+The v0.7.96 pull-style diagnostics RPCs (`context.budget.get`,
+`tool.exposure.preview`, `provider.cache.diagnostics.get` and the
+`runtime.diagnostics.latestContextBudget()` / `latestToolExposure()` /
+`latestProviderCacheDiagnostic()` facade) were removed in v0.7.97. The
+`capabilities.contextDiagnostics: true` client capability now only gates
+delivery of diagnostic event notifications (`context.budget.snapshot`,
+`tool.exposure.planned`, `provider.cache.diagnostics`, and
+`context.compaction.skipped`) on the live event stream; consume them through
+`runtime.events.subscribe(...)` or a `session.observe` snapshot. Diagnostic
+payloads carry `contextId` and, for children, `parentContextId`. These
+diagnostics are designed for status panels and debugging: budget snapshots
+contain counts, and cache diagnostics contain hashes plus Provider-reported
+usage; they do not contain raw prompt or sensitive tool input/output.
 
 ### Protocol schema and versioning
 
@@ -3678,7 +3733,9 @@ fields requires a protocol version bump.
 ### v0.7.69 Runtime verification record
 
 This subsection is the historical verification record for the original shared
-Runtime delivery. Current 0.7.80 release gates and evidence live in
+Runtime delivery. The Worker-isolation gates it records validated the Worker
+facade that v0.7.97 later removed; the current deployment shapes are inline
+embedded and daemon only. Current 0.7.80 release gates and evidence live in
 [`docs/release.md`](https://github.com/icetomoyo/KodaX/blob/main/docs/release.md#v0780-release-preparation).
 
 The v0.7.69 release validation covers the runtime migration, the Worker
@@ -3693,8 +3750,8 @@ daemon delivery:
   entries on Node 20 and Node 22;
 - runtime/daemon/SDK/ACP/REPL integration tests, including process-distinct SDK
   auto-start and multi-client sessions/permissions;
-- Worker Runtime identity, service parity, hard close, capability requirements,
-  and contradictory-option rejection;
+- the (since-removed) Worker Runtime's identity, service parity, hard close,
+  capability requirements, and contradictory-option rejection;
 - constructed-handler reverse tool RPC, abort bridging, CPU-loop termination,
   respawn, and revoke/dispose queue drainage;
 - context/tool-exposure eval gate;
@@ -3716,10 +3773,12 @@ daemon delivery:
   Tool reverse bridges, owner fencing, restart outcomes, and process-distinct
   client/daemon smokes with credential-canary scans;
 - a fresh `0.7.69` tarball consumer importing all 11 public subpaths, creating a
-  Worker-hosted session, running the packaged CLI, and checking packaged DTS and
-  Worker sidecars; plus a Windows x64 binary/version/sidecar smoke;
+  session through the embedded Worker form (removed in v0.7.97), running the
+  packaged CLI, and checking packaged DTS and sidecars; plus a Windows x64
+  binary/version/sidecar smoke;
 - external fresh npm consumer installation of the `0.7.67` tarball, proving
-  Worker isolation and a distinct daemon PID through the published subpath;
+  the embedded Worker isolation contract (removed in v0.7.97) and a distinct
+  daemon PID through the published subpath;
 - Ubuntu Node 22 Unix-domain-socket daemon gate, including two clients sharing
   one runtime and cross-client permission resolution.
 
@@ -3749,15 +3808,15 @@ runtime a specific A2A, MCP, or HTTP client. The public contracts live in
 
 ### Ownership rule
 
-An `AgentExecutorFactory` contains functions, so it cannot cross a Worker or
-daemon DTO boundary. Install factories where the Runtime owner executes:
+An `AgentExecutorFactory` contains functions, so it cannot cross a daemon DTO
+boundary. Install factories where the Runtime owner executes:
 
 | Desired owner | Supported construction |
 |---|---|
-| Private in-process owner | `createKodaXRuntime({ mode: 'embedded', isolation: 'inline', externalAgents })` |
+| Private in-process owner | `createKodaXRuntime({ mode: 'embedded', externalAgents })` |
 | New locally hosted daemon owner | `createKodaXRuntime({ mode: 'daemon', profile: '<unique>', externalAgents })` |
 | Existing daemon | Configure its owner, then attach with `connectKodaXRuntime({ requirements: { externalAgents: true } })`; a client cannot inject factories. |
-| Runtime Worker | Use `worker: { configuredA2A: true }` for the built-in configured A2A plane. Custom factories must still be installed by a custom Worker owner; passing function-valued `externalAgents` from the parent is rejected. |
+| Built-in configured A2A plane | Wire it in the owner: `createConfiguredA2ARuntimeIntegration({ configHome })` → pass `runtimeOptions` as `externalAgents` (the KodaX CLI does this for its embedded sessions and the daemon Host it launches; an SDK-created runtime never reads `integrations/a2a.json` on its own). The former `worker: { configuredA2A: true }` opt-in was removed with the Worker facade in v0.7.97. |
 
 When `mode: 'daemon'` and `externalAgents` are supplied, the caller must win a
 new in-process daemon lease. KodaX rejects an already-running profile instead of
@@ -3778,7 +3837,6 @@ import { createKodaXRuntime } from '@kodax-ai/kodax/runtime';
 
 const runtime = await createKodaXRuntime({
   mode: 'embedded',
-  isolation: 'inline',
   externalAgents: {
     factories: [createReferenceAgentExecutorFactory({
       executorId: 'example-http',
@@ -4204,7 +4262,7 @@ await runKodaX(
 );
 ```
 
-`memoryRecallRunner` is a process-local function binding. Worker and daemon DTO
+`memoryRecallRunner` is a process-local function binding. Daemon DTO
 options reject it instead of silently dropping it; configure the binding
 inside the Runtime owner or keep this run inline. The selector can return only
 exact IDs from the closed offered set and is capped at three calls per memory
@@ -4297,7 +4355,6 @@ const discovered = await discoverA2ARegistration({
 
 const runtime = await createKodaXRuntime({
   mode: 'embedded',
-  isolation: 'inline',
   externalAgents: {
     factories: [createA2AAgentExecutorFactory(client)],
     credentialBroker: {
@@ -4561,7 +4618,7 @@ import {
 } from '@kodax-ai/kodax/a2a';
 import { createKodaXRuntime } from '@kodax-ai/kodax/runtime';
 
-const runtime = await createKodaXRuntime({ mode: 'embedded', isolation: 'inline' });
+const runtime = await createKodaXRuntime({ mode: 'embedded' });
 const server = createKodaXA2AServer({
   runtime,
   dataDir: '/var/lib/kodax/a2a',
@@ -4648,6 +4705,10 @@ The normative baseline is A2A repository commit
 
 ## 23. Shared Coder daemon for Space and IDE hosts (FEATURE_269, v0.7.69)
 
+> Trusted Electron Main/Host integration reference, including capabilities not
+> exposed by Product Client. UI business operations use `/client`; do not port
+> this entire Runtime facade into the renderer. See the migration guide above.
+
 FEATURE_269 makes one local daemon the source of truth for a Coder profile.
 CLI, Space, IDE, and SDK clients can observe and control the same sessions and
 runs. The transport remains local to the current OS user; it is not a remote
@@ -4664,7 +4725,8 @@ data root.
 Space should own the daemon SDK client in Electron Main. Persist a random,
 stable `instanceId` and a separate 32+ character `instanceSecret` per Space
 installation. Store the secret in the OS keychain; never accept either value
-from renderer or model output. `connectKodaXRuntime()` is attach-only unless `autoStart: true`.
+from renderer or model output. `connectKodaXRuntime()` is passive;
+use `ensureKodaXRuntime()` for low-level startup/update.
 An explicit inline rollback policy blocks auto-start until the owner policy is
 explicitly changed back to daemon.
 
@@ -4683,7 +4745,7 @@ and cannot resume the old bridge's leases. Restore the exact existing identity
 from verified recovery material, or explicitly treat it as a new identity.
 
 For Electron, `homeDir` is still the CLI-style base directory, not
-`process.env.KODAX_HOME`. Packaged/asar applications may use `autoStart: true`
+`process.env.KODAX_HOME`. Packaged/asar applications may use `ensureKodaXRuntime()`
 directly; the SDK launches only the daemon child in Electron's Node execution
 mode and does not mutate the application's environment or start a second GUI
 instance. `ELECTRON_RUN_AS_NODE` exists only at the child exec boundary and is
@@ -4694,7 +4756,7 @@ Packaged auto-start requires Electron's `RunAsNode` fuse, which Electron enables
 by default. If an embedder deliberately disables that fuse, the packaged
 executable cannot serve as a detached Node host: start the daemon with an
 ordinary Node/CLI process and use attach-only mode instead. A packaged
-`autoStart: true` timeout includes this fuse requirement in its diagnostic; the
+startup timeout includes this fuse requirement in its diagnostic; the
 SDK does not relaunch the GUI or silently fall back to an inline Runtime.
 
 ### Packaged Electron native artifact layout
@@ -4730,11 +4792,10 @@ evidence schema while a new build is prepared. A new process with a new embedded
 hash publishes its own immutable generation atomically.
 
 ```ts
-import { connectKodaXRuntime } from '@kodax-ai/kodax/runtime';
+import { ensureKodaXRuntime } from '@kodax-ai/kodax/runtime';
 
-const runtime = await connectKodaXRuntime({
+const runtime = await ensureKodaXRuntime({
   profile: 'coder',
-  autoStart: true,
   // Opt in only when this product remains the visible owner of the daemon.
   // If the product crashes, the daemon stops after its final client is gone
   // and governed work becomes idle.
@@ -4750,10 +4811,8 @@ const runtime = await connectKodaXRuntime({
   capabilities: {
     richEvents: true,
     permissionPrompts: true,
-    operationDeduplication: true,
   },
   requirements: {
-    operationDeduplication: 1,
     sessionObservation: 1,
     afterTurnInput: 1,
     interruptInput: 1,
@@ -4790,7 +4849,7 @@ Coder. Products that depend on same-Run delivery should require
 silently substitute `delivery:'after_turn'` unless that is the user's intent.
 
 The SDK requires `runtimeAutoModeGuardrail:6` and
-`sharedSessionSettings:2` automatically for ordinary `autoStart: true`.
+`sharedSessionSettings:2` automatically for ordinary launcher startup.
 The capability gate prevents an alpha.6 client from attaching to an alpha.3
 daemon that advertises the older permission-before-sandbox contract. Supplying
 `daemonOrphanExitMs` additionally requires the
@@ -4833,11 +4892,11 @@ Require it before auto-start so an idle daemon that still exposes the legacy
 ordinary-history projection is replaced; a busy or otherwise unsafe owner
 produces the normal capability-upgrade error.
 
-`KODAX_RUNTIME_SDK_CAPABILITIES.sandboxRuntime` is `11` in v0.7.96
+`KODAX_RUNTIME_SDK_CAPABILITIES.sandboxRuntime` is `11` in v0.7.97
 and `crashOutcomeModel` remains `2`. Windows auto-start requires
 `sandboxRuntime:11`, so an idle v10-or-older daemon is replaced. Concurrent
 authenticated upgrade clients converge on one fenced replacement, including
-the exact prepared-ticket/revision-CAS attach window; a busy daemon or one with
+the exact revision-CAS attach window; a busy daemon or one with
 untrusted clients remains untouched and returns structured restart guidance. Version 6 means that
 trusted text transactions are host-owned and the native shell runner has no
 command-lifetime filesystem-effect lease; a v5 daemon cannot be reused for
@@ -4852,121 +4911,64 @@ must instead be stopped/upgraded. `reclaimStaleKodaXFileLock` remains an
 explicit stale-lock helper for APIs that still use file locks, not a general
 lock-deletion primitive.
 
-### v0.7.91 crash-resumable Runtime exit settlement
-
-Hosts that own a complete Runtime exit can use the SDK transaction instead of
-duplicating stop, process-tree, Job, ACL, and owner-policy recovery logic:
-
-```ts
-import { settleKodaXRuntimeExit } from '@kodax-ai/kodax/runtime';
-
-const outcome = await settleKodaXRuntimeExit({
-  configHome: coderConfigHome,
-  profile: 'coder',
-  runtime, // optional; omit only when resuming a prepared ticket after relaunch
-});
-
-if (outcome.status === 'blocked') {
-  // Keep the host open, relaunch the product, restart the OS, or request
-  // explicit manual recovery according to outcome.nextAction.
-  reportRuntimeExitBlock(outcome.reason, outcome.nextAction);
-} else {
-  reportRuntimeExit(outcome.status, outcome.repairs);
-}
-```
-
-`runtimeExitSettlement:2` is a local SDK capability and does not add a daemon
-handshake requirement. The SDK writes an exact owner/process-start and platform
-boot identity before cooperative stop, then returns `clean` only after the
-durable shutdown outcome and required exits are verified. `recovered` may repair
-only identity-scoped Windows process/Job/ACL residue, or exact POSIX owner/state
-residue after a boot-identity change. Same-boot POSIX uncertainty, active work,
-PID reuse, foreign markers, corrupt tickets, and replacement owners return
-`blocked`; the SDK never exposes a bare-PID kill, raw marker deletion, or forced
-ACL-recovery primitive. Version 2 removes the final same-boot Windows manual
-cleanup hole: stale, uncontained recovery tickets are retried through the
-sandbox account's own runner and clear only after an exact SID-idle proof. The
-transaction has a fixed bounded deadline and does not accept caller-supplied
-short timeouts.
-
-After a verified Windows boot change, settlement may also recover shared ACL
-state when a machine-lock recheck proves that every primary and legacy marker
-has a canonical non-current boot identity. The recovered scope, repair fact,
-and recovery boot identity are durably recorded before a second lock-scoped
-recheck removes markers. If Windows restarts again before clear, native
-recovery repeats against the new boot before the recorded identity advances.
-Same-boot or unverifiable markers remain `blocked`. A durable Windows
-`failed` shutdown outcome ends the 170-second orderly wait and enters exact
-recovery immediately. Anthropic/OpenAI `APIUserAbortError` objects are
-classified by isolated SDK class identity when the request signal is already
-aborted, so managed Stop stays interrupted before credential redaction.
-
-When the host is about to close, pass the connected Runtime so the SDK can
-record the exact owner and management revision. After a crash, call the same
-function with only `configHome` and `profile` to resume a still-exact prepared
-ticket. Do not delete `exit-settlement.json`, clear ACL markers, or start a
-replacement owner while a settlement is `prepared` or `stop_accepted`.
+### Windows lifecycle diagnostics
 
 Windows lifecycle diagnostics use the existing process-local
 `setKodaXDiagnosticSink` export from `@kodax-ai/kodax/agent`. Install the sink
-before connecting or settling Runtime ownership, and call its returned cleanup
+before connecting or ensuring Runtime ownership, and call its returned cleanup
 function when the host closes. The daemon already writes its own diagnostics
 to `daemon.log`; a client-process sink does not subscribe to daemon-process
 events.
 
 `source: 'runtime:windows'` identifies boot identity, Job membership, process
-snapshot, process-start identity, and exit-owner validation stages. Probe
+snapshot, and process-start identity stages. Probe
 details report availability, whether a cached result was used, and (for an
 executed probe) elapsed time, timeout, exit code, and a bounded OS error code.
-Exit validation lists the missing evidence field names without serializing
-owner identities. `source: 'runtime.daemon.capabilities'` with
+`source: 'runtime.daemon.capabilities'` with
 `stage: 'capability-check'` records the original required capability and version
-before a subsequent upgrade or settlement failure can obscure it.
+before a subsequent upgrade failure can obscure it.
 
 These records omit commands, environment variables, stdout, stderr, credentials,
 and identity values. They do not add probes or retries, change existing failure
-caching, relax Job/identity checks, or alter settlement results. A missing
+caching, relax Job/identity checks, or alter shutdown results. A missing
 capability diagnostic is evidence for troubleshooting, not permission to bypass
 the required capability. Diagnostic sink exceptions remain isolated from the
 Runtime operation.
 
 ### Unreleased: interrupted Run recovery and transcript ownership
 
-Runtime-owned managed Runs persist generated messages and tool results at
-Runner commit boundaries, before a later provider request or tool can hang.
-Completion still requires the canonical Session write. UI event deltas alone
-are not durable conversation messages.
-
-The next `mode: 'managed_task'` or `mode: 'coding'` Run can receive an
-`Interrupted Run Recovery` record derived from earlier unfinished Runs of the
-same Session. Embedded Runtime and daemon execution share this implementation.
-Only evidence anchored to a turn on the active history path is included:
-journaled tool results, operations whose results are unknown, and quoted,
-unconfirmed excerpts of streamed replies. Thinking and live child-actor mirrors
-are excluded. The record is bounded to three Runs and 6,000 characters;
-operations take the budget before reply excerpts. Results and reply text
-already present in the same turn's formal history are omitted.
-
-This record belongs only to the provider request, never the persisted Session
-or an ordinary UI conversation row. An unreadable journal emits a
-`runtime.interrupted-run-recovery` warning and does not block the next Run.
-Unknown-result operations may already have taken effect; verify the current
-files or processes before repeating them. Streamed claims are not completion
-proof. Tool-only invocations need no record because they make no model call.
-Standalone `runKodaX()` / `runManagedTask()` calls do not discover Runtime
-journals automatically: hosts that need automatic recovery should use
-`createKodaXRuntime()` and its Run service. The exported
-`KodaXInterruptedRunJournal`, `KodaXInterruptedRunOperation`, and
-`KodaXInterruptedRunReply` types describe internal handoff data;
-`context.interruptedRunJournals` is not a host-owned persistence protocol.
-
-When a Runtime owns an Ink Session, it is the lineage writer. The Ink host
-saves display/settings state without minting a competing lineage, then adopts
-the Runtime's durable entry ids. `FileSessionStorage` reconciles messages
-against that canonical lineage. A cancellation before any result leaves the
-host's existing transcript intact. Embedders must not build a second
-conversation writer from streaming callbacks; use the Runtime Session APIs
-and presentation overlays instead.
+The current development tree integrates the rc.14 fixes under FEATURE_298 /
+v0.7.97. Product applications use [/client](#product-client-integration), and
+the Host is the only Session writer. Ink/classic consumers render Host facts
+and submit intents; they do not save a competing transcript or lineage.
+
+Runtime-owned managed Runs save generated messages and tool results at Runner
+commit boundaries. An interrupted Run can contribute a bounded recovery note
+to the next SA or AMA model request. Its sources are canonical Session/active
+lineage, Run status, and successfully saved display checkpoints. The Host
+flushes the existing writer before reading; it does not replay durable events
+or infer success from telemetry. Failed checkpoint reads/writes remain errors.
+
+Evidence uses accepted input and turn identities, explicit sourceRunId /
+sourceTurnId, assistant outputId, and the assistantOutputId owning a tool call.
+A proposed tool is not an executed effect. Execution without a recorded result
+has an unknown outcome, including a displayed cancelled tool whose result was
+never saved. Already committed output is excluded by identity, so two equal
+replies with different outputIds remain distinct. Thinking, child output, and
+ordinary notices never enter the recovery record.
+
+The record covers at most three Runs and 6,000 characters, giving operations
+priority over quoted, unconfirmed reply excerpts. It is transient model context,
+never a user instruction or canonical Session message. No automatic tool redo
+or recovery of uncheckpointed tokens is promised. Tool-only invocations make
+no model call and need no recovery note. Standalone callers can supply the
+internal KodaXInterruptedRunEvidence / Operation / Reply handoff types through
+context.interruptedRunEvidence; that option is not a persistence protocol.
+
+Uncertain Shell cleanup retains deferred process ownership while allowing the
+next Run and Host close to proceed. ClientRunStatus and ClientRunOutcome expose
+the Host terminal.effectOutcome and Stop facts. A completed execution with
+unknown effects does not prove cleanup or confirm Stop.
 
 ### Historical v0.7.92 filesystem-effect coordinator and managed terminal authority
 
@@ -5001,16 +5003,13 @@ message-derived transcript plus optional display overlays. Do not treat
 Presentation-only synthetic completion events remain host-owned when that
 cache is non-empty.
 
-Observation boundaries such as `events.subscribe()`, `events.replay()`, and
-Session status projection flush pending events before answering, so they can
-surface a durable-persistence failure instead of returning a stale waterline.
-A determinate append failure retains one bounded batch for a later explicit
-retry. If both append and rollback fail, commit state is unknowable: the error
-is intentionally sticky and the Runtime must be closed/recreated rather than
-guessing or replaying the batch. Latest-only progress coalescing preserves its
-required first sample plus the most recent sample; discarded intermediate
-snapshots are not lifecycle events, and surviving samples retain their latest
-emission order.
+Observation boundaries such as `events.subscribe()` and Session status
+projection deliver the live in-process stream; since v0.7.97 removed the
+durable event journal, there is no replay boundary, durable append, or
+stale-waterline failure mode on this path. Latest-only progress coalescing
+preserves its required first sample plus the most recent sample; discarded
+intermediate snapshots are not lifecycle events, and surviving samples retain
+their latest emission order.
 
 When a healthy profile daemon is too old, the SDK first reads capabilities from
 the authenticated health probe, before attaching the embedder's stable client
@@ -5018,11 +5017,12 @@ identity or restoring its reverse bridge. The incompatible daemon is contacted
 with an ephemeral upgrade identity. The SDK requires `daemonManagement:1`,
 takes a revision/owner-policy fenced preflight, and replaces it only when no
 active or queued run, Workflow, Agent turn, pending permission/user input, or
-other logical client exists. Replacement reuses the durable Runtime exit
-settlement: it records a crash-resumable ticket, verifies the captured
-owner/process-start identity, waits for the complete process exit and shutdown
-outcome, repairs only identity-scoped remnants, restores daemon owner policy,
-and then starts the packaged Runtime.
+other logical client exists. Replacement performs a fenced idle shutdown: it
+verifies the captured owner/process-start identity, sends `runtime.shutdown`,
+waits for the complete process exit, and then starts the packaged Runtime.
+v0.7.97 removed the crash-resumable exit-settlement ticket this path
+previously reused; there is no prepared-ticket state to preserve across a
+crash mid-upgrade.
 A busy or still-older daemon is never stopped: the connection rejects with
 `RuntimeDaemonCapabilityUpgradeError`, whose `recoverable` and
 `restartRequired` fields are `true` and whose optional `preflight` explains the
@@ -5041,8 +5041,8 @@ The packaged daemon authenticates one local OS-user/profile trust domain with
 a random token stored beside daemon state and a user-only local endpoint. It
 does not issue a different daemon token to each application in v0.7.69. The
 returned scope set is chosen by the host (the packaged host grants the public
-local-user set). `clientInfo.instanceId` is stable attribution for origin and
-operation deduplication. `instanceSecret` proves that a new authenticated
+local-user set). `clientInfo.instanceId` is stable attribution: the daemon
+derives its authenticated connection principal from it. `instanceSecret` proves that a new authenticated
 connection is the same stable client when it resumes that client's credential
 or Host Tool leases; only its hash participates in daemon-owned bridge state.
 Keep all three values in Electron Main. Mutually distrusting processes running
@@ -5119,9 +5119,9 @@ including its stable KodaX code, stage, bounded display message, and optional
 sanitized upstream metadata.
 Sandbox and managed-child termination failures are observed and retained as
 diagnostics rather than escaping as process-global unhandled rejections.
-If terminal status persistence fails but the Session event journal remains
-healthy, Runtime durably publishes `run.updated` with `phase:'unknown'`. If the
-journal is fenced too, active `sessions.observe()` handles resolve
+If terminal status persistence fails, Runtime still publishes `run.updated`
+with `phase:'unknown'` on the live event stream. If live delivery fails too,
+active `sessions.observe()` handles resolve
 `invalidated` with `reason:'delivery_failed'`; consumers must discard their
 local projection and acquire a fresh observation instead of retaining a stale
 running/terminal state.
@@ -5231,10 +5231,10 @@ runtime.connection?.subscribe((state) => {
 });
 ```
 
-The SDK reports the current `connectionId`, `runtimeEpoch`, optional
-`journalEpoch`, disconnect reason, and whether a new connection may be
+The SDK reports the current `connectionId`, `runtimeEpoch`,
+disconnect reason, and whether a new connection may be
 attempted. It does not transparently replay requests or subscriptions. Space
-creates a replacement Runtime client, checks its new epochs, resumes eligible
+creates a replacement Runtime client, checks its new epoch, resumes eligible
 leases, and observes the session again.
 
 `RuntimeDaemonDisconnectCode` reports only transport-observable facts:
@@ -5291,54 +5291,50 @@ restart changes `runtimeId`. The observation's `invalidated` promise reports
 `transport_disconnected`; after it resolves, no state derived from that
 observation remains authoritative. Restart recovery interrupts only a Run
 whose owner is definitely gone; uncertain external execution is `unknown`.
-Timeout or cancellation removes the daemon request immediately. If a
-third-party transport ignores cancellation and later returns an observation,
-the client compensates by unsubscribing that late observation.
+Timeout or cancellation removes the daemon request immediately. A result that
+arrives after its reader abandoned the request is dropped — the transport
+sends a hygiene `request.cancel` so the Host frees the in-flight record and
+any subscription it created, but no late delivery reaches the caller.
 
 ### Durable mutations, stable ordering, and settings CAS
 
-Every durable public control mutation uses an operation envelope. Credential
-and Host Tool register/revoke/supply/complete requests are reverse-bridge
-control frames and are deliberately excluded from the control journal so
-secrets/results are not persisted. They still enter the daemon management
-draining fence: once an atomic stop begins, they fail with typed `conflict` and
-cannot change reverse-bridge state. The SDK creates an operation ID for
-ordinary one-shot calls. A
-product-level retry after a lost response must reuse its own stable operation
-ID; changing its method, payload, resource, or authenticated principal is
-rejected.
+Public control mutations no longer take an operation envelope. v0.7.97 removed
+the generic `operation: { operationId }` input, auto-generated operation IDs,
+the control journal, and the `runtime.operations.get` receipt query; mutation
+identity now comes from each mutation's own domain fields — the explicit
+`sessionId` on create, the returned `runId` on start, and the settings
+revision on CAS updates. Credential and Host Tool
+register/revoke/supply/complete requests are reverse-bridge
+control frames and persist no secrets or results. They still enter the daemon
+management draining fence: once an atomic stop begins, they fail with typed
+`conflict` and cannot change reverse-bridge state. Reconnection semantics are
+explicit: after a lost response, re-read authoritative state and reconcile in
+your product code; the SDK never transparently retries or replays a mutation.
 
 ```ts
 const session = await runtime.sessions.create({
   sessionId: stableSpaceSessionId,
   title: 'Shared session',
   surface: 'space-desktop',
-  operation: { operationId: loadOrCreatePendingOperationId('space-session-draft-7') },
 });
 
-const operationId = loadOrCreatePendingOperationId('space-run-draft-42');
 const handle = await runtime.runs.start({
   sessionId: session.id,
   input: { type: 'text', text: prompt },
   options: { provider: 'anthropic' },
-  operation: { operationId },
 });
 
 const current = await runtime.sessions.getSettingsVersioned(session.id);
 const updated = await runtime.sessions.updateSettingsVersioned(
   session.id,
   { model: 'claude-sonnet-4-5' },
-  {
-    operationId: loadOrCreatePendingOperationId('space-settings-draft-9'),
-    expectedRevision: current.revision,
-  },
+  { expectedRevision: current.revision },
 );
 ```
 
-Create retries with the same explicit session and operation IDs cannot overwrite
+Re-creating with the same explicit `sessionId` cannot overwrite
 an existing session. Same-session starts and after-turn inputs receive a durable `sessionOrder`.
-Retries with the same operation ID return the canonical result and do not
-create another run. Settings use compare-and-swap; a stale revision returns a
+Settings use compare-and-swap; a stale revision returns a
 structured conflict and must be reloaded, never silently overwritten. The
 shared settings keys are `provider`, `model`, `effort`, `thinking`,
 `reasoningMode`, `permissionMode`, `executionCwd`, `agentMode`, and
@@ -5351,7 +5347,6 @@ const queued = await runtime.runs.submitInput({
   afterRunId: handle.runId,
   delivery: 'after_turn',
   input: { type: 'text', text: 'Also update the tests.' },
-  operation: { operationId: loadOrCreatePendingOperationId('space-input-17') },
 });
 
 if (!queued.accepted) {
@@ -5365,7 +5360,8 @@ This does not create a Run. Each accepted input appears as `queued` in the
 owning Run's `interruptInputs`. At the next safe boundary, all accumulated
 interrupts are drained FIFO, remain separate user messages in one next LLM
 request, and produce one `run.input.delivered` event whose `inputs` array is the
-complete ordered batch. Exact operation retries return the same `inputId`.
+complete ordered batch. An accepted interrupt returns the `inputId` of the
+admitted item, which you keep for later reconciliation.
 The accepted result's `runId` is the existing owning Run (equal to
 `afterRunId`), not a newly created continuation.
 
@@ -5381,8 +5377,8 @@ and Runtime restart preserve a newly recorded reference.
 Since v0.7.82, submission resolves the admitted authoritative Run before it
 reads mutable canonical Session history. Active interrupt and after-turn
 requests therefore do not surface a transient `data_changed` response caused by
-predecessor persistence. `after_turn` still waits for predecessor settlement,
-and an exact `operationId` still produces one admission and one queue item.
+predecessor persistence. `after_turn` still waits for predecessor settlement;
+admission and queue placement are owned by the receiving Run.
 
 Interrupt admission closes when the Runner publishes its final completion or
 terminal error signal, or when the Run's supplied `abortSignal` aborts, even if
@@ -5405,7 +5401,6 @@ const interrupted = await runtime.runs.submitInput({
   afterRunId: handle.runId,
   delivery: 'interrupt',
   input: { type: 'text', text: 'Also preserve the public API.' },
-  operation: { operationId: loadOrCreatePendingOperationId('space-input-18') },
 });
 ```
 
@@ -5417,8 +5412,9 @@ Run status exposes acceptance/start/queue times, authenticated origin,
 `terminal.code = 'blocked'`; surface `terminal.message` when present instead of
 replacing it with a generic run failure. Respect `effectOutcome`; `unknown` must
 never be presented as success or automatically retried. After a lost response,
-query `runtime.operations.get({ operationId, journalEpoch })`; applied receipts
-include the canonical result. Permission grants remain daemon-owned and
+there is no operation receipt to query: re-read authoritative state with
+`runs.get(runId)` / `sessions.status(sessionId)` and reconcile explicitly.
+Permission grants remain daemon-owned and
 revisioned.
 
 Runtime startup restores all indexed active Runs and at most 200 recent
@@ -5494,7 +5490,7 @@ permission context contracts: Auto approvals bind to one exact text call
 without granting a directory, and direct plus managed provider requests carry
 the live permission mode refreshed on retries.
 `sharedSessionSettings` v2 advertises the four canonical profiles and the
-input-only `auto-in-project` alias. Embedded, Worker, and daemon hosts expose
+input-only `auto-in-project` alias. Embedded and daemon hosts expose
 the same contract; restart or upgrade an older daemon instead of falling back
 to client-side routing.
 
@@ -5529,11 +5525,10 @@ const run = await runtime.runs.start({
     mode: 'scoped',
     providers: ['anthropic', 'openai'],
   },
-  operation: { operationId: loadOrCreatePendingOperationId('space-run-88') },
 });
 ```
 
-The allowlist is a ceiling: an operation binding can narrow it but cannot add a
+The allowlist is a ceiling: a run binding can narrow it but cannot add a
 Provider. The daemon asks only when an actual primary, fallback, classifier,
 sidecar, compaction, Workflow, or utility wire call needs that Provider.
 An unauthorized Provider fails before the host callback. The secret crosses
@@ -5615,7 +5610,6 @@ await runtime.runs.start({
   sessionId,
   input: { type: 'text', text: 'Create the report artifact.' },
   hostTools: { leaseId: hostLease.id },
-  operation: { operationId: loadOrCreatePendingOperationId('space-artifact-run') },
 });
 ```
 
@@ -5688,16 +5682,18 @@ rollout unless the product cannot operate without it.
 
 Preflight is useful for UI, but it is not a stop authorization token. Use
 `runtime.daemon.inspect()` to obtain one consistent management revision,
-verified owner fence, owner-policy revision, and preflight projection. Only
-`runtime.daemon.stopForInline()` atomically rechecks and commits a rollback.
-The management revision also advances when the preflight projection changes,
-so a Workflow or AgentTask lifecycle transition between inspect and commit
-invalidates the stale stop. Capability details
+verified owner fence, owner-policy revision, and preflight projection, then
+send the authenticated `runtime.shutdown` request: management rechecks
+preflight under the draining fence and commits the stop only when the daemon is
+idle, otherwise it fails with a structured `conflict` and the daemon keeps
+running. The management revision also advances when the preflight projection changes,
+so a Workflow or AgentTask lifecycle transition between inspect and stop
+invalidates the stale attempt. Capability details
 `daemonManagement.backgroundWorkPreflight` and
 `daemonManagement.reverseBridgeDrainingFence` identify this complete contract.
-`runtime.operations.get()` reconciles durable mutations,
 `hostTools.getInvocation()` reconciles Host Tool metadata, and
-`permissions.listGrants()` returns the daemon-owned persistent grant set.
+`permissions.listGrants()` returns the daemon-owned persistent grant set;
+durable mutations are reconciled by re-reading their authoritative state.
 
 Terminal notification read/unread state is intentionally client-owned in
 v0.7.69 (`durableRecoveryQueries.terminalAcknowledgement === false`): Space
@@ -5709,45 +5705,47 @@ truth.
 
 Daemon and inline Coder use one profile fence. Do not compose
 `status.preflight()` with a low-level unconditional stop: another client or run
-can appear between those calls. The public rollback transaction gates new
-clients and mutations, rechecks the same Runtime and management/policy
-revisions, verifies there is no other client or active/queued/pending work,
-commits sticky inline policy while that daemon still owns the fence, and then
-requests shutdown.
+can appear between those calls. v0.7.97 removed the combined rollback
+transaction (`runtime.daemon.stopForInline()`); stopping the daemon and
+changing the owner mode are now two explicit steps, and the owner mode never
+changes implicitly. First stop the daemon through the fenced idle shutdown —
+management rechecks preflight under the draining fence and returns a
+structured `conflict` instead of stopping a busy daemon — then flip the owner
+policy while no owner lock exists:
 
 ```ts
 import {
   acquireKodaXInlineOwner,
   enableKodaXDaemonOwner,
   getKodaXRuntimeOwnerState,
+  setKodaXRuntimeOwnerMode,
 } from '@kodax-ai/kodax/runtime';
 
 const management = await runtime.daemon.inspect();
 if (!management.preflight.canStop) {
-  showRollbackBlockers(management.preflight.blockers);
+  showStopBlockers(management.preflight.blockers);
   return;
 }
 
-const rollback = await runtime.daemon.stopForInline({
-  expectedRuntimeId: management.runtimeId,
-  expectedRevision: management.revision,
-  expectedOwnerPolicyRevision: management.ownerPolicy.revision,
-  operation: { operationId: loadOrCreatePendingOperationId('coder-inline-rollback') },
-});
+// Fenced idle stop; active work returns structured `conflict`.
+const stop = await runtime.daemon.shutdown();
 
-// `accepted` means inline policy is committed and shutdown is in progress.
-// Wait through the public owner-state query; never infer release from a PID.
+// `accepted` means the stop was taken. Wait through the public owner-state
+// query; never infer release from a PID.
 const shutdownDeadline = Date.now() + 30_000;
-while (getKodaXRuntimeOwnerState({ homeDir: kodaxHome, profile: 'coder' }).owner?.runtimeId
-  === rollback.runtimeId) {
+while (getKodaXRuntimeOwnerState({ homeDir: kodaxHome, profile: 'coder' }).owner) {
   if (Date.now() >= shutdownDeadline) throw new Error('Timed out waiting for daemon owner release.');
   await delay(25);
 }
-const releasedOwner = getKodaXRuntimeOwnerState({ homeDir: kodaxHome, profile: 'coder' });
-if (releasedOwner.ownerStatus !== 'unowned') {
-  throw new Error('Coder profile acquired a different owner during rollback.');
-}
 await runtime.close(); // Detach only; it does not perform a second stop.
+
+// Explicit daemon→inline owner-mode change; rejected while an owner lock exists.
+setKodaXRuntimeOwnerMode({
+  mode: 'inline',
+  expectedRevision: management.ownerPolicy.revision,
+  homeDir: kodaxHome,
+  profile: 'coder',
+});
 const inlineOwner = acquireKodaXInlineOwner({ homeDir: kodaxHome, profile: 'coder' });
 
 // Later, after the inline owner has released its fence:
@@ -5759,25 +5757,30 @@ const daemonPolicy = enableKodaXDaemonOwner({ homeDir: kodaxHome, profile: 'code
 Any management revision change, another logical client, active or queued run,
 running/paused Workflow, non-terminal/unknown AgentTask, pending
 AskUser/permission, or in-flight mutation returns structured `conflict`; the
-daemon remains running and policy remains unchanged. Draining also rejects
-credential and Host Tool state changes without journaling their secrets or
+daemon remains running and the owner mode remains unchanged. Draining also rejects
+credential and Host Tool state changes without persisting their secrets or
 results. The inline policy is sticky: later CLI auto-start is rejected until
+`setKodaXRuntimeOwnerMode({ mode: 'daemon', ... })` or
 `enableKodaXDaemonOwner()` changes it back to `daemon`. `runtime.close()` still
 only detaches. Stale-owner handling validates the owned lock/state and never
 kills a process merely because a PID was reused.
 
 Keep all trusted objects in Electron Main: daemon token/endpoint, stable client
-identity, operation IDs, owner policy, keychain broker, Host Tool handlers, and
+identity, owner policy, keychain broker, Host Tool handlers, and
 permission-grant administration. Renderer IPC should expose product-specific
 commands and sanitized projections only. Never pass daemon credentials,
-leases, operation epochs, or trusted session/run context to renderer or model
+leases, or trusted session/run context to renderer or model
 tool arguments.
 
 ---
 
 ## 24. Runtime-owned permission routing and plan bridges (v0.7.96)
 
-The Runtime owns permission routing in inline, Worker, and daemon deployments.
+> The product equivalent is `view.interactions` plus `interactions.respond`.
+> The Runtime helpers below are for trusted Host adapters, not client-created
+> permission requests or alternate authorization owners.
+
+The Runtime owns permission routing in inline and daemon deployments.
 Clients select one of four profiles and must not add a second preflight gate:
 
 ```ts
@@ -5950,6 +5953,10 @@ for the current permission contract.
 
 ## 25. Always-on context compaction and bounded transcript recovery (v0.7.74)
 
+> Product clients use `sessions.compact`, `observe`, `readItem`, `readHistory`,
+> `readHistoryEntry` and `searchHistory`. Low-level transcript/event examples
+> below do not imply an additional Product event replay surface.
+
 Automatic large compaction is always enabled. `enabled` remains accepted for
 v0.7.x source compatibility, but `false` is normalized to `true`.
 `triggerPercent` defaults to `75` and is clamped to `15..90`. The optional
@@ -5985,16 +5992,16 @@ await runtime.sessions.compact({
     mode: 'scoped',
     providers: ['anthropic'],
   },
-  operation: {
-    operationId: loadOrCreatePendingOperationId(`compact:${session.id}`),
-  },
 });
 ```
 
 Manual compact uses the same credential-aware summary implementation as
-automatic compact. Its broker target is the stable `session.compact` operation,
-not a fabricated Run ID; the daemon validates lease, Provider, Session, and
-operation scope. Reuse the same `operationId` after a lost response.
+automatic compact. There is no client-supplied operation envelope: the daemon
+itself mints the short-lived compaction identity for the scoped credential
+target (a `compact_<uuid>` maintenance id bound to the stable
+`session.compact` operation, not a fabricated Run ID) and validates lease,
+Provider, and Session before the summary call. After a lost response, re-read
+the Session's compaction state instead of retrying blindly.
 
 Setting `compactionTriggerTokens: 0` removes the absolute Session override.
 Percentage updates are normalized to `15..90`; negative/fractional absolute
@@ -6199,7 +6206,7 @@ only prevents high-frequency progress from becoming a model control signal.
 ## 27. Windows GUI background subprocess visibility (v0.7.75)
 
 KodaX SDK hosts do not need to add process-wide console suppression around the
-Runtime. In the v0.7.75 release candidate, Runtime Worker-reachable
+Runtime. Since the v0.7.75 release candidate, Runtime-reachable
 non-interactive/background child processes request `windowsHide: true` at their
 own spawn boundary. The covered paths include:
 
@@ -6214,8 +6221,10 @@ commands, and PTY sessions remain interactive. POSIX-only `ps`, `tmux`, and
 sandbox branches are reviewed bundle-audit exceptions rather than Windows
 visibility paths.
 
-`npm run build:bundle` audits every statically identifiable child-process call
-reachable from `dist/runtime-worker.js`. The packaged Electron daemon smoke then
+The bundled runtime entry points ship with the `dist/semantic-worker.js` and
+`dist/constructed-handler-worker.js` sidecars (the former
+`dist/runtime-worker.js` sidecar and its build-time child-process audit were
+removed with the Worker facade in v0.7.97). The packaged Electron daemon smoke then
 runs 20 ordinary queries with a Win32 probe and checks that the expected Git
 children never own a visible console window. These checks validate the SDK
 boundary, but they do not replace product-level validation in the packaged host.
@@ -6309,6 +6318,9 @@ for cross-project, cache, cancellation, credential, and Windows argv checks.
 
 ## 29. Evidence-gated background Skill learning (FEATURE_263, v0.7.78)
 
+> Product clients consume the Host-owned `client.learning` service. Bootstrap
+> options below configure the trusted owner, not a separate UI learning engine.
+
 F263 completes the existing Learning Center rather than introducing a second
 queue or client-owned Skill store. Episode review runs after durable foreground
 completion and stays off the active Run's latency path. A correction, failure,
@@ -6389,7 +6401,7 @@ bindings without mutating an in-flight prompt.
 Learning Center notification state is client-specific, but capability
 lifecycle and project canary state are owner-global. Renderer code should
 receive sanitized records/events through host IPC; it should not receive
-daemon credentials or mutate files directly. Inline, Worker, and daemon
+daemon credentials or mutate files directly. Inline and daemon
 facades expose the same learning methods. A host missing `skillLearningLoop:1`
 may still support the older Ready/manual Learning Center surface, but must not
 claim the complete F263 project-canary contract.
@@ -6811,7 +6823,7 @@ try {
 when multiple projects expose the same display name or slug. `'user'` is the
 only supported scope. Daemon clients need the server-issued
 `learning:control` scope; advertising a client capability does not grant it.
-Inline, Worker, and daemon facades carry the same v2 learned-record shape and
+Inline and daemon facades carry the same v2 learned-record shape and
 promotion method.
 
 The Runtime verifies the source is a regular non-symlink file inside the exact
@@ -6838,6 +6850,68 @@ unsupported options fail before the Runtime mutation.
 
 ---
 
+## Migrating to v0.7.97
+
+For the complete product-facing mapping, use the [SDK migration guide](../../docs/SDK_MIGRATION.md).
+The table below covers removals in this development tree; it does not claim a
+published `v0.7.97` package. Retained Runtime APIs are not automatically Product APIs.
+
+v0.7.97 is a breaking SDK release for embedders. It removes the durable event
+journal/replay surface, the generic operation envelope/receipts, the
+crash-resumable exit-settlement protocol, and the Worker-hosted embedded
+runtime. If you upgrade a host past v0.7.96, map every removed surface to its
+replacement:
+
+| Removed in v0.7.97 | Replacement |
+|---|---|
+| Operation envelope (`operation: { operationId }` on public control mutations), auto-generated operation IDs, `runtime.operations.get` receipts, and the `operationDeduplication` capability/requirement | Mutation identity comes from each mutation's own domain fields (explicit `sessionId` on create, returned `runId`, `expectedRevision` CAS on settings). After a lost response, re-read authoritative state (`runs.get`, `sessions.status`) and reconcile explicitly; there is no transparent retry or receipt query. |
+| `settleKodaXRuntimeExit()` SDK export, `daemon.rollbackToInline`, client `stopForInline`, and the `runtimeExitSettlement:2` capability | `runtime.shutdown` / `runtime.daemon.shutdown()` is a real idle shutdown (busy → structured `conflict`). Daemon→inline ownership changes are explicit: `setKodaXRuntimeOwnerMode({ mode, expectedRevision })`, or owner-lock release plus `acquireKodaXInlineOwner()`. The owner mode never changes implicitly. |
+| `event.subscribe`/`event.replay` RPCs, the `{ sessionId, journalEpoch, seq }` cursor, `journalEpoch` fields, and the `sessionEventJournal:1` capability | Events are a live in-process stream (`{ id, seq, time, sessionId, runId, turnId?, type, payload }`). Remote consumption reuses `session.observe` notifications; observation snapshots carry a `seq` high-water, live listener events are strictly greater, and `seq` never persists across restarts. Deleting/recreating a Session invalidates observations with `runtime_changed`. |
+| Diagnostics RPCs `context.budget.get`, `tool.exposure.preview`, `provider.cache.diagnostics.get` (and the `runtime.diagnostics.latest*` facade) | Removed. `capabilities.contextDiagnostics: true` only gates diagnostic event notifications (`context.budget.snapshot`, `tool.exposure.planned`, `provider.cache.diagnostics`, `context.compaction.skipped`) on the live stream. |
+| `isolation: 'worker'`, `worker: { configuredA2A: true }` (and `worker.*` options), `requirements.hardDispose`, and the `dist/runtime-worker.js` sidecar | Deleted. Use inline embedded or daemon mode. For the configured A2A plane, wire `createConfiguredA2ARuntimeIntegration({ configHome })` in the owner and pass its `runtimeOptions` as `externalAgents` — the Runtime itself never reads `integrations/a2a.json`. |
+| Late-result redelivery after an abandoned read | Removed. `request.cancel`/`request.ack` remain daemon transport-control frames only; an abandoned read gets no late delivery. |
+| The product mode surfaces: the CLI `--runtime-mode` flag, the `KODAX_RUNTIME_MODE` environment variable, and the `runtimeMode` key in `~/.kodax/config.json` | Removed in the fixed-Host release. The `kodax` CLI always starts-or-attaches the daemon owner; SDK callers keep the `mode: 'embedded' | 'daemon'` option on `createKodaXRuntime` (embedded stays a low-level path, never a product fallback). |
+| `setThinking` REPL callback | Removed. Use `setReasoningMode` (the shared settings key is `reasoningMode`). |
+| `getKodaXRuntimeOwnerPolicy` export | Removed. `getKodaXRuntimeOwnerState()` remains and reports policy, owner status, and the current owner in one call. |
+
+Product UIs connect through `connectKodaXClient` from `@kodax-ai/kodax/client`.
+The Host owns execution and saved history; `sessions.observe` delivers the
+current display; `readItem` expands display references, while `readHistory`,
+`readHistoryEntry` and `searchHistory` provide canonical history and its own
+readable references. A display preview is not the full
+message. The Runtime-to-product adapter is internal and is not an SDK export.
+
+Keep an input's original text, artifacts and `inputId` until its outcome is
+known. After a lost response, query that same Host with `inputs.read`; only a
+confirmed withdrawal returns a queued input to the editor. A replacement Host
+does not inherit the old Host's input identities.
+
+Product rewind requires the head the user reviewed, so another client's newer
+work cannot be silently discarded:
+
+```ts
+const lineage = await client.sessions.readLineage(sessionId);
+await client.sessions.rewindSession(sessionId, {
+  selector: targetEntryId,
+  expectedHead: lineage?.activeEntryId ?? null,
+});
+```
+
+On `conflict`, reload the lineage and let the user review the new state before
+trying again. Rewind changes the conversation branch; it does not undo files.
+Bound REPL Memory commands use the same daemon owner, and Workflow/Skill
+execution uses real Runs with the Session's effective settings and tool policy.
+
+Two compatibilities are unchanged and worth restating: the constructed-handler
+worker (repo-intelligence and managed-task workers in `@kodax-ai/coding`) is a
+separate, kept surface, and the `mode: 'embedded' | 'daemon'` option on
+`createKodaXRuntime` still selects the ownership form. Host-minted compact
+identity (`compact_<uuid>`, minted by the daemon for the scoped credential
+target of manual compaction) still exists — it is Host-internal, not a client
+envelope.
+
+---
+
 ## Managed extension execution and Session Stop (FEATURE_299, v0.7.96)
 
 A Stop button uses one owner-side operation: