@earendil-works/pi-durable 0.87.1 → 0.99.1

package/docs/pico-v5.md

@@ -5,13 +5,18 @@ Pico5 uses existing package types as follows:
 
 ```ts
 import type {
+  AttachedReplicatedState,
   Context,
   Draft,
+  JsonRepresentation,
   JsonValue,
   ReplicatedState,
 } from "@earendil-works/chord";
-import { applyImmutable, type Op } from "@earendil-works/chord/delta";
+import type { Op } from "@earendil-works/chord/delta";
 import type {
+  AssistantMessage,
+  CacheRetention,
+  DeferredHandle,
   Message,
   Models,
   ModelThinkingLevel,
@@ -19,6 +24,7 @@ import type {
   Tool,
   ToolReference,
   ToolResultMessage,
+  Transport,
   UserMessage,
 } from "@earendil-works/pi-ai";
 
@@ -47,6 +53,10 @@ The core rule is:
 - A **definition** is a typed token describing one document or document family.
 - A **source** exposes committed document changes to Chord without exposing a
   mutable object.
+- A **turn** is one assistant response and the tool calls it makes. A **run**
+  is the sequence of turns from an admitted input to the final answer; turn
+  boundaries (section 6) sit between its turns. A conversation is busy while a
+  run is active.
 
 Required invariants:
 
@@ -55,10 +65,12 @@ Required invariants:
 3. All visible progress is durable. There is no volatile publication path.
 4. External effects do not run inside the Session mutation transaction.
 5. Entries and IDs are immutable and never reused after a committed write.
-6. Document drafts are revoked when their transaction callback settles. Values
-   assigned into a draft are copied by value.
+6. Document drafts are fully revoked when their transaction callback settles:
+   the Session synchronously prepares or aborts every open change at that point.
+   Values assigned into a draft are copied by value and must be strict JSON.
 7. The mutation line remains held through storage settlement and committed-state
-   adoption. Listener callbacks run later, off the line.
+   adoption. Commit/close observers run synchronously only to capture immutable
+   state; document-state and watch user callbacks run later, off the line.
 8. An uncertain storage failure is fatal to the open Session. It publishes
    nothing and must be reopened. Preparation and checkpoint failures occur before
    storage admission and roll back normally.
@@ -69,20 +81,37 @@ The concrete JSON representations may add bookkeeping fields, but must preserve
 these contracts.
 
 ```ts
-type Id = number;
+declare const idBrand: unique symbol;
+type Id<Kind extends string, Type = unknown> = number & {
+  readonly [idBrand]: {
+    readonly kind: Kind;
+    readonly type: Type;
+  };
+};
+type ConversationId = Id<"conversation">;
+type EntryId = Id<"entry">;
+type TaskId<Result = unknown> = Id<"task", Result>;
+type SubmissionId = Id<"submission">;
+type DocumentId = Id<"document">;
+
+declare const seqBrand: unique symbol;
 /** Strictly increases between commits; gaps are permitted. */
-type Seq = number;
-const ROOT_CONVERSATION_ID: Id = 1;
+type Seq = number & { readonly [seqBrand]: "sequence" };
+const ROOT_CONVERSATION_ID = 1 as ConversationId;
+
+type ConversationOwnership =
+  | { readonly kind: "ownerless" }
+  | { readonly kind: "task"; readonly taskId: TaskId };
 
 type ConversationRecord = {
-  readonly id: Id;
+  readonly id: ConversationId;
   readonly parent?: {
-    readonly conversationId: Id;
-    readonly at: Id;
+    readonly conversationId: ConversationId;
+    readonly at: EntryId;
   };
   readonly owner?: {
-    readonly conversationId: Id;
-    readonly taskId: Id;
+    readonly conversationId: ConversationId;
+    readonly taskId: TaskId;
   };
 };
 ```
@@ -100,38 +129,41 @@ interface SystemMessage {
 }
 ```
 
-`content` is the base prompt on the leading message and additional instruction
-text on later messages. `sections` is an ordered named patch: a string adds or
-replaces a section, while `null` removes it. `toolsRemoved` is applied before
-`toolsAdded` within one message. Replaying every system message in transcript
-order yields the effective prompt and tool set.
+In pi-ai, `content` is the base prompt on the leading message and additional
+instruction text on later messages. `sections` is an ordered named patch: a
+string adds or replaces a section, while `null` removes it. `toolsRemoved` is
+applied before `toolsAdded` within one message. Replaying every system message
+in transcript order yields the effective prompt and tool set.
+
+Pico always writes `content: ""`. Every prompt part, including the preamble, is
+a named section produced by the registry's system prompt slot (section 7.4).
 
 ```ts
 type ContextEdit = {
-  readonly target: Id;
+  readonly target: EntryId;
 } & (
   | { readonly action: "omit"; readonly messages?: never }
   | { readonly action: "replace"; readonly messages: readonly Message[] }
 );
 
 type EntryRecord = {
-  readonly id: Id;
-  readonly conversationId: Id;
+  readonly id: EntryId;
+  readonly conversationId: ConversationId;
   readonly kind: string;
   readonly model?: readonly Message[];
   readonly data?: JsonValue;
-  readonly head?: Id;
+  readonly head?: EntryId;
   readonly edits?: readonly ContextEdit[];
-  readonly byTaskId?: Id;
+  readonly byTaskId?: TaskId;
 };
 
 type EntryDraft = Omit<EntryRecord, "id" | "conversationId" | "byTaskId" | "head"> & {
-  readonly head?: Id | "self";
+  readonly head?: EntryId | "self";
 };
 
 type SubmissionRecordBase = {
-  readonly id: Id;
-  readonly conversationId: Id;
+  readonly id: SubmissionId;
+  readonly conversationId: ConversationId;
   readonly requestId?: string;
 };
 
@@ -148,21 +180,21 @@ type SubmissionRecord =
         }
       | {
           readonly status: "placed";
-          readonly entry: Id;
+          readonly entry: EntryId;
           readonly answer?: never;
           readonly reason?: never;
           readonly detail?: never;
         }
       | {
           readonly status: "done";
-          readonly entry: Id;
-          readonly answer: Id;
+          readonly entry: EntryId;
+          readonly answer: EntryId;
           readonly reason?: never;
           readonly detail?: never;
         }
       | {
           readonly status: "unanswered";
-          readonly entry?: Id;
+          readonly entry?: EntryId;
           readonly answer?: never;
           readonly reason: string;
           readonly detail?: JsonValue;
@@ -180,7 +212,7 @@ type SubmissionRecord =
         }
       | {
           readonly status: "done";
-          readonly entry: Id;
+          readonly entry: EntryId;
           readonly answer?: never;
           readonly reason?: never;
           readonly detail?: never;
@@ -194,6 +226,10 @@ type SubmissionRecord =
         }
     ));
 
+type SubmissionSettlement =
+  | { readonly status: "done"; readonly answer: EntryId }
+  | { readonly status: "unanswered"; readonly reason: string; readonly detail?: JsonValue };
+
 type SubmissionCreate = SubmissionRecord extends infer Record
   ? Record extends SubmissionRecord
     ? Omit<Record, "id">
@@ -201,10 +237,18 @@ type SubmissionCreate = SubmissionRecord extends infer Record
   : never;
 ```
 
+ID brands are compile-time only. IDs and sequences remain ordinary numbers in
+memory, JSON, JSONL, and SQLite. Code applies a brand only at a trusted creation
+or decoding boundary. The distinct sequence brand prevents an entity ID from
+being used as a document commit point.
+
 Conversation history parenting and task ownership are separate:
 
 - `parent` controls inherited entries and historical documents.
-- `owner` controls task authorization, subtree abort, and subtree idle waits.
+- `owner` records task attribution and connects scopes for subtree abort and idle traversal. It is not an access-control capability.
+- Creation always supplies `ConversationOwnership` explicitly. The Session
+  derives the persisted owner's conversation from the named task; callers never
+  construct the persisted owner pair.
 
 A conversation's owner remains recorded after the owning task becomes terminal.
 
@@ -228,9 +272,11 @@ Context derivation:
 5. If `H` exists, context entries are `H` followed by non-head entries in the
    range. Otherwise they are the range.
 6. Keep every positional system message and its tool/section changes.
-7. Order tool results by assistant tool-call order.
-8. Synthesize missing tool results after a fork when required by the provider
-   message protocol.
+7. Move each assistant's tool results, found before the next assistant message,
+   directly after it in tool-call order, ahead of any intervening user or system
+   message. The provider protocol requires results to follow their call.
+8. Synthesize an error result for every call without one, for example after a
+   fork cut or at an interrupted tail. Drop tool results with no preceding call.
 9. Exclude model-less entries and assistant messages with `aborted`, `error`, or
    `deferred` stop reasons from future provider requests.
 
