Seam contract (L1)

1. Boundary

This sub-domain is the client↔runtime coherent link (replication L1 §2): the client is the near node, the runtime the far node. In the bundled application the runtime is an embedded authority and the link is in-process; in the hosted-runtime deployment the runtime is remote and the client is a full near node (a device-resident replica with its own pending set and base cache). The renderer is a pure view over the near node either way (replication L1 §10).

2. The client is a near node

The client holds a pending set of accepted-but-unconfirmed mutations and a cache of the runtime's confirmed base, applies the shared local effect to produce optimistic state, and converges with the runtime by per-mutation confirmation — the same shape the authority-server link gives the runtime. The near node runs the same Rust link node the runtime runs, compiled to WASM in the browser (L2 §3); browser TypeScript is limited to a dumb I/O shim plus the renderer (single-local-effect, no second predictor).

3. The renderer adapter surface

The renderer talks to one opaque RuntimeAdapter (client L1 §3, runtime-adapter-opaque): open/close link, open/extend/close view, run mutation, and a frame stream. The renderer cannot tell which node is behind the adapter — the in-process runtime (httpAdapter), a fake (fakeAdapter), or the replica (entityStoreAdapter). Selecting a different node never changes the renderer.

4. The down-channel: snapshots and deltas

The far node serves the near node a frame stream. A frame is either:

• a whole-view snapshot / replace (ViewSnapshot / ViewReplace) — the full computed view, reserved for initial load, window extension, and coverage change; or
• an incremental mail-list delta (RuntimeFrame::ViewDelta, posthaste-contract-core) — only the rows that changed since the last snapshot, for a link that opted in. The client reconciles it against its held rows: drop rows absent from order, reorder, then apply upserts by row_key.

Delta delivery is opt-in and additive (RuntimeCallerCapabilities::view_delta, default false): a client that does not understand deltas keeps receiving whole ViewReplace frames, so old and new clients coexist. Structural changes still send a whole replace.

5. The up-channel and the confirmation join

The near node submits mutations — the typed MailOperation carried in a MutationRequest (defined once in posthaste-contract-core, never a stringly name/args pair) — with a ClientMutationId; the runtime assigns a RuntimeMutationId and reports the pairing in the MutationReceipt. The confirmation join (replication L1 §5.2) is realized per mutation as RuntimeFrame::MutationSettlement { mutationId, state } plus each base's pendingMutations, not as a scalar watermark — strictly more information, tolerating out-of-order and partial confirmation. The near node retires a pending mutation on its settlement (keyed through the receipt pairing), never on transport acknowledgement; Failed reverts the view to authoritative state and surfaces.

6. Assertions

ID	Sev.	Assertion
client-near-node	MUST	In a remote-runtime deployment the client is a full near node (pending set + base cache) running the shared local effect; the renderer is a pure view over it.
runtime-adapter-opaque	MUST	The renderer talks to one opaque RuntimeAdapter surface; selecting the in-process runtime, the fake, or the replica never changes the renderer.
delta-opt-in-additive	MUST	Incremental mail-list deltas are an opt-in, additive frame variant; a client that does not declare view_delta receives whole-view replaces, so clients coexist across rollout.
settlement-realizes-watermark	MUST	The client retires a pending mutation on its per-mutation MutationSettlement (keyed via the ClientMutationId/RuntimeMutationId receipt pairing), not on transport acknowledgement; this realizes the L1 confirmation watermark.