@abloatai/ablo 0.26.0 → 0.28.0

package/docs/api.md

@@ -206,27 +206,27 @@ The SDK is a convenience wrapper over a model-scoped HTTP surface — the same
 noun (`model`) and verbs as `ablo.<model>.…`. Non-JS callers (or curl) use it
 directly. The table below shows the shape with `{model}` as a placeholder; the
 [OpenAPI spec](./openapi.json) expands it into one **typed** path per model
-(`/v1/models/task`, `/v1/models/deck`, …, generated from your schema) so each
+(`/api/v1/models/task`, `/api/v1/models/deck`, …, generated from your schema) so each
 endpoint documents that model's real field contract instead of a generic blob.
 
 | SDK call | HTTP |
 |---|---|
-| `ablo.<model>.create({ data })` | `POST /v1/models/{model}` |
-| `ablo.<model>.list({ where })` | `GET /v1/models/{model}` |
-| `ablo.<model>.retrieve({ id })` | `GET /v1/models/{model}/{id}` |
-| `ablo.<model>.update({ id, data })` | `PATCH /v1/models/{model}/{id}` |
-| `ablo.<model>.delete({ id })` | `DELETE /v1/models/{model}/{id}` |
-| `ablo.<model>.claim({ id })` | `POST /v1/models/{model}/{id}/claim` |
-| (release a claim) | `DELETE /v1/models/{model}/{id}/claim` |
+| `ablo.<model>.create({ data })` | `POST /api/v1/models/{model}` |
+| `ablo.<model>.list({ where })` | `GET /api/v1/models/{model}` |
+| `ablo.<model>.retrieve({ id })` | `GET /api/v1/models/{model}/{id}` |
+| `ablo.<model>.update({ id, data })` | `PATCH /api/v1/models/{model}/{id}` |
+| `ablo.<model>.delete({ id })` | `DELETE /api/v1/models/{model}/{id}` |
+| `ablo.<model>.claim({ id })` | `POST /api/v1/models/{model}/{id}/claim` |
+| (release a claim) | `DELETE /api/v1/models/{model}/{id}/claim` |
 
 Auth is a bearer API key: `Authorization: Bearer sk_…`. Mutations take an
 `Idempotency-Key` header — derive it from the business event, not a random
 value, so a retry never double-writes. Writes return a `CommitReceipt`; a
 rejected write carries an error `code` (e.g. `stale_context`, `intent_conflict`)