@@ -271,15 +317,12 @@ type SubmissionDraft = {
 
 type InputSubmissionDraft = Extract<SubmissionDraft, { readonly type: "input" }>;
 
-type SectionSeed =
-  | { readonly key: string; readonly value: JsonValue }
-  | { readonly key: string; readonly remove: true };
+/** Runs inside the creating commit, after the conversation and its configuration exist. */
+type ConversationInit = (tx: Tx, conversationId: ConversationId) => void | Promise<void>;
 
-type ConversationSpec = {
-  readonly parent?: { readonly conversationId: Id; readonly at: Id };
-  readonly model?: ModelRef;
-  readonly sections?: readonly SectionSeed[];
-  readonly activeTools?: readonly string[];
+type ConversationCreateOptions = {
+  readonly ownership: ConversationOwnership;
+  readonly init?: ConversationInit;
 };
 
 type AnyTask = {
@@ -294,22 +337,58 @@ type AnyTask = {
   };
 };
 
-type HarnessOptions = {
+type HarnessOptions<Tool extends ToolRegistration = ToolRegistration> = {
   readonly models: Models; // the pi-ai Models interface
-  readonly tools?: readonly ToolRegistration[];
-  readonly taskKinds?: readonly AnyTask[];
-  readonly sections?: readonly SystemSection<JsonValue>[];
+  readonly registry: RegistryReader<Tool>; // section 7.1
   readonly now?: () => number;
-  readonly root?: Omit<ConversationSpec, "parent">;
   readonly onReport?: (error: unknown) => void;
 };
 
-interface Entry<E extends EntryRecord = EntryRecord> {
+/** Curated pi-ai request options; absent fields use pi-ai defaults. */
+type ConversationStreamOptions = {
+  transport?: Transport;
+  timeoutMs?: number;
+  /** Provider/SDK retries inside one request attempt. */
+  maxRetries?: number;
+  maxRetryDelayMs?: number;
+  headers?: Record<string, string>;
+  metadata?: JsonObject;
+  cacheRetention?: CacheRetention;
+  deferred?: boolean | { window?: "15m" | "1h" | "24h" };
+};
+
+/** Durable generation attempt retries; the JSON shape of pi-ai `RetryPolicy`. */
+type ConversationRetryPolicy = {
+  enabled: boolean;
+  maxRetries: number;
+  baseDelayMs: number;
+  maxAgentDelayMs?: number;
+};
+
+type ConversationConfigState = {
+  model?: ModelRef;
+  thinkingLevel: ModelThinkingLevel;
+  activeTools: string[];
+  streamOptions?: ConversationStreamOptions;
+  retry?: ConversationRetryPolicy;
+};
+
+/** Built-in rewindable configuration document; see below. */
+declare const ConversationConfig: RewindableConversationDocToken<ConversationConfigState>;
+
+/** Entry whose `data` has type `D`; `never` means the kind carries no data. */
+type TypedEntry<D extends JsonValue> = Omit<EntryRecord, "data"> &
+  ([D] extends [never] ? { readonly data?: never } : { readonly data: D });
+
+type TypedEntryDraft<D extends JsonValue> = Omit<EntryDraft, "kind" | "data"> &
+  ([D] extends [never] ? { readonly data?: never } : { readonly data: D });
+
+interface Entry<D extends JsonValue = never> {
   readonly kind: string;
-  is(entry: EntryRecord | undefined): entry is E;
+  is(entry: EntryRecord | undefined): entry is TypedEntry<D>;
 }
 
-function defineEntry<E extends EntryRecord>(kind: string): Entry<E>;
+function defineEntry<D extends JsonValue = never>(kind: string): Entry<D>;
 
 type ContextView = {
   readonly head: EntryRecord | undefined;
@@ -322,7 +401,7 @@ type SettledSubmissionRecord = SubmissionRecord & {
 };
 
 interface Submission {
-  readonly id: Id;
+  readonly id: SubmissionId;
   status(context: Context): Promise<SubmissionRecord>;
   wait(context: Context): Promise<SettledSubmissionRecord>;
   abort(context: Context): Promise<"aborted" | "already_placed" | "settled">;
@@ -332,6 +411,27 @@ type SettledTask<R> = TaskRecord<JsonValue, JsonValue, R> & {
   readonly state: Extract<TaskState<JsonValue, R>, { status: "terminal" }>;
 };
 
+type TaskInspection = {
+  readonly record: TaskRecord<JsonValue, JsonValue, JsonValue>;
+  readonly state:
+    | { readonly kind: "running" }
+    | { readonly kind: "ready"; readonly migrates: boolean }
+    | { readonly kind: "waiting"; readonly on: readonly TaskId[] }
+    | {
+        readonly kind: "blocked";
+        readonly reason: "missing_task" | "task_too_old" | "migration_failed";
+        readonly error?: unknown;
+      };
+};
+
+type HarnessInspection = {
+  readonly scheduling: "paused" | "running" | "closing";
+  readonly tasks: readonly TaskInspection[];
+  /** Queued and placed submissions in ID order. */
+  readonly submissions: readonly SubmissionRecord[];
+  readonly registry: readonly RegistryFailure[];
+};
+
 type ConversationWatch = WatchHandle<ConversationView>;
 
 type HooksOf<K> = K extends Task<infer _I, infer _S, infer _R, infer H>
@@ -339,7 +439,7 @@ type HooksOf<K> = K extends Task<infer _I, infer _S, infer _R, infer H>
   : never;
 
 interface Conversation {
-  readonly id: Id;
+  readonly id: ConversationId;
   submit(submission: SubmissionDraft, context: Context): Promise<Submission>;
 
   getModel(context: Context): Promise<ModelRef | undefined>;
@@ -348,15 +448,10 @@ interface Conversation {
   setThinkingLevel(level: ModelThinkingLevel, context: Context): Promise<void>;
   getActiveTools(context: Context): Promise<readonly string[]>;
   setActiveTools(names: readonly string[], context: Context): Promise<void>;
-  getSection<T extends JsonValue>(
-    section: SystemSection<T>,
-    context: Context,
-  ): Promise<T | undefined>;
-  setSection<T extends JsonValue>(
-    section: SystemSection<T>,
-    value: T | undefined,
-    context: Context,
-  ): Promise<void>;
+  getStreamOptions(context: Context): Promise<ConversationStreamOptions>;
+  setStreamOptions(options: ConversationStreamOptions, context: Context): Promise<void>;
+  getRetryPolicy(context: Context): Promise<ConversationRetryPolicy>;
+  setRetryPolicy(policy: ConversationRetryPolicy | undefined, context: Context): Promise<void>;
 
   commit<T>(
     change: (tx: Tx) => T | Promise<T>,
@@ -365,68 +460,50 @@ interface Conversation {
   context(context: Context): Promise<ContextView>;
   entries(
     query: Omit<EntryQuery, "conversationId">,
-    cursor: Cursor | undefined,
     limit: number,
+    cursor: Cursor | undefined,
     context: Context,
   ): Promise<Page<EntryRecord, Cursor>>;
   fork(
-    at: Id,
-    spec: Omit<ConversationSpec, "parent">,
+    at: EntryId,
+    options: ConversationCreateOptions,
     context: Context,
   ): Promise<Conversation>;
-  collapse(instructions: string | undefined, context: Context): Promise<Id>;
+  collapse(instructions: string | undefined, context: Context): Promise<TaskId>;
   reset(handoff: string | undefined, context: Context): Promise<void>;
   abort(context: Context): Promise<void>;
   waitForIdle(context: Context): Promise<void>;
-  hooks<K extends AnyTask>(
-    owner: string,
-    task: K,
-    handlers: Partial<HooksOf<K>>,
-    options?: { readonly subtree?: boolean },
-  ): () => void;
+  viewState(context: Context): Promise<AttachedReplicatedState<ConversationView>>;
   watch(context: Context): Promise<ConversationWatch>;
 }
 
 interface Harness extends Session {
   resume(): void;
-  suspend(context: Context): Promise<void>;
-  quiescent(): boolean;
-  hold(): () => void;
-
-  registerTaskKind(task: AnyTask): () => void;
-  registerTool(tool: ToolRegistration): () => void;
-  registerSection(section: SystemSection<JsonValue>): () => void;
-  hooks<K extends AnyTask>(
-    owner: string,
-    task: K,
-    handlers: Partial<HooksOf<K>>,
-  ): () => void;
-
-  root(context: Context): Promise<Conversation>;
-  onConversation(listener: (conversation: Conversation) => void): () => void;
-  conversation(id: Id, context: Context): Promise<Conversation | undefined>;
-  createConversation(
-    spec: ConversationSpec & { readonly input?: UserInput },
+
+  root(
     context: Context,
+    options?: { readonly init?: ConversationInit },
   ): Promise<Conversation>;
+  conversation(id: ConversationId, context: Context): Promise<Conversation | undefined>;
+  createConversation(options: ConversationCreateOptions, context: Context): Promise<Conversation>;
 
-  getTask(id: Id, context: Context): Promise<TaskRecord<JsonValue, JsonValue, JsonValue> | undefined>;
-  submission(id: Id, context: Context): Promise<Submission | undefined>;
+  getTask<R>(id: TaskId<R>, context: Context): Promise<TaskRecord<JsonValue, JsonValue, R> | undefined>;
+  inspect(context: Context): Promise<HarnessInspection>;
+  submission(id: SubmissionId, context: Context): Promise<Submission | undefined>;
   abortSubmission(
-    id: Id,
+    id: SubmissionId,
     context: Context,
-    conversationId?: Id,
+    conversationId?: ConversationId,
   ): Promise<"aborted" | "already_placed" | "settled" | "not_found">;
-  abortTask(id: Id, context: Context): Promise<"marked" | "terminal">;
-  markTask(id: Id, context: Context): Promise<"marked" | "terminal">;
-  waitForTask<R>(ref: TaskRef<R>, context: Context): Promise<SettledTask<R>>;
+  abortTask(id: TaskId, context: Context): Promise<"marked" | "terminal">;
+  waitForTask<R>(id: TaskId<R>, context: Context): Promise<SettledTask<R>>;
   waitForIdle(context: Context): Promise<void>;
 }
 
 declare const Harness: {
-  open(
+  open<Tool extends ToolRegistration>(
     storage: Storage,
-    options: HarnessOptions,
+    options: HarnessOptions<Tool>,
     context: Context,
   ): Promise<Harness>;
 };
@@ -439,76 +516,122 @@ conversation watch replace those surfaces. `submit()` durably admits either a
 user input or passive entry write and returns one `Submission` that tracks its
 settlement.
 
-`Harness.open()` installs built-in task, tool, and section definitions followed
-by supplied task kinds, tools, and sections. It changes
-surviving `running` tasks to `pending`, migrates task records, and settles unknown
-or unmigratable live task kinds as `orphaned` before resolving. Any built-in
-document touched by that recovery migrates through its ordinary typed access
-path. Open does not scan or migrate other documents. IDs and names in registries must be unique. No
-handler dispatches during open. Dynamic registration is available after open and
-does not resurrect a task already settled by that pass.
-
-The root conversation always has reserved ID `ROOT_CONVERSATION_ID` (`1`). Empty
-storage creates that conversation from `options.root`; reopen looks it up by the
-reserved ID. `options.root` never overwrites existing state. `root()` returns
-that handle. A conversation with no configured model produces a durable
-`no_model` generation failure.
+`Harness.open()` binds the Session to one application-owned registry (section
+7.1). `createRegistry()` pre-registers the built-in task definitions (section 8);
+they cannot be disposed or replaced, and open rejects a registry whose snapshot
+lacks any of them or the built-in `pi` conversation setup.
+Open changes surviving `running` tasks to `pending` and does nothing else to
+task records: it never migrates or terminalizes a task because its definition
+is missing or unmigratable. Such a task stays `pending` and is **blocked**: the
+scheduler skips it and reconsiders it whenever the registry changes (section
+5.4). Any built-in document touched by recovery migrates through its ordinary
+typed access path. Open does not scan or migrate other documents. No handler
+dispatches during open. Applications should register tasks before open so
+recovered work can resume immediately; registration after open also unblocks it.
+
+The root conversation always has reserved ID `ROOT_CONVERSATION_ID` (`1`).
+`root(context, { init })` creates it lazily: when the root is absent, one commit
+on the Session line creates the ownerless root, its default configuration, and
+runs `init(tx, rootId)`. When the root already exists, `init` is ignored and no
+write occurs. Reopen finds the same root by its reserved ID. A conversation with
+no configured model produces a durable `no_model` generation failure.
 
 `resume()` is idempotent while running and only enables scheduling. It does not
-repeat open-time reconciliation. `suspend()` is terminal for that Harness
-instance and follows the close semantics below; `resume()` after suspend/close
-rejects. `quiescent()` means no task invocation is currently executing; eligible
-or delayed durable tasks may still exist. `hold()` is available only while
-quiescent and pauses reservation until its idempotent release function runs.
-
-Runtime registration rejects duplicate IDs/names and returns an idempotent
-function that unregisters only that exact token. It supports declaration
-movement during normal operation, not replacement of executing extension code;
-section 7.4 governs code reload.
-
-Conversation creation atomically commits the conversation, built-in
-configuration and section/tool seeds, and an optional input submission. For a fork,
-omitted model, section, and active-tool values follow their document definition's
-fork policy; provided values override those forked built-in values in the same
-commit. Other documents follow their own definitions without special handling.
-
-The built-in conversation configuration document contains the selected model,
-thinking level, an ordered array of section key/value records, and active tool
-names. Its initial thinking level
-is `"off"`. It is rewindable with `fork: "asOf"`, so a child starts from the
-configuration visible at its selected entry unless explicit creation seeds
-override it. Conversation creation eagerly
-creates it, so `getModel()`, `getThinkingLevel()`, `getActiveTools()`, and
-`getSection()` return detached committed snapshots without a get-or-create
-write. Each setter performs one ordinary Session commit against that document;
-`setSection(section, undefined)` removes the value. A setter does not start
+repeat open-time reconciliation, and it throws after close. Work that must happen
+before any task runs, such as registration or seeding, happens before
+`resume()`. Calls that ask for progress also enable scheduling, so they never
+wait on a paused Harness: `Conversation.submit()`, `Submission.wait()`,
+`Harness.waitForTask()`, `Harness.waitForIdle()`, and
+`Conversation.waitForIdle()`. Recovered work starts with them. A viewer that only
+reads never enables scheduling.
+
+`createConversation({ ownership, init })` and
+`fork(at, { ownership, init })` commit atomically: the conversation, its
+explicitly selected ownership, its configuration, and every write made by `init`.
+A first input is an ordinary `submit()` afterward. A request ID makes a retried
+`submit()` to the same conversation exactly-once; a host that must survive a
+crash between the two calls first finds its conversation again, for example
+through a key written by `init`. Host callers must choose ownerless or task
+ownership; neither the Harness nor a conversation handle infers ownership from
+call context. A new independent conversation receives the default configuration
+before `init` runs. A fork receives the configuration visible at `at` through
+the ordinary `asOf` fork policy; `init` may then override it with
+`tx.doc(ConversationConfig, id)`. Other documents follow their own definitions
+without special handling.
+
+Every Harness commit that creates or forks a conversation runs the registry's
+conversation setups (section 7.1) in the same commit, whether through the
+conveniences or through raw `tx.createConversation()` and `tx.forkConversation()`,
+for example inside a tool commit. The built-in `pi` setup runs first: an
+independent conversation gets the default configuration and a fork keeps its
+`asOf` copy, and both get an empty `pi.live`. Applications register setups for
+their own documents the same way. The conveniences add only `init` and its checks,
+which run after every setup. A conversation created by a plain Session has no
+built-in documents; its configuration reads as
+`ConversationConfig.definition.initial()` until something writes it.
+
+The built-in conversation configuration document is final at version 1:
+
+| field | value |
+|---|---|
+| kind | `pi.conversation.config` |
+| version | `1` (no migration) |
+| scope/history/fork | conversation, `rewindable`, `asOf` |
+| schema | `ConversationConfigState` |
+| `initial()` | `{ thinkingLevel: "off", activeTools: [] }` |
+| checkpoint | complete base on every change |
+| view mount | `docs["pi.conversation.config"]` |
+
+It has no prompt sections: prompt text is produced per request by the registry
+(section 7.4). Any code may edit it with
+`tx.doc(ConversationConfig, id)`, including in the same commit as a create or
+fork. The getters return immutable committed values, falling back to
+`initial()` when the document is absent; they never write. `getStreamOptions()`
+returns `{}` and `getRetryPolicy()` returns the default policy
+`{ enabled: true, maxRetries: 3, baseDelayMs: 2000, maxAgentDelayMs: 60000 }`
+when the field is absent; `setRetryPolicy(undefined)` removes the field.
+`streamOptions` are forwarded to every generation request of the conversation;
+`streamOptions.maxRetries` are provider retries inside one request, while `retry`
+governs durable generation attempts (section 8). Each setter performs
+one ordinary Session commit against the document. A setter does not start
 generation or append a system entry. Request preparation later compares the
-desired committed configuration with transcript history and appends the required
+desired configuration with transcript history and appends the required
 positional system baseline or delta.
 
-Tool declarations and executable functions are process-local Harness registry
-entries, supplied through `HarnessOptions.tools` or `registerTool()`. The durable
-configuration document stores only active tool names. A new independent
-conversation defaults to every tool registered when its creation is admitted;
-`ConversationSpec.activeTools` overrides that default. A fork with no explicit
-`activeTools` uses the configuration document's `asOf` value.
-
-`registerTool()` changes only the runtime registry. It does not activate the tool
-in existing conversations or write a document. `setActiveTools()` is the only
-host operation that replaces one existing conversation's durable active set.
-Explicit `ConversationSpec.activeTools` and `setActiveTools()` values must contain
-unique names that are registered when their commit is admitted; otherwise the
-whole operation rejects without a write. Inherited historical names are not
-revalidated during a fork and may later be unavailable after registry movement.
-Unregistering a tool does not rewrite any conversation.
-
-If request preparation finds unavailable active names, it performs no provider
-request. It atomically terminalizes the generation task as `failed` with
-`detail: { code: "missing_active_tool", names }`, makes its placed input submissions
-`unanswered` with reason `missing_active_tool`, clears matching turn control, and
-appends a visible model-less diagnostic entry. It does not silently change the
-durable loadout. Historical system entries remain replayable because they store
-the exact declarations actually offered to prior requests.
+Default active tools for a root or independent conversation, including one
+created through `tx.createConversation()` in a Harness commit, are the names of
+every tool registered when its creation commit runs, in registry order.
+`setActiveTools()` rejects the whole operation without a write when a name is
+duplicated or when a name that was not already active in that conversation is
+not registered. The create/fork conveniences check only one thing about `init`
+writes: names that `init` newly activates must be registered. Names that were
+already active are never revalidated, so stale unregistered names survive every
+edit. All other raw document writes are trusted and unchecked, so other writers,
+such as post-tools `addTools`, never fault because of registry movement. Readers tolerate what raw
+writes can produce: request preparation offers the first occurrence of a
+duplicated name, and post-tools `addTools` appends only names not already
+active.
+
+`init` runs after the conversation creation, which is a table write, so table
+reads inside it throw `ReadAfterWrite` (section 4). Document access remains
+available.
+
+The configuration document records the desired loadout; the registry records
+what this process can execute now. An active name may therefore be unregistered,
+for example during extension reload, after restart before registration, or in a
+fork opened by a process that lacks an extension. The document is never
+rewritten because of registry movement, so a re-registered tool becomes available
+again without host action. Hosts derive current availability as active names
+that are currently registered.
+
+A missing tool implementation never fails a request. Request preparation offers
+only active names that are currently registered. If the replayed tool state still
+offers an unregistered name, the appended system delta lists it in
+`toolsRemoved`; when the name is registered again, a later delta adds its current
+declaration. When the model calls a tool that is not offered or whose
+implementation is unavailable at execution time, the tool task appends an error
+tool result with `details: { code: "tool_unavailable" }` stating that the tool is
+not available, and the run continues so the model can react.
 
 A `Conversation.commit()` is a Session commit bound to that conversation.
 `tx.createTask()` defaults `TaskOptions.conversationId` to the bound conversation.
@@ -517,29 +640,30 @@ fork-aware stored history; callers cannot substitute another conversation ID.
 Generic Session-wide document operations remain available directly on `Harness`
 because `Harness extends Session`.
 
-`fork()` requires a concrete visible parent entry and applies section 3.7.
+`fork()` requires a concrete visible parent entry and explicit ownership, then
+applies section 3.7.
 `collapse()` returns the newly admitted background collapse task ID, not its
 future summary entry. `reset()` durably admits a passive self-head reset or
 handoff write and then resolves; while busy, placement follows section 6 and may
 occur later. Observe its placement through the conversation watch. An idle wait
 does not guarantee placement of queued passive writes.
 
-`markTask()` only commits `abortRequested`; it neither signals nor joins an
-active invocation. The scheduler notices the mark on its next drain.
-`abortTask()` also signals and joins an active run before starting the abort
-invocation. `Conversation.abort()` withdraws queued input submissions, marks
-non-background tasks in the conversation and owned subtree, signals them, and
-resolves only after that subtree is ordinarily idle. Passive writes and
-background tasks survive. Conversation idle means no non-background live task
-in that conversation or its ownership subtree; Harness idle applies the same
-rule Session-wide. Pending dependency- or deadline-blocked work is still live
-and therefore not idle. Cancelling an idle wait aborts only that waiter.
-
-`onConversation()` synchronously visits the currently loaded committed
-conversations in ascending ID order, then reports each later creation after its
-commit. Listener failures go to `onReport` and do not stop other listeners. Its
-idempotent disposer removes the listener; Harness close removes all remaining
-listeners.
+`abortTask()` commits `abortRequested` and the durable foreground-subtree
+cascade, then signals and joins the active run; the scheduler then starts the
+abort invocation. Marking without signalling is internal: the cascade marks
+owned tasks in the same commit. `Conversation.abort()` withdraws queued
+input submissions, marks non-background tasks selected by ordinary ownership
+traversal, signals them, and resolves only after that scope is ordinarily idle.
+Passive writes and background subtrees survive. Conversation idle means no live
+non-background task selected from that conversation. Harness idle applies the
+same traversal from every ownerless conversation root. Pending dependency- or
+deadline-blocked work is still live and therefore not idle. Cancelling an idle
+wait aborts only that waiter.
+
+Conversation handles are stateless; compare them by `id`. Hosts discover
+conversations through lookups and scans. An activity view that lists active
+conversations and reports conversations becoming active or idle is specified
+with run control (Package 17); there is no creation listener.
 
 `submit()` returns after durable admission, not settlement. An input submission
 creates a user message with the admission timestamp; `whenBusy` defaults to
@@ -553,23 +677,37 @@ reopen; records remain queryable after settlement.
 
 `abortTask()` durably requests cancellation and returns `marked` after the mark
 is committed, any active run invocation has joined, and an abort invocation has
-been scheduled; it does not await terminal settlement. `waitForTask()` observes
+been scheduled, or a blocked task has been settled as `orphaned` (section 5.4);
+it does not await terminal settlement. `waitForTask()` observes
 the terminal receipt. Aborting an already terminal task returns `terminal`; an
 unknown ID rejects. Explicit task abort includes a background task. Cancelling a
 task or idle wait does not abort work.
 
-`Conversation.watch()` atomically captures an immutable structural view and
-registers for later complete Session commits. Its `WatchHandle` uses the same
-serialized asynchronous update and reset-compaction contract as `watchDoc()` in
-section 9.2. It carries no semantic events and owns no second tracker.
-
-`close()` is equivalent to `suspend()` for v1. It seals mutation admission and
-task reservation, signals invocations, and stops watches. Outside the Session
-line it lets already-admitted storage commits settle, joins task/tool/hook
-invocations and in-flight watch callbacks, then closes sources and storage. It
-writes no task outcome. Handles belong to that open Harness and must be
-reacquired after reopen. A non-cooperative watch callback can delay graceful
-close just like a non-cooperative task invocation.
+`inspect()` returns live work at one point on the Session line, for recovery
+decisions after open, viewers, and diagnostics. It writes nothing, does not
+enable scheduling, and runs no task code. Each pending or running task carries
+its state under the current registry: `running` with an active invocation;
+`ready` when the next scheduling pass would reserve it, with `migrates` when its
+definition is newer and has `migrate`; `waiting` on unfinished dependencies; or
+`blocked` (section 5.4). A migration shows as failed only after the scheduler
+tried it, or when the newer definition has no `migrate`; inspection never runs
+one to find out. Blocked reasons are derived, never stored. Queued and placed
+submissions and the registry's wrapper failures complete the view. Finished
+tasks, settled submissions, transcripts, and documents use their own APIs.
+
+`Conversation.viewState()` returns its current structural mount as a disposable
+read-only Chord state. `Conversation.watch()` atomically captures that immutable
+revision and registers for later exact complete-commit frames. Its `WatchHandle`
+uses the same serialized asynchronous, bounded-buffer contract as `watchDoc()`
+in section 9.2. Neither carries semantic events or owns a second persistence
+authority.
+
+`close()` seals mutation admission and
+task reservation, signals invocations, and stops future watch deliveries. Outside
+the Session line it lets already-admitted storage commits settle, joins
+task/tool/hook invocations, then closes states and storage. Already-running watch
+callbacks remain caller-owned and may finish independently. Close writes no task
+outcome. Handles belong to that open Harness and must be reacquired after reopen.
 
 ## 3. Documents
 
@@ -597,12 +735,17 @@ type DocumentSemantics =
   | RewindableConversationSemantics
   | { readonly scope: "task" };
 
+type CheckpointInfo = {
+  /** Deltas already stored after the newest base, excluding this change. */
+  readonly deltasSinceBase: number;
+};
+
 type CommonDocDefinition<T extends JsonObject> = {
   readonly kind: string;
   readonly version: number;
   initial(): T;
   migrate?(value: JsonObject, fromVersion: number): T;
-  checkpointWhen?(value: Readonly<T>, ops: readonly Op[]): boolean;
+  checkpointWhen?(value: Readonly<T>, ops: readonly Op[], info: CheckpointInfo): boolean;
 };
 
 type DocDefinition<T extends JsonObject> =
@@ -734,21 +877,21 @@ A persisted document instance has one `DocumentRecord`:
 
 ```ts
 type DocumentRecord = {
-  readonly id: Id;              // unique incarnation
+  readonly id: DocumentId;      // unique incarnation
   readonly kind: string;        // stable definition kind
   readonly key?: string;        // families only
   readonly createdAt: Seq;      // stamped by the committing storage
   readonly retiredAt?: Seq;
 } & (
   | { readonly scope: { readonly kind: "session" } }
-  | ({ readonly scope: { readonly kind: "conversation"; readonly conversationId: Id } } & (
+  | ({ readonly scope: { readonly kind: "conversation"; readonly conversationId: ConversationId } } & (
       | { readonly history: "latest"; readonly fork: "current" | "initial" }
       | {
           readonly history: "rewindable";
           readonly fork: "asOf" | "current" | "initial";
         }
     ))
-  | { readonly scope: { readonly kind: "task"; readonly taskId: Id } }
+  | { readonly scope: { readonly kind: "task"; readonly taskId: TaskId } }
 );
 
 type DocumentCreate = DocumentRecord extends infer Record
@@ -779,56 +922,83 @@ There is no mutable `session.document()` API.
 interface Session extends DocumentObserver {
   commit<T>(change: (tx: Tx) => T | Promise<T>, context: Context): Promise<T>;
   close(context: Context): Promise<void>;
+  subscribeCommits(listener: (publication: CommitPublication, context: Context) => void): () => void;
+  subscribeClose(listener: () => void): () => void;
 
   snapshot<T extends JsonObject>(token: SessionDocToken<T>, context: Context): Promise<Readonly<T> | undefined>;
-  snapshot<T extends JsonObject>(token: ConversationDocToken<T>, conversationId: Id, context: Context): Promise<Readonly<T> | undefined>;
-  snapshot<T extends JsonObject>(token: TaskDocToken<T>, taskId: Id, context: Context): Promise<Readonly<T> | undefined>;
+  snapshot<T extends JsonObject>(token: ConversationDocToken<T>, conversationId: ConversationId, context: Context): Promise<Readonly<T> | undefined>;
+  snapshot<T extends JsonObject>(token: TaskDocToken<T>, taskId: TaskId, context: Context): Promise<Readonly<T> | undefined>;
   snapshot<T extends JsonObject, I extends JsonValue>(token: SessionDocFamilyToken<T, I>, key: string, context: Context): Promise<Readonly<T> | undefined>;
-  snapshot<T extends JsonObject, I extends JsonValue>(token: ConversationDocFamilyToken<T, I>, conversationId: Id, key: string, context: Context): Promise<Readonly<T> | undefined>;
-  snapshot<T extends JsonObject, I extends JsonValue>(token: TaskDocFamilyToken<T, I>, taskId: Id, key: string, context: Context): Promise<Readonly<T> | undefined>;
-
-  snapshotAsOf<T extends JsonObject>(token: RewindableConversationDocToken<T>, conversationId: Id, at: Id, context: Context): Promise<Readonly<T> | undefined>;
-  snapshotAsOf<T extends JsonObject, I extends JsonValue>(token: RewindableConversationDocFamilyToken<T, I>, conversationId: Id, key: string, at: Id, context: Context): Promise<Readonly<T> | undefined>;
-
-  documentSource<T extends JsonObject>(token: SessionDocToken<T>, context: Context): Promise<DocumentSource<T> | undefined>;
-  documentSource<T extends JsonObject>(token: ConversationDocToken<T>, conversationId: Id, context: Context): Promise<DocumentSource<T> | undefined>;
-  documentSource<T extends JsonObject>(token: TaskDocToken<T>, taskId: Id, context: Context): Promise<DocumentSource<T> | undefined>;
-  documentSource<T extends JsonObject, I extends JsonValue>(token: SessionDocFamilyToken<T, I>, key: string, context: Context): Promise<DocumentSource<T> | undefined>;
-  documentSource<T extends JsonObject, I extends JsonValue>(token: ConversationDocFamilyToken<T, I>, conversationId: Id, key: string, context: Context): Promise<DocumentSource<T> | undefined>;
-  documentSource<T extends JsonObject, I extends JsonValue>(token: TaskDocFamilyToken<T, I>, taskId: Id, key: string, context: Context): Promise<DocumentSource<T> | undefined>;
+  snapshot<T extends JsonObject, I extends JsonValue>(token: ConversationDocFamilyToken<T, I>, conversationId: ConversationId, key: string, context: Context): Promise<Readonly<T> | undefined>;
+  snapshot<T extends JsonObject, I extends JsonValue>(token: TaskDocFamilyToken<T, I>, taskId: TaskId, key: string, context: Context): Promise<Readonly<T> | undefined>;
+
+  snapshotAsOf<T extends JsonObject>(token: RewindableConversationDocToken<T>, conversationId: ConversationId, at: EntryId, context: Context): Promise<Readonly<T> | undefined>;
+  snapshotAsOf<T extends JsonObject, I extends JsonValue>(token: RewindableConversationDocFamilyToken<T, I>, conversationId: ConversationId, key: string, at: EntryId, context: Context): Promise<Readonly<T> | undefined>;
+
+  documentState<T extends JsonObject>(token: SessionDocToken<T>, context: Context): Promise<DocumentState<T> | undefined>;
+  documentState<T extends JsonObject>(token: ConversationDocToken<T>, conversationId: ConversationId, context: Context): Promise<DocumentState<T> | undefined>;
+  documentState<T extends JsonObject>(token: TaskDocToken<T>, taskId: TaskId, context: Context): Promise<DocumentState<T> | undefined>;
+  documentState<T extends JsonObject, I extends JsonValue>(token: SessionDocFamilyToken<T, I>, key: string, context: Context): Promise<DocumentState<T> | undefined>;
+  documentState<T extends JsonObject, I extends JsonValue>(token: ConversationDocFamilyToken<T, I>, conversationId: ConversationId, key: string, context: Context): Promise<DocumentState<T> | undefined>;
+  documentState<T extends JsonObject, I extends JsonValue>(token: TaskDocFamilyToken<T, I>, taskId: TaskId, key: string, context: Context): Promise<DocumentState<T> | undefined>;
 }
 
 interface Tx {
-  conversation(id: Id): Promise<ConversationRecord | undefined>;
-  entry(id: Id): Promise<EntryRecord | undefined>;
-  task(id: Id): Promise<TaskRecord<JsonValue, JsonValue, JsonValue> | undefined>;
-  scanEntries(query: EntryQuery): Promise<readonly EntryRecord[]>;
-  scanTasks(query: TaskQuery): Promise<readonly TaskRecord<JsonValue, JsonValue, JsonValue>[]>;
-
-  createConversation(value: Omit<ConversationRecord, "id">): Promise<ConversationRecord>;
-  appendEntry(conversationId: Id, value: EntryDraft): Promise<EntryRecord>;
+  conversation(id: ConversationId): Promise<ConversationRecord | undefined>;
+  entry(id: EntryId): Promise<EntryRecord | undefined>;
+  /** Undefined when the entry is absent or has another kind. */
+  entry<D extends JsonValue>(token: Entry<D>, id: EntryId): Promise<TypedEntry<D> | undefined>;
+  task(id: TaskId): Promise<TaskRecord<JsonValue, JsonValue, JsonValue> | undefined>;
+  scanConversations(query: ConversationQuery, limit: number, cursor?: Cursor): Promise<Page<ConversationRecord, Cursor>>;
+  scanEntries(query: EntryQuery, limit: number, cursor?: Cursor): Promise<Page<EntryRecord, Cursor>>;
+  scanTasks(query: TaskQuery, limit: number, cursor?: Cursor): Promise<Page<TaskRecord<JsonValue, JsonValue, JsonValue>, Cursor>>;
+
+  createConversation(options: { readonly ownership: ConversationOwnership }): Promise<ConversationRecord>;
+  forkConversation(
+    parentConversationId: ConversationId,
+    at: EntryId,
+    options: { readonly ownership: ConversationOwnership },
+  ): Promise<ConversationRecord>;
+  appendEntry(conversationId: ConversationId, value: EntryDraft): Promise<EntryRecord>;
+  /** The token supplies `kind` and types `data`. */
+  appendEntry<D extends JsonValue>(
+    token: Entry<D>, conversationId: ConversationId, value: TypedEntryDraft<D>,
+  ): Promise<TypedEntry<D>>;
   createTask<I, S extends { phase: string }, R, H extends object>(
     task: Task<I, S, R, H>, input: I, options?: TaskOptions,
-  ): Promise<TaskRef<R>>;
-  setTask(value: TaskRecord<JsonValue, JsonValue, JsonValue>): void;
+  ): Promise<TaskId<R>>;
+  /** Settle a queued or placed submission; only a placed input can be answered. A settled one stays unchanged. */
+  settleSubmission(id: SubmissionId, settlement: SubmissionSettlement): void;
 
   doc<T extends JsonObject>(token: SessionDocToken<T>): Promise<Draft<T>>;
-  doc<T extends JsonObject>(token: ConversationDocToken<T>, conversationId: Id): Promise<Draft<T>>;
-  doc<T extends JsonObject>(token: TaskDocToken<T>, taskId: Id): Promise<Draft<T>>;
+  doc<T extends JsonObject>(token: ConversationDocToken<T>, conversationId: ConversationId): Promise<Draft<T>>;
+  doc<T extends JsonObject>(token: TaskDocToken<T>, taskId: TaskId): Promise<Draft<T>>;
   doc<T extends JsonObject, I extends JsonValue>(token: SessionDocFamilyToken<T, I>, key: string, seed: I): Promise<Draft<T>>;
-  doc<T extends JsonObject, I extends JsonValue>(token: ConversationDocFamilyToken<T, I>, conversationId: Id, key: string, seed: I): Promise<Draft<T>>;
-  doc<T extends JsonObject, I extends JsonValue>(token: TaskDocFamilyToken<T, I>, taskId: Id, key: string, seed: I): Promise<Draft<T>>;
+  doc<T extends JsonObject, I extends JsonValue>(token: ConversationDocFamilyToken<T, I>, conversationId: ConversationId, key: string, seed: I): Promise<Draft<T>>;
+  doc<T extends JsonObject, I extends JsonValue>(token: TaskDocFamilyToken<T, I>, taskId: TaskId, key: string, seed: I): Promise<Draft<T>>;
 
   retireDoc<T extends JsonObject>(token: SessionDocToken<T>): Promise<void>;
-  retireDoc<T extends JsonObject>(token: ConversationDocToken<T>, conversationId: Id): Promise<void>;
-  retireDoc<T extends JsonObject>(token: TaskDocToken<T>, taskId: Id): Promise<void>;
+  retireDoc<T extends JsonObject>(token: ConversationDocToken<T>, conversationId: ConversationId): Promise<void>;
+  retireDoc<T extends JsonObject>(token: TaskDocToken<T>, taskId: TaskId): Promise<void>;
   retireDoc<T extends JsonObject, I extends JsonValue>(token: SessionDocFamilyToken<T, I>, key: string): Promise<void>;
-  retireDoc<T extends JsonObject, I extends JsonValue>(token: ConversationDocFamilyToken<T, I>, conversationId: Id, key: string): Promise<void>;
-  retireDoc<T extends JsonObject, I extends JsonValue>(token: TaskDocFamilyToken<T, I>, taskId: Id, key: string): Promise<void>;
+  retireDoc<T extends JsonObject, I extends JsonValue>(token: ConversationDocFamilyToken<T, I>, conversationId: ConversationId, key: string): Promise<void>;
+  retireDoc<T extends JsonObject, I extends JsonValue>(token: TaskDocFamilyToken<T, I>, taskId: TaskId, key: string): Promise<void>;
 }
 ```
 
-ID-creating transaction methods are asynchronous because remote storage may allocate globally unique IDs durably. Only public typed `tx.doc()` is get-or-create. Internal fork copying may create
+ID-creating transaction methods are asynchronous because remote storage may
+allocate globally unique numeric IDs durably. Conversation creation always
+requires explicit ownership; no transaction wrapper injects the executing task.
+For task ownership, the caller supplies only a typed task ID. The Session derives
+the persisted owner conversation from the task's final candidate record.
+
+An owner task may be committed or staged earlier in the same transaction. Before
+Storage admission, the Session rejects a missing, terminal, or abort-marked owner,
+including one made terminal or abort-marked later in that transaction. Existing
+owner edges remain valid when their owners terminalize afterward. Conversation
+creation returns an inert record, never an operational handle.
+`forkConversation()` additionally validates one visible entry and applies section
+3.7. Only public typed `tx.doc()` is get-or-create. Internal fork copying may create
 new incarnations directly from stored values without a definition. `tx.doc()`
 receives the definition token that supplies
 its static type, initializer, migration, and checkpoint policy. Scope-preserving
@@ -844,7 +1014,7 @@ registered and ordinary documents are not scanned at open.
 - The first acquisition of one logical address is memoized before awaiting. Later
   acquisitions in that transaction return the same draft; for a missing family,
   the first call's detached seed wins and later seeds are ignored.
-- `snapshot()`, `snapshotAsOf()`, `documentSource()`, and `watchDoc()` never create
+- `snapshot()`, `snapshotAsOf()`, `documentState()`, and `watchDoc()` never create
   or persist migration. They return `undefined` when the requested incarnation is
   absent and migrate a reconstructed value only in memory.
 - Task-scoped `tx.doc()` validates against the transaction's latest candidate task
@@ -858,9 +1028,11 @@ registered and ordinary documents are not scanned at open.
 - A terminal candidate rejects later task-document access. Terminal settlement
   retires both existing task documents and task documents created earlier in the
   same transaction.
-- `snapshot()` returns a detached JSON copy.
-- `documentSource()` returns an opaque source bound to one committed incarnation.
-- `tx.doc()` returns one revocable copy-on-write `Draft<T>` for the transaction.
+- `snapshot()` returns the current shareable immutable revision. Mutation of it
+  or any retained descendant is unsupported; callers that need mutable ownership
+  must copy it first.
+- `documentState()` returns a disposable read-only Chord state bound to one committed incarnation.
+- `tx.doc()` returns one revocable Astra overlay `Draft<T>` for the transaction.
 - Historical reads never create documents in the past.
 
 `snapshotAsOf()` is available only for rewindable conversation documents. It
@@ -877,13 +1049,15 @@ alive at the target commit.
 
 ### 3.4 Mutation ownership
 
-Pico uses Chord Delta's transaction shape directly:
+Pico uses Chord Delta's Astra-immutable transaction shape directly:
 
 ```ts
 interface Prepared<T extends object> {
   readonly base: T;
   readonly value: T;
   readonly ops: readonly Op[];
+  readonly baseRevision: number;
+  abort(): void;
 }
 interface Change<T extends object> {
   readonly state: Draft<T>;
@@ -892,64 +1066,91 @@ interface Change<T extends object> {
 }
 interface Tracker<T extends object> {
   readonly value: T;
+  readonly revision: number;
   beginChange(): Change<T>;
   prepareReplace(value: T): Prepared<T>;
   adopt(prepared: Prepared<T>): void;
 }
 ```
 
-One tracker has at most one open change. `prepare()` revokes the draft and returns
-an inert branded result without changing `tracker.value`; `abort()` is
-idempotent. `adopt()` accepts only a result from that tracker whose `base` is
-still current. `ops.length === 0` implies `value === base`. Pico's Session line
-ensures no tracker becomes stale between preparation, Storage settlement, and
-adoption.
-
-Each loaded document owns one tracker. The first `tx.doc()` acquisition calls
-`tracker.beginChange()` and memoizes that change's draft for the rest of the
-possibly async Session callback.
+Each loaded document owns one tracker whose `value` is its current immutable
+revision. Immutability is a trusted ownership contract, not runtime freezing:
+a revision and its descendants must never be mutated after transfer to the
+tracker. `prepare()` revokes the draft, emits detached self-contained
+operations, and computes `value` with the optimized immutable applier before
+Storage admission. Unchanged subtrees are structurally shared with `base`.
+Operation placement payloads may also be shared with `value`; mutating either a
+prepared operation or an immutable revision is unsupported. Astra preserves an
+empty operation batch for changes it proves are no-ops, but Pico performs no
+additional whole-value equality pass for nonempty structural batches.
+
+`abort()` is idempotent. `adopt()` accepts only a prepared result from that
+tracker at its current revision, then performs only a synchronous pointer swap
+to the already-computed immutable `value`. It performs no diffing, application,
+allocation, or callback. The Session line permits at most one open change per
+tracker and ensures no result becomes stale between preparation, Storage
+settlement, and adoption.
+
+The first `tx.doc()` acquisition calls `tracker.beginChange()` and memoizes that
+change's draft for the rest of the possibly async Session callback.
 
 Transaction behavior:
 
 ```text
 begin transaction
   acquire and memoize document changes by logical address
-  mutate revocable copy-on-write drafts
+  mutate revocable Astra overlay drafts
 callback settles
-  seal Tx and synchronously reject further draft/Tx use
+  seal Tx; synchronously prepare or abort every open change, revoking every draft
   if any acquisition is pending: abort open changes, reject, then drain and abort it
 callback fails with no pending acquisition
   abort every open change; persist and publish nothing
 callback succeeds with no pending acquisition
-  prepare every open change -> immutable candidate + frozen Chord Op[]
-  normalize deep no-ops to the previous value + []
+  prepare every open change -> immutable next revision + self-contained Chord Op[]
   Session evaluates each required/ordinary document write exactly once
+  prepare every affected loaded conversation mount revision
   Storage.commit persists the atomic batch while the Session line remains held
 storage succeeds
-  adopt every prepared change and enqueue candidate/ops publication
+  adopt every prepared change by pointer swap and enqueue immutable revision/ops publication
   release the line; invoke listeners later
 storage fails
-  poison Session and publish nothing
+  abort every prepared change, poison Session, and publish nothing
 ```
 
 A pending acquisition that resolves after sealing never exposes a draft; its
 change is aborted and its promise rejects. The Session observes every such
-settlement before releasing the line.
-
-`prepare()` performs all JSON, ownership, diff, and freezing work. Preparation or
-checkpoint failure occurs before Storage admission and rolls back normally.
-Adoption performs no diffing, allocation, or callback. The prepared candidate
-itself becomes the immutable published value; Pico does not replay its operations
-to construct another copy. An unchanged existing current-version document writes
-and publishes nothing. Creation and required version transitions still write a
-base when their prepared operation batch is empty; an equal-value version base
-does not emit a watch update.
-
-Values assigned into a draft are copied immediately by value. Repeated placements
-are independent. Chord may structurally share unchanged immutable subtrees across
-revisions. Operation tuples, paths, splice payload arrays, permutations, and the
-outer batch are frozen before checkpoint code, Storage, or listeners can observe
-them.
+settlement before releasing the line. Initializer, migration, and replacement
+roots come from caller code: the Session copies each one into exclusive kernel
+ownership, rejecting any value that is not strict JSON, before it becomes an
+immutable tracker revision. Loaded and fork-copy roots are already detached
+strict JSON from Storage and enter the tracker without another copy. Chord's
+`track()` and `prepareReplace()` take ownership in O(1) without traversal, so
+every root they receive must come from one of these sources. Migration callbacks
+never receive a live tracker revision.
+
+Preparation, validation, checkpoint, or mounted-view preparation failure occurs
+before Storage admission and rolls back normally. The Session performs no
+strict-JSON walk of prepared operations or selected bases: roots are checked on
+entry and Chord checks every draft placement, so every revision, operation
+payload, and base is strict JSON by construction. Tracker branding and `baseRevision` enforce ownership and staleness; the
+Session never substitutes caller-created prepared values. The prepared immutable
+candidate itself becomes the adopted and published value. Storage receives that complete value only when the
+Session selects a base; otherwise it receives only the prepared operation batch.
+An existing current-version document with an empty batch writes and publishes
+nothing. A nonempty structural batch whose final value is deeply equal to its
+base remains a valid durable change and publication. Creation and required
+version transitions still write a base when their prepared batch is empty; an
+equal-value version base does not emit a watch update.
+
+Values assigned into a draft are copied immediately by value. Repeated
+placements are independent. Chord checks each placement while copying it and
+throws at the offending assignment, before the draft changes, when the value is
+not strict JSON: `undefined` array elements or nested object values, non-finite
+numbers, functions, symbols, bigints, accessors, symbol keys, sparse arrays, or
+objects whose prototype is neither `Object.prototype` nor `null`. Assigning
+`undefined` directly to an object property deletes that property. Draft reads, draft writes, and all `Tx` operations
+reject after the callback settles. The prepared immutable value remains readable
+by Session-owned checkpoint and Storage preparation.
 
 ```ts
 let escaped: Draft<LiveState>;
@@ -960,8 +1161,7 @@ escaped.message = message; // throws: the draft was revoked
 ```
 
 Fire-and-forget work that mutates a draft before the owner callback settles may
-silently enter that transaction and is unsupported. After settlement, draft and
-`Tx` operations reject.
+silently enter that transaction and is unsupported.
 
 ### 3.5 Bases and checkpoints
 
@@ -971,10 +1171,14 @@ For an ordinary later mutation, the definition alone decides whether the
 storage record is a base:
 
 ```ts
-const useBase = definition.checkpointWhen?.(candidateValue, ops) ?? false;
+const useBase = definition.checkpointWhen?.(candidateValue, ops, { deltasSinceBase }) ?? false;
 ```
 
 The Session evaluates this predicate exactly once after tracker preparation.
+`deltasSinceBase` counts the deltas already stored after the incarnation's newest
+base, excluding the change being evaluated. Storage reports it when it
+materializes the current value; the Session advances it after each adopted write
+and resets it after every base, so evaluation performs no Storage read.
 Creation and version transitions require bases and do not call it. The Session
 then gives Storage only the selected representation:
 
@@ -997,6 +1201,12 @@ code and never receives an unused complete candidate with a selected delta.
 - Storage does not count encoded bytes, compare against `initial()`, or invent
   checkpoints.
 
+A definition can bound replay directly:
+
+```ts
+checkpointWhen: (_value, _ops, info) => info.deltasSinceBase >= 31
+```
+
 A high-churn live document can checkpoint when it becomes empty:
 
 ```ts
@@ -1017,11 +1227,17 @@ no migrate      -> reject older stored version
 ```
 
 `migrate()` is pure and returns a complete current-version value. Migration is
-access-driven: `tx.doc()`, `snapshot()`, `snapshotAsOf()`, `documentSource()`, and
+access-driven: `tx.doc()`, `snapshot()`, `snapshotAsOf()`, `documentState()`, and
 `watchDoc()` reconstruct and migrate through the token supplied to that call.
 Harness open does not sweep ordinary documents.
 
-- Read-only access migrates only its returned in-memory value and never writes.
+- Read-only access migrates only in memory and never writes. It may cache a
+  tracker over that migrated immutable revision together with the older stored
+  version marker; the next successful `tx.doc()` access still writes the required
+  current-version base. A cached tracker serves only tokens of the version its value was
+  materialized for. Access with any other version, such as a token from reloaded
+  extension code, drops it and reloads the stored value, so each token migrates
+  from the stored version or rejects a newer one. Migration always starts from a detached stored value.
   `tx.doc()` stages migration in its enclosing transaction; callback failure
   persists nothing, and later draft edits coalesce into one final required base.
 - Rewindable history is not rewritten. Current and historical reconstructed
@@ -1048,7 +1264,7 @@ Each conversation document follows the history/fork policy persisted in its
 | conversation setting | child value |
 |---|---|
 | `fork: "asOf"` | parent value at `E`'s commit |
-| `fork: "current"` | parent value when the fork commit runs |
+| `fork: "current"` | committed parent value selected when the fork commit runs |
 | `fork: "initial"` | no copied instance; initializer on first child access |
 
 `current` and `asOf` copy logically present conversation singleton and family
@@ -1058,21 +1274,54 @@ values become independent child instances with new IDs and initial bases.
 supplied definition. Task documents and tasks are never copied. Session documents
 remain shared and are not rewindable.
 
+Fork copying reads committed stored values rather than typed tracker caches. A
+transaction that creates a fork therefore rejects if it also writes one of the
+parent's `fork: "current"` documents; commit the parent change first so the fork
+has one unambiguous stored source revision.
+
+Forks stage backend-side `document.copy` commands carrying the child create
+record and an exact source incarnation/point. Storage materializes each source
+and persists its stored value/version as the child's independent initial base;
+remote Storage performs this server-side. Every copy reads committed pre-batch
+source state independent of write-array order. A selected source may not be
+created, changed, or retired in the same batch. Copying remains atomic with the
+conversation, overrides, registry writes, and other mutations.
+
+An unaccessed copy retains only its descriptor in Session memory. Typed access
+inside the creating transaction lazily reads the detached source, migrates when
+required, and replaces the copy with one ordinary child create containing the
+final prepared value. Definition-free copies publish explicit `document.copy`
+metadata rather than a value. That metadata announces Storage-backed initial
+state and is never interpreted as a document value. Document states, watches,
+and mounted views hydrate by capturing their baseline and subscription
+atomically on the Session line: a later commit already present becomes the
+baseline, while one committed after registration is delivered. Publications
+and watches are convergence mechanisms, not audit streams. A mounted aggregate
+must acquire all of its document baselines and commit subscription in one
+Session-line operation so it never exposes a mixture from one commit.
+
 ## 4. Transactions and storage ownership
 
 A Session commit callback may be asynchronous. It owns the Session mutation
 line through callback execution, preparation, storage settlement, committed
-baseline adoption, and publication enqueue. Listener callbacks run later.
+baseline adoption, and publication enqueue. Commit observers run on the
+line; document-state and watch user callbacks run later.
 External model, process, tool, network, and human effects run outside it.
+`subscribeCommits()` observes complete immutable publications synchronously on
+the line after adoption. `subscribeClose()` observes close synchronously when it
+begins, after admission is sealed; the Harness stops watches and signals task
+invocations there. Both return idempotent disposers; their listeners must not
+throw, block, or call Session APIs. Document-state subscribers and watch
+listeners still run later, off the line.
 
 ```ts
 await session.commit(async tx => {
-  const task = await tx.task(taskId);                // table read
+  const conversation = await tx.conversation(conversationId); // table read
   const live = await tx.doc(LiveDoc, conversationId);
 
   await tx.appendEntry(conversationId, message);     // first table write
   delete live.message;                               // document mutation remains valid
-  tx.setTask(nextTask(task));
+  await tx.createTask(Follow, { after: message.id }); // further table writes are fine
 }, context);
 ```
 
@@ -1116,12 +1365,12 @@ type TaskState<S, R> =
   | { readonly status: "terminal"; readonly outcome: TaskOutcome<R> };
 
 type TaskRecord<I, S, R> = {
-  readonly id: Id;
-  readonly conversationId: Id;
+  readonly id: TaskId<R>;
+  readonly conversationId: ConversationId;
   readonly kind: string;
   readonly version: number;
   readonly input: I;
-  readonly after: readonly Id[];
+  readonly after: readonly TaskId[];
   readonly background: boolean;
   readonly abortRequested: boolean;
 } & (
@@ -1139,6 +1388,9 @@ type RunningTask<I, S, R> = TaskRecord<I, S, R> & {
   readonly state: Extract<TaskState<S, R>, { status: "running" }>;
 };
 
+/** State a task commits for itself: a replacement checkpoint or its terminal outcome. */
+type NextTaskState<S, R> = Extract<TaskState<S, R>, { status: "running" | "terminal" }>;
+
 interface HookRunner<H extends object> {
   each<K extends keyof H>(name: K, invoke: (handler: H[K]) => void | Promise<void>): Promise<void>;
 }
@@ -1149,19 +1401,32 @@ type PhaseHandler<I, P, S, R, H extends object> = (
   context: Context,
 ) => Promise<void>;
 
-interface TaskRuntime<I, S, R, H extends object> extends DocumentObserver {
-  readonly taskId: Id;
-  readonly conversationId: Id;
+interface TaskRuntime<I, S, R, H extends object> extends DocumentObserver, DocumentReader {
+  readonly taskId: TaskId<R>;
+  readonly conversationId: ConversationId;
   readonly signal: AbortSignal;
+  /** Registry snapshot of the current phase; refreshed at every phase boundary. */
+  readonly registry: RegistrySnapshot<ToolRegistration>;
+  readonly models: Models;
   readonly hooks: HookRunner<H>;
 
   commit(
-    change: (tx: Tx, current: RunningTask<I, S, R>) => void | Promise<void>,
+    change: (
+      tx: Tx,
+      current: RunningTask<I, S, R>,
+    ) => NextTaskState<S, R> | undefined | Promise<NextTaskState<S, R> | undefined>,
     context: Context,
   ): Promise<void>;
 
   memo<T extends JsonValue>(name: string, context: Context): Promise<T | undefined>;
   memo<T extends JsonValue>(name: string, candidate: T, context: Context): Promise<T>;
+  conversation(id: ConversationId, context: Context): Promise<ConversationHandle | undefined>;
+  /** Committed raw active transcript and model context, optionally cut off at `at`. */
+  context(conversationId: ConversationId, context: Context, at?: EntryId): Promise<ContextView>;
+  /** The Harness clock. */
+  now(): number;
+  /** Forward a non-fatal failure to `HarnessOptions.onReport`. */
+  report(error: unknown): void;
   sleep(until: number, context: Context): Promise<void>;
 }
 
@@ -1172,7 +1437,7 @@ type TaskDefinition<I, S extends { phase: string }, R, H extends object> = {
   readonly phases: {
     [P in S["phase"]]: PhaseHandler<I, Extract<S, { phase: P }>, S, R, H>;
   };
-  abort(task: TaskRecord<I, S, R>, runtime: TaskRuntime<I, S, R, H>, context: Context): Promise<void>;
+  abort(task: RunningTask<I, S, R>, runtime: TaskRuntime<I, S, R, H>, context: Context): Promise<void>;
   migrate?(input: JsonValue, checkpoint: JsonValue, fromVersion: number): {
     input: I;
     checkpoint: S;
@@ -1184,11 +1449,9 @@ interface Task<I, S extends { phase: string }, R, H extends object> {
   readonly definition: TaskDefinition<I, S, R, H>;
 }
 
-declare const taskResultType: unique symbol;
-type TaskRef<R> = { readonly id: Id; readonly [taskResultType]?: R };
 type TaskOptions = {
-  readonly conversationId?: Id;
-  readonly after?: readonly Id[];
+  readonly conversationId?: ConversationId;
+  readonly after?: readonly TaskId[];
   readonly background?: boolean;
 };
 
@@ -1197,34 +1460,98 @@ function defineTask<I, S extends { phase: string }, R, H extends object = {}>(
 ): Task<I, S, R, H>;
 ```
 
+`TaskId<R>` is the numeric task ID itself with an erased result-type brand. It
+replaces a separate task-reference wrapper: `createTask()` returns `TaskId<R>`,
+typed waits infer `R` from that ID, and result-agnostic operations accept
+`TaskId<unknown>`. A task's `conversationId` is immutable after creation; a
+replacement that moves an existing task to another conversation rejects before
+Storage admission so persisted conversation-owner edges cannot become stale.
+
 The phase map is exhaustive and phase-narrowed. A handler may perform several
 commits around one effect, but each durable checkpoint is a full replacement.
 `TaskRuntime.commit()` rereads and gates the current durable task on the Session
-line before invoking its callback. Transaction methods replace its checkpoint
-or write its terminal outcome.
+line before invoking its callback. It rejects when the invocation has ended, the
+Harness is closing, the task is terminal, or a run invocation's task carries an
+abort mark. Its `tx.createTask()` defaults to the task's conversation, and every
+entry it appends records the task as `byTaskId`. When the
+callback returns a state, the runtime replaces the task's state in the same
+commit, so the checkpoint or outcome is atomic with the callback's entries,
+documents, and child tasks and is type-checked against the task's checkpoint and
+result types. Returning nothing leaves the state unchanged. A terminal state
+drops the memos. `pending` is never returned; only reconciliation and handover
+write it.
+
+`Tx` has no task replacement operation. A task changes only its own state,
+through its runtime. The scheduler owns reservation, reconciliation, handover,
+faults, and orphaning; `abortTask()` owns abort marks. Other code
+stops a task with `abortTask()` and reads its result with `waitForTask()`.
+
+```ts
+// Intent, effect, outcome.
+prepare: async (task, runtime, context) => {
+  await runtime.commit(() => ({ status: "running", checkpoint: { phase: "charge", key: newKey() } }), context);
+},
+charge: async (task, runtime, context) => {
+  const receipt = await payments.charge(task.state.checkpoint.key); // idempotent by key
+  await runtime.commit(async (tx, current) => {
+    const entry = await tx.appendEntry(current.conversationId, receiptEntry(receipt));
+    return { status: "terminal", outcome: { status: "completed", result: { entryId: entry.id } } };
+  }, context);
+},
+// The abort handler decides the outcome; returning without one faults the task.
+abort: async (task, runtime, context) => {
+  await payments.cancel(task.state.checkpoint);
+  await runtime.commit(() => ({ status: "terminal", outcome: { status: "aborted", reason: "user" } }), context);
+},
+```
+`memo(name, candidate)` is one gated commit; `memo(name)` reads the committed
+record. `sleep(until)` compares against the Harness `now` clock and rejects when
+the invocation is signalled or its context is cancelled. Watches acquired through
+the runtime stop when the invocation ends. `snapshot()`/`snapshotAsOf()` read
+committed documents, for example to supply `PromptInput.read` (section 7.4).
+`context()` captures its bounds on the Session line and derives the view from
+immutable entries off the line, like `Conversation.context()`. Like every runtime
+operation, these reject after the invocation ends.
 
 Reservation durably changes `pending` to `running`. One invocation runs phase
-handlers in sequence; checkpoint commits retain `running`. After a handler
-settles, the scheduler rereads the task and applies the first matching rule:
+handlers in sequence; checkpoint commits retain `running`. Before every phase,
+including the first, the scheduler runs one step callback on the Session line.
+It reads the committed task and synchronously applies the first matching rule
+below to the phase that just returned. It writes any fault or handover in the
+same commit, together with the Harness cleanup for a scheduler-written outcome
+(section 5.4), which may await document access inside that callback. It ends
+the invocation there when a rule stops it. A runtime commit the
+invocation queued earlier therefore either lands before the step and counts, or
+reaches the line after it and rejects. Before the first phase only rules 1–3
+apply:
 
 1. Terminal: stop.
 2. Session closing: stop; preserve the checkpoint and any abort mark for reopen.
 3. Run mode with a durable abort mark: end and join the run invocation, then
    dispatch a fresh abort invocation.
 4. Uncaught error: write terminal `faulted`.
-5. Checkpoint changed, including progress within the same phase: invoke its
-   phase handler in the same task invocation.
+5. Checkpoint changed, including progress within the same phase: refresh the
+   registry snapshot and either hand over (section 5.4) or invoke the phase
+   handler in the same task invocation.
 6. Checkpoint unchanged: write terminal `faulted` because no durable progress
    was made.
 
+An abort invocation runs its abort handler once. After it settles, a step
+applies rules 1, 2, and 4; a handler that returns without a terminal outcome
+faults the task. When Storage rejects a step's fault or handover write, the
+invocation still ends; the task stays `running` and the next reservation runs it
+again.
+
 On open, running-task reconciliation changes surviving `running` tasks back to
-`pending`, preserving their checkpoint and abort mark. Task migration then runs
-before dispatch. One callback handles every supported older version; newer or
-unmigratable live tasks become orphaned.
+`pending`, preserving their checkpoint and abort mark. Task migration runs at
+reservation, atomically with `pending -> running`. One callback handles every
+supported older version. A task whose definition is missing, older than the
+stored version, or fails migration stays `pending` and blocked until a fitting
+definition is registered or the task is aborted (section 5.4).
 `close()` marks the runtime closing, seals admission and reservation, signals
 invocations, and stops watches. Outside the Session line it settles admitted
-commits and joins invocations plus in-flight watch callbacks before closing
-storage. Later runtime commits reject, and close writes no task outcome. Closing
+commits and joins invocations before closing storage. Already-running watch callbacks remain
+caller-owned. Later runtime commits reject, and close writes no task outcome. Closing
 starts no fresh phase or abort invocation. It does not set abort marks,
 terminalize tasks, retire task documents, or publish document retirement. The
 hosting layer withdraws services and
@@ -1268,7 +1595,8 @@ A terminal transition atomically:
 The execution checkpoint and memos disappear from the terminal representation.
 Terminal records remain queryable for dependencies, waiters, inspection, and
 reopen. A normal run becomes eligible when every `after` task is terminal. An abort
-mark bypasses dependencies so pending work can always reach its abort handler.
+mark bypasses dependencies so pending work can always reach its abort handler,
+or its `orphaned` settlement when its definition is unavailable.
 
 ### 5.4 Scheduler, abort, and ownership
 
@@ -1293,50 +1621,132 @@ the durable mark on reopen. Cancelling one caller's `Context` only cancels
 that call or wait; it does not durably abort shared work unless the invoked API
 commits an abort mark.
 
-A task may create owned conversations. Abort and idle operations traverse the
-conversation ownership tree. History parents are irrelevant to this traversal.
-Background tasks do not block ordinary idle waits and survive ordinary
-conversation abort unless explicitly included.
-
-Initial task definitions are registered before open performs live-task migration
-and orphan reconciliation. Dynamic registration begins only after that pass.
-Document migration remains access-driven. Unknown or unmigratable live task kinds
-become terminal `orphaned`;
-affected input submissions become unanswered, any matching active turn control is cleared,
-task-scoped documents retire, and a visible notice entry is appended in one
-commit. Faulting a turn task performs the same control/submission cleanup with a
+A task may create owned conversations. Conversations are durable scopes; tasks
+are the units of live work counted by idle and marked by abort. History parents
+are irrelevant to ownership traversal.
+
+Ordinary traversal starts at an explicitly addressed conversation, visits its
+tasks, and follows conversations owned by each non-background task. It follows
+owner edges after the owner becomes terminal, but a background owner is a
+boundary: ordinary traversal skips that task and its complete owned subtree.
+Direct conversation operations start inside that conversation regardless of its
+owner. Directly aborting a live background task includes that task and follows
+its ordinary owned subtree; nested background owners remain boundaries. Full
+teardown crosses every boundary, marks every live task, and must seal new
+admission while it gathers the complete indexed ownership subtree.
+
+`Conversation.abort()` withdraws queued inputs and marks live non-background
+tasks selected by ordinary traversal. `Conversation.waitForIdle()` waits until
+that traversal contains no live non-background task. Harness idle performs the
+same traversal from every ownerless conversation root rather than globally
+counting tasks, so ordinary work below a background owner does not block it.
+Explicit `waitForTask()` waits for its referenced task regardless of the task's
+background flag.
+
+An abort mark atomically and idempotently cascades to foreground-owned work,
+including conversations, tasks, and submissions staged in the same transaction.
+Terminal outcomes `failed`, `faulted`, `orphaned`, and `aborted` record the same
+durable cancellation intent; `completed` does not. Conversation records and
+owner edges are never retired with the task. Active invocations are signalled
+after commit, and a terminal receipt guarantees durable cancellation intent,
+not descendant quiescence.
+
+Every run invocation start resolves the task's definition by `TaskRecord.kind`
+from the scheduler's current registry snapshot:
+
+```text
+definition missing                 -> stay pending, blocked: missing_task
+stored version newer than it       -> stay pending, blocked: task_too_old
+stored version older than it       -> migrate(input, checkpoint, storedVersion)
+  failure                           -> stay pending, blocked: migration_failed
+  success                           -> commit migrated record + running atomically
+equal version                       -> commit running
+```
+
+An abort invocation resolves the definition the same way. When the definition
+can take the task, its abort handler runs; otherwise the task is orphaned as
+described below.
+
+A failed migration is reported once through `onReport` and retried only after
+the registry resolves a different definition object for the task's kind.
+
+The Harness never terminalizes a task merely because registry code is missing or
+incompatible, neither at open nor later. A blocked task without an abort mark
+keeps its durable record unchanged, remains live, still blocks ordinary idle
+waits, and is reconsidered whenever the registry changes. The blocked reason is derived
+runtime state, not a persisted task status. Document migration remains
+access-driven.
+
+Aborting a blocked task cannot run its abort handler, because that code is
+missing or cannot take the task. The Harness therefore settles it as terminal
+`orphaned` instead of `aborted`: `aborted` means the task's own abort handler
+ran and decided the outcome, while `orphaned` means no task code ran, so external
+effects the task started may remain uncleaned. The orphaned `reason` is the
+blocked reason (`missing_task`, `task_too_old`, or `migration_failed`). When
+`abortTask()` finds no active invocation and the current snapshot
+cannot take the task, the marking commit settles it directly; otherwise the
+scheduler settles it when it would reserve the abort invocation. Only an abort (direct, by
+conversation, or by cascade) orphans a task; a missing definition alone never
+does. The orphaning commit performs the cleanup the task's code cannot: affected
+input submissions become unanswered with the reason, any matching active run
+control is cleared, and task-scoped documents retire. No transcript entry is
+written; the terminal task record and unanswered submissions carry the reason.
+Faulting a run task performs the same control/submission cleanup with a
 `faulted` outcome.
 
+The scheduler knows nothing about runs or task kinds. The Harness, which owns
+submissions, run control, and the built-in tasks, gives it one hook that the
+scheduler calls in the same commit for every terminal outcome it writes itself
+(`faulted` and `orphaned`). The hook ignores tasks whose kind is not a built-in
+run kind, so it never creates `pi.live` elsewhere. It settles the run when
+`pi.live.run` names the task (section 8): its inputs become `unanswered` with reason `faulted`
+(detail: the error message) or the blocked reason, and `run` and `generation`
+are removed. Outcomes a task commits for itself do their own settlement.
+
+At every normal phase boundary (section 5.1, rule 5), the step refreshes the
+invocation's registry snapshot. If the task definition resolved by name is a different object
+than the one the invocation started with and the new definition can reserve the
+task (same version, or a higher version with `migrate`), the invocation hands
+over: the step commits the task back to `pending` with its checkpoint, memos,
+and abort mark and ends the invocation, and the next reservation starts a fresh invocation under the new
+definition, applying the reservation rules above. When the definition is missing
+or cannot reserve the task, the invocation keeps running under its old
+definition, reports once through `onReport` per resolved definition, and
+reconsiders at its next boundary. A handler that
+never settles never hands over.
+
 ## 6. Submissions and inbox
 
-Submission records back awaitable host objects. Their record transitions use
-Session-private transaction operations, not the public `Tx` interface. The inbox
+Submission records back awaitable host objects. Admission is Harness-internal;
+run tasks settle the inputs they answer with `tx.settleSubmission()`. The inbox
 itself is an ordered conversation document containing tagged items:
 
 ```ts
 type InboxItem =
-  | { readonly id: Id; readonly mode: "steer" | "followUp"; readonly message: Message }
-  | { readonly id: Id; readonly mode: "write"; readonly entry: EntryDraft };
+  | { readonly id: SubmissionId; readonly mode: "steer" | "followUp"; readonly message: Message }
+  | { readonly id: SubmissionId; readonly mode: "write"; readonly entry: EntryDraft };
 ```
 
-A built-in turn-control document has an optional `active` value naming the task
-currently responsible for the turn and its placed input-submission IDs. `active !==
-undefined` defines `busy`; get-or-create of the idle document does not. The
-value remains active while generation, tools, and post-tools hand work to one
-another.
+Run control lives in the built-in live document `pi.live` (section 8). Its
+optional `run` value names the task currently responsible for the run and its
+placed input-submission IDs. `run !== undefined` defines `busy`; get-or-create
+of the idle document does not. The value remains while generation, tools, and
+post-tools hand work to one another. The ID list is mutable state because a
+boundary adds placed steering inputs to an active run; every terminal path
+settles exactly the listed inputs.
 
 Admission and terminal transitions:
 
 | action | submission state | other writes |
 |---|---|---|
-| idle input submission | `placed`, with user entry | create turn controller/generation |
+| idle input submission | `placed`, with user entry | create run controller/generation |
 | busy input submission | `queued` | append steer/follow-up inbox item |
-| idle write submission | `done`, with entry | append entry; no turn |
+| idle write submission | `done`, with entry | append entry; no run |
 | busy write submission | `queued` | append write inbox item |
-| boundary places user item | `placed`, with entry | add ID to current/successor turn |
+| boundary places user item | `placed`, with entry | add ID to current/successor run |
 | boundary places write | `done`, with entry | append entry |
-| turn answers | input `done`, with required answer entry | clear/hand off turn controller |
-| turn fails or aborts | input `unanswered`, with reason | clear/hand off turn controller |
+| run answers | input `done`, with required answer entry | clear/hand off run controller |
+| run fails or aborts | input `unanswered`, with reason | clear/hand off run controller |
 | withdraw queued item | `unanswered`, reason `aborted` | remove inbox item |
 | stale item | `unanswered`, reason `stale` | remove inbox item |
 
@@ -1357,33 +1767,233 @@ Boundary selection is deterministic by item ID:
 | `final` | all | first/all by mode | first/all by mode |
 
 A queued self-head write cuts older pending user items: those submissions become
-stale, the write is placed, and the current turn terminates. Other head writes
+stale, the write is placed, and the current run terminates. Other head writes
 whose target predates the caller's newest known head are stale.
 
 At ordinary `postTools`, generation continues even with no queued trigger;
 selected steer IDs join that continuation. A terminating/handoff post-tools
-boundary uses final behavior instead. At `final`, the current turn's placed
+boundary uses final behavior instead. At `final`, the current run's placed
 input submissions settle first; selected user IDs start one successor generation. Writes
 never trigger generation by themselves. A final boundary without continuation
 or user triggers leaves the conversation idle.
 
 Selected and stale items are removed positionally while retained item order is
-preserved. Chord's revision differ must express scattered removals without
-carrying retained values; IDs are not substituted for positional inbox
+preserved. Chord's Astra operation generator must express scattered removals
+without carrying retained values; IDs are not substituted for positional inbox
 semantics.
 
-## 7. Hooks, tools, and system sections
+## 7. Registry, hooks, tools, and system prompt
+
+### 7.1 Registry
+
+Extension code reaches the Harness through one application-owned registry. The
+registry is process-local, may outlive a Harness, and is the only place tools,
+tool wrappers, hooks, tasks, and the system prompt are registered. Nothing
+in it is persisted; durable state stays in conversations, entries, tasks, and
+documents.
+
+```ts
+type DocumentReader = Pick<Session, "snapshot" | "snapshotAsOf">;
+
+interface Registration {
+  /** Idempotent; removes exactly the registrations this token covers. */
+  dispose(): void;
+}
+
+type ToolWrapper<Tool extends ToolRegistration> = (tool: Tool) => Tool;
+
+type HookScope = {
+  readonly conversationId: ConversationId;
+  /** Also match conversations owned, transitively, by tasks of this conversation. */
+  readonly subtree?: boolean;
+};
+
+type PromptInput<Tool extends ToolRegistration> = {
+  readonly conversationId: ConversationId;
+  /** Active and registered tools in configured order, as offered in this request. */
+  readonly tools: readonly Tool[];
+  /** Sections already in effect after replaying the active transcript. */
+  readonly shown: Readonly<Record<string, string>>;
+  readonly model?: ModelRef;
+  readonly thinkingLevel: ModelThinkingLevel;
+  /** Committed document reads. */
+  readonly read: DocumentReader;
+};
+
+type PromptSection<Tool extends ToolRegistration> = {
+  readonly key: string;
+  render(
+    input: PromptInput<Tool>,
+    context: Context,
+  ): string | undefined | Promise<string | undefined>;
+  /** Default true: wrap the text as `<key>\n...\n</key>`. */
+  readonly tag?: boolean;
+};
 
-### 7.1 Hooks
+type PromptSectionWrapper<Tool extends ToolRegistration> = (
+  section: PromptSection<Tool>,
+) => PromptSection<Tool>;
+
+/**
+ * Stages the documents every new conversation gets, inside the creating commit, after fork copies and before host
+ * `init`. Table reads throw; a fork (`conversation.parent`) already holds its copied documents. A throw fails the
+ * creation.
+ */
+type ConversationSetup = (
+  tx: Tx,
+  conversation: ConversationRecord,
+  registry: RegistrySnapshot<ToolRegistration>,
+) => void | Promise<void>;
+
+type RegistryFailure = {
+  readonly kind: "tool" | "section";
+  /** Tool name or section key. */
+  readonly name: string;
+  readonly error: unknown;
+};
+
+interface RegistryReader<Tool extends ToolRegistration = ToolRegistration> {
+  /** Immutable view of the whole current registry. */
+  snapshot(): RegistrySnapshot<Tool>;
+  /** Called synchronously after every publication; wakes the scheduler to reconsider blocked tasks. */
+  subscribe(listener: () => void): () => void;
+}
+
+interface RegistrySnapshot<Tool extends ToolRegistration> {
+  /** Composed tools in registry order; a tool whose wrapper failed is absent. */
+  tools(): readonly Tool[];
+  tool(name: string): Tool | undefined;
+  /** Base tool names in registry order, including tools whose wrappers fail. */
+  toolNames(): readonly string[];
+  task(name: string): AnyTask | undefined;
+  /** Hooks registered for tasks with `task`'s name, in registry order. */
+  hooks<K extends AnyTask>(task: K): readonly {
+    readonly handlers: Partial<HooksOf<K>>;
+    readonly scope?: HookScope;
+  }[];
+  /** Composed sections in registry order; a section whose wrapper failed is absent. */
+  sections(): readonly PromptSection<Tool>[];
+  /** Wrapper failures of this state; the Harness reports them where it uses them. */
+  failures(): readonly RegistryFailure[];
+  /** Conversation setups in registry order, the built-in `pi` setup first. */
+  conversationSetups(): readonly { readonly key: string; readonly setup: ConversationSetup }[];
+}
+
+interface Registry<Tool extends ToolRegistration = ToolRegistration> extends RegistryReader<Tool> {
+  readonly tools: {
+    add(tool: Tool): Registration;
+    wrap(name: string, key: string, wrapper: ToolWrapper<Tool>): Registration;
+    list(): readonly Tool[];
+  };
+  readonly hooks: {
+    add<K extends AnyTask>(
+      task: K,
+      handlers: Partial<HooksOf<K>>,
+      options?: { readonly scope?: HookScope; readonly key?: string },
+    ): Registration;
+  };
+  readonly tasks: {
+    add(task: AnyTask): Registration;
+    list(): readonly AnyTask[];
+  };
+  readonly conversations: {
+    setup(key: string, setup: ConversationSetup): Registration;
+  };
+  readonly systemPrompt: {
+    section(
+      key: string,
+      render: PromptSection<Tool>["render"],
+      options?: { readonly tag?: boolean },
+    ): Registration;
+    wrap(key: string, wrapperKey: string, wrapper: PromptSectionWrapper<Tool>): Registration;
+    sections(): readonly PromptSection<Tool>[];
+  };
+  batch(register: () => void): Registration;
+}
+
+function createRegistry<Tool extends ToolRegistration = ToolRegistration>(): Registry<Tool>;
+```
+
+The `Tool` parameter lets applications attach metadata such as prompt snippets to
+their tools; the Harness only relies on `ToolRegistration`. Pi-ai declarations
+derived from a registered tool keep only pi-ai `Tool` fields (`toToolDeclaration`),
+so application metadata never enters the transcript.
+
+Registration rules:
+
+- `createRegistry()` starts with the built-in task definitions of section 8 and
+  the built-in `pi` conversation setup registered first. They have no
+  `Registration`, so they cannot be disposed, and the duplicate rule rejects
+  another task with a built-in name or another `pi` setup. `tasks.list()`
+  includes them. Hooks register against built-in tasks like any other task.
+  Setup keys are unique and ordered like section keys.
+- Tool names, section keys, and task names are unique among published
+  registrations. Tool wrapper keys are unique per tool name, section wrapper
+  keys per section key, and hook keys per task name. Duplicates reject.
+  Section keys match `^[a-z][a-z0-9_-]*$`.
+- Keyed slots are ordered by the position at which their key was first
+  registered. The registry remembers that position forever, so re-registering an
+  existing key, as a reload does, keeps its position; a new key appends. Hooks
+  without a key append.
+- Registered objects are immutable and wrappers are pure: a wrapper returns a
+  new object and never mutates its input.
+- Every call outside `batch()` publishes immediately. Publication is synchronous,
+  invokes no extension callback, and notifies subscribers.
+
+`batch(register)` stages every registration and disposal made while `register`
+runs and publishes once when it returns. It validates only the final staged
+state, so order inside the block does not matter: disposing an old tool and
+adding its replacement is a gapless reload. If `register` throws, returns a
+thenable, or the final state is invalid, nothing is published, staged disposals
+are rolled back, and `batch()` throws. Only registrations made synchronously
+inside `register` belong to the batch; a registration made later by a detached
+continuation is an ordinary immediate registration. Calling `batch()` inside a
+batch is a programming error and throws. The returned `Registration` covers every
+registration added in the batch that was not disposed inside it.
+
+A snapshot is a plain immutable value; nothing is released. The scheduler takes
+one per phase-handler invocation and passes it through the runtime; handlers and
+hooks read that snapshot and never take their own. At every normal phase boundary
+the scheduler takes a fresh one (section 5.4). A tool task keeps the composed tool
+it pinned until execution settles. Different phases may observe different
+registry states; nothing requires one run to see a single registry state across
+its generation, tool, and post-tools tasks. Host operations, such as the create
+conveniences, take one snapshot inside their commit.
+
+```ts
+// ToolTask is the built-in tool task's token; its hooks are listed in section 7.2.
+const registration = registry.batch(() => {
+  registry.tools.add(grep);
+  registry.hooks.add(ToolTask, { beforeTool: audit }, { key: "audit" });
+});
+// later, reload: publish the replacement at once
+registry.batch(() => {
+  registration.dispose();
+  registry.tools.add(grepV2);
+  registry.hooks.add(ToolTask, { beforeTool: audit2 }, { key: "audit" });
+});
+```
+
+The registry does not track which running work still uses a disposed
+registration. Work that already started keeps using the code it took, so an
+extension that frees resources right after `dispose()` can make a still-running
+call fail with an ordinary error result. Extensions that need graceful disposal
+manage their resources' lifetime themselves, for example by reference counting.
+
+### 7.2 Hooks
 
 A hook is a typed question asked by a task before it commits a decision. Hooks
-are declared by task kind and registered in registration order Session-wide or
-for a conversation and its owned subtree. They run off the line; a crash before
-the consuming commit may rerun them. Abort errors always propagate.
+are declared by task definition and registered through `registry.hooks.add()`
+Session-wide or, with `scope`, for one conversation and optionally its owned
+subtree. Subtree matching follows conversation ownership, not history parents.
+Registration is typed by the task token, but dispatch matches the task's name,
+so hooks survive a reload of their task; keeping hook signatures compatible
+across task versions is the task author's responsibility. Hooks run in registry
+order off the line; a crash before the consuming commit may rerun them. Abort
+errors always propagate.
 
 | hook | composition | ordinary throw |
 |---|---|---|
-| system instructions | all; draft changes compose; last tool override wins | roll back that handler, report, continue |
 | `beforeRequest` | replacement chain | report, continue |
 | `afterResponse` | all observers | report, continue |
 | `onYield` | first continuation wins | report, continue |
@@ -1395,7 +2005,7 @@ the consuming commit may rerun them. Abort errors always propagate.
 Hooks use task memos for durable first-writer-wins decisions. There is no public
 semantic event channel; current UI status is document state.
 
-### 7.2 Tools
+### 7.3 Tools
 
 ```ts
 type ToolControl = {
@@ -1411,20 +2021,20 @@ type ToolExecutionResult = {
   readonly control?: ToolControl;
 };
 
-interface OwnedConversation {
-  readonly id: Id;
+interface ConversationHandle {
+  readonly id: ConversationId;
   submit(submission: InputSubmissionDraft, context: Context): Promise<Submission>;
   abort(context: Context): Promise<void>;
   waitForIdle(context: Context): Promise<void>;
 }
 
-interface ToolExecutionApi extends DocumentObserver {
-  readonly taskId: Id;
-  readonly conversationId: Id;
+interface ToolExecutionApi extends DocumentObserver, DocumentReader {
+  readonly taskId: TaskId;
+  readonly conversationId: ConversationId;
   readonly callId: string;
-  stream(chunk: string | Uint8Array): void;
+  output(chunk: string | Uint8Array): void;
+  details(value: JsonValue, context: Context): Promise<void>;
   commit<T>(change: (tx: Tx) => T | Promise<T>, context: Context): Promise<T>;
-  progress(value: JsonObject, context: Context): Promise<void>;
   memo<T extends JsonValue>(name: string, context: Context): Promise<T | undefined>;
   memo<T extends JsonValue>(name: string, candidate: T, context: Context): Promise<T>;
   createTask<I, S extends { phase: string }, R, H extends object>(
@@ -1432,18 +2042,15 @@ interface ToolExecutionApi extends DocumentObserver {
     input: I,
     options: Omit<TaskOptions, "conversationId">,
     context: Context,
-  ): Promise<TaskRef<R>>;
-  getTask<R>(ref: TaskRef<R>, context: Context): Promise<TaskRecord<JsonValue, JsonValue, R> | undefined>;
-  waitForTask<R>(ref: TaskRef<R>, context: Context): Promise<SettledTask<R>>;
-  createConversation(
-    spec: Omit<ConversationSpec, "parent"> & { readonly inherit?: boolean },
-    context: Context,
-  ): Promise<OwnedConversation>;
+  ): Promise<TaskId<R>>;
+  getTask<R>(id: TaskId<R>, context: Context): Promise<TaskRecord<JsonValue, JsonValue, R> | undefined>;
+  waitForTask<R>(id: TaskId<R>, context: Context): Promise<SettledTask<R>>;
+  conversation(id: ConversationId, context: Context): Promise<ConversationHandle | undefined>;
 }
 
 type ToolRegistration = Tool & {
   readonly replay?: "safe" | "unsafe";
-  readonly output?: {
+  readonly outputLimits?: {
     readonly maxBytes?: number;
     readonly maxLines?: number;
     readonly retain?: "head" | "tail";
@@ -1456,60 +2063,138 @@ type ToolRegistration = Tool & {
 };
 ```
 
-Omitted `replay` is `unsafe`. Omitted output bounds are 64 KiB, 200 lines, and
-`retain: "head"`. `stream()` synchronously accepts UTF-8 output into that
-invocation-owned bounded buffer and throws after invocation end. Throttled
-commits publish the retained output and dropped byte/line counts in the tool
-presentation document. If `execute()` omits `content`, the final retained stream
-becomes one text content item; no stream becomes an empty content list. Explicit
+Omitted `replay` is `unsafe`. Omitted `outputLimits` are 50 KiB, 2,000 lines,
+and `retain: "head"`.
+
+A running tool reports two things to the UI, mirroring the two halves of its
+final result:
+
+- `output(chunk)` appends running text output, like stdout. If `execute()` omits
+  `content`, the final retained output becomes one text content item; no output
+  becomes an empty content list.
+- `details(value)` replaces the running details with a complete JSON value; it
+  does not merge keys. If `execute()` omits `details`, the last value becomes the
+  final `details`, so a renderer handles one details shape from the first
+  update through the final result.
+
+Neither is sent to the model while the tool runs. `output()` synchronously
+accepts UTF-8 output into that invocation-owned bounded buffer and throws after
+invocation end. Throttled commits publish the retained output, dropped
+byte/line counts, and the current details in the tool presentation document. Explicit
 text in explicit result content is bounded by the same limits before transcript
 persistence; non-text content is retained as declared by its pi-ai type.
 
-`progress(value)` replaces the invocation's complete JSON `progress` payload; it
-does not merge keys. Its promise resolves after the corresponding or coalesced
-document commit. During normal settlement, accepted output updates drain before
+`output()` never spills complete output to a file because spilling requires a
+filesystem, which may be remote or unavailable. A tool that must preserve
+complete output spills through the `ExecutionEnv` or `FileSystem` it was given,
+such as shell execution with spill capture, and reports the resulting path in its
+details.
+
+The `details()` promise resolves after the corresponding or coalesced document
+commit. During normal settlement, accepted output updates drain before
 the tool-result entry and terminal task record commit. Abort and close obey
 invocation and Session admission gates: uncommitted buffered updates may be
 discarded, while admitted commits settle. Cancellation, callback, tracker
 preparation, and checkpoint failures occur before Storage admission and do not
 poison the Session. An uncertain Storage failure follows the fatal Session rule.
 
-Tools are dynamically registered declarations with name, description, JSON
-schema, replay policy, and execute function. A tool call is accepted only if it
-was offered in the request's effective system/tool history. Arguments are
-validated before and after `beforeTool` hooks.
+Tools are registry entries (section 7.1) with name, description, JSON schema,
+replay policy, and execute function. `registry.tools.wrap(name, key, wrapper)`
+decorates a tool without replacing it. Each snapshot composes the current base
+tool with its wrappers in registry order; a wrapper never captures a base, so
+reloading the base keeps its wrappers. A wrapper that throws or returns a tool
+with a different name makes that tool absent from the snapshot (fail closed:
+not offered, and calls produce `tool_unavailable`) and is reported. A wrapper
+without a base contributes nothing. The composite supplies the declaration,
+argument validation, replay policy, and execution.
+
+A tool call is accepted only if it was offered in the request's effective
+system/tool history. A call to a tool that is not offered or has no registered
+implementation produces the `tool_unavailable` error result described in section
+2.2 instead of failing the run. The tool task resolves the composed tool once
+from its snapshot before argument validation and pins it until execution
+settles, even across later snapshot refreshes. Arguments must satisfy both the offered
+declaration and the pinned implementation's schema; they are validated before
+and after `beforeTool` hooks.
 
 After hooks and validation, the tool task durably records the final call and
 resolved replay policy before execution. Recovery does not rerun `beforeTool`
-and does not let a changed registry declaration alter that stored policy.
+and passes the same stored arguments to `execute()`. A replay-safe tool may
+reconstruct a submission from those arguments when that transformation is pure.
+Random values, timestamps, mutable document/configuration reads, or other derived
+inputs that must remain stable are first captured in a durable memo, checkpoint,
+or task input. A background supervisor receives the final submission draft in
+its own durable input so it can finish independently. Recovery does not let a
+changed registry declaration alter the stored replay policy.
 
-An owned conversation accepts only input submissions; tools use ordinary
-transaction writes for passive entries.
+A tool-acquired conversation handle accepts only input submissions; tools use
+ordinary transaction writes for passive entries.
 
 A tool executes in a durable task. It may:
 
-- write bounded progress/output to a presentation or task-scoped document;
+- publish bounded running output and details to its presentation document;
 - commit memos;
 - create and wait for tasks;
-- create owned conversations;
+- atomically create or fork explicitly owned conversations through `commit()`;
 - observe documents for which it has a token/reference;
 - mutate authorized documents through `commit()`;
 - return bounded model content and separate diagnostic details.
 
-Tool operations use the invoking task's admission and
-invocation-lifetime gates. Task creation defaults to that task's conversation.
-Trusted document access follows sections 3.3 and 9.2; there is no additional
-document subtree authorization layer. `createConversation()` records the
-invoking task as owner and returns an invocation-bound handle. `inherit` defaults
-to `false`. When true, creation atomically selects the invoking conversation's
-newest committed visible entry as `parent.at`; if no entry exists, it creates no
-history parent. Conversation documents then apply section 3.7 at that entry, and
-explicit model/section seeds override their inherited built-in values. With no
-parent, documents initialize normally. That handle's
-operations reject after the invocation ends. A `Submission` returned by its
-`submit()` is invocation-bound in the same way; the admitted submission remains
-durable after those methods reject. Invocation-owned document watches stop when
-the invocation ends.
+Tool operations use the invoking task's admission and invocation-lifetime gates.
+Task creation defaults to that task's conversation. Trusted document and
+conversation access follows sections 3.3 and 9.2; there is no additional subtree
+authorization layer. Possession of a Session-global typed ID is sufficient in
+trusted code.
+
+Tools have no conversation-creation convenience method. They create or fork a
+conversation inside `commit()`, state its ownership explicitly, atomically stage
+any related document/task writes, and receive only the inert record. After that
+commit settles, `conversation(id)` acquires an invocation-bound operational
+handle for submission, explicit abort, and idle waits without changing
+ownership. A commit callback must not call `conversation()` or use a previously
+acquired handle: nested Session operations and external effects are forbidden
+while the mutation line is held. A handle's operations reject after the
+invocation ends. A `Submission` returned by its `submit()` is invocation-bound in
+the same way; the admitted submission remains durable after those methods reject.
+Invocation-owned document watches stop when the invocation ends.
+
+A foreground subagent conversation is explicitly owned by its tool task. One
+transaction creates or forks the child and records its durable registry mapping;
+after settlement the tool reacquires the child, submits with the registered
+request ID, and waits for that submission's result. Aborting or abnormally
+terminalizing the tool task cascades through the owned scope.
+
+A background subagent is provisioned in one transaction. After deduplicating by
+its durable registry key, the tool stages a background supervisor task `B`, a
+child conversation `C` explicitly owned by `B`, and the registry mapping from the
+semantic name to `C` plus its stable request ID. `B` may be staged earlier in the
+same transaction and used immediately as `C`'s owner. Its durable input contains
+the exact submission draft and the registry location/key; it need not contain
+`C`'s not-yet-created ID. Once scheduled, `B` resolves `C` from the mapping,
+verifies the immutable owner edge, and performs normal `Conversation.submit()`.
+A crash before admission makes `B` retry; a crash after admission returns the
+existing request-ID-deduplicated `Submission`. The initiating tool may race the
+same submit for lower latency and wait only for the durable admission receipt.
+The supervisor may complete after setup: its terminal record retains
+`background`, so ancestor ordinary abort and idle traversal continue to stop at
+its owned scope.
+
+Applications may maintain a conversation document mapping semantic subagent
+names to durable conversation IDs and application-minted submission request IDs.
+Such a live registry uses `fork: "initial"` so children do not inherit the
+parent's agent list and its update is not a selected fork source. Conversation
+creation/forking, supervisor creation when applicable, and the registry mapping
+commit atomically. The supervisor input, tool's durable final arguments, or a
+durable checkpoint must retain enough information to reconstruct the exact
+submission draft; the registry itself need not duplicate that payload. Initial
+or later input then uses the registered stable request ID with the full
+`Conversation.submit()` state machine. A crash before admission leaves a durable
+request to submit; a crash after admission retries the same request and receives
+the existing `Submission`. A read-only lookup by conversation/request ID can
+report absence or return the durable queued/placed/done/unanswered receipt.
+Submission admission therefore needs no private transaction shortcut and does
+not move onto `Tx`. Kernel ownership indexes independently drive abort and idle
+traversal.
 
 A tool result may request `addTools`, `terminate`, or `handoff`. Post-tools
 applies added tool names to configured loadout, uses a final boundary for
@@ -1517,27 +2202,19 @@ terminate/handoff, and writes a headed handoff entry when requested.
 
 On reopen, a tool reruns only when both its stored intent policy and the current
 registered declaration say `safe`. A current `unsafe` declaration may veto a
-stored-safe replay; a current-safe declaration never upgrades stored unsafe.
-Every other orphaned effect produces an interrupted result containing the
+stored-safe replay; a current-safe declaration never upgrades stored unsafe. A
+tool with no current registration is treated as `unsafe`. Every other orphaned
+effect produces an interrupted result containing the
 durable partial output. Completed, failed, and aborted
 tool terminal outcomes retain their tool-result entry ID for post-tools.
 
-### 7.3 System sections and dynamic tools
-
-```ts
-interface SystemSection<T extends JsonValue = JsonValue> {
-  readonly key: string;
-  render(value: T): string;
-}
-
-function defineSystemSection<T extends JsonValue>(definition: {
-  readonly key: string;
-  render(value: T): string;
-}): SystemSection<T>;
-```
+### 7.4 System prompt and dynamic tools
 
-Pico stores prompt and tool changes directly as PR #9548 `SystemMessage` values
-at their transcript positions:
+Pico has no durable prompt sections. The registry's system prompt slot produces
+the desired sections for each request; the transcript's `pi.system` entries are
+the only durable record of what the model saw. Pico stores prompt and tool
+changes directly as PR #9548 `SystemMessage` values at their transcript
+positions, always with empty `content`:
 
 ```ts
 type SystemEntry = EntryRecord & {
@@ -1547,8 +2224,8 @@ type SystemEntry = EntryRecord & {
 
 const baseline: SystemMessage = {
   role: "system",
-  content: basePrompt,
-  sections: { persona: renderedPersona, cwd: renderedCwd },
+  content: "",
+  sections: { preamble: renderedPreamble, cwd: renderedCwd },
   toolsAdded: allEffectiveTools,
   timestamp: now,
 };
@@ -1563,10 +2240,51 @@ const delta: SystemMessage = {
 };
 ```
 
-System sections are registered by stable, non-integer-like key. Generation
-prepares the desired rendered section values and effective tool roster, compares
-them with the state obtained by replaying the active transcript, and appends a
-positional `pi.system` baseline or delta.
+Generation preparation takes these steps against its phase snapshot:
+
+1. Read the committed configuration and replay the active transcript's system
+   messages into the shown sections and offered tools.
+2. Compute the desired tools: active names that the snapshot resolves, in
+   configured order, as composed by their wrappers.
+3. Render every registered section, in registry order, with `PromptInput`: the
+   conversation, those tools, the shown sections, the configured model and
+   thinking level, and a `DocumentReader` for committed documents (the task
+   runtime). The results are the desired sections.
+4. Compare desired sections and tool declarations with the replayed state and
+   append one positional `pi.system` entry when they differ.
+
+Preparation does not recheck the transcript before appending: only the Harness
+writes to a busy conversation, through submissions, run tasks, and boundaries,
+so the transcript it read is still current (section 12).
+
+Model and thinking level are request options, not prompt state.
+
+Registered sections are the only source of prompt text; there is no separate
+builder. `systemPrompt.section(key, render, { tag })` adds a section, and
+`systemPrompt.wrap(key, wrapperKey, wrapper)` decorates one, composed per
+snapshot like tool wrappers. Sections render in registry order: the position at
+which each key was first registered. A section whose `render` returns
+`undefined` is omitted, which is how a section varies by conversation. With
+`tag` omitted or true, text is wrapped as `<key>\n...\n</key>`. A section that
+throws keeps its shown text, if any, and is reported; the request is still sent.
+Errors thrown after the generation invocation is cancelled propagate; an abort
+error of the section's own, such as its fetch timing out, is an ordinary failure. With no registered sections, the desired section set is
+empty.
+
+A minimal prompt is one untagged section:
+
+```ts
+registry.systemPrompt.section("preamble", () => "You are a helpful assistant.", { tag: false });
+```
+
+Sections read per-conversation data through `input.read`. For example, a
+coding agent keeps its own conversation document with the agent kind, preamble,
+and working directory; its preamble and cwd sections render from that document,
+and its AGENTS.md and skills sections return `undefined` for subagent
+conversations.
+Renderers must be deterministic for equal inputs: any change in rendered text,
+such as an embedded timestamp, appends a system delta and invalidates provider
+prompt caches.
 
 Replay applies messages in transcript order. Non-empty `content` appends
 instructions. A section string adds or replaces that name without moving an
@@ -1574,74 +2292,64 @@ existing section; `null` removes it, and a later re-addition appends it to the
 ordered section map. Within one message, tool removals happen before additions,
 so a same-name replacement gets the new declaration and position.
 
-The built-in configuration document stores sections as an ordered array, never
-as an object whose key order must be inferred by Delta. `setSection(section,
-undefined)` removes the record; setting it later appends it at the end. Preparation compares both values and order. If values can be patched
-without changing order, it emits the minimal patch. If effective and desired
-section order differ, one commit appends two `pi.system` entries: the first
-removes every effective section with `null`, and the second re-adds every desired
-section in desired order. This makes order-only changes and deletion/re-addition
-between requests replay exactly; merely restating equal values is insufficient.
+Preparation compares both values and order. If values can be patched without
+changing order, it emits the minimal patch. If shown and desired section order
+differ, one commit appends two `pi.system` entries: the first removes every
+shown section with `null`, and the second re-adds every desired section in
+desired order. This makes order-only changes and deletion/re-addition between
+requests replay exactly; merely restating equal values is insufficient.
 
 A PR #9548 `SystemMessage` is always a patch, not a reset: it cannot remove
 previous `content` or restore section order merely by restating current values.
-Therefore, when a head removes the previous request-visible baseline, the new
+Therefore, when a head removes the previous request-visible baseline, which is
+the case when the active context has a head marker and no `pi.system` entry
+follows that marker, the new
 `pi.system` entry adds `ContextEdit` omissions for every earlier `pi.system`
 entry still retained after the cut. Its own message is then a complete baseline
-containing the base `content`, every desired section in order, and every effective
-tool declaration. Model-context replay sees the new baseline instead of the
-omitted retained deltas. Head rebaselining takes precedence over ordinary
-order/value patching. Without a head cut, an order mismatch uses the two-entry
-remove/re-add sequence above; only when order already matches does preparation
-emit the minimal changed values, `null` removals, and tool additions/removals.
-Same-name tool replacements remove before adding. Registry or document changes
-while preparation hooks run cause preparation to retry against a new snapshot.
-
-Conversation creation may seed section values or explicit removals. Preparation
-uses a mutable section draft with get/set/delete/wrap; each throwing hook loses
-only its own draft changes. The rendered strings stored in historical
-`SystemMessage.sections` remain authoritative even if the current renderer
-changes. Pi-ai decides whether to send the messages positionally to a capable
-provider or fold them into one leading system message; Pico does not rewrite its
-stored transcript for provider compatibility.
-
-### 7.4 Host extension reload
-
-A host extension generation is the Session-side code implementing its task kinds,
-hooks, tools, sections, and document definitions. Registry APIs may
-change registered declarations during normal product operation, but they do not
-make replacement of that implementation code safe while its callbacks are
-running. Document definitions are passed explicitly to typed access rather than
-registered.
-
-In v1, changing host extension code is a Harness generation boundary:
-
-1. Stop new admission and task reservation.
-2. Close the Harness, signalling and joining its active task, tool, and hook
-   invocations plus in-flight watch callbacks without writing abort marks or
-   terminal outcomes.
-3. Dispose the old facets and registrations.
-4. Construct a new Harness over the same storage and new document tokens.
-5. Register the complete task definition set before open performs live-task
-   migration and orphan reconciliation. Ordinary documents migrate on later
-   typed access.
-6. Resume scheduling from the durable checkpoints.
-
-A durable task does not need to become terminal before this restart; only its
-current invocation must settle. A task definition must increase its version when
-the meaning of persisted input or checkpoint state changes and migrate supported
-older state. Uncommitted hook work may rerun under the new generation; committed
-memos remain part of the live task.
-
-If old extension code ignores cancellation and never settles, graceful in-process
-reload cannot complete. The host must terminate that isolated worker/process
-before opening the Session under the new generation. Old and new generations
-must never own the same Session concurrently.
-
-Generation-pinned registries that drain old callbacks while routing new work to
-new code, plus explicit compatible task takeover, are possible future work. Safe
-forced takeover of arbitrary non-cooperative JavaScript requires worker/process
-isolation and is not a v1 promise.
+containing every desired section in order and every effective tool declaration.
+Model-context replay sees the new baseline instead of the omitted retained
+deltas. Preparation writes this baseline even when it restates the replayed
+values, so every later preparation finds a `pi.system` entry after the marker.
+Head rebaselining takes precedence over ordinary order/value patching.
+Without a head cut, an order mismatch uses the two-entry remove/re-add sequence
+above; only when order already matches does preparation emit the minimal changed
+values, `null` removals, and tool additions/removals. A changed tool declaration
+is removed and re-added in the same message. When the offered tool order differs
+from the desired order, the message removes every offered tool and re-adds the
+desired tools in order.
+
+The rendered strings stored in historical `SystemMessage.sections` remain
+authoritative even if the current renderer changes. Pi-ai decides whether to
+send the messages positionally to a capable provider or fold them into one
+leading system message; Pico does not rewrite its stored transcript for provider
+compatibility.
+
+### 7.5 Extension reload
+
+Extension code is reloaded in process through the registry. The host publishes
+the new registrations and disposes the old ones in one `batch()`. The Harness
+keeps running; no close or reopen is required.
+
+- New phase invocations and tool tasks use the new registrations immediately;
+  running invocations see them at their next phase boundary.
+- Work already running keeps its snapshot until its phase handler settles, and a
+  pinned tool keeps its implementation until its execution settles. Replacement
+  never signals or interrupts it. Resources the old code uses are the
+  extension's responsibility (section 7.1).
+- A task definition replaced by name hands over at its next normal phase boundary
+  (section 5.4). A task definition must increase its version when the meaning
+  of persisted input or checkpoint state changes and migrate supported older
+  state; a failed migration blocks the task rather than terminalizing it.
+- Keyed registrations re-registered under the same key keep their position, so a
+  reload does not reorder hooks, tools, or sections.
+- Document definitions are passed explicitly to typed access and need no
+  registration; changed tokens take effect on their next access.
+
+If old extension code ignores cancellation and never settles, new work already
+uses the replacement. Harness close still joins every invocation. Safe forced termination of arbitrary
+non-cooperative JavaScript requires worker/process isolation; that host
+terminates the process and reopens the Session from durable state. Old and new
+Harness instances must never own the same Session concurrently.
 
 ## 8. Built-in tasks
 
@@ -1649,10 +2357,10 @@ The initial implementation provides:
 
 | kind | responsibility |
 |---|---|
-| generation | prepare system/loadout, request or poll model, retry, classify response |
-| tool | validate, hook, execute, persist progress, append result |
-| post-tools | wait for tools, apply controls, run boundary, continue generation |
-| collapse | select a transcript range, summarize, append a headed summary |
+| `pi.generation` | prepare system/loadout, request or poll model, retry, classify response |
+| `pi.tool` | validate, hook, execute, persist output and details, append result |
+| `pi.post-tools` | wait for tools, apply controls, run boundary, continue generation |
+| `pi.collapse` | select a transcript range, summarize, append a headed summary |
 
 Generation uses `HarnessOptions.models` without a Pico-specific model adapter. It
 resolves `models.getModel(ref.provider, ref.modelId)`, builds a pi-ai `Context`
@@ -1673,12 +2381,136 @@ Bounded output records whether content was truncated and any retained file path.
 Compaction changes model context by appending a summary entry with a head. It
 does not delete transcript history.
 
+### 8.1 Built-in entries
+
+Built-in entry kinds carry no `data`; each is exported as an `Entry` token.
+
+| kind | `model` | written by |
+|---|---|---|
+| `pi.user` | `[UserMessage]`, timestamp from the Harness clock at admission or placement | submissions |
+| `pi.assistant` | `[AssistantMessage]` with any stop reason | generation |
+| `pi.system` | `[SystemMessage]` with `content: ""` (section 7.4) | generation preparation |
+| `pi.tool-result` | `[ToolResultMessage]` | tool tasks |
+
+Every provider result becomes a `pi.assistant` entry: answers, failed attempts
+with their error text and usage, and converted partials with stop reason
+`aborted`. Context derivation (section 2.1, rule 9) keeps failed and aborted
+messages out of later requests, so no separate usage or notice kind exists.
+
+### 8.2 Live document
+
+```ts
+type LiveState = {
+  /** Run control (section 6); present exactly while the conversation is busy. */
+  run?: { taskId: TaskId; inputs: SubmissionId[] };
+  /** Presentation of the current generation attempt. */
+  generation?: {
+    attempt: number;
+    /** Committed throttled partial of the in-flight response. */
+    message?: JsonRepresentation<AssistantMessage>;
+    /** Durable backoff before the next attempt. */
+    retry?: { at: number; error: string };
+    /** Provider-side deferred response being polled. */
+    deferred?: { pollAt: number };
+  };
+};
+```
+
+| field | value |
+|---|---|
+| kind | `pi.live` |
+| version | `1` |
+| scope/history/fork | conversation, `latest`, `initial` |
+| `initial()` | `{}` |
+| checkpoint | complete base whenever `generation` is absent |
+| view mount | `docs["pi.live"]` |
+| created | with every Harness conversation (section 2.2) |
+
+Nothing is in flight at every turn boundary and while idle, so the stored delta
+chain spans at most one generation, including its retries and deferred polls, or
+one tool round, and each base is small. Tool progress adds its own condition with the tool task.
+
+Tool progress and compaction status join this document with the tool and
+collapse tasks. Partials are normalized to strict JSON before assignment. Every
+terminal path of a run task removes `run` and `generation` in the commit that
+settles the run's inputs. `tx.settleSubmission()` stages each input's new status
+and resolves the transaction's latest candidate submission record, falling back
+to committed state, during assembly, like task-document validation (section 3.3),
+so it is not a caller table read and works after the commit's first table write.
+
+### 8.3 Generation
+
+```ts
+type GenerationInput = {};
+type GenerationCheckpoint =
+  | { phase: "prepare"; attempt: number }
+  | {
+      phase: "request";
+      attempt: number;
+      model: ModelRef;
+      thinkingLevel: ModelThinkingLevel;
+      streamOptions: ConversationStreamOptions;
+      /** Newest entry included in the request. */
+      cutoff: EntryId;
+    }
+  | { phase: "retry"; attempt: number; until: number }
+  | { phase: "poll"; attempt: number; model: ModelRef; handle: DeferredHandle; pollAt: number };
+type GenerationResult = { entryId: EntryId };
+```
+
+`pi.generation` is version 1 and starts at `{ phase: "prepare", attempt: 1 }`.
+The run's inputs live in `pi.live.run`, not in the task input.
+
+- `prepare` runs section 7.4 against the committed configuration. When no model
+  is configured or `models.getModel()` does not know it, the task fails with
+  `no_model`. Otherwise one commit appends the planned `pi.system` entries and
+  moves to `request` with the new tail as `cutoff` and the configuration's model,
+  thinking level, and stream options.
+- `request` and `poll` resolve the checkpoint's model through
+  `models.getModel()`; an unknown model fails the task with `no_model`, like
+  `prepare`. `request` converts a leftover partial (below) before it resolves
+  the model.
+- `request` first converts a committed partial left in `pi.live` by an
+  interrupted attempt into an aborted `pi.assistant` entry. It then streams the
+  model context through `cutoff` with the invocation signal, the thinking level
+  as `reasoning` (omitted for `off`), and the pinned `streamOptions`,
+  committing throttled partials. Recovery resends the same messages with the
+  same pinned model, thinking level, and stream options.
+- Before classifying, the handler stops the partial throttle and awaits any
+  partial commit in flight, so no stale partial lands after the outcome. The
+  terminal message is classified in one commit that also clears the partial:
+  - `stop`/`length`: append the answer, settle the run's inputs `done`, remove
+    `run` and `generation`, and complete with `{ entryId }`. The same commit
+    applies the final boundary (section 6).
+  - `toolUse`: append the assistant entry and continue through the tool chain.
+  - `error` that `isRetryableAssistantError()` accepts while the conversation's
+    retry policy allows another attempt (`enabled` and `attempt <= maxRetries`,
+    so `maxRetries` counts retries after the first attempt): append the error entry and move to
+    `retry` with `until = now + retryDelayMs(policy, attempt)`.
+  - any other `error`, or `aborted` without an abort mark: append the error
+    entry, settle the inputs `unanswered` with `model_error`, remove `run` and
+    `generation`, and fail.
+  - `deferred`: move to `poll` with `pollAt = now + (handle.pollAfterMs ?? 5000)`.
+- `retry` sleeps until `until`, then returns to `prepare` with the next attempt,
+  so configuration changes made during the backoff apply.
+- `poll` sleeps until `pollAt` and calls `models.fetchDeferred()`. A still
+  deferred result moves `pollAt` strictly later; any other result is classified
+  as above.
+- The abort handler calls `models.cancelDeferred()` in `poll` when the model is
+  known (a failure is reported), converts a committed partial, settles the inputs `unanswered` with
+  `aborted`, removes `run` and `generation`, and ends `aborted`.
+
+Input submissions settle `unanswered` with one of these reasons: `no_model`,
+`model_error` (detail: provider error text), `aborted`, `faulted` (detail: error
+message), or an orphaning blocked reason (section 5.4). Fault and orphan
+settlement discard a committed partial without writing a transcript entry.
+
 
 ## 9. Document observation and Chord
 
-### 9.1 Document source
+### 9.1 Document state
 
-Chord exposes this source-adoption contract from its replicated-state layer:
+Chord's existing replicated-state layer exposes this source-adoption contract:
 
 ```ts
 interface ReplicatedStateSourceFrame<T> {
@@ -1715,24 +2547,21 @@ function replicatedState<T>(
   options?: ReplicatedStateSourceOptions,
 ): AttachedReplicatedState<T>;
 
-declare const documentSourceType: unique symbol;
-interface DocumentSource<T extends JsonObject>
-  extends ReplicatedStateSource<Readonly<T> | null> {
-  readonly [documentSourceType]: T;
-}
+type DocumentState<T extends JsonObject> =
+  AttachedReplicatedState<Readonly<T> | null>;
 
 type WatchEnd =
   | { readonly reason: "stopped" | "cancelled" | "session_closed" | "retired" }
   | { readonly reason: "listener_error"; readonly error: Error };
 
 interface WatchHandle<T> {
-  /** Immutable acquisition snapshot. This reference never changes. */
+  /** Acquisition revision before start; latest delivered immutable revision afterward. */
   readonly value: T;
   /** Installs the sole serialized asynchronous listener. */
-  start(listener: (ops: readonly Op[], context: Context) => Promise<void>): void;
-  /** Prevents another callback from starting and signals an in-flight callback. */
-  stop(): void;
-  /** Settles after termination and any in-flight callback. */
+  start(listener: (value: T, ops: readonly Op[], context: Context) => Promise<void>): void;
+  /** Idempotently stops future callbacks and returns this watch's terminal result. */
+  stop(): Promise<WatchEnd>;
+  /** Settles when the watch terminates; an already-running callback remains caller-owned. */
   readonly closed: Promise<WatchEnd>;
 }
 
@@ -1740,35 +2569,35 @@ type DocumentWatch<T extends JsonObject> = WatchHandle<Readonly<T> | null>;
 
 interface DocumentObserver {
   watchDoc<T extends JsonObject>(token: SessionDocToken<T>, context: Context): Promise<DocumentWatch<T> | undefined>;
-  watchDoc<T extends JsonObject>(token: ConversationDocToken<T>, conversationId: Id, context: Context): Promise<DocumentWatch<T> | undefined>;
-  watchDoc<T extends JsonObject>(token: TaskDocToken<T>, taskId: Id, context: Context): Promise<DocumentWatch<T> | undefined>;
+  watchDoc<T extends JsonObject>(token: ConversationDocToken<T>, conversationId: ConversationId, context: Context): Promise<DocumentWatch<T> | undefined>;
+  watchDoc<T extends JsonObject>(token: TaskDocToken<T>, taskId: TaskId, context: Context): Promise<DocumentWatch<T> | undefined>;
   watchDoc<T extends JsonObject, I extends JsonValue>(token: SessionDocFamilyToken<T, I>, key: string, context: Context): Promise<DocumentWatch<T> | undefined>;
-  watchDoc<T extends JsonObject, I extends JsonValue>(token: ConversationDocFamilyToken<T, I>, conversationId: Id, key: string, context: Context): Promise<DocumentWatch<T> | undefined>;
-  watchDoc<T extends JsonObject, I extends JsonValue>(token: TaskDocFamilyToken<T, I>, taskId: Id, key: string, context: Context): Promise<DocumentWatch<T> | undefined>;
+  watchDoc<T extends JsonObject, I extends JsonValue>(token: ConversationDocFamilyToken<T, I>, conversationId: ConversationId, key: string, context: Context): Promise<DocumentWatch<T> | undefined>;
+  watchDoc<T extends JsonObject, I extends JsonValue>(token: TaskDocFamilyToken<T, I>, taskId: TaskId, key: string, context: Context): Promise<DocumentWatch<T> | undefined>;
 }
 ```
 
-`DocumentSource` is an opaque Chord-recognized `ReplicatedStateSource`. A Chord
-replicated state adopts it directly and forwards its committed immutable value
-and operations without another tracker or re-diff. `attach()` is one synchronous
-boundary: `snapshot.value` includes every commit through `snapshot.cursor`, and
-the attachment buffers only later frames. `activate()` installs the sole listener
-and synchronously drains those frames in contiguous cursor order before returning.
-An operation already covered by the snapshot is never redelivered. Source-backed
-state is publication-only and Pico remains its sole mutator.
+`documentState()` attaches Pico's committed document stream to Chord before
+returning. The returned state is already hydrated with the exact shareable
+immutable revision, has no mutation methods, and publishes every later exact
+committed revision and operation batch without another tracker, value copy, or
+re-diff. Disposing it unregisters only that observation; Pico remains the sole
+document mutator.
 
-Source and watch acquisition never create; absent lookup returns `undefined`.
+State and watch acquisition never create; absent lookup returns `undefined`.
 Successful acquisition binds one concrete incarnation. Retirement publishes a
-JSON `null` replacement and ends that incarnation's stream. The service may then
-withdraw itself; if it remains exposed, consumers see `null`, never stale state.
-If the incarnation retires before attachment, attachment hydrates terminal
-`null`; it never binds a replacement incarnation. A later recreation requires
-acquiring a new source/watch.
+JSON `null` root replacement and ends that incarnation's stream. If the state
+remains exposed, consumers see `null`, never stale state. A later recreation
+requires acquiring a new state or watch.
 
-Each adopted replicated state assigns its own in-memory contiguous delivery
-sequence; Pico does not persist or expose that sequence through `WatchHandle`.
-A live source or watch pins its incarnation's loaded tracker; eviction begins only
-after every attachment ends. Reopen creates a new source lifetime and hydration.
+Each document state assigns its own in-memory contiguous Chord delivery sequence.
+Pico does not persist or expose that sequence through `WatchHandle`. States and watches retain immutable revisions independently of the loaded tracker
+cache. Reopen creates a new state lifetime and hydration.
+
+Internally, state attachment uses Chord's synchronous atomic snapshot-and-register
+boundary: the snapshot includes every commit before attachment, and every later
+exact frame is buffered until activation. This prevents a snapshot from being
+paired with operations based on a newer unseen revision.
 
 ### 9.2 `watchDoc`
 
@@ -1776,83 +2605,60 @@ Tasks, hooks, and tools may observe any existing document for which their code
 has a token and owner/key. There is no additional subtree permission system inside trusted
 Session code.
 
-`watchDoc()` is available on task, hook, and tool APIs. On the Session line,
-acquisition resolves one existing concrete incarnation, captures its immutable
-committed value, and registers the handle for every later committed operation
-batch. It returns `undefined` when absent. `watch.value` is that fixed acquisition snapshot and
-never changes.
+On the Session line, `watchDoc()` resolves one existing concrete incarnation,
+captures its current immutable tracker revision in O(1), and registers for every
+later exact committed revision and operation batch. It returns `undefined` when
+absent. Before `start()`, `watch.value` remains the acquisition revision while
+later frames buffer.
 
 ```ts
 const watch = await api.watchDoc(JobOutputDoc, producerTaskId, context);
 if (watch === undefined) return;
-let value = watch.value;
 try {
-  await initializeConsumer(value, context);
-  watch.start(async (ops, deliveryContext) => {
-    value = applyImmutable(value, ops);
-    await consume(value, deliveryContext);
+  await initializeConsumer(watch.value, context);
+  watch.start(async (value, ops, deliveryContext) => {
+    await consume(value, ops, deliveryContext);
   });
 } catch (error) {
-  watch.stop();
-  await watch.closed;
+  await watch.stop();
   throw error;
 }
 ```
 
-The caller initializes from `value` before `start()`. `start()` synchronously
-installs the sole listener, changes the prepared handle to active, and schedules
-delivery; it never invokes the listener inline. A second `start()`, or `start()`
-after stop, throws.
-
-One per-watch delivery line awaits each callback before starting the next, so
-callbacks never overlap. Commits never wait for callback settlement: while one
-batch is in flight, later batches append to the pending queue. Empty operation
-batches are discarded before enqueueing and cannot consume queue bookkeeping. An
-update accepted between acquisition and return, or between return and `start()`,
-is therefore not lost. The listener's promise covers all work the watch
-serializes; fire-and-forget work started by the listener is outside that
-guarantee.
-
-The pending queue is bounded only by the total number of operations in its
-undelivered batches. It never estimates serialized size or calls
-`JSON.stringify()` to make a compaction decision. When the operation-count limit
-is exceeded, the handle leaves the in-flight batch untouched and replaces the
-entire pending suffix with one newly allocated root replacement batch:
-
-```ts
-[["r", latestImmutablePublishedValue]]
-```
+`start()` installs the sole listener and schedules delivery; it never invokes
+user code inline. Each callback receives the exact immutable committed value and
+the exact operation batch that produced it. Immediately before invocation,
+`watch.value` advances to that value. The watch awaits the listener before
+starting its next callback, but Session commits never wait for callback
+settlement.
 
-The reset counts as one pending operation regardless of the document's in-memory
-size. Later deltas append behind it. If the operation-count limit is exceeded
-again, the whole pending suffix is replaced with a newer reset rather than
-accumulating an unbounded operation list. This bounds delta bookkeeping, not the
-document value itself. This watch observes convergent committed state, not every
-intermediate transition.
-
-The replacement value is the prepared immutable candidate corresponding exactly
-to the last batch compacted into it. Pico adopts and publishes that candidate
-after storage succeeds; it never exposes a draft or borrowed storage value.
-Watches may share the immutable candidate and frozen operation payloads. A
-mutable consumer must detach them before using mutable `apply()` or `track()`.
-
-A watch remains bound to its original incarnation. Retirement replaces the
-pending suffix with `[["r", null]]`. Before start, `value` remains the original
-snapshot and the terminal reset becomes the first delivered batch. While active,
-the reset follows any in-flight callback. Successful terminal delivery closes as
-`retired`; recreation requires another watch.
-
-`stop()` is idempotent, unregisters the handle, discards pending batches,
-prevents another callback from starting, and signals the watch delivery context.
-An in-flight callback is allowed to settle; `closed` resolves only afterward.
-The acquisition `Context` governs the watch lifetime. Cancellation during
-acquisition cleans up any registration before rejecting. Cancellation immediately
-after successful acquisition may return an already-stopped handle,
-whose `start()` throws and whose `closed` reports `cancelled`. Invocation
-termination and Session close stop owned watches similarly. Listener rejection
-is reported, discards pending work, and closes only that watch as
-`listener_error`. The first termination reason wins, and every late rejection is
-observed.
+A watch retains at most 100 pending committed frames, excluding the frame already
+being delivered. Adding frame 101 replaces the complete undelivered suffix with
+one self-contained root replacement `[["r", newestValue]]`, using the newest
+exact immutable revision and that commit's Context. Later exact frames follow
+that replacement normally. Another overflow replaces the pending suffix again.
+No serialized-byte measurement, value copy, operation replay, or re-diff occurs.
+This is convergent observation, not an audit stream; consumers requiring every
+transition must persist those facts separately.
+
+`watch.value` and every previously returned revision remain stable forever under
+the trusted immutability contract. Consumers must not mutate them or retained
+descendants. The selected commit Context's values are preserved without inheriting the
+producer's cancellation. A callback owns its own asynchronous work.
+
+A watch remains bound to its original incarnation. Retirement queues the exact
+terminal `[["r", null]]` frame, or folds it into an overflow replacement with
+value `null`. After that callback settles, the watch closes as `retired` and never
+follows a replacement incarnation.
+
+`stop()` is idempotent. It synchronously unregisters, discards pending frames,
+prevents another callback from starting, and returns the common terminal promise.
+An already-running callback is not aborted or joined and remains caller-owned.
+The acquisition `Context` governs watch lifetime. Cancellation during acquisition
+cleans up before rejecting; later cancellation and Session close stop future
+delivery similarly. Listener failure discards pending work and closes only that
+watch as `listener_error`. The first termination reason wins, and every late
+rejection is observed.
 
 ### 9.3 Conversation view
 
@@ -1873,31 +2679,34 @@ through their own Chord services, not automatically mounted.
 The mount consumes one complete Session commit and publishes one Chord batch:
 
 ```text
-document op ["s", ["message"], value]
--> view op ["s", ["docs", "pi.live", "message"], value]
+document op ["s", ["generation", "message"], value]
+-> view op ["s", ["docs", "pi.live", "generation", "message"], value]
 ```
 
 Entry appends/head changes and every changed mounted document are included in
-the same publication. The mount owns no document revision producer and performs no semantic
-projection. It materializes one immutable published view per batch with
-`applyImmutable(previousView, mountedOps)` so every conversation watch can share
-that value for reset compaction. A Chord adapter assigns a contiguous in-memory
-delivery sequence per view source lifetime.
-
-`Conversation.watch()` exposes that mount through the same immutable acquisition
-snapshot, serialized asynchronous listener, and reset-compacted pending queue as
-`watchDoc()`. Each non-empty operation batch represents one complete Session
-commit; a commit that does not change the mounted view emits no watch batch. Chord
-Session facets may forward the captured value and committed operations through
-services, but that product wiring is not part of the Harness facade and must not
-add another tracker or semantic event envelope.
+the same publication. Before Storage admission, the Session derives the mounted
+operation batch and prepares each affected loaded mount's next immutable revision
+with the optimized immutable applier. Failure rolls back normally. After Storage
+success, finalization only installs the prepared mount pointers/cursors and
+enqueues publication. Mounted document revisions may be structurally shared
+because they obey the same trusted immutability contract. The mount performs no
+semantic projection and owns no second persistence authority. A Chord adapter
+assigns a contiguous in-memory delivery sequence per view source lifetime.
+
+`Conversation.viewState()` exposes the mount directly as a disposable read-only
+Chord state for facets and UI services. `Conversation.watch()` exposes the same
+mount through Package 12's serialized exact-frame watch with bounded pending
+frames and full-value overflow replacements. An empty mounted operation batch
+creates no revision; a redundant nonempty batch remains a real publication.
+Neither API adds another tracker, persistence authority, or semantic event
+envelope.
 
 ### 9.4 Agent-mode notifications
 
 The Session kernel and Chord structural sources do not maintain a semantic event
 journal. Coding-agent JSON/RPC compatibility uses a thin agent-mode adapter
-derived from each uncoalesced committed publication before per-watch queue
-compaction. It owns no tracker or persistence and emits notifications only after
+derived from each uncoalesced committed publication before any per-watch
+overflow replacement. It owns no tracker or persistence and emits notifications only after
 the commit that makes them true.
 
 The adapter protocol covers run start/settlement, committed assistant progress,
@@ -1920,7 +2729,7 @@ these rules:
   adapter.
 
 This adapter is allowed even though a public Session-kernel semantic stream is a
-non-goal. It must not derive notifications from a lossy, reset-compacted watch
+non-goal. It must not derive notifications from a lossy, overflow-reset watch
 when complete subscribed lifecycle delivery is promised.
 
 ## 10. Storage contract
@@ -1935,20 +2744,30 @@ type Page<T, C> = {
 
 type Cursor = Readonly<Record<string, JsonValue>>;
 
+type ConversationQuery = {
+  readonly ownerConversationId?: ConversationId;
+  readonly ownerTaskId?: TaskId;
+};
+
 type EntryQuery = {
-  readonly conversationId: Id;
-  readonly minEntryId?: Id; // inclusive
-  readonly maxEntryId?: Id; // inclusive
+  readonly conversationId: ConversationId;
+  readonly minEntryId?: EntryId; // inclusive
+  readonly maxEntryId?: EntryId; // inclusive
 };
 
 type TaskQuery = {
-  readonly conversationId?: Id;
+  readonly conversationId?: ConversationId;
   readonly kind?: string;
   readonly status?: "pending" | "running" | "terminal";
   readonly abortRequested?: boolean;
   readonly background?: boolean;
 };
 
+type SubmissionQuery = {
+  readonly conversationId?: ConversationId;
+  readonly status?: SubmissionRecord["status"];
+};
+
 type DocumentPoint = Seq | "current";
 
 type DocumentAddress = {
@@ -1971,6 +2790,8 @@ type StoredDocument = {
   readonly record: DocumentRecord;
   readonly version: number;
   readonly value: JsonObject;
+  /** Deltas replayed after the selected base to materialize `value`. */
+  readonly deltasSinceBase: number;
 };
 
 type StorageWrite =
@@ -1983,12 +2804,17 @@ type StorageWrite =
       readonly record: DocumentCreate;
       readonly content: Extract<DocumentContent, { kind: "base" }>;
     }
+  | {
+      readonly type: "document.copy";
+      readonly record: DocumentCreate;
+      readonly source: { readonly id: DocumentId; readonly at: DocumentPoint };
+    }
   | {
       readonly type: "document.change";
-      readonly id: Id;
+      readonly id: DocumentId;
       readonly content: DocumentContent;
     }
-  | { readonly type: "document.retire"; readonly id: Id };
+  | { readonly type: "document.retire"; readonly id: DocumentId };
 
 /**
  * Trusts the owning Session to supply semantically valid records, references,
@@ -1999,29 +2825,45 @@ type StorageWrite =
  */
 interface Storage {
   commit(writes: readonly StorageWrite[], context: Context): Promise<Seq>;
-  mintId(): Promise<Id>;
+  /** Allocate from the one global numeric namespace; the generic brand is compile-time only. */
+  mintId<I extends Id<string>>(): Promise<I>;
 
-  conversation(id: Id, context: Context): Promise<ConversationRecord | undefined>;
-  scanConversations(cursor: Cursor | undefined, limit: number, context: Context): Promise<Page<ConversationRecord, Cursor>>;
+  conversation(id: ConversationId, context: Context): Promise<ConversationRecord | undefined>;
+  scanConversations(query: ConversationQuery, limit: number, cursor: Cursor | undefined, context: Context): Promise<Page<ConversationRecord, Cursor>>;
 
-  entry(id: Id, context: Context): Promise<{ readonly entry: EntryRecord; readonly commitSeq: Seq } | undefined>;
-  findLatestHeadMarker(conversationId: Id, atOrBeforeEntryId: Id | undefined, context: Context): Promise<(EntryRecord & { readonly head: Id }) | undefined>;
-  scanEntries(query: EntryQuery, cursor: Cursor | undefined, limit: number, context: Context): Promise<Page<EntryRecord, Cursor>>;
+  entry(id: EntryId, context: Context): Promise<{ readonly entry: EntryRecord; readonly commitSeq: Seq } | undefined>;
+  entry(conversationId: ConversationId, id: EntryId, context: Context): Promise<{ readonly entry: EntryRecord; readonly commitSeq: Seq } | undefined>;
+  findLatestHeadMarker(conversationId: ConversationId, atOrBeforeEntryId: EntryId | undefined, context: Context): Promise<(EntryRecord & { readonly head: EntryId }) | undefined>;
+  scanEntries(query: EntryQuery, limit: number, cursor: Cursor | undefined, context: Context): Promise<Page<EntryRecord, Cursor>>;
 
-  task(id: Id, context: Context): Promise<TaskRecord<JsonValue, JsonValue, JsonValue> | undefined>;
-  scanTasks(query: TaskQuery, cursor: Cursor | undefined, limit: number, context: Context): Promise<Page<TaskRecord<JsonValue, JsonValue, JsonValue>, Cursor>>;
+  task(id: TaskId, context: Context): Promise<TaskRecord<JsonValue, JsonValue, JsonValue> | undefined>;
+  scanTasks(query: TaskQuery, limit: number, cursor: Cursor | undefined, context: Context): Promise<Page<TaskRecord<JsonValue, JsonValue, JsonValue>, Cursor>>;
 
-  submission(id: Id, context: Context): Promise<SubmissionRecord | undefined>;
-  submissionByRequest(conversationId: Id, requestId: string, context: Context): Promise<SubmissionRecord | undefined>;
+  submission(id: SubmissionId, context: Context): Promise<SubmissionRecord | undefined>;
+  scanSubmissions(query: SubmissionQuery, limit: number, cursor: Cursor | undefined, context: Context): Promise<Page<SubmissionRecord, Cursor>>;
+  submissionByRequest(conversationId: ConversationId, requestId: string, context: Context): Promise<SubmissionRecord | undefined>;
 
   findDocument(address: DocumentAddress, at: DocumentPoint, context: Context): Promise<DocumentRecord | undefined>;
-  document(id: Id, at: DocumentPoint, context: Context): Promise<StoredDocument | undefined>;
-  scanDocuments(query: DocumentQuery, cursor: Cursor | undefined, limit: number, context: Context): Promise<Page<DocumentRecord, Cursor>>;
+  document(id: DocumentId, at: DocumentPoint, context: Context): Promise<StoredDocument | undefined>;
+  scanDocuments(query: DocumentQuery, limit: number, cursor: Cursor | undefined, context: Context): Promise<Page<DocumentRecord, Cursor>>;
 
   close(context: Context): Promise<void>;
 }
 ```
 
+`StorageRejected` means a batch was rejected before any durable effect and is
+guaranteed not to have committed. Session rolls such a batch back normally;
+unknown failures after Storage admission remain fatal because their commit state
+is uncertain. Backends use `StorageRejected` for deterministic `document.copy`
+source, replay, and consistency failures only when rollback is guaranteed.
+
+A `document.copy` reads committed pre-batch source state independent of command
+order. The source must be an alive conversation document at the selected point,
+and kind/key/history/fork must match the child create record. Storage persists
+one independent complete child base at the source's stored version. A batch may
+not create, change, or retire a selected source. Later source changes,
+reclamation, retirement, or backend reopen cannot affect the child.
+
 Cursors are backend-owned JSON objects. Callers only round-trip them to the same
 scan on the same storage; cross-storage or cross-query use is unsupported. The
 Session owns the mutation line, so storage implementations do not add a second
@@ -2034,8 +2876,14 @@ inclusive ID range in newest-first order while applying every conversation
 ancestry cap. With no bounds it pages complete visible history. To read context
 through entry `E`, find the marker at or before `E`, then scan from
 `marker?.head` through `E`. For current context the upper bound is omitted.
-`entry()` combines exact global lookup with the commit sequence required by
-historical document reads. `limit` is always the maximum page size.
+Conversation owner filters are indexed and conjunctive. They support ownership
+traversal without an all-conversation scan; application-maintained registries
+are not a substitute for these kernel indexes.
+
+`entry(id)` combines exact global lookup with the commit sequence required by
+historical document reads. `entry(conversationId, id)` returns that pair only
+when the entry is visible through the requested conversation's ancestry. `limit`
+is always the maximum page size.
 `findDocument()` resolves one exact logical kind/scope/key address at current or
 historical membership. A missing key means the singleton, not every family
 member. `scanDocuments()` enumerates only the incarnations alive in one exact
@@ -2047,8 +2895,8 @@ background status.
 `document(id, at)` materializes one specific incarnation and never follows a
 replacement at the same logical address. Callers resolve an address with
 `findDocument()` when they do not already hold an incarnation ID. It selects the
-newest applicable base, applies its ordered Chord delta tail, and returns the detached materialized value plus stored
-definition version. Base/delta records are backend-private. The lookup never
+newest applicable base, applies its ordered Chord delta tail, and returns the detached materialized value, stored
+definition version, and number of replayed deltas after that base. Base/delta records are backend-private. The lookup never
 scans unrelated documents. An unknown ID returns `undefined`. At `"current"`, a
 retired incarnation returns `undefined`. A numeric lookup of a rewindable
 conversation incarnation returns `undefined` outside its half-open lifetime and
@@ -2096,11 +2944,12 @@ benchmarks.
 
 ### 11.3 JSONL
 
-JSONL uses reclaimable sidecars without exposing them to the harness. Persistence
-alone does not provide the ownership boundary: any decoded indexes, materialized
-values, or caches retained in memory must be detached from commit arguments and
-must not be exposed directly by reads. A JSONL backend cannot simply add file
-appends around aliasing memory tables.
+JSONL depends on the portable `FileSystem` capability, not the broader
+`ExecutionEnv`. It uses reclaimable sidecars without exposing them to the
+harness. Persistence alone does not provide the ownership boundary: any decoded
+indexes, materialized values, or caches retained in memory must be detached from
+commit arguments and must not be exposed directly by reads. A JSONL backend
+cannot simply add file appends around aliasing memory tables.
 
 ```text
 main.jsonl       table writes, document records, and one marker per commit
@@ -2115,9 +2964,18 @@ Publication protocol:
 3. Publish in memory only after the marker write succeeds.
 
 Every commit uses this protocol; there is no standalone-sidecar fast path.
-Without `fsync`, it guarantees ordinary process-crash consistency, not survival
-of power, host, kernel, or filesystem failure. Durable mode flushes sidecars
-before the marker.
+JSONL creation accepts an `fsync` option that defaults to `false`. Without
+`fsync`, it guarantees ordinary process-crash consistency, not survival of
+power, host, kernel, or filesystem failure. With `fsync: true`, the backend
+appends all affected sidecar records, flushes each affected sidecar, and only
+then appends the main marker. Ordinary publication does not explicitly flush
+`main.jsonl`; an acknowledged tail commit may therefore still disappear, but a
+marker that survives should not overtake its sidecar data. A main-only commit has
+no sidecars to flush. Before destructive reclamation with `fsync: true`, the
+backend flushes `main.jsonl` once so the authorizing marker cannot disappear
+while its replacement or removal survives. If that flush fails, the committed
+state remains published and reclamation is deferred. A non-empty temporary
+replacement is also flushed before rename.
 
 Recovery:
 
@@ -2129,25 +2987,32 @@ Recovery:
   record unnecessary.
 - Any uncertain append failure poisons the open backend.
 
-Reclamation starts only after the authorizing base/retirement commits. It writes
-a temporary replacement, renames it, and invalidates cached file descriptors so
-future appends cannot target an unlinked inode. `main.jsonl` is not compacted in
-the initial implementation.
+Reclamation starts only after the authorizing base/retirement commits. When no
+sidecar records remain, it removes the sidecar directly. Otherwise, it writes a
+temporary replacement, renames it, and invalidates cached file descriptors so
+future appends cannot target an unlinked inode. Flushing `main.jsonl` to
+authorize reclamation does not compact it. `main.jsonl` is not compacted in the
+initial implementation.
 
 ## 12. API footguns
 
 These are contracts, not invitations to add defensive machinery:
 
-- **Detached draft work:** drafts and bound array methods are revoked after the
-  Session callback settles. Fire-and-forget work that runs before settlement can
-  still mutate the active transaction and is unsupported.
+- **Detached draft work:** draft reads, draft writes, and all `Tx` operations
+  reject after the Session callback settles. Fire-and-forget work that runs
+  before callback settlement can still mutate the active transaction and is
+  unsupported.
 - **Read after write:** read every required table row before the first table
   write. Document drafts remain usable afterward; table reads do not.
+- **Writing to a busy conversation:** only the Harness appends to a conversation
+  with an active run. Raw entries appended by `Harness.commit()` or a custom
+  task while a generation prepares its request can misplace its system prompt entries;
+  use a write submission.
 - **Long transactions:** an async commit callback holds the Session mutation
   line. Never await models, tools, processes, network calls, humans, a nested
   Session commit, or a Session waiter inside it. Use methods on the current `Tx`.
 - **Explicit creation:** only typed `tx.doc()` creates an absent document. Snapshot,
-  source, and watch lookup return `undefined` instead.
+  state, and watch lookup return `undefined` instead.
 - **Family initialization:** the first acquisition of an absent family address
   selects its seed. Existing instances and later calls ignore seeds; a seed is
   neither identity nor an update.
@@ -2161,15 +3026,20 @@ These are contracts, not invitations to add defensive machinery:
   change requires explicit copy and retirement. Passing incompatible definition
   tokens that claim the same kind is unsupported caller misuse; Session does not
   maintain a document-definition registry to detect it.
-- **Watch activation:** `watch.value` is the immutable acquisition snapshot.
-  Initialize the consumer from it before `start()`; queued operations are based
-  on exactly that value.
-- **Coalesced watches:** slow or unstarted watches may replace an undelivered
-  suffix with a complete reset, omitting intermediate committed states. A facet
-  that must audit every transition must persist each fact as an immutable entry
-  or in its own journal and scan that history explicitly.
-- **Watch self-join:** a listener may call `stop()`, but must not await its own
-  `closed` promise or a Session close that joins that listener.
+- **Trusted immutable revisions:** `snapshot()`, state values, watch values, and
+  their descendants may share tracker-owned containers. Never mutate them; copy
+  first when mutable ownership is required. Runtime freezing is not provided.
+- **Watch activation:** before `start()`, `watch.value` remains the immutable
+  acquisition revision. Initialize the consumer from it first. After start, the
+  property advances to each delivered immutable revision before its callback;
+  every earlier reference remains stable.
+- **Buffered watches:** slow or unstarted watches retain up to 100 exact committed
+  frames. Overflow replaces the undelivered suffix with one full-value root
+  replacement, so intermediate committed states may be omitted. A consumer that
+  must audit every transition must persist each fact in an immutable entry or
+  journal and scan that history explicitly.
+- **Watch stop:** a listener may call and await `stop()`; it prevents future
+  callbacks but neither aborts nor joins the callback already running.
 - **Durable progress cadence:** clients see only committed progress. A crash may
   lose the current uncommitted throttle window.
 - **Large terminal results:** terminal task records remain queryable. Put large
@@ -2177,6 +3047,20 @@ These are contracts, not invitations to add defensive machinery:
   outcome. Never reference a task-scoped document retired by that same outcome.
 - **Raw transcript:** view entries are not model context. Rendering edits,
   display-only entries, and model filtering require the appropriate reducer.
+- **Reserved `pi.` names:** task names, document kinds, and entry kinds starting
+  with `pi.` belong to built-ins by convention. Nothing enforces it; reusing one
+  collides with Harness behavior, such as `pi.system` entries being replayed as
+  system messages.
+- **Early resource disposal:** disposing a `Registration` only stops new use.
+  Freeing resources immediately can fail calls that are still running.
+- **Async batches:** `batch()` callbacks are synchronous. A callback that returns
+  a promise publishes nothing and throws.
+- **Unstable prompt text:** a section renderer whose output changes without a
+  real content change, for example by embedding the time, appends system deltas
+  and defeats provider prompt caching.
+- **Durable stream options:** `streamOptions.headers` and `metadata` are stored
+  in the conversation configuration history and copied into forks. Never put
+  credentials there; `Models` resolves auth.
 - **Fatal storage errors:** after an uncertain storage failure the Session is
   poisoned. Do not catch the error and continue using it.
 - **JSONL durability:** default JSONL ordering handles ordinary process crashes;
@@ -2197,4 +3081,4 @@ Pico5 initially has no:
 - SQL translation of arbitrary Chord operations;
 - JSONL global compaction or automatic corruption repair;
 - compatibility layer for removed Pico prototypes;
-- in-process hot replacement of Session-side extension implementations.
+- forced termination of non-cooperative extension code inside one process.