dsh-plugin-guide 0.3.42 → 0.4.0

package/references/official-docs/docs/subsystems/computer-use.zh.md

@@ -1,59 +0,0 @@
-# 计算机操作
-
-[English](computer-use.md) | 中文
-
-计算机操作让模型通过配置的提供方观察并操作本地桌面。DSH 的共享能力称为 **computer use（计算机操作）**；**Cua Driver** 是上游实现的名称。
-
-
-[macOS CUA 提供方](../../packages/experimental/cua-macos/README.zh.md)使用[共享 CUA 对象与执行器](../../packages/experimental/cua/README.zh.md)，通过 User Questions 和配置档设置执行应用授权。
-
-## 选择提供方
-
-在同一组合中挂载 [`dsh-computer-use`](../../packages/computer-use/computer-use/README.zh.md) 和一个提供方。两个 Cua Driver 提供方都是公开发布到 npm 的实验性包，均需显式启用。
-
-| 提供方 | 运行时 |
-|---|---|
-| [Cua Driver MCP](../../packages/experimental/computer-use-cua-driver-mcp/README.zh.md) | 通过 MCP 连接已安装的 `cua-driver` 可执行文件 |
-| [Cua Driver 原生](../../packages/experimental/computer-use-cua-driver-native/README.zh.md) | 随 npm 依赖安装的平台原生运行时 |
-
-各提供方提供上游工具目录。共享服务只注册名称，并拒绝任何第二个提供方，包括使用相同名称的另一个实例。服务不包含通用桌面操作方法或模型控制的选择器。
-
-## 生命周期和桌面共享
-
-提供方在关闭工具和自有资源期间保留注册。启动失败会释放此次尝试的注册。MCP 提供方在重连期间保留注册。
-
-一个已注册的提供方不会为某个 Session 预留桌面。调用方负责协调跨 Session 和独立 DSH 进程的完整观察、操作和验证流程。取消调用无法撤销桌面已收到的输入。
-
-## 结果和平台要求
-
-工具使用常规执行流程和 Session 日志。支持图像的模型路由在挂载附件存储时接收持久化截图；不支持图像的路由接收现有 MCP 图像诊断。提供方 README 负责说明安装、权限和平台限制。
-
-[决策记录](../../.agents/notes/implemented/architecture/2026-09-12-computer-use-provider-registration.zh.md)解释只负责注册的服务和两个 Cua Driver 集成。
-
-<!-- BEGIN GENERATED cordis-surface (gen-cordis-catalog.ts) — do not edit between markers -->
-
-<a id="cordis-surface"></a>
-
-## Cordis API
-
-Generated from source by `scripts/gen-cordis-catalog.ts` (verified fresh by `pnpm run verify-cordis-catalog` in doc-sync; regenerate with `pnpm run gen-cordis-catalog`) — the language sides differ only in locale-specific paired document paths. Signature blocks use a `ts cordis-catalog` fence and keep the original source JSDoc; dispatch modes are defined in the [primer](../cordis-primer.zh.md#dispatch-modes), and the framework-inherited `ctx` API lives in [cordis-api/inherited.md](../cordis-api/inherited.md).
-
-<a id="ctxcomputeruse--computeruseregistry"></a>
-
-### `ctx.computerUse` — `ComputerUseRegistry`
-
-Owns one optional provider registration in the shared computer-use service.
-
-```ts cordis-catalog
-/**
- * Reserve the sole provider slot until the contribution is disposed.
- * A second registration fails even when it repeats the current name. Providers
- * must stop their tools and await owned work before releasing this registration.
- * @param name - provider-owned name used in registration diagnostics.
- * @returns the effect disposer for this exact registration.
- */
-register(name: ComputerUseProviderName): () => Promise<void>
-```
-
-Source: [`packages/computer-use/computer-use/src/index.ts`](../../packages/computer-use/computer-use/src/index.ts)
-<!-- END GENERATED cordis-surface -->

package/references/official-docs/docs/subsystems/conversation.i18n.yaml

@@ -1,31 +0,0 @@
-# Bilingual-pair consistency record for conversation.md (docs/i18n/README.md): per heading
-# section, a hash of its English and Chinese blocks outside code blocks and generated regions.
-# After editing either side, bring the other along and re-record with:
-#   pnpm run verify-translation-pairing --write docs/subsystems/conversation.md
-/conversation-assembly:
-  en: 986c210044271162
-  zh: afe3372d8b68d963
-/conversation-assembly/data-model-and-ownership:
-  en: 9f86eaf987b4f631
-  zh: b1ecc4c292715445
-/conversation-assembly/target-activation:
-  en: 41a32beb5c85354f
-  zh: 346f7c9a17cb1f67
-/conversation-assembly/group-definitions:
-  en: 62c0a5ae4ed7e1aa
-  zh: 787ad4d04b79adaf
-/conversation-assembly/replayable-event-families:
-  en: c216e2df128b8cb9
-  zh: c039cf84b0d86ad8
-/conversation-assembly/definition-and-typed-chat-payload:
-  en: d8f5e4773704c718
-  zh: f3db8c0d01080dba
-/conversation-assembly/predecessor-reads:
-  en: da849b3b5da81da8
-  zh: 37a647a439bc24b1
-/conversation-assembly/window-update-paths:
-  en: 1e22169d3d7b8ff1
-  zh: 669d03d2148e9a46
-/conversation-assembly/verification-obligations:
-  en: ee832671cb7d94ef
-  zh: 380303a2de942710

package/references/official-docs/docs/subsystems/conversation.md

@@ -1,301 +0,0 @@
-# Conversation assembly
-
-English | [中文](conversation.zh.md)
-
-Conversation is the target-neutral assembly layer between a Client `SessionEventLikeEntry` window and browser views. [`ui-conversation`](../../packages/client/ui-conversation/README.md) owns the event and view registries, one identity-stable binding per `SessionBinding`, Turn/Step locations, incremental Context assembly, target sources, the shared shell, and input orchestration. Target packages such as [`ui-chat`](../../packages/client/ui-chat/README.md) and [`ui-trajectory`](../../packages/client/ui-trajectory/README.md) own their Definitions, final snapshots, and rendering.
-
-This page defines the data model and the extension path for a business-owned Conversation node. The [Web Client architecture](web-client.md) places the subsystem between Client models and Slots; the [Conversation Node assembly decision](../../.agents/notes/implemented/architecture/2026-08-09-client-conversation-node-assembly.md) owns its rationale.
-
-## Data model and ownership
-
-The Session Controller owns the contiguous loaded logical-event window. Each `SessionEventLikeEntry` is either `{ type: 'event', event: SessionEvent }` for one durable event or `{ type: 'transient', event: AssistantLiveChunkEvent }` for one Client-only `assistant/live-chunk` presentation. Both inner events expose `type`, `seq`, `time`, and `data`. `ui-conversation` passes these entries to the assembler without opening a second history stream. One `ConversationNodeAssembler` per Session applies every registered Definition and publishes an independent source for each registered view target.
-
-| Concept | Owner and purpose |
-|---|---|
-| Event Definition | A business package matches one durable or Client-only transient event at a time, correlates it by stable `(kind, id)`, folds deterministic State, and optionally materializes one target node. |
-| Context | The engine-owned ordered Matches and current State for one `(kind, id)`. Durable and transient events may be starts. The earliest loaded start initializes State; later Matches update it. Update-only evidence stays pending until its start is loaded. |
-| Location | The engine-owned Session, Turn, or Step coordinates derived from durable boundary events. Definitions may publish typed data onto one Turn or Step. |
-| View Definition | A target package creates one incremental builder per Session and owns the final snapshot type for that target. |
-| Group Definition | A business package derives one target's root references and group snapshots from materialized Nodes; it owns membership, segmentation, summaries, and incremental caches. |
-| View | A Slot entry such as Chat or Trajectory reads only its target snapshot and renders target-owned nodes. |
-
-Chat and Trajectory may recognize the same durable event family, but each keeps its own Definition State and final node payload. Shared target-neutral machinery is limited to identity routing, ordered replay, Location data, predecessor dependencies, and publication cadence.
-
-## Target activation
-
-Each Session keeps a monotonic set of active targets. Creating or reading a target source does not activate it. The shell explicitly activates its persisted or newly selected View, while another consumer activates a target through its first source subscription. First activation creates that target's builder and calls `replace()` once from the current target-indexed Contexts. Later flushes call `apply()` for every active target, and unsubscription does not remove one.
-
-The shell owns View selection and resolves the registered preferred View or Chat fallback before rendering when a binding is created or selected as current, and after View-roster changes. The assembler receives only the resolved target id and does not select Chat or another default target. A third-party View participates through the same selection and activation operations. A View Definition may expose `toolCallFocus(callId)`; the shell supplies Inspect only for a visible target that declares this capability, and the target maps the call id to its own focus identity.
-
-<a id="group-definitions"></a>
-## Group Definitions
-
-The optional `ctx.uiConversation.groups.register(definition)` contribution uses the same effect-owned registry lifecycle as event and view registrations. It requires an existing View target and rejects duplicate target registrations without constructing a Builder. Each Session creates its own Group context only when that target activates. Registration replacement discards the old context and clears its observed groups during the existing registry rebuild.
-
-The [group types](../../packages/client/ui-conversation/src/client/contract/groups.ts) define the complete protocol:
-
-| Type | Meaning |
-|---|---|
-| `ConversationGroupDefinition<Node, State, Data>` | `create()` initializes Session-local State; `update(context, input)` returns its next State; `buildGroups(context)` returns pending output or `null`. Replacement input requires entries and a complete group replacement. |
-| `ConversationGroupInput<Node>` | `replace` supplies target order, timeline, and synchronous `readNode`, `readTurn`, and `readPosition` readers. `apply` adds projected `previous/current` Node changes, lifecycle `changedTurns`, and `changedTurnOrders`. Do not retain readers in State. |
-| `GroupNodePosition` | Owning Turn, when present, and immediate previous/next visible Node keys. Neighbours preserve interruptions that a Turn-only key list omits. |
-| `NodeReference` / `GroupReference` | Branded `NodeKey` or `GroupKey`, distinguished by `kind`. A Node reference may select a renderer-owned `groupPart`; omission selects the whole Node. |
-| `GroupSnapshot<Data>` | Immutable group key, business data, and ordered Node references. Groups cannot contain other groups or own source Node data. |
-| `GroupUpdate<Data>` | `entries` replaces the complete root sequence; only apply input may omit it to preserve the sequence. Replacement input requires both `entries` and `groups.replace`. `groups.replace.snapshots` replaces all groups; `groups.apply.upserts/removes` updates only named group records. Removal does not delete Nodes. |
-| `ConversationGroupDataMap` | Declaration-merged target-to-data association shared by registration and `views.grouped(target)`. Undeclared targets have no group payload type. |
-| `ConversationGroupedView<Data>` | Stable root `entries` and keyed `groupSource(key)` readers; a removed group reads as `undefined`. |
-
-The Builder exposes `groupInput()` when grouping is registered; missing input fails at first activation. It records the Node values after its own projections and preserves content-only order identity. The assembler supplies changed Turns with every update; direct ungrouped Builder callers may omit them. Builders with independent sources defer their notifications to `publish()`. First activation and ordinary flush share the same sequence: materialize Location data and Nodes, update the Builder, call the Group Definition, validate and install grouping, then publish every affected target and Location source. The group phase reuses the existing publication cadence.
-
-Target position indexes supply the readers and identify Turns whose visible keys or neighbours changed. `changedTurnOrders` includes both owners of a moved Node and Turns adjacent to inserted or removed unscoped Nodes; lifecycle-only changes remain in `changedTurns`. A business Definition can resegment those Turns and refresh only groups containing changed content. Structural output still replaces the complete root-reference array, without requiring unchanged Node contents to be reread.
-
-The Group store validates the whole submitted result before installation: root Group references and records correspond one-to-one, all referenced Nodes exist, and each `(NodeKey, groupPart)` occupies at most one root or member position. A whole Node cannot coexist with one of its parts. Duplicate upserts, duplicate removals, and simultaneous upsert/removal of a group fail. Data-only upserts retain root and member arrays, do not read Nodes, and notify only changed group sources; full replacement revalidates every reference.
-
-Renderers switch on the two reference kinds and choose components in the owning View, not through a renderer field in group data. Root Node references and referenced group members form the complete render list; unreferenced target Nodes remain stored but do not render. The group body reads members separately from summary data. Presentation modes must retain component types, keys, and member parents; changing data membership may legitimately remount a moved member. The framework does not interpret part completeness, segmentation, or presentation policies.
-
-## Replayable event families
-
-Choose one stable business id before writing the Definition. Every event that contributes to the same Node must carry that id or derive it independently from its own payload; the client must never assign an update to “the latest unfinished” Context.
-
-For a review job, the event contract could be:
-
-| Event | Role | Required durable facts |
-|---|---|---|
-| `review/start` | unique start | `reviewId`, Turn/Step coordinates, title |
-| `review/progress` | update | the same `reviewId`, coordinates, replayable progress |
-| `review/end` | update | the same `reviewId`, coordinates, final summary |
-
-Use the producer-owned branded id type across the process boundary. Put the `SessionEventMap` merge and payload types on the producer's type-only export, then import that export for side effects from the client package. Each `(kind, id)` may have at most one start event. A single-event business can use the event's stable identity, such as `event.seq`, as its Definition-local id.
-
-Incremental events are supported. Prefer whole-value checkpoints when the producer can emit them cheaply, because they remain useful when the start is outside the loaded window. Each delta must carry the stable id and produce deterministic State when replayed in ascending log `seq`; it must not depend on live-only memory. If the current history window contains only updates, the assembler keeps a pending Context and builds no State until an older page supplies the start. If the product must render before the start is loaded, a terminal or checkpoint event must carry enough whole fallback state for the Definition to build that result directly; do not recover it by scanning unrelated events.
-
-Live Assistant deltas arrive as Client-only `assistant/live-chunk` events. Reconnect baselines expand the active process-local compact stream into the same transient events, while durable `assistant/message` and `assistant/attempt` events embed complete compact streams for history replay. A transient event may initialize a Context. Every tool delta and its later `tool/call` can match as start under the same callId, even before the name arrives; only the earliest calls `start()`, and later Matches call `update()`. A preparing Tool node becomes visible only after its name is available. Historical pages do not expand settled messages into live deltas. A Definition that consumes Assistant output handles live chunks and durable settlements through the same matching and update interfaces, while unrelated Definitions return `null` without expanding a stream.
-
-## Definition and typed Chat payload
-
-The example keeps the producer declarations and client contribution in one block so the complete relationship is visible. In a package family, keep the branded id and `SessionEventMap` declaration with the event producer, and keep the Definition, Chat data merge, and renderer in the client plugin.
-
-```ts ignore-check
-import { createElement } from 'react'
-import type { Context as ClientContext } from '@deepseek-ai/cordis'
-import type { Branded } from '@deepseek-ai/dsh-brand'
-import type {
-  ConversationLocation, ConversationNodeContext,
-  ConversationNodeDefinition,
-} from '@deepseek-ai/dsh-client-ui-conversation/client'
-import type { ChatNodeViewProps } from '@deepseek-ai/dsh-client-ui-chat/client'
-
-type ReviewId = Branded<'ReviewId'>
-
-interface ReviewStartData {
-  readonly reviewId: ReviewId
-  readonly turn: number
-  readonly step: number
-  readonly title: string
-}
-
-interface ReviewProgressData {
-  readonly reviewId: ReviewId
-  readonly turn: number
-  readonly step: number
-  readonly completed: number
-}
-
-interface ReviewEndData {
-  readonly reviewId: ReviewId
-  readonly turn: number
-  readonly step: number
-  readonly summary: string
-}
-
-declare module '@deepseek-ai/dsh-session/types' {
-  interface SessionEventMap {
-    /**
-     * Opens one durable review job.
-     * @mode emit
-     * @param data - stable identity, location, and initial display state.
-     */
-    'review/start': ReviewStartData
-    /**
-     * Records replayable progress for one review job.
-     * @mode emit
-     * @param data - stable identity, location, and latest progress.
-     */
-    'review/progress': ReviewProgressData
-    /**
-     * Closes one review job with its final summary.
-     * @mode emit
-     * @param data - stable identity, location, and final display state.
-     */
-    'review/end': ReviewEndData
-  }
-}
-
-interface ReviewChatData {
-  readonly title: string
-  readonly completed: number
-  readonly status: 'running' | 'completed'
-  readonly summary?: string
-}
-
-declare module '@deepseek-ai/dsh-client-ui-chat/client' {
-  interface ChatNodeDataMap {
-    'review-job': ReviewChatData
-  }
-}
-
-declare module '@deepseek-ai/dsh-client-ui-conversation/client' {
-  interface ConversationStepDataMap {
-    'review-job': ReviewChatData
-  }
-}
-
-interface ReviewState extends ReviewChatData {
-  readonly turn: number
-  readonly step: number
-}
-
-function locationOf(context: ConversationNodeContext): ConversationLocation {
-  return context.start?.location ?? context.matches[0]?.location ?? { kind: 'unresolved' }
-}
-
-function viewData(state: ReviewState): ReviewChatData {
-  return {
-    title: state.title,
-    completed: state.completed,
-    status: state.status,
-    ...state.summary === undefined ? {} : { summary: state.summary },
-  }
-}
-
-const reviewDefinition: ConversationNodeDefinition<ReviewState> = {
-  kind: 'review-job',
-  target: 'chat',
-  match: (event) => {
-    if (event.type === 'review/start') {
-      return { id: String(event.data.reviewId), role: 'start' }
-    }
-    if (event.type === 'review/progress' || event.type === 'review/end') {
-      return { id: String(event.data.reviewId), role: 'update' }
-    }
-    return null
-  },
-  start: (_context, match) => {
-    if (match.event.type !== 'review/start') throw new Error('review-job requires review/start')
-    return {
-      turn: match.event.data.turn,
-      step: match.event.data.step,
-      title: match.event.data.title,
-      completed: 0,
-      status: 'running',
-    }
-  },
-  update: (context, match) => {
-    if (match.event.type === 'review/progress') {
-      return { ...context.state, completed: match.event.data.completed }
-    }
-    if (match.event.type === 'review/end') {
-      return { ...context.state, completed: 100, status: 'completed', summary: match.event.data.summary }
-    }
-    return context.state
-  },
-  publication: match => match.event.type === 'review/progress'
-    ? 'animation-frame'
-    : 'immediate',
-  buildLocationData: (context, scope) => {
-    if (scope !== 'step' || context.state === undefined) return null
-    return {
-      kind: 'step',
-      turn: context.state.turn,
-      step: context.state.step,
-      key: 'review-job',
-      value: viewData(context.state),
-    }
-  },
-  buildViewNode: (context) => {
-    if (context.state === undefined) return null
-    return {
-      key: context.key,
-      kind: 'review-job',
-      id: context.id,
-      target: 'chat',
-      anchorSeq: context.start?.event.seq ?? context.matches[0]?.event.seq ?? 0,
-      location: locationOf(context),
-      visibility: 'visible',
-      data: viewData(context.state),
-    }
-  },
-}
-
-function ReviewNodeView({ node }: ChatNodeViewProps<'review-job'>) {
-  const text = node.data.summary ?? `${node.data.title}: ${node.data.completed}%`
-  return createElement('p', null, text)
-}
-
-export const inject = ['uiConversation', 'slots']
-
-export function apply(ctx: ClientContext): void {
-  ctx.uiConversation.events.register(reviewDefinition)
-  ctx.slots.inject('conversation.chat.node', () => ctx.slots.register({
-    name: 'conversation.chat.node',
-    key: 'review-job',
-  }, ReviewNodeView))
-}
-```
-
-`match(event)` is an identity extractor, not a fold: it receives only the current `SessionEventLike` and returns the Definition-local id and lifecycle role. After a match, the assembler locates the Context by `(kind, id)` and initializes from its earliest loaded start, whether durable or transient. Every later Match calls `update`, including another start. Removing transient Matches reselects the start from remaining evidence and recomputes State; no remaining start leaves State undefined. Both functions return the State that the engine adopts; returning a new immutable value is preferred, but a function that mutates and returns the same object has the same adoption semantics.
-
-`ConversationNodeDefinitionInput` accepts either this function or a read-only table from event type to matching function. Function-form registrations receive every event; table registrations receive only their listed types. The Registry copies table entries and precomputes ordered candidate Sets when registrations change, keeping candidate construction out of per-event dispatch. Replace a table by unregistering and registering again. Resolved `ConversationNodeDefinition` values retain a callable `match(event)` in both cases.
-
-A match result with `exclusive: true` claims that event on the Definition's target. The assembler evaluates every match of the event before accepting any, so the outcome is independent of registration order: other Definitions of the claimed target build no Context for the event, and the target's unmatched-event fallback does not run. Definitions of other targets and Definitions without a target still receive it. Two claims on one target, or a claim from a Definition without a target, throw during dispatch; a claim returned by the fallback itself has no effect. A business Definition uses a claim to present one kind of message that a generic Definition of the same target would otherwise also present, such as a late question reply.
-
-`buildLocationData(context, scope)` optionally publishes Definition-owned data onto an engine-owned Turn or Step. Use declaration merging to give each key a precise value type. Another Node in the same Location can consume that value through its constrained slot hook, such as `useTurnData(key)`, without receiving the Session or scanning `snapshot.chat.nodes`.
-
-`target` and `buildViewNode(context)` declare one target-owned rendering contribution and must appear together. Preserve `context.key` as the React-facing identity, choose `anchorSeq` from the matched event ordering, and return only renderer-ready data. Once a target Node has been published, keep returning the same key; use `visibility: 'hidden'` when it must temporarily leave the visible flow rather than withdrawing it with `null`.
-
-A Chat Node also chooses where its row stands through `groupTree`. Positions are ordered from the outermost inward, and a Node at a position also has the effect of every inner one. Chat process grouping, whole-Turn folding, and Turn-input detection read only this position; [group-tree.ts](../../packages/client/ui-chat/src/client/contract/group-tree.ts) holds the complete contract.
-
-| The Node is | Declare |
-|---|---|
-| A person's input claimed in Step 1; its Turn opens an exchange | `exchange` |
-| Another input of its Turn, such as later human input or a trigger notice; before the process it is the opening input, after it the whole Turn stays open | `input` |
-| A Turn notice that stays outside whole-Turn folding, such as an error or the completed-turn footer | `turn` |
-| An independent row that whole-Turn folding still hides, such as a model retry | `process` |
-| Ordinary process content that joins the surrounding step run | omit `groupTree` |
-
-The [Chat business rules](../../packages/client/ui-chat/src/client/conversation-nodes/README.md#process-grouping) list the positions the built-in Nodes declare. When a generic Definition of the same target also matches the event your Node presents, claim the event with `exclusive: true` as described above.
-
-## Predecessor reads
-
-Some Definitions need the latest earlier State of another business kind. `start` receives a `ConversationContextReader`; call `reader.previous<State>(kind)` there instead of accepting a Context collection or scanning events. The reader returns the nearest started Context before the current start `seq` as read-only data.
-
-The assembler records that dependency. If an older prepend later supplies a nearer predecessor, closes a previously unknown window gap, or revises the predecessor State, it reruns the dependent Context from `start` and replays its updates in ascending `seq`. The queried Definition remains responsible for writing useful State; the reader exposes no business-specific query methods and grants no mutation authority over another Context.
-
-## Window update paths
-
-History may be requested from the tail backward one page at a time. The Session journal validates non-overlapping logical sequence ranges first; the Assembler then orders accepted inputs by their first `seq` before State replay.
-
-| Path | Engine work | Definition-visible behavior |
-|---|---|---|
-| Replace on open, resync, or gap repair | Rebuild the loaded window, match every standard event or packed run once per Definition, then replay each started Context | `start`, followed by its updates in ascending logical `seq`; pending update-only Contexts remain without State |
-| Prepend one older page | Match only fresh older inputs, merge them into Contexts by `(kind, id)`, preserve existing keyed nodes, and replay only affected Contexts and dependencies | A newly found scalar start activates its collected scalar and packed updates; a changed Location or predecessor may rerun the Context |
-| Append one live event | Call each Definition's `match` once, look up the matched Context by key, and update only that Context | One scalar `update` and one requested publication for a matching post-start event; no existing Context scan |
-
-With `D` registered Definitions, one incoming scalar event or packed run performs `D` current-input matches and constant-time Context-key lookup after a match. Definition code must preserve that property: do not traverse the complete event window, every Context, `context.matches`, or the rendered Node collection on the normal append path. Use State for accumulated facts, Location data for same-Turn/Step sharing, and `reader.previous()` for indexed predecessor dependencies.
-
-`publication` controls when changed State is materialized. Use `immediate` for structural or terminal changes, `animation-frame` for high-frequency visible deltas, and `none` when the State change feeds only a later publication. The engine applies every scalar update in log order and every packed run in one batch update; cadence only coalesces view publication.
-
-## Verification obligations
-
-Add focused tests that establish these outcomes:
-
-1. A complete window passed through replace produces the expected final State, Location data, Node payload, and `anchorSeq`.
-2. An update-only tail stays pending; prepending its start produces the same result as a complete replace.
-3. Initial history followed by live append produces the same result as replaying the combined window.
-4. Prepending an older page adds earlier rows without replacing existing keyed Node values whose data did not change.
-5. Repeated visible deltas preserve `context.key` and publish at most once per animation frame when requested.
-6. The keyed renderer consumes `node.data` and constrained Location hooks only; it does not scan the Session event window, Contexts, or Chat Nodes.
-7. Scalar and packed Assistant history produce the same final State, timing boundaries, and target snapshot, while one packed run remains one Match through replace, prepend, Location replay, and registry rebuild.
-8. Creating a target source performs no builder work; explicit selection or the first subscription performs one complete replacement, later updates reach every active target, and repeated activation performs no replacement.
-
-Use [`packages/client/ui-chat/src/client/conversation-nodes/assistant.ts`](../../packages/client/ui-chat/src/client/conversation-nodes/assistant.ts) for streaming and interruption, [`inbox.ts`](../../packages/client/ui-chat/src/client/conversation-nodes/inbox.ts) plus [`message.ts`](../../packages/client/ui-chat/src/client/conversation-nodes/message.ts) for predecessor queries, and [`packages/client/ui-deliverables`](../../packages/client/ui-deliverables) for a Definition that publishes Turn data without creating its own Node.