-to act on. `GET /v1/models/{model}` is cursor-paginated (`limit`, `order`,
+to act on. `GET /api/v1/models/{model}` is cursor-paginated (`limit`, `order`,
 `order_by`, `starting_after`) and returns `{ data, has_more, next_cursor }`.
 
-`POST /v1/commits` remains the path for **atomic multi-op** writes (several
+`POST /api/v1/commits` remains the path for **atomic multi-op** writes (several
 operations across rows/models that must commit together) — the per-model routes
 above are the one-record path. Both run the identical guarded-write engine.
 

package/docs/coordination.md

@@ -416,6 +416,65 @@ try {
 }
 ```
 
+### `heartbeat` — holding a claim for long-running work
+
+```ts
+held.heartbeat(ttl?: Duration): Promise<{ expiresAt: number }>
+```
+
+A claim's TTL is crash cleanup, not a work-duration estimate — so a task that
+outlives it (an agent run, a background worker's job) keeps its lease by
+**beating**, the same pattern as an SQS visibility heartbeat or a Temporal
+activity heartbeat. Each beat extends the lease from now (never shortens it,
+and each extension is clamped server-side); a crashed worker stops beating and
+its lease lapses within one beat window, promoting the next waiter.
+
+Usually **implicit** — pass `heartbeat` when claiming and the SDK beats every
+third of the TTL until release:
+
+```ts
+await using claim = await ablo.reports.claim({
+  id: 'report_q3',
+  reason: 'generating',
+  ttl: '5m',
+  heartbeat: true,               // or an explicit cadence: heartbeat: '2m'
+  onHeartbeatLost: () => abortWork(),
+});
+await runLongGeneration(claim.data); // lease held for the duration
+// scope exit releases; the loop stops with it
+```
+
+A beat that comes back with a definitive loss — the lease expired and the
+queue moved on — rejects with `AbloClaimedError` (`claim_lost`) and stops the
+auto-loop. For a worker with no socket, **the failed beat is the loss
+notification**; abandon or re-claim, and remember any write attempted under
+the old lease is independently rejected by its `readAt` guard. Transient
+failures (a connection blip) don't stop the loop — the next tick retries.
+
+Each beat's answer carries two more things:
+
+- **`queueDepth`** — how many participants wait in line behind the lease.
+  This is the cooperative-yield pressure signal: a worker that can checkpoint
+  may release early when others wait. Read it from the resolved beat, or pass
+  `onHeartbeat` when claiming to observe every auto-beat.
+- **progress `details`** — `held.heartbeat({ details: { pages: 42, of: 100 } })`
+  stores the payload as the claim's peer-visible `meta.progress` (last beat
+  wins, via `claim.state`). This is presence, not a checkpoint: it dies with
+  the lease. Durable progress belongs in the data itself — write a row, and
+  every subscriber already sees it.
+
+Works identically on both transports: the realtime client sends a
+`claim_heartbeat` frame; the HTTP client posts
+`POST /api/v1/models/{model}/{id}/claim/heartbeat` (`{ ttl?, claimId?, details? }`).
+Over HTTP, a **queued** claim can heartbeat too — it refreshes the waiter's
+slot in the line (a queued slot is TTL'd like a lease) and reports
+`{ status: 'queued', position }`.
+
+A stateless worker holding **many** rows beats them all in one round trip:
+`ablo.claims.heartbeatAll({ ttl: '5m' })` → `POST /api/v1/claims/heartbeat`, one
+entry per extended lease. This is the socketless twin of the realtime
+keepalive, which already renews every held lease on each ping.
+
 ### `watch` — presence for a set of rows
 
 Reading or claiming a row auto-enrolls you in its sync group, which is enough for

package/docs/mcp.md

@@ -16,7 +16,7 @@ edits rows → coordination; teaching your IDE assistant the SDK → helper.
 ## Coordination server (`@ablo/mcp`)
 
 The coordination server is the MCP projection of the model-scoped API
-(`/v1/models/...`) — the same surface as `ablo.<model>.create/update/claim` and
+(`/api/v1/models/...`) — the same surface as `ablo.<model>.create/update/claim` and
 the REST routes, rendered as tools. An agent connects with your API key and
 gets one safe loop: **claim → read → commit → release.**
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@abloatai/ablo",
-  "version": "0.26.0",
+  "version": "0.28.0",
   "description": "The Collaboration Layer For AI Agents",
   "license": "Apache-2.0",
   "type": "module",
@@ -28,6 +28,11 @@
       "import": "./dist/coordination/index.js",
       "default": "./dist/coordination/index.js"
     },
+    "./commit": {
+      "types": "./dist/commit/index.d.ts",
+      "import": "./dist/commit/index.js",
+      "default": "./dist/commit/index.js"
+    },
     "./react": {
       "types": "./dist/react/index.d.ts",
       "import": "./dist/react/index.js",
@@ -150,10 +155,10 @@
     "pretest": "node scripts/check-dist-fresh.mjs",
     "test": "jest",
     "test:quickstart": "node scripts/test-quickstart.mjs",
-    "test:unit": "jest --testPathPattern=__tests__/unit",
-    "test:integration": "jest --testPathPattern=__tests__/integration",
-    "test:contract": "jest --testPathPattern=__tests__/contract",
-    "test:property": "jest --testPathPattern=__tests__/property",
+    "test:unit": "jest --testPathPatterns __tests__/unit",
+    "test:integration": "jest --testPathPatterns __tests__/integration",
+    "test:contract": "jest --testPathPatterns __tests__/contract",
+    "test:property": "jest --testPathPatterns __tests__/property",
     "test:coverage": "jest --coverage",
     "test:e2e": "E2E_TEST=true jest --config jest.e2e.config.ts",
     "test:e2e:up": "docker compose -f docker-compose.test.yml up -d --wait",
@@ -207,14 +212,14 @@
     "mobx": "^6.13.7",
     "mobx-react-lite": "^4.0.0",
     "uuid": "^11.1.0",
-    "zod": "^4.0.17"
+    "zod": "^4.1.11"
   },
   "devDependencies": {
     "@ai-sdk/provider": "^3.0.0",
     "@clack/prompts": "^0.11.0",
-    "@jest/globals": "^29.7.0",
+    "@jest/globals": "^30.2.0",
     "@prisma/client": "^7.3.0",
-    "@types/jest": "^29.5.0",
+    "@types/jest": "^30.0.0",
     "@types/node": "^22.0.0",
     "@types/react": "^19.0.0",
     "@types/uuid": "^10.0.0",
@@ -225,13 +230,14 @@
     "fake-indexeddb": "^6.0.0",
     "fast-check": "^3.0.0",
     "globals": "^16.5.0",
-    "jest": "^29.7.0",
-    "jest-environment-jsdom": "^29.7.0",
+    "jest": "^30.2.0",
+    "jest-environment-jsdom": "^30.2.0",
+    "jest-environment-node": "^30.2.0",
     "picocolors": "^1.1.0",
     "postgres": "^3.4.0",
     "react": "^19.0.0",
     "react-dom": "^19.0.0",
-    "ts-jest": "^29.4.0",
+    "ts-jest": "^29.4.5",
     "ts-morph": "^26.0.0",
     "tsup": "^8.0.0",
     "tsx": "^4.19.0",

package/dist/ai-sdk/coordinated-tool.d.ts

@@ -1,101 +0,0 @@
-/**
- * `coordinatedTool` — the one-liner that turns an Ablo model write into a Vercel
- * AI SDK tool with multi-agent coordination already handled, so an AI agent can
- * contribute to shared state without ever silently clobbering a concurrent
- * writer.
- *
- * The base `./ai-sdk` pattern (see index.ts) is "write your own `tool()` and
- * call `ablo.<model>.update({ id, data, claim })` inside `execute`". That's the
- * right amount of control when a tool does something bespoke. But the *common*
- * case — "the agent produced some content; save it into the shared row" — should
- * not require every integration to re-derive optimistic concurrency by hand. This
- * collapses it to a declaration:
- *
- * ```ts
- * import { coordinatedTool } from '@abloatai/ablo/ai-sdk';
- * import { z } from 'zod';
- *
- * const saveSection = coordinatedTool(ablo.documents, {
- *   description: 'Save your section into the shared document.',
- *   inputSchema: z.object({ text: z.string() }),
- *   id: () => DOC_ID,
- *   apply: (current, { text }) => ({ content: appendBlock(current.content, text) }),
- *   // strategy: 'merge'  ← the default
- * });
- *
- * await streamText({ model, messages, tools: { saveSection } });
- * ```
- *
- * `apply` is the whole API: a pure function of `(freshest row, tool input) →
- * patch`, exactly like React's `setState(prev => next)`. Everything underneath —
- * reading the latest row, the compare-and-swap, the jittered backoff between
- * reconcile rounds, releasing claims — is the runtime's job, not yours.
- *
- * ## Strategies (pick by how writers should relate; all verified to converge
- * under N-way agent contention)
- *
- * - `'merge'` *(default)* — delegates straight to the functional update
- *   `ablo.<model>.update(id, current => apply(current, input))`. The SDK re-reads
- *   and re-applies `apply` on top of every concurrent write and backs off between
- *   rounds, so N agents *accumulate* into one row and the model never sees a
- *   conflict. **Requires the model's agent conflict policy to be `reject`** (the
- *   default, or `agentsReject()`); a model declaring `agentsNotify()` HOLDS the
- *   losing write instead of rejecting it, which defeats the reconcile — use
- *   `claim`/`queue` there, or switch the policy.
- *
- * - `'claim'` — mutual exclusion. Takes a fail-fast claim; if another participant
- *   holds the row it returns `{ status: 'claimed' }` so the *model* decides to
- *   retry (a legible signal beats a hidden wait when the agent might do something
- *   better with its turn). Works regardless of conflict policy.
- *
- * - `'queue'` — fair-ish serialization over stateless HTTP, the SQS shape: a
- *   client poll-acquire loop (true FIFO needs a socket) until the claim is granted
- *   or `poll.timeoutMs` elapses. The model calls once and the tool waits its turn.
- */
-import type { z } from 'zod';
-import type { ModelOperations } from '../client/createModelProxy.js';
-export type CoordinationStrategy = 'merge' | 'claim' | 'queue';
-/** The structured result the tool hands back to the model (or the caller). */
-export interface CoordinatedWriteResult<T> {
-    /**
-     * `'written'` — saved. `'claimed'` — another participant holds the row; NOT
-     * saved, the model should try again. `'timeout'` — the queue strategy could not
-     * acquire the row within `poll.timeoutMs`.
-     */
-    status: 'written' | 'claimed' | 'timeout';
-    /** The reconciled row, on `'written'`. */
-    row?: T;
-    message?: string;
-    /** On `'written'` via the `queue` strategy, how long the tool waited in line. */
-    waitedMs?: number;
-}
-export interface CoordinatedToolOptions<TInput, T> {
-    /** Tool description shown to the model. */
-    description: string;
-    /** What the model may send — a normal AI SDK / zod input schema. */
-    inputSchema: z.ZodType<TInput>;
-    /** Which row this write targets, derived from the tool input. */
-    id: (input: TInput) => string;
-    /**
-     * Produce the write patch from the freshest current row + the tool input — a
-     * pure `(prev, input) => next`. Under `merge` it re-runs on every concurrent
-     * write, so it must be idempotent w.r.t. its own contribution (e.g. skip if its
-     * marker is already present) to be safe across reconcile rounds.
-     */
-    apply: (current: T, input: TInput) => Partial<T>;
-    /** How concurrent writers relate. Defaults to `'merge'`. */
-    strategy?: CoordinationStrategy;
-    /** Human-legible coordination metadata attached to the claim (`claim`/`queue`). */
-    claim?: {
-        reason?: string;
-        description?: string;
-    };
-    /** Reconcile budget for `merge` (rounds before `AbloContentionError`). */
-    retries?: number;
-    /** Poll cadence / ceiling for `queue` (defaults 250ms / 30s). */
-    poll?: {
-        intervalMs?: number;
-        timeoutMs?: number;
-    };
-}
-export declare function coordinatedTool<TInput, T = Record<string, unknown>, CreateInput = Partial<T>>(model: ModelOperations<T, CreateInput>, options: CoordinatedToolOptions<TInput, T>): import("ai").Tool<TInput, CoordinatedWriteResult<T>>;

package/dist/ai-sdk/coordination-context.d.ts

@@ -1,52 +0,0 @@
-/**
- * Coordination context middleware — reads peer claims on the same
- * entity from the sync engine's presence stream and injects a brief
- * coordination note into the prompt before the LLM call.
- *
- * The complement of `claim-broadcast.ts`: that one declares what
- * THIS agent is about to do; this one reads what OTHERS are doing
- * and tells the LLM about it. Together they make multiplayer-with-
- * AI structurally real — the AI knows when a human or another
- * agent is mid-edit and can defer / phrase its work as
- * "while you finish that, I'll …" / suggest waiting / coordinate
- * explicitly.
- *
- * Open-source-clean: depends only on `@ai-sdk/provider` types and
- * the package's own `SyncAgent`. Consumers compose via the AI
- * SDK's `wrapLanguageModel`.
- *
- * Cost: zero extra LLM calls (read happens locally from the agent's
- * cached presence stream — already in memory from the WS subscription).
- * Adds a few sentences to the system prompt (typically <100 tokens)
- * only when peers are actively editing.
- */
-import type { LanguageModelV3Middleware } from '@ai-sdk/provider';
-import type { Ablo } from '../client/Ablo.js';
-import type { SchemaRecord } from '../schema/schema.js';
-import type { ClaimTarget } from '../types/streams.js';
-export type { ClaimTarget };
-export interface CoordinationContextMiddlewareOptions<R extends SchemaRecord = SchemaRecord> {
-    readonly agent: Ablo<R> | null;
-    readonly target: ClaimTarget | null;
-    /**
-     * Optional claimId(s) to exclude from the read — typically this
-     * agent's own active claim so the coordination note doesn't tell
-     * the AI "you yourself are editing this." When middleware is
-     * composed with `claimBroadcastMiddleware` in the standard order,
-     * `transformParams` runs BEFORE the broadcast's `wrapStream`
-     * declares its claim, so the agent's own claim isn't yet in the
-     * cached presence and self-filtering isn't needed. The hook is
-     * here for callers that compose differently or for fleet
-     * coordination (filter sibling worker claims).
-     */
-    readonly excludeClaimIds?: readonly string[];
-}
-/**
- * Build the middleware. When `agent` or `target` is null, returns a
- * pass-through.
- *
- * Generic over the schema record — see `claimBroadcastMiddleware`
- * for why `Ablo<S>` and `Ablo<SchemaRecord>` aren't structurally
- * assignable.
- */
-export declare function coordinationContextMiddleware<R extends SchemaRecord = SchemaRecord>(options: CoordinationContextMiddlewareOptions<R>): LanguageModelV3Middleware;

package/dist/core/query-utils.d.ts

@@ -1,34 +0,0 @@
-/**
- * query-utils — Pure query helpers for the MobX `QueryView`. One source of
- * truth for sort, filter, and binary insertion logic.
- *
- * No MobX, no ObjectPool, no Model — just arrays and values.
- */
-/**
- * The incremental-update contract a view satisfies. `ViewRegistry` stores views
- * as this base type so it can dispatch to many views with different `T`
- * parameters from one Set — `View<T>` is invariant in T, so without this shared
- * base the registry would have to widen via `unknown as View<Record<...>>` at
- * every register/unregister/notify call.
- */
-export interface IncrementalView {
-    handleAdded(entity: Record<string, unknown>): void;
-    handleUpdated(entity: Record<string, unknown>): void;
-    handleRemoved(id: string): void;
-}
-/** Compare two values for sorting, null-safe. Returns -1 | 0 | 1. */
-export declare function compareValues(a: unknown, b: unknown, dir: 1 | -1): number;
-/**
- * Binary search for the correct insertion index in a sorted array.
- * Returns the index at which `item` should be inserted.
- */
-export declare function binaryInsertionIndex<T>(arr: ArrayLike<T>, item: T, sortKey: string, dir: 1 | -1): number;
-/**
- * Check whether an entity matches a declarative `where` clause.
- * Every key in `where` must exactly match the entity's value.
- */
-export declare function matchesWhere<T extends Record<string, unknown>>(entity: T, where: Partial<T>): boolean;
-/**
- * Find the index of an entity by id in an array. Returns -1 if not found.
- */
-export declare function findIndexById<T extends Record<string, unknown>>(arr: ArrayLike<T>, id: string): number;

package/dist/core/query-utils.js

@@ -1,59 +0,0 @@
-/**
- * query-utils — Pure query helpers for the MobX `QueryView`. One source of
- * truth for sort, filter, and binary insertion logic.
- *
- * No MobX, no ObjectPool, no Model — just arrays and values.
- */
-/** Compare two values for sorting, null-safe. Returns -1 | 0 | 1. */
-export function compareValues(a, b, dir) {
-    if (a === b)
-        return 0;
-    if (a == null)
-        return 1;
-    if (b == null)
-        return -1;
-    return (a < b ? -1 : 1) * dir;
-}
-/**
- * Binary search for the correct insertion index in a sorted array.
- * Returns the index at which `item` should be inserted.
- */
-export function binaryInsertionIndex(arr, item, sortKey, dir) {
-    let lo = 0;
-    let hi = arr.length;
-    const itemVal = item[sortKey];
-    while (lo < hi) {
-        const mid = (lo + hi) >>> 1;
-        const midVal = arr[mid][sortKey];
-        if (compareValues(midVal, itemVal, dir) <= 0) {
-            lo = mid + 1;
-        }
-        else {
-            hi = mid;
-        }
-    }
-    return lo;
-}
-/**
- * Check whether an entity matches a declarative `where` clause.
- * Every key in `where` must exactly match the entity's value.
- */
-export function matchesWhere(entity, where) {
-    for (const [key, value] of Object.entries(where)) {
-        if (value === undefined)
-            continue;
-        if (entity[key] !== value)
-            return false;
-    }
-    return true;
-}
-/**
- * Find the index of an entity by id in an array. Returns -1 if not found.
- */
-export function findIndexById(arr, id) {
-    for (let i = 0; i < arr.length; i++) {
-        if (arr[i]?.id === id)
-            return i;
-    }
-    return -1;
-}

package/dist/schema/sync-delta-row.js

@@ -1,103 +0,0 @@
-/**
- * Canonical Zod description of the `sync_deltas` STORAGE ROW, decomposed by the
- * subsystem it belongs to and the database plane it lives in.
- *
- * `sync_deltas` fuses five control-plane subsystems onto one denormalized row
- * (see `docs/plans/sync-delta-zod-decomposition.md`). This module is **P0** of
- * that decomposition: it DESCRIBES the existing columns as Zod schemas — no DB
- * change, no rewiring — so the subsystem + plane boundaries become explicit and
- * type-enforced:
- *
- *   - {@link syncDeltaCoreSchema}    — the SYNC-PROTOCOL slice. `tenant` plane:
- *                                      the only part that must be written
- *                                      atomically with the app row, and the shape
- *                                      a BYO outbox marker carries (the portable
- *                                      slice).
- *   - {@link deltaAttributionSchema} — who / on whose authority. `control` plane.
- *   - {@link deltaProvenanceSchema}  — which AI task caused it. `control` plane.
- *
- * {@link syncDeltaRowSchema} is the full stored row (core ∪ attribution ∪
- * provenance). {@link DELTA_RESIDENCY} declares each slice's plane so provisioning
- * (P1) can derive "what a customer DB gets" from the schema, not hand-code it.
- *
- * Distinct from the WIRE `SyncDelta` (`sync/SyncWebSocket.ts`, client-facing) and
- * `SourceDelta` (`source/index.ts`, source-mode input) — those are projections of
- * this row. Field names mirror those + `AuditChainRow` (`@ablo/audit-chain`).
- *
- * Monorepo is on Zod v4 — `.extend(...).shape` (not deprecated `.merge`).
- */
-import { z } from 'zod';
-// ── Enums (mirror the Postgres enums; @@map name in the comment) ──────────────
-/** `participant_kind` */
-export const participantKindSchema = z.enum(['user', 'agent', 'system']);
-/** `confirmation_state` */
-export const confirmationStateSchema = z.enum([
-    'auto',
-    'previewed',
-    'approved',
-    'required_human_approval',
-    'auto_historical',
-]);
-/** `backfill_provenance` */
-export const backfillProvenanceSchema = z.enum(['exact', 'inferred', 'unknown']);
-/** A delta payload: the full post-mutation row (or null for deletes). */
-const deltaDataSchema = z.record(z.string(), z.unknown()).nullable();
-// ── Core — `tenant` plane (the sync-protocol slice) ───────────────────────────
-/**
- * Everything a client needs to materialize the change, plus the tenant key. The
- * portable slice: the only part written atomically with the app row, and the
- * shape a BYO outbox marker carries. `id` / `createdAt` / `syncGroups` are
- * control-plane-assigned at enrich/append time, so they're optional here (an
- * outbox marker doesn't have them yet).
- */
-export const syncDeltaCoreSchema = z.object({
-    /** Monotonic sync id; assigned control-plane on append (absent on a marker). */
-    id: z.union([z.bigint(), z.number()]).optional(),
-    /** `action_type` — single char: `I` | `U` | `D`. */
-    actionType: z.string().min(1).max(1),
-    modelName: z.string().min(1),
-    modelId: z.string().min(1),
-    data: deltaDataSchema,
-    previousData: deltaDataSchema.optional(),
-    /** Sync-group routing keys; computed control-plane (`buildDeltaSyncGroups`). */
-    syncGroups: z.array(z.string()).optional(),
-    /** The TRUSTED committing org — the coarse tenant-isolation boundary. */
-    organizationId: z.string().nullable(),
-    /** ISO timestamp; control-plane-assigned at append. */
-    createdAt: z.string().optional(),
-    transactionId: z.string().nullable(),
-});
-// ── Attribution — `control` plane ─────────────────────────────────────────────
-export const deltaAttributionSchema = z.object({
-    /** Legacy single-actor column, derived during the dual-write window. */
-    createdBy: z.string().nullable(),
-    actorId: z.string().nullable(),
-    actorKind: participantKindSchema.nullable(),
-    onBehalfOfId: z.string().nullable(),
-    onBehalfOfKind: participantKindSchema.nullable(),
-    capabilityId: z.string().nullable(),
-    delegationChainRootUserId: z.string().nullable().optional(),
-    confirmationState: confirmationStateSchema.nullable(),
-    backfillProvenance: backfillProvenanceSchema.nullable(),
-});
-// ── Provenance — `control` plane (→ tasks) ────────────────────────────────────
-export const deltaProvenanceSchema = z.object({
-    /** FK to `Task.id` — the LLM turn that produced this commit. */
-    causedByTaskId: z.string().nullable(),
-});
-// ── Full stored row + plane map ───────────────────────────────────────────────
-/** The complete `sync_deltas` row as stored today (core ∪ attribution ∪ provenance). */
-export const syncDeltaRowSchema = syncDeltaCoreSchema
-    .extend(deltaAttributionSchema.shape)
-    .extend(deltaProvenanceSchema.shape);
-/**
- * Each slice's database plane. The durable answer to "what does a BYO customer DB
- * get?" — only `tenant`-plane slices. Provisioning (P1) reads this instead of
- * hand-coding the boundary; the BYO outbox writes the `tenant` slice and the
- * relay enriches the `control` slices in Ablo's own database.
- */
-export const DELTA_RESIDENCY = {
-    core: 'tenant',
-    attribution: 'control',
-    provenance: 'control',
-};

package/dist/schema/sync-delta-wire.js

@@ -1,102 +0,0 @@
-/**
- * Canonical Zod contract for the WIRE delta — the broadcast object that travels
- * server → client (the `delta` / `sync_response` frame payload). This is the
- * "same contract across both" seam: the SDK client and the sync-server each
- * derive their `SyncDelta` type from THESE schemas via `z.infer`, instead of
- * hand-maintaining two interfaces that drift (they had: the server typed
- * `actionType` as `string` and `createdBy` as a nested ref; the client typed
- * `actionType` as the 8-value union and `createdBy` as a flat string — a silent
- * divergence the client never noticed because it ignores attribution).
- *
- * Distinct from {@link import('./sync-delta-row.js').syncDeltaRowSchema} — that
- * is the STORED ROW (has `organizationId`, flat `actor_id`/`actor_kind`
- * columns, single-char action). The wire delta is a PROJECTION: no
- * `organizationId` (the server-trusted isolation predicate is never broadcast),
- * the full Linear action vocabulary, and attribution hydrated into nested
- * {@link ParticipantRef}s.
- *
- * Shape (per the "shared core + layer extensions" decision):
- *   - {@link syncDeltaWireCoreSchema} — the fields BOTH sides agree on.
- *   - {@link clientSyncDeltaSchema}    — core + the SDK-only extras.
- *   - {@link serverSyncDeltaSchema}    — core + the audit attribution the server
- *                                        enriches each broadcast with (the client
- *                                        structurally ignores these).
- *
- * Monorepo is on Zod v4.
- */
-import { z } from 'zod';
-import { participantKindSchema, confirmationStateSchema } from './sync-delta-row.js';
-/**
- * `action_type` on the WIRE — the full Linear-compatible vocabulary a broadcast
- * carries (vs the stored row's core CRUD). `I`nsert, `U`pdate, `D`elete,
- * `A`rchive, `V` reVive/unarchive, `C`overing (gained visibility), `G`roupAdded,
- * `S` groupRemoved.
- */
-export const syncDeltaActionSchema = z.enum(['I', 'U', 'D', 'A', 'V', 'C', 'G', 'S']);
-/**
- * A wire delta payload: the post-mutation row object, a control-frame STRING
- * (e.g. a serialized group-change payload on `G`/`S` deltas), or `null` (on
- * deletes). Wider than the stored `data` (row-or-null) precisely because the
- * group/permission frames serialize a string.
- */
-export const wireDeltaDataSchema = z
-    .union([z.record(z.string(), z.unknown()), z.string()])
-    .nullable();
-/**
- * A nested participant reference as carried on a BROADCAST delta. The server
- * hydrates the flat `actor_id`/`actor_kind` stored columns into this.
- */
-export const participantRefSchema = z.object({
-    kind: participantKindSchema,
-    id: z.string(),
-});
-/**
- * The fields BOTH server and client agree on for a broadcast delta — the shared
- * contract. `transactionId` is modelled as the client sees it (optional string);
- * the server projection widens it to nullable. No `organizationId` (never
- * broadcast). No `createdBy`/attribution here — those types differ per layer and
- * live in the extensions below.
- */
-export const syncDeltaWireCoreSchema = z.object({
-    id: z.number(),
-    actionType: syncDeltaActionSchema,
-    modelName: z.string().min(1),
-    modelId: z.string().min(1),
-    data: wireDeltaDataSchema,
-    previousData: wireDeltaDataSchema.optional(),
-    syncGroups: z.array(z.string()),
-    transactionId: z.string().optional(),
-    createdAt: z.string(),
-});
-/**
- * Client projection — core + the SDK-only fields the client reads locally.
- * `z.infer` of this is the SDK's `SyncDelta` (see `sync/SyncWebSocket.ts`).
- */
-export const clientSyncDeltaSchema = syncDeltaWireCoreSchema.extend({
-    /** @deprecated Flat actor id; superseded by the server's nested `actor`. The
-     *  client never reads it — kept only so the wire shape round-trips. */
-    createdBy: z.string().optional(),
-    /** Client-only payload slot (e.g. legacy group-change metadata). */
-    metadata: wireDeltaDataSchema.optional(),
-    /** Echo-matching id the client correlates against its optimistic mutation. */
-    clientMutationId: z.string().optional(),
-});
-/**
- * Server projection — core + the audit attribution the server enriches each
- * broadcast with (for the audit pane). The client ignores all of it. Overrides
- * `transactionId` to nullable (the server's stored-column reality).
- */
-export const serverSyncDeltaSchema = syncDeltaWireCoreSchema.extend({
-    transactionId: z.string().nullable(),
-    /** @deprecated Mirrors `actor` 1:1. */
-    createdBy: participantRefSchema.nullable(),
-    /** Who DID the action. */
-    actor: participantRefSchema.nullable(),
-    /** On WHOSE AUTHORITY they acted (equals `actor` for human-direct commits). */
-    onBehalfOf: participantRefSchema.nullable(),
-    /** FK to AgentCapabilityRoot.capabilityId; non-null for agent/system commits. */
-    capabilityId: z.string().nullable(),
-    confirmationState: confirmationStateSchema.nullable(),
-    /** FK to AgentTurn.id — the prompt that caused this delta. */
-    causedByTaskId: z.string().nullable(),
-});