Oracle coverage and closeout#

Use Writing reliable oracle tests when adding or reviewing a law. This map identifies existing owners, their judgment, and their limits. It is not a claim that every state or every test has been audited.

The project glossary owns terms shared by these executable models and their production subsystems. A coverage owner may define narrower local terms, but it must not silently rename a production concept.

The 2026-10-10 owner-overlap review distinguishes canonical laws from their receiving witnesses across packages.

Scope of the oracle repair project#

Issue #1808 commissioned a bounded portfolio audit and repair. The September 11 inventory contained 329 tracked paths: 132 selected/support entries and 197 discovery-tier files. The latter received routing recommendations, not 197 full semantic reviews. Focused examples, type tests, and host-wiring tests remain useful; converting them all to generated tests is not a completion criterion.

Literate model audit#

The literate-model pass audits every primary executable owner in Find an owner and every repository file explicitly named oracle or property. Derive that strict inventory from the repository rather than copying a count into this document:

git ls-files -co --exclude-standard packages \
  | rg '/[^/]*(oracle|property)[^/]*$' \
  | sort -u

The command includes tracked and untracked package files so an in-progress audit cannot hide a new owner. A surface is complete only when each primary owner states its contract, model, history grammar, production driver, and refinement check—including its public observations and checkpoint—in the executable file. Focused regressions outside that inventory may remain short, but a file named oracle or property cannot use that allowance to omit the literate structure.

The pass must not change product behavior. If clearer prose exposes a missing model rule or assertion, strengthen the oracle and run it against unchanged production first. Track any production failure as separate follow-up work.

The same pass audits vocabulary. Shared concepts use the production names in the project glossary. The audit corrected model prose that collapsed a physical acquisition into a request or called an acquisition lease merely a lease. Model-only terms such as an appointment ledger or fault tape remain local and say what production facts they abstract. This is a semantic review, not a rule that test identifiers must copy production's private data structures.

Guide-audit boundary handoffs#

The includes-space owner (packages/db/tests/query/includes-space-oracle.test.ts) now varies leaves per twig across 0, 1, and 10. Public leaf rows change from 0 to 10 to 100 while 13 Collection facades remain. This protects facade ownership for the fixture's fixed root/branch/twig topology; route churn, D2 demand retention, and a heap bound need separate witnesses in the includes owners.

The virtual-row-fields owner (packages/db/tests/query/virtual-row-fields-oracle.test.ts) checks presence of all four public virtual fields directly after implicit, expression, and functional root publication. Its fixed controlled-Collection cases do not establish every nested projection shape or framework receiving boundary.

Three type-only owners check compile-time boundaries: packages/db-sqlite-persistence-core/tests/persisted-options-type-oracle.test-d.ts checks local and synced persisted option input/output and key types; packages/db/tests/mutation-handler-type-oracle.test-d.ts checks sibling Collection/key/utilities in mutation handlers; and packages/db/tests/query/virtual-row-fields-oracle.test-d.ts checks all four published virtual fields against an independently written public shape. Their passing type assertions do not prove runtime parsing, I/O, or publication.

The shared-driver fairness owner now distinguishes K=1 from K=2 at the second hydrate and checks full logical persist FIFO order in its Node seam. The Chromium OPFS receiving spec checks a cold SQL read, the K=1 hydrate bound, public rows, the pending persist backlog at the second hydrate, and all five logical persist completion IDs in FIFO order during one held-BEGIN storm through the real worker. This closes the bounded real-OPFS handoff at logical adapter completion for that history. It does not establish durable write order after reopen, naturally occurring contention, a browser matrix, multi-context coordination, elapsed-time latency, or unbounded eventuality.

The D2 source reconciliation owner checks its helper and controlled Effect and live-query consumers. Fixed truncate/replay and cleanup→preload graph-restart cuts run on both eager-index and scan-fallback routes. Its generated histories still do not cover arbitrary graph shapes or real provider event delivery; the Electric real-provider E2E owner must supply that external premise before a cross-boundary claim.

PowerSync's correctness owner reaches native local SQLite and records an SDK-delivered watcher callback after a metadata-bearing Collection.update; registration is wrapped for observation while delivery uses the SDK callback. The oracle checks the public and SQLite rows and the exact queued CRUD patch. Its held watcher callbacks are a controlled delivery premise, and its trailing no-op and tracked metadata-only cases enter through the public transactor with synthetic mutations rather than Collection.update. Neither path establishes remote backend upload or that Collection updates can construct those zero-field mutations.

The Query DB nested-shape work owner checks both an all-reachable finite tree and an on-demand irrelevant-branch variant. At preload, one or three disconnected branches leave the public tree and delivered rows unchanged and cause exactly one acquisition attempt and one Query provider call per child level. Provider scans, internal index traversal, facade allocations, and elapsed time remain outside this owner; DB includes-work counts source Collection reads and delivered changes, not internal index traversal.

Three Ordered acquisition companions own distinct controlled cuts: packages/db/tests/query/load-subset-replay-refinement-oracle.test.ts checks held replay authority and public snapshots; packages/db/tests/query/load-subset-source-readiness-refinement-oracle.test.ts checks source-generation readiness, progressive old-child retention, and retired-route publication; and packages/db/tests/query/load-subset-transaction-refinement-oracle.test.ts checks before, during, and after-commit abort boundaries with applied receipts. These fixtures do not establish real-provider cancellation or framework timing. The core load-subset-oracle.property.test.ts now distinguishes each exact demand-key option through one-axis pairs; its derived-sync expected-failure guard and controlled-adapter scope remain explicit limits.

The QueryRef owner checks DISTINCT support through source deletions, last-support removal, reinsertion, and person enable/disable. It checks nested and flat aggregate joins through source updates, and ordered joined findOne() through initial, singleton, empty, restored, and changed-join-key cuts. An unordered findOne() QueryRef used on either side of a join keeps one default-key row through deletion and reinsertion. The optimizer aggregate owner checks the initial public inner join of a global aggregate with accepting, rejecting, and absent outer predicates; a materialized-Collection formulation supplies matching and nonmatching controls. Other singleResult forms, join forms, and scheduling cuts remain outside these owners.

The offline scheduler owner (packages/offline-transactions/tests/KeyScheduler-oracle.property.test.ts) checks FIFO eligibility and retry order at the scheduler boundary. It does not observe the executor's awaited outbox update between updateTransaction and markFailed, or public caller settlement. Those receiving cuts belong with packages/offline-transactions/tests/transaction-settlement-oracle.property.test.ts. The transaction serializer owner uses controlled Temporal constructors and fake storage; a claim about native Temporal or browser storage needs a receiving witness in those runtimes. The offline settlement owner follows the README's success boundary: the configured mutationFn has returned and the storage adapter has acknowledged outbox deletion. Its controlled storage histories hold and fail deletion, stop the executor and queued peers on a storage failure, reject new admission, and restart after a persisted deletion-pending phase. A marked row skips provider replay even when beforeRetry filters all ordinary pending work; an old unmarked row still replays. Adapter tests prove that IndexedDB transaction failure and localStorage removeItem failure reject rather than masquerade as deletion. When a caller removes an active row with removeFromOutbox or clearOutbox while its provider is held, the caller remains pending until that provider returns. The controlled witness then checks provider calls, public settlement, and the empty outbox. The leadership owner checks that an earlier deletion-pending row with the same persisted timestamp is deleted before its later peer reaches the provider. This restart witness uses storage insertion order to distinguish creation order; independent storage writers and native browser hosts remain outside its claim. These witnesses do not establish physical power-loss durability, a real provider's idempotency, or the crash window between provider completion and the phase write. The provider must honor the supplied idempotency key in that window. Older application versions that do not understand the phase can also replay a marked row. Native browser restart and multi-owner handoff of the marked phase remain receiving witnesses for this owner.

The same owner also needs a captured failing seed-and-shrink-path replay for its generated settlement property. The deletion-settlement review record preserves its earlier executable revision. The fail-stop follow-up records the revised storage-failure law, RED/GREEN witnesses, and limits. The guarded replay owner (packages/db/tests/oracle-replay.test.ts) now checks that named pagination and index campaigns execute only the requested replay lane. An unrelated failing fixed campaign no longer runs first. The prep-PR review record records these four review repairs at their exact executable revision.

Recent fix-wave authority inventory#

This inventory records the permanent authority for the September 17 fix wave. It distinguishes an executable oracle from a specialized real-provider authority and does not award oracle credit for a filename alone.

PR #1816 preserves existing witnesses, repairs false-green assertions and drivers, adds missing histories, and includes narrow runtime fixes reproduced by the stronger tests. The later ten-area audit found 59 actionable findings or optional suggestions: 46 repaired, one partly repaired storage item, nine contract decisions, and three deferred suggestions. These are not counts of production bugs. The earlier 13-item review is a separate ledger, not another 13 unique defects.

Find an owner#

Paths below are relative to the repository root. Follow each suite's domain comment and the current API/architecture contract before extending its model.

For standalone descriptor queries, the primary owner is packages/react-db/tests/descriptor-query-binding-oracle.test.tsx. It checks one prebuilt Query with a reusable factory descriptor under two DbProvider clients. Disjoint-key inserts and same-key updates with different client values are compared against plain per-client maps after initial publication, each write, and a mounted A→B→A provider switch. It checks the public $key against each projected row ID, exact public key sets, and identity equality with direct Collection formulations. The same owner crosses join, nested FROM, union, and include placements of two standalone descriptors under two clients with equal row keys and different values. Complete selected rows are compared with plain per-client values after initial publication, a child write in the first client, and a parent write in the second. A first-client-only binding mutation fails at the second client's initial public-row assertion. This finite matrix does not observe on-demand requests or arbitrary write interleavings. The receiving include also crosses shadowed and renamed child aliases while projecting a captured parent value. It compares both clients' public rows at the same three cuts. An alias-only parent lookup fails the shadowed initial row while the renamed control passes. Dropping binding IDs during descriptor materialization fails the bound-versus-unbound public hash comparison in both alias forms. More include depths remain outside this cell. The receiving outer-join history crosses RIGHT/FULL, correlation on the main or joined source, shadowed/renamed aliases, eager/on-demand sources, and two clients with equal keys and different values. Plain per-client maps predict complete public rows after initial acquisition and five source writes, including an absent main side, an absent joined side, and return of the main side. It also checks each client's source starts, on-demand requests, and descriptor-binding hash. An absent-main join-route mutant fails the public-row check at initial acquisition. Multi-join receiving histories and arbitrary write interleavings remain outside this finite matrix; the core alias owner covers its own bounded multi-join grammar. The same owner also checks a prebuilt Query consumed by useLiveQueryEffect: two clients with the same row key report their own initial enter events, and one mounted Effect reports the new client's row after a provider switch. After that switch, an old-provider write produces no update event and a new-provider write produces one. The event-history check rejects an Effect that retains the old subscription. It checks that a descriptor Collection first acquired by a committed Effect appears in DbClient.dehydrate() after the first enter event. A separate same-hash transition from a concrete query to an unbound descriptor query checks that the hook reports the missing client before reusing prior rows. The same React owner checks that a descriptor render suspended before commit starts no source work, while a later direct Collection.preload() starts that source once and reaches ready. This is one abandoned-render/direct-reader cut, not a general concurrent-render schedule. Its no-client diagnostic also covers explicit queryKey and legacy dependency identity for both useLiveQuery and useLiveSuspenseQuery at first consumption. A local hook-first SSR stream over a concrete source rejects a later same-hash descriptor preload over a different source; the same source is accepted. A hydration-first stream has no server Collection objects in its payload. The first committed browser hook claims its local source objects for the hash before source readiness; a later conflicting preload rejects, and the public row changes from the server result to the browser result after readiness. Removing the hook's attach claim fails the conflict assertion while readiness is held. A pending hydrated stream also has a Suspense receiving cut: its uncommitted read preloads the first local source, so that source may start and claim the hash before React commits. A later same-source preload succeeds while a different same-hash source rejects. A mutant that skips the Suspense preload claim fails at the conflict assertion. This differs from an ordinary hook render with no explicit preload demand. This owner does not claim that a failed Svelte effect can recover in place after a reactive query replacement. packages/db/tests/db-client.test.ts supplies a focused nested-query preload witness across two clients, including equal query hashes and distinct dehydrated rows. packages/db/tests/db-client-preload-identity-oracle.test.ts owns the bounded same-hash preload law within one DbClient: the second local preload reuses a result only when its source Collection objects are the same at each query position. Concrete then descriptor, descriptor then concrete, and two concrete same-ID sources must reject a conflicting second request without changing the first dehydrated row; a same-ID pair swapped between union branches also rejects. A descriptor and its own materialized Collection may reuse it. For a hydrated hash, the first local preload claims ordered source-object identity; a later conflicting preload rejects for settled and pending streams. A newer hydration chunk keeps that claim. If the earlier local stream instead fails, a newer settled or pending hydrated result starts without its source claim. A healthy observer using a different same-ID source then attaches and reads its own row. The old preload entry cannot claim the new stream. Different explicit query keys, concurrent first local claims, and other failure/hydration orders remain outside this finite history. Observer preload checks that an active settled graph or pooled stream, and a pending hydrated graph stream, reject a different same-hash source through the returned Promise without a synchronous throw. Same-source pooled preload is the neighboring success case. A controlled reentrant registration collision also checks that a discarded stream Promise's later rejection has an observer; it does not claim that an official adapter currently makes this reentrant call. An ordinary observer's first subscription also checks an active stream claim before retaining its listener. With equal hashes, same-source attachment and public row read succeed; a different-source attempt and its retry both reject while the first stream remains active. A failed first attach leaving a retained listener fails the retry assertion. After the first observer's live result becomes authoritative, public dehydration omits the consumed client stream. The next observer may then attach with the same or a different source object under the same hash and reads its own row; the earlier preload entry cannot extend the consumed stream's source claim. Other attach failures and concurrent subscription orders remain outside this control. An adapter observer over a pooled view crosses the same-source and different- source cases for an existing stream hash. The former completes its own preload and reads the first source; the latter rejects before borrowing the first stream. Pooled views have no query Collection config, so this receiving path needs a separate source-identity witness. packages/db/tests/live-query-deferred-acquisition-oracle.test.ts also checks a two-source descriptor union when the first sync start fails: the second source still starts and reaches ready on direct preload, and a preparation error stays primary if a deferred source also throws during release. The controlled sources start synchronously. At the synchronous preload error cut, even a caller that opts to stream pending queries cannot dehydrate the failed query; a later same-hash preload over a healthy replacement publishes its own row. Asynchronous failure is also exercised with a later controlled markError: the pending stream rejects and disappears from dehydration, the peer source is ready, and a healthy same-hash replacement publishes its row. A mutant that dehydrates errored records fails at that cut. Other asynchronous schedules and larger source sets remain open. Retrying the same options after the source entered terminal error reports that source error instead of reusing the failed query's pending stream; it does not restart the source. A replacement observer subscribed after the controlled asynchronous failure can attach under the same hash and reads the healthy replacement row as ready, without a stale stream error, before a new client preload. The prior source-mismatch check fails that attachment assertion. The same history rejects a different-source preload while its original stream is still pending. A second fixed history crosses a synchronous source throw and then attaches a healthy replacement observer before a new client preload; its settled snapshot contains only the replacement row. Removing the failed-record source-claim guard fails that observer attachment, while ignoring every existing stream's claim fails the pending-stream rejection. The preload-identity owner also checks active streams. These histories do not enumerate concurrent replacement observers, other failure schedules, or later conflicting preloads while an observer has no reusable client stream. An observer preload over a config-free pooled view is also explicit demand: it starts an idle eager source once, does not restart a running source, and reaches a ready public snapshot in both cases, with or without an SSR cleanup client. This bounded witness does not claim the same path for on-demand or asynchronous sources. packages/svelte-db/tests/descriptor-query-release-oracle.svelte.test.ts checks Svelte's two-source release after a first startup error and a direct reader after a second descriptor factory fails. It observes source start counts, ready status, and failed-hook subscription release. A fresh effect root after the failed root is retired consumes an independent healthy query and its row. A controlled Svelte runtime probe showed that an uncaught effect error does not rerun the same effect when its reactive query changes; in-place recovery after that error is not promised. This owner does not establish two-client Svelte provider binding or ordinary reactive query replacement. Concrete- config descriptors, on-demand acquisition, and those Svelte paths remain open for this binding law; a receiving oracle needs the relevant public observation for each. Vue, Solid, and Angular have no DbClient descriptor-binding contract in this work. Their query callers use concrete Collections. packages/db/tests/live-query-options.test.ts checks that a client-aware consumer binds nested, union-branch, and include-child descriptors during final preparation. Construction retains descriptor refs in those positions, including direct, nested, materialized, and conditional includes. A prepared builder is a bound snapshot; a later descriptor join remains unbound until another client-aware consumption. The focused core tests check source materialization and sync starts before and after release of a render deferral set, plus the missing-client error for direct consumption. The React descriptor oracle checks public rows after a committed hook consumes such a continuation and zero source starts when a render containing one never commits. These bounded checks do not compare union or include rows under separate clients, or concurrent render schedules. The original standalone Query remains the reusable two-client plan; rebinding a previously prepared snapshot to a different client is not claimed. packages/db/tests/query/collection-ref-compatibility.test.ts pins the exported IR.CollectionRef shape for concrete Collections: collection is an enumerable, writable own field that a spread copies. It also checks that an unbound descriptor uses IR.DescriptorRef with no collection field. A bounded source-position matrix checks collection, nested query, union, join, and include IR traversal and conversion to concrete refs during placement cloning. This focused shape test does not establish public rows for those query forms or generic visitor behavior outside the named collectors.

The Query DB ownership oracle owns the direct-write no-automatic-refetch law (review). Its real QueryClient witness loads ten disjoint on-demand subsets, then checks writeUpsert, writeUpdate, writeDelete, writeInsert, and a mixed writeBatch. After each accepted write it compares public live-query rows with an independent category filter and checks that no provider request started. The pre-repair implementation failed this request check with ten requests after one upsert. A held deferDataRefresh barrier adds a request checkpoint after release; the pre-review implementation made an unwanted request there. A derived-select witness checks that a direct write cannot replace an edges array with node objects. It permits a stale cache row while requiring a valid response envelope and the accepted public row. A direct-insert/unload witness keeps a manually written row after its queried peer retires; assigning every insert to the active subset fails that public-row checkpoint. Existing sibling cache witnesses reject retaining inactive entries under the Collection's base query-key prefix, including entries seeded before sync starts. The load-lifecycle oracle separately owns explicit refetch settlement; the ownership oracle checks that an explicit refetch after a direct write starts a post-write request when the initial fetch is still pending. A direct write alone starts no request. These bounded witnesses do not establish exact Query cache membership, ordering, or window replacement after a direct write. The ownership oracle owns future scoped-cache witnesses; the cursor-pagination oracle owns windowed receiving cases. The offline-transactions owner still needs a full reconnect-replay witness for its real deferDataRefresh premise. The ownership oracle also owns a later-remount witness after an inactive prefetched entry is evicted, and direct-insert retention across persisted restore remains with its persisted-owner histories.

The ownership oracle also checks per-key precedence when a held on-demand refetch meets a later direct update, error and invalidation/freshness metadata across cache patches, one patch per physical Query under a colliding hash, and owner-bounded key extraction for ten disjoint 1,000-row subsets. An eager derived-select remount witness rejects replaying its stale envelope over a direct write; a foreign-observer witness permits an old inactive cache value while requiring the public row to survive remount and release of another owner. These controlled Query Core histories do not establish arbitrary select inverses, exact scoped membership or window replacement, every custom hash collision, or unbounded performance. The Query DB ownership oracle owns further direct-write cache histories; cursor pagination owns windowed receiving behavior. A caller using direct writes must accept the scoped-cache limits or request an explicit refetch.

The ownership oracle also checks five later boundaries from PR #2065 review: a derived select still applies a held fetch's rows and settles eager readiness after a direct insert; overlapping explicit refetch callers follow the replacement request after a silent cancellation; a fetched result queued behind a persisted-baseline scan cannot overwrite a later accepted write; a zero-lease subset observer retained by a listener receives a direct cache patch before reacquisition; and eight retired on-demand subsets leave no fetch-start positions (removing the retirement call fails at eight retained entries). The Query error, invalidation, and staleness checks now cover both eager and on-demand modes. These are controlled Query Core and persistence seams. They do not establish every derived response shape, arbitrary overlapping refetch schedule, native SQLite timing for the queued-result cut, or unbounded cache-memory growth. This owner retains those boundaries; the persisted direct-write oracle owns native durable-order receiving cases. The retained-Query witness holds an empty-cache fetch across subset unload and reacquisition. A direct delete then requires an explicit refetch to start a post-write request and preserve the deleted public row at settlement; without a later write, the same refetch may reuse the in-flight request. A separate checkpoint keeps the detached fetch-start position until that request settles and retires it afterward. Two further shared-Query histories add A's sync restart after a direct insert/delete while B's pre-write request remains in flight. Without an explicit refetch, the old result must preserve the delete; with one, A must start a post-write request. Both were RED before physical fetch-start positions survived the restart and are GREEN afterward. These controlled histories do not establish every persisted adapter or Query cache-removal schedule. The intermediate review at 74e399150 adds ordinary-unload and unobserved-fetch histories to that request-order law. The final direct-write authority review records the later law decisions, RED/GREEN evidence, and ten-item audit. The four-review follow-up audits legal subset predicates, cache-projection boundaries, scoped omissions, and the generated cursor manual-write campaign against its repaired commit. The ownership oracle also checks derived-select reacquisition and eager restart, explicit subset refetch, a derived result held behind deferDataRefresh, a provisional cache row awaiting persisted application, aliased physical Queries, and the boundary between an in-flight pending Query and an idle empty cache entry. The cursor-pagination integration oracle supplies the idle-entry control. Its shared-Query reset history holds B's acquisition after A's direct cache patch, resets the physical Query so the next fetch repeats the patch's numeric update count, and requires B's load to settle on the new provider row. It runs with a new response array and with the patch's exact array reference. This checks the authority boundary at fetch settlement, but does not model every Query Core reset schedule or custom-hash collision. An outside-prefix custom-hash collision remains in Query Core's cache after a direct write. The disabled reacquisition witness requires the load to wait for an explicit provider result, then checks that result and ownerless-row retirement. It covers one physical alias and an unbounded scope, not arbitrary hash functions or windowed scopes. The ordinary-unload, provisional-row, and alias tests reject their respective hostile classifiers at public-row or cache checkpoints. These finite histories do not establish every persistence schedule, every Query hash collision, or a full offline replay; those remain owned by the Query DB ownership and offline receiving oracles. Query Core 5.90.15 is the lowest version on which the full Query DB suite passed; 5.90.14 failed error-recovery witnesses, and 5.85.2 failed the post-write refetch witness. Older versions are excluded by the peer minimum.

The ownership oracle now checks a direct row's ownership lifetime across one and two subset claims, with and without Collection row metadata. A direct update preserves those claims; a direct delete ends them; a later insert or upsert of the same key starts unowned; a later Query result can claim the new row. Its 20 bounded histories compare accepted public rows and exact persisted owner identities after each action and subset release. Removing the delete-retirement repair fails nine histories at those checkpoints. One real SQLite receiving history releases both former subsets, restarts the Collection from the same storage, and keeps the reinserted unowned row. A controlled persisted snapshot restart also retires two overlapping claims one at a time and compares durable owner identities and public rows after each empty result. This does not establish every persisted adapter, overlapping result schedule, or ownership of an inferred window replacement; the persisted direct-write owner retains the wider durable receiving boundary. Shared-Query cached-result authority across an unobserved Collection is now an accepted law: a newer physical fetch may replace and claim a direct row on later acquisition, while an older cached result or another Collection's local cache edit may not. The 24-history matrix crosses fetch/write order, a later same-key or unrelated write, a local cache edit, and another real refetch. It compares public rows at acquisition and subset release and checks that acquisition did not start an extra request. The pre-repair implementation failed the post-write and unrelated-write orders; removing fetched-data provenance fails two local-cache-edit histories. Two real SQLite receiving histories restart A as a fresh Collection instance while B retains the shared Query, with and without a later local cache edit. An ownerless stored row colliding with the cached result has unknown order, so acquisition refetches once and the new server row wins. Without that guarded revalidation the original receiving history kept the direct value. These finite histories do not establish every persisted adapter, a cached result without a colliding key, or a cross-process Query cache hydration order.

Further controlled histories compare an accepted direct insert with a cached server row across cleanup and restart, so a discarded run's write position cannot suppress that row. The insert/delete neighbor distinguishes a stale position from intentional row deletion. An equivalent-predicate alias history coalesces two logical demands into one physical Query: a held pre-write fetch must preserve the accepted direct row, while a later fetch can replace it. A shared-Query history also checks A's direct insert while only B has loaded the Query; B's public row and cache stay on the server value until a newer fetch. The latter history rejects a cache patch that depends on A already owning a subset. A stable empty persisted result avoids repeated full-store scans on retained reacquisition, while a cold run still scans and retires a newly seeded durable owner. A nonempty provisional result still takes the baseline scan before applying. These checks use real Query Core observers and controlled persistence; they do not cover every custom hash collision or external durable writer. The overlap matrix below covers two requests and one shared row.

The shared-Query authority histories now also vary peer acquisition timing: both Collections loaded at the write, B loaded while A is not, and B acquiring after A patched the cache. The latter rejects a local edit leaking into a late peer at a held-request public-row checkpoint, then admits the later server result. A real SQLite restart matrix distinguishes a persisted ownerless insert from an owned direct update against a shared pre-write cache row. It compares durable storage after cleanup and the fresh Collection's row after acquisition; an owned row cannot silently revert to the cached older value. Two alias schedules separately reject omitting the observer-attach fetch position and omitting propagation of a later physical fetch position to all logical observers. A directly selected response property checks the same late-peer rule as a raw array. A failed replacement fetch reaches the peer's public error state without publishing the other Collection's local edit. An outside Query observer retains A's own cache patch through cleanup; A's next sync run must request a new result rather than replay that old patch. A separate owned-row history checks that queryClient.setQueryData can update B but cannot replace A's later accepted direct value; a real post-write fetch may replace it. A held-fetch history checks the local edit before that provider result, and a sole-owner unload/reacquire history requires a new result before the manually edited cache can establish rows again. Eager shared-Query histories require compatible Collections to project the same representable cache patch. They cross active co-owners, a new direct key, a later or disabled peer, a cold cache seed, an older held fetch, and a later complete result. They compare A and B's public rows and the shared cache at write and fetch-settlement cuts. A held B application checks that disjoint writes alter only their own cache keys while preserving the peer's edit, for raw rows and a directly selected { items } envelope whose unrelated metadata must survive. An eager writer's representable edit also reaches an already-acquired on-demand peer sharing its exact Query, while an unacquired peer waits for a server result. An eager peer with a derived visibility filter projects a direct-property writer's cache edit. A disabled eager peer projects a cached edit without a request; a disabled on-demand peer waits for an explicit refetch. A held persisted direct commit crossed with a refetch start compares public and durable rows before the provider responds, then after a newer response; eager and on-demand modes both reject replay of the old cached success.

A complete matching on-demand refetch removes an omitted ownerless direct row, whether the result is empty or nonempty. A real SQLite restart witness confirms that the complete filtered fetch ran, retired the matching durable row, and preserved a disjoint durable sibling. Unload alone, disjoint, limited, offset, cursor, or failed results leave the row intact. Empty disjoint, offset, and cursor results and matching/disjoint compound predicates check the completeness and membership boundary at public-row settlement.

A seven-history overlap model crosses prior ownership, both request settlement orders, equal-value responses, and direct writes between or after request starts. Its provider rows satisfy real IR.PropRef predicates; a fixture guard rejects literal-field comparisons that would make these histories illegal. It compares the public row after each result and after releasing both owners in either order. The older response may add an owner without replacing the later-started fetch's value while row ownership remains continuous. After full release, a receiving witness reacquires each retained Query with infinite staleTime and gcTime: each cache entry projects its own value without a new request. A complete response that omits an ownerless direct row settles that row for its matching scope; it does not tombstone older responses from other Query entries. A cross-scope omission-ordering guarantee would need a separate law and model. The original implementation fails three reverse-settlement histories. A separate real Query Core history writes inside an observer's success notification; a late on-demand peer must not mistake that cache edit for the fetch action's payload. The original implementation fails at the peer's held-request checkpoint. These finite histories leave same-run external durable writers, larger overlapping-fetch schedules, and direct-patch provenance after Query cache dehydration outside their proven scope.

The alias-scope owner also has a compiler invariant witness for a malformed include plan: removing a captured ancestor's parent projection after the builder creates it must fail before child rows are read. Without that check, the plan compiled and a shadowed child could read its local row. The original Query-builder paths remain covered by the owner's public-row histories; this invariant witness does not claim arbitrary manually constructed IR is valid.

The following related oracles own distinct production paths or observation cuts:

• The Collection lifecycle publication oracle owns exact public rows and change batches. The replay oracle applies that law to competing replay schedules and same-key writes. Bounded three-row histories now compare a subscription's selected keys with callback key/type batches across full, explicit, filtered, and empty snapshots, two later ordered selections, both initial-state modes, and callback reentry. A delete and reinsert checks that selection can reset. A 12-case callback matrix also crosses new insertion and delete/reinsert with filtered, full-state, and skip-filtering subscriptions, with and without a cursor. It checks callback batches after each source commit and checks retained-key count after deletion. Source-callback reentry also selects an unseen ordered row after publishing another key. A controlled three-row offset provider checks sparse callback and ordered callback-reentry histories in both initial-state modes: local selection does not establish a provider prefix. A second offset-only adapter checks cursors near the end of three- and seven-row sources: without an explicit offset, the request must be unbounded because no finite prefix derived from local keys can reach an arbitrary cursor value. A four-cell optimistic-overlay matrix submits a new ordered request after one or two pending deletes or predicate-removing updates. A plain remote array checks that the provider page reaches the first still visible remote rank. The source commit can remain queued behind the mutation, so this is a request-bound check, not an immediate-publication claim. The replay owner checks a filtered snapshot followed by an ordered selection during a pending direct truncate replay, including callback reentry before the target receives the source transaction. It also settles a repeated ordered replay and compares public batches before and after settlement. A sparse successful replacement checks that an adapter honoring a last-key cursor can still acquire lower-ranked rows. The snapshot-selection review records the baseline and reservation-removal mutant kills at public-row, request-bound, and replay checkpoints. The controlled providers cover three and seven distinct ranks and the tested request schedules; arbitrary rankings, provider-specific pagination contracts, and compiled live-query windows remain outside these owners.
• The pagination oracle owns general ordered-window rows and publication. Its optimistic overlay matrix crosses one and two pending source deletes or rank moves. It checks that a submitted provider page reaches the independently modeled window, then accepts the mutations through source sync and compares final public rows. A second matrix holds one or two optimistic inserts or rank moves while an indexed window widens. It crosses cursor-expression and offset-only providers, including windows opened from zero. The plain remote array checks the needed provider rank when a request can start before settlement; after source acceptance the public window must equal independent recomputation. The original six failing cells and narrow overlay, padded-boundary, and delayed continuation mutants reached these request or public-row comparisons. Settled ten-page traversals bound returned provider row volume and use only cursor-expression and offset transports. CollectionSubscription cannot emit lastKey; the TrailBase adapter test covers an external last-key caller and shows that core requests do not retain unused opaque cursors. Direct ordered subscription requests without an explicit offset may repeatedly load a growing prefix; with a cursor and no offset they may load the full source, because the adapter is permitted to ignore cursor expressions. The ordered-work oracle rechecks rows while bounding eager indexed and joined work. These finite matrices do not establish arbitrary overlapping optimistic histories, ties, or provider-specific cursor behavior.
• The IR identity oracle owns demand-key encoding. The load-subset oracle owns runtime sharing and retry. The transaction refinement oracle owns abort timing around sync acceptance and publication.

The LocalStorage owners above also cover the peer and materialization review: a failing same-tab receiver cannot revoke a durable writer receipt or block later peers; a nested peer write remains authoritative through a later update; a DbClient Collection and its module-level manual utility share one write order, including before explicit preload; unrelated equal-ID Collections cannot borrow that utility even when they share the Storage object and key; startup validation fails before begin; and clear reads once per active receiver. The default JSON writer avoids a second full parse only when its saved bytes remain current. Custom parsers still read back. These finite witnesses do not establish recovery of an invalid writer key extractor or manual acceptance without a mutation Collection owner.

The follow-up oracle review adds direct-owner idle, ready, and cleaned-up histories for module-level acceptance into a DbClient materialization. It checks the manual receipt, durable snapshot, active public snapshots, and fresh restore. A hostile subject that drops transaction commit work fails the held-receipt checkpoint. The peer owner checks a peer write admitted by a restore subscriber, custom-parser normalization of an authored insert and update without a version-token change, invalid events followed by same-token repair, and malformed stored row shape or key identity before startup opens a sync transaction. The order owner checks a handler-free direct write at method return immediately after a synchronous handler failure. These finite witnesses do not prove arbitrary reentrant subscriber histories or cross-tab atomicity. Default JSON intentionally keeps the writer's authored rich value until restore; a Date witness records the public/durable representation difference.

The second LocalStorage review extends the peer owner across unchanged versus changed version tokens for an untouched parser-normalized row. At a fulfilled receipt it compares writer, peer, durable bytes, and fresh restore. It also checks duplicate decoded keys, serializable NaN-derived keys, nonfinite default-JSON row IDs, and prewrite versus postwrite read faults. The order owner holds an earlier handler while manual acceptance is followed by a mutationFn failure, then compares both receipt cuts and the eventual public, durable, and restored rows. A direct nested peer write replaces the unsupported manual-acceptance fixture. These finite histories do not establish arbitrary parser side effects, concurrent cross-tab writes, or every possible row serialization shape.

The boundary audit crosses default-JSON native-value retention with a disjoint same-tab peer write: the writer keeps its authored Date while receiving the peer's row, and a later same-key peer edit replaces that Date. Writer, peer, durable bytes, and fresh restore are observed at the peer receipt. A throwing writer subscriber after Storage acceptance does not revoke the receipt or prevent peer publication. The controlled host does not establish arbitrary native values or toJSON side effects, many-operation histories, or native browser scheduling. Those need a widened peer-owner value/history grammar and a receiving browser witness.

The LocalStorage peer owner checks descriptor admission after three failed constructor boundaries: invalid index configuration before sync binding, controlled browser-listener registration failure during sync startup, and a missing on-demand loadSubset handler after a browser listener was acquired. A corrected retry must persist; a third construction and reuse after successful owner cleanup must reject. The original owner can restart and persist, while controlled browser-listener counts return to zero after failure and cleanup. Paired hosts compare the Storage reads caused by one later same-tab write; the failed-construction host has one extra read on 8b3debb3a, exposing an abandoned same-tab callback. These checks cannot prove that a failed Collection is no longer retained by a private adapter closure or an inert callback in the same-tab registry; those resource-retention claims need a receiving lifecycle/GC witness owned by packages/db/tests/local-storage-peer-oracle.test.ts. Native browser listener failure and host scheduling remain outside the controlled history.

The React source ID reuse oracle (review) checks that a mounted derived-identity hook rejects a different same-ID source Collection directly, after an intervening ID and predicate, within one query, and after source cleanup. Stable sources, new IDs, a fresh hook after cleanup, and independent client scopes remain usable. Returning to a prior client scope retains that scope's binding, including through DbProvider. A suspended render that starts a source query also claims the ID until unmount. An infinite-hook driver runs direct reuse, reuse after another ID, the same object and a new ID, reuse after a suspended render, and deferral release on rejection through useLiveInfiniteQuery, whose render-time collection cache is keyed by the same derived identity. Separate client-scoped Suspense hooks and an initial suspended retry keep their same-ID sources distinct. A rejected collision render releases sync-start deferral for a different shared client descriptor; a later direct reader reaches ready and observes its row. The public rerender error, status, or row is the observation cut. A second controlled history makes two deferred sync starts throw and checks that a later shared source still starts and publishes its row. This distinguishes releasing every pending source from stopping at the first startup error. The first thrown error still reaches React's error boundary. This owner does not constrain explicit queryKey, direct Collection input, or legacy dependency-array identity, and it does not install a process-wide ID registry. Real persisted SQLite sources and DbClient SSR preload/streaming remain outside this controlled React driver. A space policy for a mounted hook that visits unbounded distinct source IDs remains open; this owner needs a bounded-navigation counter witness once that policy is chosen.

The SQLite core binding-capacity oracle in packages/db-sqlite-persistence-core/tests/sqlite-core-adapter-oracle.test.ts is a bounded owner for issue #1993. The review record gives the exact executable revision and guide audit. It failed on the original 900-item chunking and passes with one JSON table binding per runtime IN list and a statement-total fallback. It compares independently filtered rows and typed values with loadSubset on real Node prepared SQLite statements. Node versions that expose the configured 999-parameter limit use that native cap. Older versions use a controlled driver that rejects over-cap bindings before SQLite preparation; the oracle tests that guard separately. Fixed and generated cases cover empty lists, 998/999/1000 single lists, 499+500 and 500+500 statement totals, mixed scalar/list and nested predicates, root and distinct transaction-driver routes (including an omitted transaction cap at the 100/101 driver boundary), signed-64-bit BigInt edges, escaped strings, an ordered two-hit list across the old 900-item chunk, both cursor SELECTs, and a 1,000-scalar fallback. Both index-definition IN contexts must remain literal SQL. The existing CLI large-list test substitutes values into SQL and cannot witness parameter capacity. This new owner does not establish behavior for null, nonfinite, container, or structured values; 50,582-ID stress; JSON-function availability; the cost of a full-table fallback; concurrent writers; or browser, mobile, Tauri, and native-host execution. The core owner needs typed equivalence and row-read work witnesses before claiming class closure. Each host driver owns a receiving capacity witness for its real SQLite engine.

The Query ownership oracle checks that a direct-write promise stays pending while a controlled persisted adapter holds its sync commit and settles after the adapter stores the row. It also checks that all five direct-write methods reject after cleanup starts and that a restarted sync run can persist a new write. Focused Query tests check a synchronous batch callback returning another Collection's write without losing either write, while an async callback still rejects. They also check two serialized updates: after each awaited response write and mutation settlement, the public row shows the server revision. These witnesses cover an eager Query Collection after initial load with a controlled adapter, not a direct write already in flight when cleanup starts, native SQLite, or overlapping Query revalidation. The Query ownership and optimistic-history owners still need a joint generated witness for competing source writes around mutation settlement.

The hash-identity owner also runs every law in a second module copy whose initialization draws are all equal, so every type marker has the same hash number in any declaration order. There it checks equality verdicts, equal hashes for equal identities, cycle rejection, and a topKBatch Map-to-Set replacement. No distinct-digest check is needed: a legal 32-bit collision cannot weaken the equality verdict. This closes the equality type-separation witness for every generated carrier. It does not prove hash collision freedom. Generated Map keys include numbers, symbols, references, and containers, and the model merges keys under SameValueZero.

The NaN ranked-window review records an eager direct-source refinement in the pagination owner. It covers initial ascending and descending windows, two NaN tie values, an offset move, and equal, changed, and deleted source ranks. On-demand NaN rank acquisition, joined queries, and null/NaN order combinations still need public witnesses in the pagination owner before they support a broader claim.

The Angular conformance driver checks a required signal input on a real TestBed component. Angular assigns the input after field initialization, then the driver checks rendered data and exact selected IDs after initial change detection and one input change. The driver supplies the AOT-equivalent signal-input flag because this suite uses Angular's JIT test environment. It does not exercise Angular's AOT compiler, older Angular runtimes, or every scheduler cut. The same driver checks that an explicitly disabled query reports disabled and ready before effects run.

The query identity owner generates both equal and unequal primitive string pairs. Its fixed pairs also check public groupBy rows after initial publication. End-to-end subset-demand reuse is still unproven: the demand-key check observes internal identity only. The identity owner needs a subscription witness that compares public rows and acquisition counts after equivalent and distinct predicate demands settle.

The subscription callback-reentry companion kills eleven guard-deletion mutants at the named request, resource, status, replay, or retention checkpoint on the reviewed production head. It also checks that releasing a direct snapshot during an unoptimized callback or snapshot evaluation prevents publication. A combined-predicate loader case checks release by the original request predicate before the loader returns. Three guards remain for a separate code-weight review (SUBS-09): M1's generation check after loadSubset is followed by demand-membership and generation checks after cleanup removes a starting demand; M6's replaced-state check before restart setup is followed by detached-demand and replay-state checks; M8's releaseAttempted true branch was unreached in 538 focused tests and its callers remove or detach ownership before invoking adapter unload. These are bounded equivalence arguments, not permission to delete the guards without a separate review. The companion does not establish arbitrary provider callback behavior.

Row canonicalization before the result boundary now runs only for DISTINCT, which tracks visibility by selected value; removing it fails the functional projection oracle. Ordering already consolidates each key's batch before top-K state changes, and materialized relations reduce by public key. Removing the former parent-route, non-Collection source, join, grouping, ordering, and includes conditions passed the whole @tanstack/db suite and a TANSTACK_DB_ORACLE_RUNS_MULTIPLIER=10 oracle campaign. Without the keyed reduction, live-query-result-multiplicity.test.ts witnesses the output boundary rejecting a flush that changes one key by more than one row.

The Collection lifecycle publication owner checks 32 bounded histories in which cleanup interrupts nested publication deferrals and a restarted sync run later publishes or discards one or two source rows. It compares the next subscriber's exact batch when the new deferral closes, including an old handle closed before or during that deferral. The includes publication owner still needs a compiled includes witness for cleanup during a discarded source deferral, followed by a parent or child publication at its callback boundary.

packages/db/tests/query/group-by-work.test.ts owns the work law for grouped aggregates: a change costs the same number of iterator steps at every group size, for a groupBy count and for an include count. group-by.test.ts checks which member supplies the value of a group whose members are equal under query equality but differ exactly, in both arrival orders. It also checks that min and max equal a remaining member's value after each delete, for signed zero and Dates and for stored and rebuilt arguments (review). Open: no law observes which parent supplies an include route's parent context, because a single-group include aggregate drops non-aggregate select fields; parents equal under query equality but different exactly share one route.

The Temporal group-key oracle owns the db-ivm groupBy value boundary for the eight Temporal kinds recognized by structural hashing. It compares public group counts with fixture-defined identity classes after one input batch, including distinct and matching fresh values and a plain object with its own spoofed Temporal tag. Nested serialization controls cover records, arrays, Maps, and Sets. Incremental retractions and unsupported symbols, cycles, and mutable RegExp state are outside this owner's bounded domain. The owner uses db-ivm's established kind-and-string Temporal key domain. Alternate representations remain separate: Durations such as PT1H and PT60M form different groups even when they compare equal. The supported inputs are ordinary native Temporal values or values from one polyfill copy. A custom prototype that impersonates Temporal can still merge a plain object with a genuine value. A genuine value with a replaced prototype can split from an equal value. Both altered-prototype cases and separately loaded polyfill copies are outside this contract. The oracle still protects a plain object's own spoofed tag without a custom prototype.

The includes publication oracle now checks one held ordered repair with two public parent rows and one inline child. Its bounded history crosses a single-step row move, a private value change that returns to the prior value, and a final value change. It compares root Collection reads and subscriber callbacks with an independent sorted source Map, and checks Effect callbacks against the last callback-visible row. Its optimistic rollback histories also require the callback to be reached and compare the restored public rows and callback trace after rejection. This rejects a final-row-only check that misses a torn callback publication. The DEC-02 review record retains the RED and mutant evidence. The receiving Collection-valued owner (packages/db/tests/query/includes-collection-oracle.property.test.ts) now checks a held finite ordered child repair request with A→A, A→B→A, and B→C histories, facade identity, silence during the hold, final child order, and subscriber delivery. The optimistic owner (packages/db/tests/query/includes-optimistic-oracle.property.test.ts) checks a same-root-row optimistic update during held ordered repair, comparing exact public snapshots and change events before release, after release, and after rollback. Both use controlled provider timing; real-provider ordering remains a separate receiving handoff.

The ordinary committed-transaction companion in the SQLite resume-snapshot owner checks durable rows, row and collection metadata, expected-key evidence, tombstones, applied position, idempotent reapply, and replay threshold behavior for bounded insert, partial-update, delete, metadata-only, and repeated-key histories. Its fixed and random generated campaigns cover a two-row seed, ordered action prefixes, seven required action/metadata suffixes, optional dependent updates, and late-bookkeeping rollback, comparing durable state after each settlement. The generated grammar is bounded to two writable string keys, one absent metadata key, up to 60 prefix mutations sampled in short, middle, and long bands, three row-metadata and two collection-metadata prefix actions, and up to three committed positions; it does not claim arbitrary histories or concurrent owners. Every generated seed, candidate, dependent update, and late rollback must enter exactly one SQLite transaction; counters are captured before durable snapshot reads. A separate fixed/random generated work grammar covers 0–60 distinct keys, six insert/update/delete/row and collection metadata shapes, and 100/999 parameter caps. It checks durable values before applying the same proposed chunk-bound work law; all repeated-key histories now check a distinct-key work bound after both committed and rolled-back candidates. A fixed 205-update single-key case drops from 824 to 8 query/run calls against a bound of 18. Truncate cases require overwritten invalid row and metadata values, including unbindable undefined collection metadata, to reject and roll back. Fixed 25/26 and 10,000-row cases separately witness the independent-key work boundary. Both fixed and generated independent-key work laws were RED on ef1e6a4 and are GREEN with ordinary batching: the 10,000-row insert plus metadata takes 505 query/run calls instead of 50,005. A later 125-row-ceiling follow-up checks 124/125/126 rows under a 500-parameter host cap; the 10,000-row case now takes 405 calls. A temporary repeated-key classifier mutation fails the generated oracle at the candidate durable checkpoint, seed 1992, path 2:0:0:2:2:2:2. A temporary chunk-limit mutation passes the Cloudflare 25-row case but fails at 26 rows under the 100-parameter guard. A collection-metadata classifier mutation that ignores repeated keys fails at the durable checkpoint for a set/delete history. All mutations were restored. The Cloudflare receiving driver also persists ordinary writes with row and collection metadata at 25, 26, and 205 rows within that guard. Its Node SQLite storage seam does not establish Cloudflare Worker execution. The synthetic node:sqlite seam does not establish OPFS worker scheduling, browser latency, or native-device performance. Tagged-value serialization, unavailable key evidence after raw loss, concurrent schema migration, WAL across processes, and arbitrary longer transaction histories remain with their existing owners or need explicit future witnesses.

The SQLite resume-snapshot owner also checks a cold, unique-key, non-delete full replacement with 205 rows. It compares exact durable rows, row metadata, key-set evidence, resume metadata, and applied position at transaction return; the driver query/run count is bounded, and a later-batch fault rolls back the whole transaction. Duplicate-key and delete histories keep their sequential semantics. This in-memory driver-call law does not measure Chromium OPFS latency, worker scheduling, or an end-to-end Electric snapshot.

The Cloudflare Durable Object test applies 25-, 26-, and 205-row full replacements and ordinary writes with row and collection metadata through the actual Cloudflare driver. A storage seam enforces Cloudflare's documented 100-bound-parameter query limit and checks durable keys and metadata after each transaction. Its subset receiving witness compares exact rows for 100 and 101 equality or one-item IN clauses through both savepoint and native transaction drivers; the same seam rejects a statement above 100 bindings. The original transaction driver exceeded the cap at 101. This Node SQLite seam does not execute in Workers or prove native JSON-function support.

The browser OPFS lifecycle owner also checks that a silent initialization rejects at the default or overridden open deadline, terminates its worker, ignores a late response, and releases the deadline and abort listener after a successful open. It also checks an abort during synchronous option evaluation, after the initial signal check but before listener registration. A Chromium fixture holds the VFS database Web Lock while a second tab times out. It checks that the queued request disappears, then reopens the database after releasing the lock. This controlled lock holder does not reproduce a frozen tab or establish behavior in other browsers. The issue #1883 review record preserves the exact-head unit and Chromium evidence and the queued-lock mutant.

The ordered-work owner also checks that an Effect with skipInitial waits for joined demand before ending initial callback suppression. A deterministic work counter rejects an extra joined-filter graph schedule on root readiness while preserving the joined-source wake-up. Nonterminal per-demand failure recovery is outside this owner: failDemand enters terminal live-query error while its plan record remains unsettled until sync teardown. A future recovery contract must reconcile plan and subscription pending state before reopening publication. Its startup witness covers one synchronous rank update after an indexed page load and before the last source subscription returns. It does not cover every source ordering, multiple buffered mutations, or asynchronous startup changes. The ordered Effect startup review records its baseline and hostile-mutant observations.

The Collection lifecycle change-event history owner also checks eager auto-index equality buckets and fresh indexed eq live queries against its independent row Map. Its required same-turn delete/reinsert prefix reaches an already-built index for both BasicIndex and BTreeIndex. In the batched lane, public rows and equality buckets are checked after each mutation returns, before any transaction is awaited; the batched final state and each sequential settled prefix are also checked. Fresh indexed queries are checked at the final checkpoint. Fixed and random tails check nearby legal histories. One temporary mutant that skipped index updates failed the fixed batched final count: one indexed key versus two model rows. Another fault that preserved the final keys failed the new returned-mutation check. The direct index refinement owner does not prove this Collection mutation path. Callback-time index agreement, the reported insert-seeded string-key setup, adapter cancellation, and non-local-only persistence remain outside this lane. The issue #1912 review record records the grammar controls, exact reviewed commit, and ORC audit.

The live Electric immediate-reload witness checks one Chromium/OPFS history: an onInsert handler receives PostgreSQL transaction evidence, awaitTxId and the optimistic transaction settle while the source row's adapter write is held, and a hard page close is followed by an empty raw OPFS snapshot before the recovering Collection or Electric starts. After release, the witness checks the exact public and durable row from live Electric and records that the reopened page sent no user-insert request. Public rows are polled before durable snapshots to avoid a full OPFS read on every pre-publication tick. This bounded history does not prove Windows/Edge behavior, offline recovery, arbitrary later re-inserts, or a durable-acknowledgment contract for awaitTxId.

The PR #1914 follow-up review record preserves the held-checkpoint and extra-POST mutant results at the exact reviewed executable commit.

The PR #1902 review record also covers one-pass queued-sync cancellation, partial-update dependencies on queued source rows, and focused late-hydration cases in packages/db/tests/db-client.test.ts. Those cases cross queued adapter insert and delete with a held local mutation. The DbClient hydration authority oracle crosses applied adapter insert, update, delete, and truncate with hydration before and after the applied receipt. It includes delete/reinsert and truncate/reinsert controls. These owners do not establish arbitrary hydration stream order, a later authoritative hydration epoch, or unbounded retention.

The two-tab OPFS remote-subset oracle now exercises a real Chromium follower with a QueryClient-backed, filtered on-demand live query. It checks the function-bearing local request, clone-safe follower post, public row, and rejection of an invalid nested wire value before transport. A raw-options mutant fails with browser DataCloneError. The review record names the exact reviewed commit. The test does not run React, Firefox/Zen, or a live backend, and it does not settle exclusive OPFS ownership during leadership transfer.

The two-tab live Electric OPFS oracle crosses real Chromium tabs, Web Locks, OPFS workers, PostgreSQL, and the installed Electric SDK. It checks distinct per-Collection schema versions, unchanged public and durable rows when a follower opens, leadership transfer with later source rows, and recovery of partial-row loss or a fully empty pre-key-ledger baseline with a stale resume marker. A wrapped source-commit test in packages/browser-db-sqlite-persistence/tests/browser-coordinator-oracle.test.ts checks scheduler entry before the writer-lock request; the old bypass fails at that order assertion. The live recovery histories also guard the resulting progress. These bounded histories do not prove Firefox/Zen, React rendering, React Native, arbitrary large datasets, or an exclusive-OPFS ownership topology. Their review record preserves the RED and GREEN host observations.

The issue #2085 review record preserves the baseline RED result and the subsequent repair audit. The source Collection law keeps an applied receipt pending after an indeterminate RPC. The replacement leader checks its exact transaction ID under the writer lock; an existing ID acknowledges the commit, while an absent ID permits application only against an unchanged durable anchor. The Collection and a dependent live query stay in one sync run. Direct mutating RPCs retain the #1845 IndeterminateCommitError contract. An absent ID after an intervening write, reset, or pruning remains indeterminate because applying it could regress a newer row or opaque source cursor.

The persisted wrapper owner in packages/db-sqlite-persistence-core/tests/persisted-oracle.test.ts checks before/after durability, pending receipts, mounted live-query rows, queued hydration, later work, known durability failures, and an unchanged reconciliation reload. Its orphan row-metadata case fails on a shortcut that skips needed cleanup. Sparse-array, extra-array-property, and nested-prototype histories require a changed durable value to reload even when ordinary deep equality would skip it.

The PR #2096 four-oracle review adds a mixed-demand reset route to the targeted/full-reload history. A previously public row outside the current filter is retained, refreshed, or deleted according to complete durable evidence; an unconfirmed DbClient seed remains source-owned. The controlled reset must publish no intermediate empty snapshot. Eighteen crossed histories compare every callback snapshot and final rows, including absent or older durable seed values. The original reset failed at the callback checkpoint. Targeted peer metadata set/delete now crosses active complete demand, an active filter, and retired demand with row update/delete/insert: an unconfirmed seed keeps both its row and its row metadata. The old receiver failed all eighteen seed-metadata histories. A protected-seed no-op reconciliation control reaches the same public event cut and emits none; its suspected redundant public event did not reproduce. Accepted same-key source transactions racing a targeted notice, paginated mixed demand, a peer write between complete and filtered reads, and atomic multi-subset reads remain unproved by these controlled histories. The four-oracle review records the exact laws, witnesses, and dispositions.

Direct persisted options and their spread copies can create only one Collection, both with and without a wrapped upstream sync source. The second creation rejects before it redirects the first owner's local or source writes. Selecting only the exposed wrapped sync config omits the descriptor claim; the runtime guard rejects that second Collection before changing control callbacks. A local-only write and an in-flight upstream source transaction remain with the first owner after the rejection. The ownership history now starts a selected-sync copy before the original lazy wrapped-source Collection as well as after it. A copy cannot bind first and steal the runtime from the successfully constructed options owner. The LocalStorage peer owner crosses those start orders for a selected sync copy and checks the owner's receipt, public rows, durable bytes, and listener count. Controlled listener and row observations do not establish that retained module options stop strongly referencing a cleaned-up restartable Collection. Whether cleanup promises collectability remains a separate resource-contract question. Cleanup does not release that claim. A selected sync config also cannot bind a second Collection after the first cleans up; the original Collection can restart and write through the same runtime in local-only and upstream-sync modes. Two DbClients materializing one descriptor receive independent runtimes. A no-demand on-demand full-reload notification reads collection metadata without fetching durable rows when no row is public. If a retired demand left public rows, the notification reads one durable snapshot and corrects only those rows. It retracts a peer-deleted row, updates a changed row, and removes obsolete row metadata without exposing unrelated stored rows. A later constrained demand does not need another validation read. An empty bounded page does not retract a row outside its scope. Eighteen source-precedence histories for that route preserve accepted source rows across insert/update/delete, truncate replay, and queued or serial reads. The original unbounded-read path and direct options reuse both failed these new witnesses before repair. The notice corrects already public rows even during the idle interval after demand retirement. With an active unpaginated filter, six further histories retain, update, or delete a previously public out-of-filter row across targeted and full-reload notices while another in-filter row changes. The original mixed-demand implementation failed three of six exact public comparisons; the repaired path validates previously visible out-of-filter keys from a complete durable snapshot. Paginated mixed demand, arbitrary overlapping retired subsets, a peer write between the full and filtered reads, and host scheduling remain outside these bounded controlled histories. A failed direct Collection constructor releases its options claim if the runtime never bound an owner; a corrected retry can then create the Collection. A successful owner still retains its claim through cleanup. The persisted owner also checks DbClient hydration seeds against absent, older, and equal durable rows through complete demand, zero-demand peer validation, and a bounded peer notice. The active-notice history combines a protected seed with ordinary row replacement, deletion, and insertion, then repeats the notice with an older durable seed. These controlled paths assert public rows and change batches; they do not prove every host-delivered peer schedule. Zero-demand validation clears orphan row metadata with zero or one public row, while an equal metadata-bearing row emits no change batch. The full durable snapshot used to validate visible keys remains O(table) per notice, including when a current filter leaves previously public keys outside its scope. There is no O(visible) read budget. A keyed atomic snapshot would need an adapter contract and receiving witness before that work bound can be claimed.

The persisted wrapper owner models complete durable rows as exact values: field absence, including an own undefined field in the generic adapter, matters as much as scalar content. Eighteen bounded histories cross complete demand, retired-demand full-reload notice, and retired-demand reset with field removal, addition, and scalar change. They compare full public rows, event values, deleted and newly admitted keys, and a protected DbClient hydration seed at settled publication. Nine removal histories fail on the reviewed 8b3debb3a implementation, while nine neighboring controls pass. The undefined arms are generic-adapter evidence; SQLite object encoding omits those fields. A captured-read source history checks submitted same-key and new-key writes after the held read releases, while eighteen complete-demand source-precedence histories extend the existing bounded matrix. These checks do not assert that a source write was accepted before the held read releases.

Targeted tx:committed notices have separate bounded demand-scope and partial-patch histories. Six cases cross active title = Keep demand and retired demand with a row that stays in, enters, or leaves that predicate; five fail at exact public-row comparison and the leaving-active control passes. Nine more cases protect a DbClient hydration seed against durable replacement, partial update, or deletion under active complete, active filtered, or retired demand while an ordinary row changes; all nine fail. Two active-demand union controls keep a row that leaves title = Keep but enters title = Other, in both demand acquisition orders; both pass on the reviewed head. Temporary first-only and last-only evaluator mutants each fail one control at the public snapshot comparison. Ten source-confirmation histories apply a source insert, update, or delete to a DbClient hydration seed, await its applied receipt, then deliver a targeted or full-reload peer update, deletion, or insertion. A changing ordinary sibling ensures a perpetual-seed-protection mutant fails at exact public-row comparison rather than only timing out. Six same-key operation-order cases cross active complete and retired demand with delete-then-update, update-then-delete, and two partial updates; three fail and three pass. The independent models select authored complete durable rows, while notices carry legal source patches. Delete-then-update and update-then-delete produce the same separated changedRows and deletedKeys but opposite durable outcomes, so the receiver cannot infer the row from that envelope alone. The baseline failures and neighboring controls are recorded in the PR #2096 law review; the repaired controlled paths pass. Further in-scope source transactions concurrent with targeted delivery need a same-key acceptance-order witness in this owner. Real SQLite delta creation and browser/Electron notification delivery need matching receiving witnesses in their existing adapter and host owners before this controlled result can be claimed across those boundaries. The Electric recovery owner has separate real SQLite restart histories. Its generated peer-publication history instead uses a Map-backed adapter and a manually delivered notice. It compares exact public rows, durable rows, and a committed metadata marker. A full-reload notice requires an authoritative durable row read in that active-demand history, through either adapter row-read route. A targeted notice for a previously unseen key may also read durable rows because its value has no completeness certificate. The oracle does not treat requiresFullReload: false as a no-read guarantee. The metadata of an unseen targeted row is not asserted to be demand-scoped: core permits explicit row metadata for an absent row, so this needs a separate product decision before changing that contract.

The user chose demand-scoped schema-reset publication for on-demand Collections. With no active subset, reset validates only already public keys against durable rows; an empty public Collection remains empty, and a changed or deleted visible row is corrected. Eager reset still restores its full baseline. Eighteen source-precedence histories cross on-demand reset with insert/update/delete, source truncate replay, and queued or serial reads; three focused reset histories distinguish empty, changed, and deleted visible scopes. They do not establish host notification delivery or a keyed SQLite read budget. The visible-key validation may read the full durable table.

A controlled term-jump history recovers a missed row; a position-only certification history shows that observing a durable version does not publish its rows. Reset continuations rebase the publicly applied row version, reject a delayed pre-reset notification in both orders relative to a newer election, and recover a row committed between the reset reload and the later position-only read. A controlled same-term reset continuation checks two new-epoch commits separated by a delayed old-epoch notice. The commit envelope has no reset epoch, so the wrapper rereads durable rows for all three ambiguous notices; a no-fence mutant publishes the old row. This establishes public-row safety and its three-reload work cost, not a bounded-work promise. The built-in coordinator currently has no collection:reset sender; a real-host same-term reset needs a Browser/OPFS receiving witness. A future epoch-aware fast path needs the persisted wrapper owner to distinguish old and new same-term notices at each public cut before that real-host receiving witness. The controlled wrapper compares public rows after each held cut; removing the old-term fence or treating the later position read as published rows fails those assertions. The SQLite adapter owner checks exact IDs, row versions, reset epochs, pruning, unchanged anchors, same-key peer writes, cursor metadata, durable no-write term reservation, and the exact-ID index plan against real SQLite transactions. It also checks that a live claim on a retired physical generation can proceed, that live claims cannot cross physical generations, that expiry fences reconciliation and term reservation before a durable write, and that a new claim remains usable. The Browser coordinator owner checks writer-lock stream advancement, changed routes, and invalid wire anchors. It delays a former owner's captured heartbeat past a no-write Web Lock takeover and checks both the new owner and a passive follower retain the newer route after the delayed heartbeat. Distinct durable terms protect the later routed source write. Its election witness checks that the registered physical storage ID and claim reach term reservation. The Electron IPC bridge runs the SQLite adapter contract through its renderer and main-process handlers, including exact-ID reconciliation and protocol-v5 claim-scoped term reservation. Its resolved-adapter witness checks that reconciliation carries each Collection's mode and schema version, and its absent-capability witness checks that an unknown result leaves durable state unchanged. The real-process witness runs the renderer adapter in Vitest and sends its envelope to an Electron main process. It does not execute the adapter inside an Electron renderer or check concurrent requests from multiple renderers. A reconciliation IPC reply delayed until after main applies is an untested transport history owned by the Electron receiving contract. The Chromium/OPFS host owner runs idle, before-durable, after-durable, peer-before-reconciliation, notification-before-lost-answer, and cold-successor histories across real tabs, Web Locks, BroadcastChannel, workers, and SQLite. It observes durable rows, cursor, and exact applied transaction IDs, public source/live-query rows, receipt settlement, one sync run, and passive-tab event counts. The peer history holds reconciliation before the writer lock until the peer write is durable. Removing the reconciliation reload marker leaves the passive source and live query without the original row at that public checkpoint. The real Electric receiver in packages/browser-db-sqlite-persistence/e2e/electric-leader-close.opfs.spec.ts streams a PostgreSQL row through the installed SDK, closes the first writer after SQLite applies that source transaction, and checks the surviving Collection, mounted live query, durable rows, exact applied ID, resume marker, and later PostgreSQL row. The original Electric applied receipt fulfills in one sync run. The crossing row's transaction and first durable snapshot agree on resume offset, handle, and shape ID. It supplies the SDK handoff for this one after-durable history.

The wrapper's controlled term jump and the real OPFS cold-successor election are separate evidence cells. The persisted wrapper now has a controlled same-key peer-write continuation: X is durable at version 1, Y advances storage to version 2, exact-ID reconciliation acknowledges X's original position, the source receipt fulfills, and the wrapper's owned resume evidence fails closed against version 2. A temporary latest-position response makes that evidence assertion fail. The real SQLite exact-ID decision and this wrapper receiving history still have separate drivers; one real-adapter wrapper join remains with the persisted SQLite receiving owner. A single real-host history combining a missed original notice, an empty reserved term, and a passive follower's later public rows remains with the Chromium/OPFS owner. The controlled nested-prototype replacement reaches source and mounted live-query cuts; real SQLite serialization of that nested class in the same wrapper history remains with the Node SQLite receiving owner. The reset continuation uses a controlled snapshot with the same version-zero premise that the real SQLite adapter's schema-reset oracle proves. A combined real-adapter wrapper reset and later notification remains with the persisted SQLite receiving owner.

The persisted wrapper owner also holds an on-demand resume certification across a newer, sequence-zero term while the row version and reset epoch stay fixed. It rejects the old exact-generation guard at key-set evidence. The Electric held-snapshot owner joins the real SQLite term reservation with the persisted wrapper and mocked Electric stream: the source retains its cursor and reaches ready with the original durable rows. Neighboring committed-write and schema- reset histories reject inheritance of the old baseline. The real Chromium/OPFS reopen history still owns the host election and restart schedule; this local join does not prove that schedule passes in CI.

A bounded TLA+ design grammar and exact TLC receipts live in review-evidence/issue-2085-tla/. It explores one X, one same-key peer Y, one reset, delayed/lost notices, position-only observation, and ledger pruning; it checks the reference laws and kills wrong-design mutants but does not execute a production path. A separate challenge shows that an old commit notice can publish an old row after durable reset before a passive peer receives any reset signal. The built-in coordinator has no reset sender, so this is an unresolved proposed cross-tab reset law, not a confirmed current receiving failure. A future sender needs a Browser/OPFS witness for that pre-signal order.

This bounded owner assumes tabs run the same protocol version and one txId identifies one immutable payload. The Electric receiver does not cover before-durable loss, queued hydration, two Electric providers contending in both tabs, seven concurrent Collections, or a closing leader's active SQLite call; those need receiving schedules owned by the Browser Electric, hydration, and OPFS page-lifecycle suites. Arbitrary concurrent writes, physical crash durability, other browsers, and cross-version tabs are outside the established host evidence. These limits do not authorize a late apply after an intervening durable write.

The persisted wrapper owner now also checks the no-pullSince row-version-gap fallback at every Collection change callback: a durable baseline, a missed commit, and a later notice may expose only the baseline or the complete durable replacement. The old truncate fallback exposed an empty intermediate snapshot. The Electric recovery owner drives ordinary peer notifications only after its adapter commits matching rows, metadata, and a contiguous row version; its bounded peer/stream histories retain exact public-row and publication-marker checks. The previous fixture announced version 101 while its durable position remained zero, so the new gap detector treated an ordinary notification as a missed history. These controlled owners do not prove real Electric delivery of a lost-notice gap; the Browser Electric/OPFS receiver owns that schedule. The Electric recovery fixture now distinguishes same-key insert replacement from partial update merge. Its generated peer-publication grammar varies that operation and a removable field, and requires a subscriber event carrying the authored callback-time snapshot when public rows change. A missing-event mutant fails at that event assertion. The generated same-key insert history found a receiver violation: targeted notices omit insert/update identity, so a public row must be checked against durable state before interpreting an omitted field. The primary persisted owner crosses insert replacement with two-update and delete/update controls under active and retired demand; removing the durable check fails both insert histories at exact public-row comparison. These Map-backed histories do not establish real SQLite notice construction or browser delivery; the relevant real-provider receiver remains needed.

The live Electric hydration-straddle oracle owns one #1754 host history: an on-demand Collection has an initial durable row; an OPFS subset hydration is held after its local read; a PostgreSQL update begins an Electric source transaction during that hold; and the row-bearing commit is released only after the hydration scope exits. It checks the old row before release and the exact new public and durable row afterward, then after follower takeover and reopen. The fixture observes the on-demand run's claimed storage ID and claim at coordinator registration; PostgreSQL supplies the expected row independently. A late-buffer mutant leaves the old row in both observations. The core persistence tests own the adjacent during/straddling/after settlement, FIFO, abort, and failure histories. The live oracle does not prove eager-startup overlap, other mutation shapes, arbitrary Electric fetch schedules, Firefox/Zen, React rendering, or exclusive OPFS ownership. The review record preserves the live-host and mutant evidence.

Source durability inside a shared hydration scope#

The hydration source durability routing owner in packages/db-sqlite-persistence-core/tests/persisted-oracle.test.ts now runs 144 bounded histories: startup/subscription/after-ready × scoped/unscheduled × empty/shared-key baseline × twelve transaction templates. Its independent edit log covers full upsert, same-key order/delete, truncate/replacement, row and collection metadata set/delete, truly empty work, atomic multi-row batches, independent pre-abort, and first/second durability failure. It checks each acceptance and applied receipt separately, exact durable admission and prefixes, sequence allocation, current scoped-adapter identity/lifetime, ordinary next use, a second on-demand scope, and durable reopen. Four cleanup/restart histories and one early-receipt checker calibration supplement the matrix. Existing startup-read failure, request-local failed-read/retry, and optimistic causal replay witnesses preserve no-scope, same-adapter and distinct-adapter paths. Three callback-lifetime calibrations distinguish nested scopes and both overlap exit orders. Forwarding-wrapper and explicit-adapter controls cover coordinator composition and the ordinary registered fallback.

The receiving packages/browser-db-sqlite-persistence/e2e/hydration-commit-oracle.opfs.spec.ts runs 24 real Chromium OPFS histories plus one cleanup-failure calibration. It crosses the original phases/coordinators/baselines with single-insert and rich source histories, and checks three distinct Collection schemas, a cold peer, metadata, durable rows, and reopen. Sixteen startup/subscription histories require exact owning-scope exit; eight after-ready controls have no held scope and report that fact explicitly. The held cut waits for real peer hydration and ordinary-write scheduling admission. Peer hydrate/regular callback entry and C's commit SQL remain forbidden until the owning callback exits. Election stream-position reads are deliberately outside that regular-work law. The tail joins any truncate-triggered hydration, then must use the default coordinator's public apply or the browser coordinator's regular scope exactly once. Cycle detection ties the same transaction to the supplied live scope and its erroneous scheduled call; temporal overlap alone is insufficient. Captured primary evidence survives cleanup failures.

The default coordinator now uses the supplied scoped adapter for that call, without caching it. The initial repair receipt on main at a37e69ab records 48 core routing assertion failures and eight real scheduler-cycle assertion failures for the original production code. The latest review follow-up passes 640 persisted-oracle checks (with one existing todo) and 25 Chromium OPFS checks. The original eight hostile repairs cover premature receipts, cached loans, omitted data, reverse FIFO and suppressed/misclassified failure. New calibration shows the old browser checks accepting cached loans and ordinary scheduling bypass; the strengthened receiver rejects them at tail routing and the complete scope boundary. A no-scope error-identity mutant is rejected by the restored failure paths. The loss audit and exact content bindings preserve all source recoveries, decisions, commands, calibration and limits; the initial review retains the original issue ledger.

• Scoped lifecycle compositions. The persisted-history owner needs distinct-scope witnesses for dependent and post-publication aborts, buffered partial-update recovery, row metadata from different owning reads, arbitrary queued reloads, and late already-issued storage results after replacement. Existing semantic owners remain authoritative. The new queued-cleanup witness does not promise rollback of issued writes.
• Nested work under fairness backlog. The shared-driver fairness owner (tests/shared-driver-fairness-oracle.ts in the browser package, with its OPFS receiver) needs a nested source commit inside a hydrate while both lanes retain a backlog that distinguishes K=1 from K=2. Finite peer progress here does not establish that composition.
• Elected-owner/host handoffs. The per-Collection coordinator owner retains transfer/cross-tab RPC while nested durability is pending. The OPFS receiver owns provider-supplied physical failure and abort/cleanup witnesses; other browsers and native hosts need their own receivers. Distinct-schema isolation on this host is now checked.
• Historical attribution. A package bisect is still needed for the earliest affected release; this work checks the stated origin/main.

SQLite boolean predicate arity and row work#

packages/db-sqlite-persistence-core/tests/sqlite-boolean-arity-oracle.test.ts is the primary executable owner for bounded and/or predicate arity at SQLiteCorePersistenceAdapter.loadSubset return. Its independent three-valued model compares public keys while a node:sqlite driver records SQL and raw row work. The 960-case matrix and paired fixed and unseeded campaigns cover root arity 0–3, one nested operator, boolean and nonboolean operands, safe selective predicates, and sound candidate supersets for unsafe predicates. Eight direct cases challenge Unicode ilike and like patterns, tagged NaN comparison, lone-surrogate equality, and null-vs-missing under not. Paired- and lone-surrogate equality controls retain SQL row-work reduction. An empty-IN control and two-SELECT cursor composition check zero-row work.

The original compiler was RED for unary and empty boolean work and multioperand under-selection. The first repair was RED for unsafe SQL prefilters: Unicode case folding, an emoji spanning two JavaScript code units, tagged NaN, and null-vs-missing under negation. A later lone-surrogate equality witness was RED for public rows and SQL work. The compiler now applies SQLite JSON extraction to the matching binding; paired and lone surrogates both keep indexed equality. The current compiler passes the bounded oracle. A removed-WHERE mutant fails the raw-row work law and a blind-unary mutant fails public rows. For this grammar, SQL pushdown admits every row that the in-memory evaluator could retain; a statically false AND may read zero rows even with an unsafe sibling. Mixed-AND witnesses retain a certified equality while an unsafe range, NOT, or OR sibling stays with the row evaluator. They cover child order and one nested AND, measure one raw row instead of twenty, and reject a removed-WHERE mutant. The unsafe OR mutant loses a public row. A fixed 80-level nested AND witness bounds compiler argument reads to linear work. It was RED on the prior quadratic compiler and is GREEN after removing the repeated subtree compilation; elapsed latency and arbitrary depth remain outside this owner. TimFL's 50,582-string-ID AND(OR(IN, IN)) scope was RED for SQL row work: the adapter returned the right public row but read all 20 stored rows. A fixed real-SQLite witness now checks the public result, exact candidate count, two bound JSON arrays, and use of both named expression indexes. It includes lone-surrogate, NUL, and paired-surrogate string members. Mixed-type lists, other SQLite hosts, and elapsed-time gains remain outside this witness.

The Node expression-index oracle checks the receiving SQLite query, raw candidate keys, public keys, and named-index plan. Its generated indexed grammar uses string equality, BigInt membership, numeric range, and string conjunction. Focused Date-epoch witnesses keep numeric equality and numeric membership on the JavaScript fallback path: a stored Date(1) matches numeric 1 in the row evaluator but is ISO text in the SQLite expression index. Fixed lower-wrapped BigInt membership and lone-surrogate coalesce witnesses also retain fallback: SQLite converts the former to text and encodes the latter's inline fallback differently from a JSON-extracted binding. Integer-bound range cases include adjacent fractional values and tagged or mixed scalars; this is bounded evidence, not a proof over every persisted representation. Large Number versus BigInt range cases check both operand directions, four inequalities, and unary boolean wrappers. Unsafe BigInt bounds admit a wider candidate range over the indexed expression for potentially rounded Numbers; JavaScript still decides the public result. Numeric-key object and array cases check public rows and named-index use through three digit segments, including mixed carriers. Deeper numeric paths use an unbounded candidate read. Unicode lowercase cases place NUL before and after a fold and keep the matching row through either equality direction and unary wrapper. The receiving Node plan uses the named index for the selective BigInt range orientation in both operand orders. The opposite orientation can scan because its candidate union also admits text and rounded Numbers; this oracle makes no constant-index-use claim for that branch. Fixed strftime, add, and Date-range witnesses also use full reads for mixed stored types; direct SQL would exclude a matching numeric timestamp or string concatenation. A typed-field contract or a separate indexed representation is needed before those forms can gain a generally sound selective candidate.

The owner does not establish arbitrary depth or arity, every equality or LIKE pattern, limit/offset after filtering, all cursor shapes, order or value/metadata semantics, index-expression compilation, native hosts, OPFS, or multi-process execution. The existing SQLite owners above retain their separate reset/resume, order, driver, and host contracts. Broader class closure needs witnesses at those remaining paths.

Acceptance map#

The post-merge review added three missing domains to existing owners:

• Top-K batch contracts cross sparse-array length/holes and RegExp source/flags/position with equal controls, replacement order, hash consolidation, and actual retained graph output. Ordinary replacements also run without the global File constructor.
• Leadership replay holds real storage-read delivery across successful and permanently rejected durable removals, with bounded scans, concurrent loads, and unfinished peers. This is distinct from exactly-once execution across independent owners.
• Settlement-time drop of optimistic state is owned by the optimistic history model and state retention. A transaction's optimistic state drops when its mutation function settles. Sync transactions committed while it persisted are held and publish with that drop; isPersisted settles after that publication. Handler sync writes are generated at every cut, with and without awaiting their acceptance. Receipts stay pending until visible. With one persisting local mutation and no truncate, the first queued same-key source transaction consumes local attribution at settlement if that mutation succeeds. An absent-key delete consumes it without leaving a row. Repeated same-key writes in that first atomic source transaction keep its attribution. Later source transactions are 'remote' without another local owner. A truncate can publish while the mutation remains active and label its same-key row 'local' even if that mutation later fails. Attribution uses key and timing; SyncConfig.write has no causal client identity. A pending manual mutation does not hold source writes; a same-key source row can retain local attribution after rollback. A subscriber can commit a truncate and a later same-key transaction during another drain. The suffix truncate can use the still-active mutation's attribution. The later same-key transaction in that suffix drain is remote. An active mutation on a key the truncate does not write still attributes that key's first later transaction in the same drain. Bounded histories also cross two persisting same-key mutations, one or two source batches, both settlement orders, and success/failure combinations. The first source batch is local when at least one mutation succeeds; two failures leave it remote. A hostile failed-sibling mutant fails the one-success cases at settlement. The pending lane rejects a mutant that ignores pending mutations at its source or settlement publication. Bounded manual histories now cross success, direct rollback, and handler rejection with both optimistic visibility settings. A later disjoint edit cannot supply the earlier manual request's handler outcome. The original harness left rejected manual requests pending; the new settlement check rejects that harness and a shared-handler variant. Six pending-peer histories distinguish same-key rollback cascades from secondary rollback and different-key controls, through public settlement and publication. Longer manual interleavings and larger same-key cascades remain outside these fixed histories. The original truncate implementation failed the reentrant history at failed-mutation settlement. The earlier accepted-snapshot retention law and its truncate-capture ownership refinement were retired with this contract. The PR #1907 review record is historical. The settlement-drop review record holds the RED/GREEN and mutant evidence. A handler that awaits a visibility receipt held by its own transaction, such as an on-demand load of its own Collection, waits for itself; that history is outside the generated grammar.

Issue #2071 adds two focused checks to this acceptance map:

• The issue #2071 review checks a rejecting onInsert through the persisted wrapper. Four controlled histories cross source insert/delete with acceptance before/after rejection. They compare live rows, exposed base, durable rows, origin, and a held source receipt at mutation settlement and after source application. The real SQLite receiver checks two same-key continuations, including a real source update after reinsert. Each reopens the same file with a new Collection, adapter, and SQLite driver. Both the reported release and this review tree pass these bounded histories. The reporter's private bridge sequence is unavailable; these witnesses do not establish its behavior, other mutation kinds, on-demand sync, other SQLite hosts, or an OS process restart. The persisted wrapper owner needs the bridge callback and write sequence to reach that path.

• The optimistic publication owner distinguishes one and two queued same-key source transactions during a successful local mutation, two same-key writes inside one atomic transaction, an absent-key delete before a source insert, a delete and reinsert in one atomic source transaction, a truncate published before a mutation fails, pending manual mutations, two overlapping same-key mutations, a truncate followed by another same-key transaction, and a truncate followed by a different-key transaction with an active mutation in one reentrant drain. The persisted wrapper receives the one/two transaction pair. The source grammar can now preserve mixed write order inside one transaction; its atomic delete/reinsert witness is distinguished from a later same-key transaction. These histories establish bounded key-and-timing attribution; they do not establish every mixed operation sequence, causal authorship, or every overlapping mutation schedule. A causal $origin guarantee would require an explicit source signal and a new core-owner model and provider receiving witness. The PR #2078 review records the original same-drain RED, the repair, and hostile controls. The optimistic history owner still needs controlled pending-plus-persisting same-key histories, truncate with two active owners, and longer reentrant or mixed source suffixes if those broader schedules are claimed. Such a witness must compare origin and complete publication cuts, not only the final row. The persisted wrapper owner still needs the private bridge callback and write sequence before claiming that reported path.

Running and replaying#

Build workspace dependencies before testing consumers of package exports. Use the package's checked-in config; source aliases and native shims must be named when they replace that path.

pnpm --filter @tanstack/db-ivm build
pnpm --filter @tanstack/db build
pnpm --filter @tanstack/db test:oracles
pnpm --filter @tanstack/powersync-db-collection test:oracles
pnpm --filter @tanstack/db-sqlite-persistence-core build
pnpm --filter @tanstack/node-db-sqlite-persistence test:oracles
# Service-dependent: requires Electric and PostgreSQL to be running.
pnpm --filter @tanstack/electric-db-collection test:e2e
pnpm run typecheck:tests
pnpm exec tsc --noEmit -p packages/db/tsconfig.json
pnpm --dir packages/db exec vitest run --coverage.enabled=false --maxWorkers=2
pnpm --dir packages/db-ivm exec vitest run --coverage.enabled=false --maxWorkers=2
pnpm --dir packages/offline-transactions exec vitest run --maxWorkers=2

Core guarded replay is run from packages/db, for example:

TANSTACK_DB_ORACLE_SEED=1813 TANSTACK_DB_ORACLE_PATH=0 \
TANSTACK_DB_ORACLE_PROPERTY=live-query-observer.granular-history \
node --import tsx tests/oracle-replay.ts \
  tests/live-query-observer-history-oracle.property.test.ts \
  -t 'granular listeners follow the eligibility ledger with a random or replayed seed' \
  --coverage.enabled=false --typecheck.enabled=false

Use the failure's actual seed/path for a reproduction. The example establishes target execution, not reproduction of a particular bug. Local IVM and offline properties have separate environment variables; inspect their test headers. Do not assume the core multiplier reaches them.

The Node expression-index oracle runs matching fixed-seed and seedless-random campaigns by default. Supplying both replay values selects only the requested seed and shrink path:

TANSTACK_DB_WS5A_SEED=1659005 TANSTACK_DB_WS5A_PATH=0 \
pnpm --filter @tanstack/node-db-sqlite-persistence test:oracles

Stress runs need an explicit file list, run budget, seed policy, runtime, exit status and cost. For long synchronous campaigns, yield between complete histories, never between an action and its synchronous observation. In this project, worker progress RPC starvation produced passing assertions with a nonzero process exit. Such a run is not green. Raising a test timeout alone does not let the worker process its progress messages.

Action enforcement example#

examples/react/action-enforcement/eslint-rules/no-direct-collection-mutations-oracle.test.js owns the example's file-local lint boundary. Its finite grammar covers 12 binding forms, six methods, six call forms, and two callback definition orders, plus lexical shadowing, sibling scopes, configurable imports/methods, and alias cycles. The independent model labels the constructed receiver as a Collection and predicts one diagnostic for writes and none for reads. The checkpoint is the complete diagnostic list from the real ESLint Linter.verify call. A receiving check runs the actual ESLint configuration on feature writes, feature reads, and action writes. The import-source dimension checks eight alias/relative/barrel spellings against four nearby unrelated paths, including the real configuration. Three TypeScript import-equals forms must preserve other diagnostics without crashing; static and escaped template members are paired with dynamic names. On 7d3a3e85b, the expanded suite fails 21 of 32 groups: the parser-node witness throws while linting; the other failures are missing diagnostics. The repair passes all 32 groups. A path-prefix mutant that includes collections-extra fails three groups. A template-prefix mutant that treats interpolated names as static fails the dynamic-name assertion. Both failures reach diagnostic comparisons; neither is a setup failure.

The original implementation (3da274d8a) failed 11 of the 18 test groups at that checkpoint: name-based scope pollution, declaration-order dependence, and missed destructuring. The repair passes all groups. The example README states the conservative rule for reassigned aliases. This oracle does not establish inter-module or type-based tracking, function argument/return propagation, new object/array containers, extracted mutation functions, or dynamic method names. Those are outside this example's declared static scope; expanding it requires new syntax witnesses here.

Guide evidence: ORC-001–005 and ORC-009 are stated beside the finite grammar, model and driver. ORC-006 uses the original production rule as the rejected wrong design; failures are diagnostic assertion mismatches, not setup failures. ORC-013 pairs writes with reads and imported bindings with shadowing local values. ORC-007 does not apply to this bounded enumeration; ORC-008 has no stateful model, ORC-010 has no shrinking or resource cleanup, ORC-011 has no named shared semantic fault requiring a second formulation, and ORC-014 is witnessed at the real ESLint configuration boundary; no browser or backend-provider claim is made. These outcomes supply ORC-012 evidence; the executable suite contains the law and observations, rather than relying on this record for expected behavior.

examples/react/action-enforcement/tests/TodoApp.test.tsx owns the example's application input and pending-write controls. Its focused component witnesses use real actions and the fake API with a virtual clock. They check unchanged, newer, and empty drafts after successful adds; unchanged and newer drafts after controlled create rejection; native form submission; and disabled toggles at 0, 40, and 119 ms during creation. A settled row remains enabled while another row is pending, and a newly settled row can toggle and persist its change. The original component fails the newer-draft, form, and three pending-row checks. The fixed component passes these nine cases. The lint oracle above cannot observe these application behaviors, and the shared framework owners do not own form state.

The component suite also owns add admission: one add may be pending per mounted form, the input stays editable, and settlement permits the next submission. Four controlled-create histories cross fulfillment/rejection with repeated submits before/after a React render. They assert one action and provider call, reject submissions of a newer draft while pending, then admit that draft after settlement and check exact persisted counts. A fifth witness checks admission after synchronous validation rejection. The original handler fails all four pending-add histories. A guard based only on React state fails the same-render histories; a mutant that omits guard cleanup fails subsequent admission.

A controlled-toggle history also checks failure and retry in both completion directions. It observes pending disablement, optimistic state, rollback, visible error, retry error clearing, and final provider state. The original component rolls back but fails the error-message assertion. This provider rejection is injected at the component boundary; it does not claim a real backend emits it. The same-path rejection probe found no unhandled rejection: Collection cleanup already catches the persistence promise.

Toggle tests select buttons by accessible role. A hidden-toggle mutant passes the original tag selector but fails the scoped role query before interaction. This checks exposure in the accessibility tree; it does not establish keyboard focus or screen-reader behavior.

These 15 focused cases do not establish arbitrary-length form histories, remount behavior during pending writes, or browser-native Enter dispatch. This component suite owns the first two extensions; a browser form witness is needed for native keyboard dispatch.

Reusable-law backlog#

RFC #1659 reviews found several green oracles whose stated laws remained valid but whose fixtures, grammars, or observations did not cover a neighboring boundary. Track the generalized repairs here instead of accumulating isolated regressions. Completion requires an executable owner, a production-path witness, a hostile wrong-answer control, and an explicit statement of remaining limits.

• Accepted sync transactions across persistence reads (partial coverage). The persistence-history owner retains the original 24 histories: insert/partial-update, one/two/three queued reads, unreserved/reserved commit turns, and an absent/present dependent successor. They check applied receipts, public/durable rows, metadata, cursor, and durable source order. Eight adjacent histories begin during an owning persistence read and commit after it finishes. They vary original key membership, commit-turn reservation, and one/two later reads. Captured row metadata ownership survives acceptance. The maintainer specified that persisted rows are an older baseline for newer sync-adapter changes; an internal read cannot revoke an accepted sync transaction. Ninety additional histories compare queued and completed reads against the same independent snapshot algebra. They cross insert/update/delete, no/before/after truncate replay, on-demand subset demand, and coordinator reset/full-reload notifications in eager and on-demand Collections. Exact settled rows, row metadata, opaque cursor metadata, status, applied receipts, loaded rows and durable completion order distinguish source precedence from truncate replay's ordered replacement. The old guard fails all 45 queued cells; serial controls pass. Omitting public truncate fails 60 cells; omitting public delete fails 10. Owner: packages/db-sqlite-persistence-core/tests/persisted-oracle.test.ts. The original review and admission follow-up preserve revision receipts, review dispositions and oracle-guide audits. Further witnesses must compose these schedules with cancellation, cleanup, or persistence-read failure. Existing rejection of still-open transactions across persistence reads remains a characterized admission restriction; its independent authority argument is not established by these tests. The notification fixtures assume a compatible persisted baseline. They do not establish behavior after schema changes or invalidated resume points, or each intermediate publication during a multi-transaction truncate replay. The same owner needs those histories before claiming those stronger laws. A claimed leftover-replay/reset failure still needs a concrete schedule; the bounded two-replay-then-reset probe drains replay before reset. Live Electric/browser OPFS delivery needs the matching schedule in packages/browser-db-sqlite-persistence/e2e/electric-hydration-straddle.opfs.spec.ts; its current ordering does not establish this handoff. These are bounded witnesses, not closure of arbitrary interleavings.

• Optimizer residual convergence beyond the checked paths. The optimizer-semantics owner now checks sourceWhereClauses, source-free predicates, namespace-only predicates, later RIGHT/FULL join nullability, and an ordered QueryRef refusal at structural checkpoints. It still needs public-row witnesses for later RIGHT/FULL chains, residual checks for aggregate, functional, and projection-remapped QueryRef refusals, a separate UNION branch model, and incremental source/publication histories. Owner: packages/db/tests/query/optimizer-semantics-oracle.test.ts and its production compiler driver. Each extension needs a distinguishing wrong-plan control at the relevant checkpoint.

• Real-provider conformance fixtures. Frozen 15.2.7 React Native and Node receipts cover the supported peer version; 18.2.1 React Native, Node, and browser receipts cover the known forward shapes. Exact-row checks and a row-dropping hostile control prove the shim accepts those envelopes without mutating them. Owner: packages/react-native-db-sqlite-persistence/tests/fixtures/op-sqlite-provider-results.ts and packages/react-native-db-sqlite-persistence/tests/op-sqlite-driver-oracle.test.ts. Native device/host execution remains a separate runtime receipt.

• Minimal ambiguity and name invariance. Generate one-field and otherwise minimally distinguishable results. Renaming a selected column to a structural-looking alias must not turn a data row into a write envelope. Owner: packages/react-native-db-sqlite-persistence/tests/op-sqlite-driver-oracle.test.ts.

• Carrier coexistence and representation symmetry. Cross rows, rawRows, columnNames, and supported result containers, including legal coexistence. Equivalent array and object forms must agree on rows or on the documented rejection. Owner: packages/react-native-db-sqlite-persistence/tests/op-sqlite-driver-oracle.test.ts and the shared SQLite driver contract.

• Shared-handle transaction admission. Concurrent driver wrappers for one provider database handle serialize root transactions. Nested work must use the transaction driver supplied to the callback on hosts without async context propagation. Owners: packages/node-db-sqlite-persistence/tests/node-driver.test.ts and packages/react-native-db-sqlite-persistence/tests/op-sqlite-driver-oracle.test.ts.

• Transitions at every relevant await. Hold each coordination boundary, then change leadership, remote-subset ownership, abort state, cleanup, or restart generation before release. Owners: browser/electron coordinator, persisted-history, and collection cleanup/restart oracles.

• Local-versus-transport refinement. Compare local-leader and transported remote-subset behavior for immutable values. Separately prove that local signal and subscription references survive delivery and reach matching unload cleanup. Owners: browser/electron coordinator and persisted-history suites.

• Partial-construction cleanup. Fail database, driver, worker, and subscription construction after each acquired resource. Preserve the primary failure while proving all acquired resources are released exactly once. Owners: OP-SQLite driver-contract construction and OPFS page/worker lifecycle suites.

• On-demand persistence after evidence changes. Cross baseline versus on-demand hydration with consistent, unknown, and incompatible key-set evidence. A baseline certification failure must not silently erase valid on-demand rows. loadSubset checks baseline visibility and on-demand rows; the sync-absent forceReloadSubset route crosses the same startup evidence states but records baseline visibility as unobserved because that API does not expose baseline hydration. Owner: packages/db-sqlite-persistence-core/tests/persisted-oracle.test.ts.

• Deterministic value-and-work laws. Pair row correctness with stable statement, scan, trigger, or queue-cardinality observations where the subsystem promises bounded work. Owners: SQLite resume snapshots, Electric acquisition work, shared-driver scheduling suites, and the Node same-database-handle admission law.

• Startup generation interleavings. Hold persisted startup between its metadata and hydration snapshots, then cross no write, a managed mutation, and hostile raw loss. Compare public rows with the atomic durable snapshot, and require mutation persistence to wait until the prior stream position is known. Owners: SQLite resume snapshots and Electric resume snapshot races.

• Schema-generation fences on cached adapters. Cross a newer-schema reset with snapshot, row, metadata, delta, position, and index-lifecycle operations from the cached older adapter. Every stale operation rejects; the current adapter remains readable and its index registry remains intact. Owners: SQLite resume snapshots plus browser/electron coordinator routing.

• Explicit omission records. Add a short Known omissions section to each primary executable owner touched above and keep this map synchronized as laws land. An omission record narrows evidence; it does not waive a product obligation.

• Atomic active-subset full reload. Load collection metadata and every active subset from one adapter generation, including filtered and paginated on-demand subsets. A sound implementation needs an atomic multi-subset API; loading all rows or accepting a metadata/row torn pair is not equivalent. RED evidence and the deferred executable placeholder live in packages/db-sqlite-persistence-core/tests/persisted-oracle.test.ts under R5-007.

• Joined aggregate and singleResult subquery histories. packages/db/tests/query/subquery-user-value-oracle.test.ts checks flat and nested aggregate source changes and joined findOne() QueryRefs at initial and later public checkpoints. The bounded histories and remaining forms are recorded in the QueryRef owner row above.

Persisted readiness and network-first initial rendering#

The persisted-readiness oracle in packages/db-sqlite-persistence-core/tests/persisted-readiness-oracle.test.ts owns the opted-in eager restore boundary through the persisted wrapper, Collection, live query, and observer. A finite two-source model checks all 36 opt-in/outcome combinations independently of the observer classifier. Its controlled persistence histories check nonempty and empty restore while upstream remains pending, all-source conjunction, mixed opt-out, nested live-query sources, exact failure, SSR seed handoff, stale cleanup/restart work, an already-restored source, and a two-source history in which A restores, restarts, and remains pending after B restores. A new query's persisted readiness and initial-render wait stay gated until A restores in its current sync run. This history uses controlled adapter reads and does not claim that an old query survives source cleanup. The remaining controlled histories cover a network-first deadline, early network success and failure, network failure before nonempty restore, client query stream failure before or after empty and nonempty restore or before observer construction, joined-source deadline composition, and a derived-query error alone or alongside a failed client stream that must not be mistaken for network failure. It checks a separate initial-render wait that leaves network preload() unchanged. The framework conformance suite checks the projected signals in React, Vue, Svelte, Solid, and Angular, including exact identity for a plain-object restore error after notification. The window-controller test checks infinite-query projection, and focused React and Solid tests check Suspense gating. The React tests check client-stream failure before and after completed empty and nonempty restore, including a failed record already present before mount. They also check error-boundary handling for derived-query failures with and without a failed client stream. A replacement client record arriving during an initial-render wait has no persisted-fallback witness yet. This owner uses a controlled persistence adapter, not native SQLite or a real network provider; it does not prove browser scheduling or arbitrary histories. The framework identity scenario does not cover every possible rejection value or an error already present before a hook mounts.

Deferred contracts and evidence#

The maintainer assigned offline policy work to RFC #1659. It is not a merge blocker for this oracle repair. Keep these scenarios and decisions with that owner:

• A10 R7/R13: the executor holds caller success until deletion is acknowledged, and a persisted deletion-pending phase prevents provider replay after a known deletion failure. Controlled restart and adapter-failure witnesses cover that boundary. A crash before the phase write, old readers of marked rows, physical power loss after adapter acknowledgement, and native browser restart or multi-owner handoff remain open. Provider idempotency is required to avoid a repeated effect in the first two cases.
• A10 R4: Issue #1939 is owned by the leadership replay oracle. The action grammar crosses retained leadership, loss before invocation, and loss during or just after onMutate after offline selection; a manual transaction loses leadership after its optimistic mutation and before commit(). The original action path fulfilled with no outbox record or provider call. The repaired paths reject and roll back; retained-leader and before-invocation controls still fulfill. Later leadership changes and a held outbox write crossed with loss or regain remain for this leadership oracle, using controlled write settlement and caller checkpoints. The IndexedDB write-settlement owner still needs a browser-host composition with leadership loss across a write. These paths are outside this bounded repair. The review record preserves the RED/GREEN and checker-calibration evidence.
• A10 R5/R9: manual removal/clear outside the active-provider witnesses and broader restored optimistic lifetimes remain open. The settlement owner checks the optional retry decision across AbortError, ordinary network, 400/401/403/ 422/404 message, and permanent errors. Each kind crosses true, false, undefined, and absent hook answers with 1–3 FIFO peers. The fixed examples each receive a campaign run before generated cases, with a reach assertion. A later failure checks the current retry count. Public commit() witnesses cover thrown, null, zero, and fulfilled or rejected Promise hook results; a rejected Promise must not escape as an unhandled process rejection. Primitive and status-bearing object provider rejections check Error conversion before the hook. A status-bearing Error from another JavaScript realm reaches the hook by identity, keeps its first retry record, and later settles after a successful attempt. A plain status-bearing object still takes the non-Error conversion path; spoofed Error tags are outside these witnesses. The first stored decision distinguishes terminal rejection from a retry record. A hook fault records a terminal rejection for only the failed row. The executor removes that row, rejects its caller with the hook failure, and continues queued work after acknowledged deletion. The public admission witness holds the terminal marker read, write, or deletion after a thrown or invalid hook: a new commit durably joins the queue at each cut but cannot run before head cleanup. The started-write witness crosses write acknowledgement before, during, or after the hook fault, including a row visible before acknowledgement and a write rejected before storage changes. It checks both public promises, outbox IDs, Collection rows, and same-executor peer progress. A visible but unacknowledged peer cannot run even after the head is removed. The controlled adapter does not cover a write that changes storage and then rejects its acknowledgement; fresh executor startup before a held write acknowledges remains outside this witness. Failed terminal marker or deletion storage still stops the executor: the head caller receives the hook error, the batch receives the storage error, and queued peers stay durable and unrun. If deletion fails after the terminal marker is written, restart removes the marked row without another named mutation function call or optimistic restoration. The settlement owner also checks terminal named mutation function rejection with failed deletion, a halted executor with queued peers held, and offline executor restart without a second named mutation function call or optimistic restore. The executor does not automatically retry a failed phase write or deletion. A failed terminal marker write followed by a crash remains an unmarked outbox replay window. The row-local review, retry-decision grammar review, rejected-Promise review, and error-boundary review record the checker controls. The Node-hosted Promise witnesses do not establish browser unhandledrejection, third-party thenables, or rejection after executor disposal; this settlement owner needs a receiving witness for any broader claim. A held provider can reject after removeFromOutbox or clearOutbox acknowledges deletion. The default network retry and a hook's 401 retry both reject that caller with the provider Error, keep the outbox empty, and allow later same-executor work. Manual removal overlapping the read/write inside outbox.update, rather than finishing before provider settlement, still needs a controlled witness and an atomicity decision in this owner. Broader offline retry and recovery policy remains with RFC #1659.
• A10 R11/R12 and earlier R8: metadata/native-value domain, old readers of new wire records, and unreadable/unknown-version outbox recovery. New readers accepting old records does not prove reverse compatibility. Do not delete unreadable work silently or invent exactly-once guarantees.

Other explicit follow-up boundaries are owned by issue #1820, not silently claimed green:

• Effect disposal: the existing external-disposal wait and synchronous in-handler cancellation are tested. Waiting for independent work returned by the initiating handler conflicts with supporting a handler that awaits its own disposal. The candidate implementation was removed pending a contract.
• Proxy native mutators and symbol writes: retain supported standard Map/Set behavior. Decide additional support versus a clear error before generalizing expectations; do not silently drop native edits.
• Progressive/native execution: eight progressive registrations lack valid phase/capability evidence. Electric's ready gate is after application, not a pre-swap source gate; TrailBase does not supply that capability. The 24 move cases and actual native hosts need separate execution receipts. A green registration helper or package job does not prove these cells ran.
• Optional mechanics/performance: separating the expensive replay-process campaign, sharing native runner code only with both host builds verified, optional cancellation calibration and proxy construction-work budgets. An earlier suggestion to merge unnamed cleanup helpers still lacks exact targets; do not perform a blind consolidation.

SQLite Temporal value preservation#

The implemented v2 grammar and evidence cover native Temporal.Instant and Temporal.PlainDate through the shared SQLite adapter and local persisted wrapper. Global constructors must be registered; other Temporal kinds reject. Existing lifecycle, receipt and publication-before-durability laws remain with their current owners.

• The typed-value owner checks real file reopen, direct/nested rows, metadata, replay, equality/range, Boolean/IN, large IN, field comparisons, cursor ties/continuation and ordered windows. Its directly named rank/text companion supplies independent native observations across precision, signed-year, endpoint and calendar families. Constructor failures, invalid brands and marker-shaped records are included.
• The Node expression-index owner checks raw SQL before residual cleanup, final adapter keys and actual named index use. Wrapper-created coalesce indexes reach Collection metadata/native literals and distinguish adjacent-literal signatures. Small and large scalar membership indexes protect compatibility with SQLite's DDL restrictions. Numeric array/object native EQ and IN also inspect persisted expression values. Mixed-domain polarity checks retain NaN, null/missing and scalar controls. NUL strings cover both equality directions, membership and Boolean composition. Negated coalesce and scalar eq(in(...), true) keep #1997's full-read fallback. Exact replay excludes unrelated native cases; simultaneous semantic/cleanup failure retains both errors and still closes SQLite.
• The ordinary-work owner adds twelve native repeated-action success/rollback histories and invalid superseded actions. Its independent Map model retains immutable native values; kind/text observations reject the old structuredClone false-green boundary.
• The persisted wrapper owner rejects native remote-subset literals before dispatch/retry, including an ownerless leader that becomes a follower while hydration waits or after local success followed by sequence-gap recovery. The latter uses the existing terminal error path before retry admission. String controls dispatch once; existing transient retry, receipt and FIFO histories still run. The mixed-demand refinement covers both demand orders, retained/aborted/released candidates, both native kinds and string controls. It observes valid-prefix dispatch, exact reentrant and later error identity, post-terminal replay/retry fencing, and exact release objects. Successful controls observe complete demand coverage after held transport settles. First-demand-only and replacement-error mutants distinguish these laws from the older singleton checks; successful pullSince recovery and real-host elections remain separate receiving paths.

The initial RED receipt remains historical. The v2 receipt records failures against original production, a lexical-order mutant that retains native reconstruction, and intermediate paired-IN, nested-path, routing and membership-index counterexamples. Final results are green for the reached paths; this is not a universal proof or a latency guarantee. SQL cleanup alone cannot compensate for lost candidates.

Remaining witnesses have explicit owners: engine-native/alternate constructors and old-byte/marker-shaped compatibility belong to the typed-value owner; native truncate/delete, crash and format-transition histories belong jointly with ordinary-work/resume owners; real mobile/browser roundtrips belong to each adapter's receiving contract; actual native multiprocess transport belongs to browser/Electron coordinator receiving owners. The persisted owner retains native release/abort/reset and wider ownership schedules. None of those receiving claims follows from this Node/shared-core result. Same-kind ordering is the supported domain; arbitrary Temporal arithmetic and other kinds are excluded. Applications may rebuild old damaged caches through existing schema/reset paths; no type can be recovered from an already-erased empty object.

Law enforcement audit#

The law audit strengthens the persisted and Browser owners after three demonstrated false greens. Captured pre-validation expectations protect mutable builtin state on acceptance and rejection. Rich output checks now enforce detachment and exact release-object identity; later projections must reflect changed input without altering earlier snapshots. Optional indexes cross both supported native kinds and missing-global cases, plus independent local/coordinator synchronous and held failures. The intermediate held cut checks that coordinator completion evidence cannot precede local settlement; settled cuts check warnings, exact calls, healthy siblings, readiness and ordinary reads. Mutants establish assertion sensitivity. Copy-work bounds remain explicitly limited to the measured buffer/record copy seams and full discarded projections; total allocations, latency, arbitrary third-party coordinator work, and real-host scheduling are not established by these checks.

Remaining review investigations#

The high-effort follow-up records measured work and upgrade behavior. Remaining questions are assigned to the following owners:

• The boolean-arity compiler-work owner now counts discarded literal quoting for bound string IN at sizes 0, 1, 32 and 1,025. The old compiler performed two quotes per value; the repair performs none and retains exact rows and binding counts (BUG-007, HE-006). This is not a latency bound.
• The bounded follow-up closes repeated native literal encoding (HE-007): the typed-value work witness admits at most one encoding per literal occurrence for EQ and IN at sizes 1/3/1,025. Both native kinds are calibrated against the previous implementation; the surrounding expression-index and rank/text owners retain semantic coverage.
• Discarded wire projections (HE-008) are closed for the three persisted admission guards by shared validation-only traversal. The work follow-up records an 18-case persisted matrix: follower/role transition/retry/recovery and abort/release during hydration at 0/1/33 bytes. Payload copies drop from two to one per successful attempt, four to two across a retry, and one to zero when demand retires during hydration. Independent Browser-owner rejection/path fixtures cover validation-only admission; frozen rich-value receiving histories retain cycles, aliases, detached snapshots, and local lifecycle identity. The original guards and no-admission/no-detachment mutants fail at intended assertions. Repeated validation traversal and runtime latency remain unmeasured; real-host scheduling remains with the browser/Electron receiving owners.
• Optional index specification serialization now shares the existing best-effort persistence boundary. The index-admission follow-up records startup/runtime histories with supported native controls, unsupported kinds, missing global constructors, and healthy siblings. The persisted owner asserts readiness, exact local/coordinator signatures, warning paths, rows, and subsequent ordinary reads. Original source and a local-only repair fail six cases each. This covers wrapper admission; real SQLite index execution and browser scheduling retain their separate receiving owners.
• The resume owner now proves the selected explicit schema-reset route for obsolete indexes (HE-010) and ambiguous legacy marker bytes (HISTORY-002). It removes both registry entries and physical indexes before the first read, preserves an unrelated collection, and retains newly escaped data and rebuilt indexes on same-schema reopen. A registry-cleanup mutant fails this witness. Automatic reclamation without reset and lossless old-byte migration remain outside the selected policy; this test does not claim either.
• The Collection index-value owner distinguishes native literals from ordinary tagged records, nested mixtures, and the escape envelope while preserving equivalent key orders (BOUNDARY-005). Plain and null-prototype own-tag records have isolated metadata snapshots (BOUNDARY-004/HISTORY-004). The old implementation fails these public metadata observations. Custom-prototype impersonators are outside this owner's native contract; the typed-value owner separately checks rejection and rollback of an invalid native brand at SQLite persistence.
• The Node expression-index owner now covers ordinary/native-mixed NUL lists, four NUL/Unicode positions, positive and negated membership, exact stored index values, final keys and candidate containment (VERIFY-NUL-NOTE). The former SQL literal encoder fails at the public index-DDL boundary. Direct runtime mixed membership already passed; the defect was persisted expression construction.

Final evidence record#

Verification receipts and follow-up issue links are recorded in the PR and the issue closeout comment. Keep their exact revision/runtime boundaries; historical counts in research notes do not certify later commits. Closing the bounded repair means the acceptance map has evidence and each remaining question has an owner—not that there can be no more bugs.

IndexedDB Collection persistence#

Owner: IndexedDB oracle portfolio. Settled histories compare independently authored scalar rows with public, subscription, peer, export, raw durable and fresh-restored snapshots. Imports check changed-value versions; detached driver inputs protect authored truth. Handler decisions are followed by an ordinary successful insert before a separate replacement suffix, so replacement cannot erase the observed leak. Wrong-version, input-mutation and suffix-leak controls calibrate those boundaries.

The transport owner adds twelve histories: delayed clear/import followed by a later disjoint receiver insertion under FIFO/reverse/duplicate notifications; idle/cleaned-up clear/import; real manual acceptance after cleanup; and whole- database deletion with active sibling stores. Every affected public snapshot must match authored durable operation order after controlled delivery. A raw unseen row makes excluded-notification handling observable. These cases repair specific convergence laws; they do not establish arbitrary concurrent receivers.

The compatibility owner checks full versus getRandomValues-only crypto through write/broadcast, one reusable descriptor across independent DbClients and cleanup, and injected factories without ambient IndexedDB globals across typed-key multi-store restore/import/clear. Wrapper tests distinguish callback, request and native completion, including durable rows after late callback rejection. Store creation is additive; declared stores and actual native stores are distinct. Normal generated persistence tests retain fixed/random campaigns and direct seed/path replay. Blocked/unblocked open/delete cases check native terminal settlement and caller connection ownership through later native upgrade/delete. Native failed opens preserve durable rows/schema. A blocked administrative deletion retains public and durable snapshots. Its receipt has no row-publication authority; managed versionchange marks affected Collections errored while retaining rows. Failure to issue deletion preserves those snapshots. The controlled cases establish no timeout, cancellation, or automatic in-memory fallback. Native receiving cases below cover named blocker and release schedules; arbitrary browser lock scheduling remains open.

The transport owner also crosses two/three independent managed descriptors with native upgrade/delete. Exact versionchange recipients and zero blocked events check automatic close. Deletion retains errored public snapshots while fresh storage is empty; upgrade preserves durable rows. Both require fresh descriptors for further persistence. The four original-source assertion failures and repaired cases distinguish this law from the earlier shared-descriptor fixtures. Raw unmanaged blockers keep the wrapper's pending-until-terminal law. These controlled cases do not prove browser scheduling.

The concurrent extension adds independent per-Collection expectations, raw publication and Collection-status recording, native transaction gates and non-awaiting dispatch. It receives the whole-row omission law and rejects a full-to-partial application mutant. It also rejects a spurious Collection error, invalid delta semantics and a repaired partial publication. A serial delivery fixture fails the overlap reach control. Generated histories use fixed/fresh parity, original-failure-preserving reduction and checked direct replay.

Executed coverage and remaining package-owned cells:

• Connection ownership, CR-02: native managed versionchange with a held test-owned readwrite transaction and unmanaged deletion blocking, in all three engines. The retirement and deletion-queue owners now receive admitted writes, immediate error notification, obsolete reads, late startup, caller/publication obligations, and both native blocker-release orders. The retirement owner additionally receives abnormal native closure with ready, idle, loading and five admitted persistence operations. Chromium receives actual native close/abort through storage clearing; other engines lack that control. Raw close bypass and automatic restart remain outside the managed contract.
• Persistence, PC02: all six manual acceptance orders for three distinct Collection identities, two stores, disjoint same-store keys, reused sibling keys, mixed deletes/inserts and unaffected versions. The compatibility owner also projects same-ID/disjoint-key payloads by Collection reference, in both acceptance orders before/after cleanup. Same-ID/same-key core payload merging remains outside that adapter witness.
• Settlement, PC04/PC06: first/middle/last clone failure in a three-row batch for automatic/manual/import; multi-row held CRUD with both decisions and independent peer progress. Raw storage, caller, payload, versions, ordinary suffix and restore cuts remain distinct.
• Transport/settlement, PC08/PC10: two to five independent descriptors, generated read windows across replacement/CRUD, one held whole-row local intent crossed with peer CRUD/clear/import, and downstream query cuts. Native import exposed transient union publication and ordered peer persistence exposed duplicate-insert confirmation; both have source repairs and receiving tests. The local-order owner now crosses three held local intents with ordered peer update/delete/replace and checks every decided prefix. Peer work interleaved between those acceptances, multi-intent intermediate local publications and reads straddling unordered writes still need receiving witnesses in the pending/transport owners; final local equality does not prove those cuts.
• Transport, PC12/CC09: obsolete receiving read success/abort after cleanup and restart; native obsolete abort and later restore. Pending mutation caller outcome/confirmation into a restarted sync run remains a distinct policy and test obligation; callback invalidation does not specify it.
• Transport/core optimistic, PC16: non-truncating omission via ordered delete/reinsert in controlled and native drivers; active intent, exposed base, public snapshot and one-use acknowledgement metadata at held/settled cuts. Nested values and several overlapping local intents remain with the core owner.
• Settlement, AUX01: valid post-durability send/publication failure still needs a native premise and defined caller/source/public outcome. No retry or rollback-after-commit policy is inferred.
• Native/consumer, CC10: Chromium, Firefox and WebKit receive overlapping callbacks, native read/write abort, startup subscriptions, blockers, versionchange, controlled page close/reload and restore. Raw evidence survives acknowledged page destruction with a held handler. A schedule-dependent mutant reproduces its original law/checkpoint in each engine. The controlled pending companion checks complete downstream live-query snapshots. Real suspension, lost-message recovery, quota/eviction, process-crash durability and evidence lost before runner acknowledgement remain open and require their own premises.

Native evidence is per engine. Simulated reverse/duplicate messages do not prove browser delivery ordering. The package has no leader election, timeout or in-memory fallback. Same-key writers without explicit persistence order, untested mutable-value shapes and timing guarantees remain unresolved; separate Collection acceptance calls do not promise cross-Collection atomicity.

Typed-key payload identity (HC005): the optimistic transaction payload oracle now crosses four numeric/string pairs, both author orders, insert/update/delete/ repeat-update, and success/rejection. Exact handler payload multiplicity, order, types and final public keyed rows reject the original collision. The native host owner receives numeric 0 and string "0" in one insert, then peer update, import, clear and restore. Core global mutation identity now encodes Collection id, key type and key value as a tuple. This does not establish interoperability between distinct Collections that intentionally reuse the same id and key.

Failed mutation callback context: the optimistic transaction payload owner checks that restoration publishes after the failed callback's ambient frame ends. A subscriber's new write is visible but does not enter the failed transaction payload. Nested success and failure witnesses retain the enclosing callback's context for subsequent writes. The reviewed implementation fails the subscriber payload cut; the frame-specific repair passes it and the adjacent nested histories. These finite histories do not establish arbitrary subscriber reentry or cross-scope restoration behavior.

Failed-callback snapshot work: the same owner places 16 prior mutations in one transaction and counts array-entry visits across five no-write mutate callbacks. The eager snapshot on the reviewed code visits 80 entries; capturing only before the first real applyMutations visits none. The neighboring failed-write histories still check restoration of prior intent. This bound does not remove the existing linear merge traversal for each real write or establish elapsed-time performance.

Compound joins#

The replacement evidence record records RED admission on main, GREEN refinement, and hostile-mutant failures. The cold-join reconciliation owner now covers compound equality classes, nullish operands, two/three terms, order/reversal/nesting, all four join types, scan/index paths, controlled cold acquisition, and keyed replacement histories. The identity-output-shape owner checks complete predicates through direct, from-QueryRef and joined-QueryRef boundaries. The includes-context-transport owner checks parent values used only in a later equality across both operand sides and direct/joined-QueryRef sources, in all three materialization forms.

The compiler demand oracle in packages/db/tests/query/compiler/lazy-demand.test.ts independently recomputes active first-key demand from satisfiable rows. Its finite histories cross LEFT/RIGHT, two/three fields, both term orders, shared primary keys, nullish components, and put/remove/restore. Nullish tuples contribute no keyed demand. The controlled cold provider now applies direct-field IN requests using the independent value-class labels. Four distinguishing numeric tuples reject wrong-field demand that the former whole-table provider missed.

The bounded claim excludes arbitrary expression trees and wider tuples. Real provider acquisition, eviction/reentry, and exact lazy-demand minimality need receiving witnesses in the cold-join and adapter owners. Compound async, optimistic, paginated, and deeper nested include histories remain with the includes-temporal, includes-optimistic, pagination, and includes owners. This feature does not claim those cross-products are established by its finite matrix. Consumer hook caches require framework conformance witnesses; the identity owner proves the compiler identity boundary and fresh public rows.

Review follow-ups remain bounded by the evidence above:

• The cold-join owner must distinguish required acquisition from demand minimality. A nullish tuple contributes no keyed demand; a satisfiable tuple still needs a positive witness. Real-provider demand counts remain with the receiving adapter owner.
• A deterministic 10,000-row-per-side probe measured the new operand-array cost and the repair: single equality 20,000 to zero arrays, two equalities 40,000 to 20,000. Whole-query runtime and heap impact remain unmeasured. The always-tuple alternative restores single-equality allocation, so its simplification remains a tradeoff for a future measured join benchmark.
• Builder admission checks Boolean join syntax, while the compiler binds sources and also accepts direct IR. A single-parse representation would need a design for these separate entry points and measured compile-work benefit. No parser state or cached validation is added for an unmeasured saving.
• The cold-join driver's cleanup callback unsubscribes before cleaning up its live query. No legal throwing-unsubscribe witness was found. The owner is checkWithCleanup in the cold-join oracle; any future cleanup change must demonstrate the throwing path and verify later cleanup plus primary-error preservation. This is an evidence gap, not a demonstrated production bug.

Compound-join planning and identity follow-ups#

The second high-effort review at 5bb211519 distinguishes semantic identity from physical acquisition. A controlled React useLiveQuery rerender keeps its Collection and region-first demand when only the equality order changes. Freshly compiled controls use the supplied order. The guide now states that ordering selects a plan when the Collection is created. This React witness does not establish other frameworks' reuse behavior.

• The compiler/lazy-targets and cold-acquisition owners retain the proposed first-eligible-equality optimization. A receiving witness must cross join direction, computed operands, direct and subquery sources, and index modes.
• The identity owner retains join-specific unary/duplicate equality normalization. Public and() requires two operands; direct unary AND IR and and(eq(...), eq(...)) with duplicate terms currently differ from bare EQ. A change must preserve general Boolean coercion and test actual Collection reuse in the receiving framework. Making loading order part of identity is a separate design choice; current identity remains semantic.
• Exact compound acquisition needs a tuple-preserving demand model in the compiler/lazy-demand and cold-acquisition owners, plus adapter witnesses. Independent per-field IN sets admit cross-pairs from different parent tuples. Current first-field candidate supersets remain permitted by the architecture.

IndexedDB review extension: local ordering and boundary admission#

The xhigh review at 6ad2edc42 receives its audit in the versioned review record. local-write-order-oracle.test.ts owns the approved automatic-write ordering law for one Collection: three authored effects, every handler completion permutation, every accept/reject mask, held earlier handlers, and synchronous handler reentry. It checks caller outcomes, durable/public/peer snapshots and fresh restore. The native suite receives held insert followed by update in Chromium, Firefox and WebKit. Cross-Collection writers and explicit utility operations remain outside this ordering contract.

The compatibility owner adds id changes at options/Collection construction, automatic/manual acceptance and acceptance after cleanup. Transport adds none/mixed/all version metadata, typed keys, duplicate delivery, invalid message exclusion with a valid neighboring read, old-connection error propagation, and native deletion completion separated from callback delivery and database recreation. Native multi-page tests receive the deletion/recreation premise in all three engines with the old success callback deliberately held.

The wrapper owner observes native error causes. Settlement counts all native write requests admitted before the first success and retains its atomic abort matrix. This establishes request admission work, not an elapsed-time speedup. Runtime and type tests use source without built DB output. Published declarations have a separate build-consuming lane after concurrent CI runtime tests finish.

The law enforcement follow-up records the subsequent calibration and closes the stored-field/type cleanup.

• Connection closure, XH-06: implemented under the subsequent approved contract. Managed versionchange and explicit descriptor close immediately mark affected Collections errored. New reads lose publication authority; native- admitted writes finish and confirm without regaining readiness. Applications recreate Collections. The retirement owner, core readiness owner, and native receiving cases enforce these separate obligations.
• Deletion lifetime authority, XH-07: closed under administrative deletion. The stale-receipt counterexample was retained before implementation. The Collection deletion utility and database-deleted message authority were removed; deleteDatabase(name) only reports the native administrative outcome. The deletion-queue owner checks old/new receipt cuts, retained errored snapshots, queued name targeting, and fresh empty storage. The browser owner receives both unmanaged/native transaction release orders. See the TLA refinement audit for exact bounds and provider limitations. No persisted identity or deferral.
• Stored metadata/public types, XH-14: new version records omit updatedAt; legacy absent/past/future timestamps retain their row semantics. Persistence checks ordinary writes, untouched records, mixed-format restore and replacement. Utils now carry output and input types only; source assertions and published ESM/CJS consumers preserve the transformation distinction and Collection keys.
• Ownership, XH-02: equal/distinct Collection IDs, both manual acceptance orders and live/cleaned-up sync runs retain only reference-owned effects.
• Transport, XH-03/XH-08: absent metadata at the receiving read is independent of startup metadata. Typed keys, initial membership, duplicate delivery and a successful suffix are checked. Invalid envelopes cannot issue storage work. Native pages receive missing-metadata rows and duplicate notifications in all three engines; low-level writes still require their own invalidation.
• Settlement and diagnostics, XH-04/XH-09/XH-13: transformed-key collisions and schema failures at first/middle/last input preserve rows and versions; exact cause identity survives each native admission branch. Request admission counters cover automatic insert/update/delete and import, with atomicity enforced by the existing abort matrix.

IndexedDB connection closure: TLA+ refinement owners#

packages/db/tests/indexed-db/retirement-oracle.test.ts owns the finish policy's row, caller, admission, read-authority, accepted-work and error-status laws. deletion-queue-oracle.test.ts owns administrative receipt authority across delete/recreate/delete. packages/db/tests/truncate-readiness-oracle.test.ts owns replacement publication with explicit readiness preservation. Their models remain structurally independent of production connection listeners and caches. See the loss audit for every formal transition/invariant, recovered distinctions, fault calibration and bounds.

The browser receiving owner crosses five admitted mutation kinds × three closure origins × commit/abort in all three engines. It separately receives both releases of an old native transaction and unmanaged deletion blocker. This last receiving witness is required: fake-indexeddb 6.2.5 violates the transaction-only deletion hold. The model law remains normative; the faulty provider does not narrow it.

The closed-connection finish policy is separate from cleanup/restart, physical crash, lost notifications, post-durability application listener failures and uncontrolled browser discard. Those existing owners/boundaries are unchanged. This bounded translation does not claim every formal graph path is executed by the TypeScript suite or that finite tests prove unconditional progress.

IndexedDB wrapper observer composition#

packages/db/tests/indexed-db/wrapper-settlement-oracle.test.ts owns callback/native settlement independently of native event-observer registration. Its 20-case matrix crosses native complete/abort, none/additive/property/replaced/ cleared observers and immediate/held callbacks. It checks caller outcome at native terminal and callback-release cuts, durable rows and exact application observer events. Twelve cases failed against property-owned settlement; eight controls passed. Two adjacent native request-error cases distinguish prevented errors that permit commit from uncanceled errors that abort. The original wrapper owner keeps callback failure identity and late rejection after native commit. Provider scope is fake-IDB; no physical-crash or arbitrary event-suppression guarantee is added.

IndexedDB donor coverage receiving extension#

The sighted donor survey now has these receiving owners. The port audit records calibration, validation and the remaining limits.

• DP08: compatibility-oracle.test.ts starts two/three native opens against absent same/independent names, with identical complete declarations. It checks schema, held restore/readiness, disjoint writes, convergence, restore and a later upgrade with no orphan blocker. packages/db/e2e/indexed-db/value-oracle.spec.ts receives three-open histories in all engines. These histories settle all opens before writing; they do not impose an order on open callbacks or union conflicting declarations.
• DP09: persistence-values-oracle.test.ts extends the persistence owner with independent tagged descriptions in structured-clone-oracle.ts. Seven value shapes cross scalar updates, peer delivery, export/import, first/middle/last nested clone rejection, metadata rollback and fresh descriptor restore. Type, offsets, backing bytes, dates and Blob content are observed inside the receiving realm. Native receiving is in packages/db/e2e/indexed-db/value-oracle.spec.ts.
• DP10: the compatibility owner substitutes six legal database/store names into the same authored multi-store history. Prefix neighbors, typed keys in separate transactions, version values, peers and restore distinguish routing mistakes. packages/db/e2e/indexed-db/host-oracle.spec.ts receives all six names through single-transaction typed-key insertion, peer update, import, clear, export and fresh restore. Prefix-neighbor and anchor snapshots must remain unchanged.
• DP17: packed-consumer.test.ts supplements declaration tests with installed tarball ESM/CJS consumers and broken-export controls. The browser spec builds the same consumer without source aliases and executes it in all three engines. Tarball overrides pin the installed dependency closure; registry range selection, older Node/tool versions and every public export remain outside this smoke test.

The ordinary local Playwright WebKit profile rejects Blob preparation with UnknownError; its two Blob-containing cells require exact rejection and a healthy suffix. The additional disposable persistent WebKit profile requires native acceptance and executes the full preservation/capture/rejection/restore histories. Chromium and Firefox receive the same full corpus. The provider rejection branch cannot certify success in the persistent profile.

IndexedDB approved donor follow-up laws#

The follow-up audit records the approved contracts and assertion-killed wrong implementations.

• DP02, abnormal closure: the retirement owner adds idle/ready/loading and five admitted persistence phases. It compares actual native outcome, caller settlement, retained public rows, error status, rejected later admission and fresh restore. Its forced-close fixture compensates for fake-IDB's missing forced transaction abort by aborting those native transactions explicitly. Native Chromium storage clearing supplies seven actual close witnesses, including six with admitted work. This proves neither other-engine forced termination nor physical-crash durability.
• DP03, blocked diagnostics: wrapper open/delete and managed opening expose the optional native event without settling the caller. Native old/new version, independent blocked reach, callback count and eventual terminal settlement are checked. No timeout, cancellation or fallback is added.
• DP12, value capture: persistence-values-oracle.test.ts crosses six mutable kinds with update/import behind handler/storage gates. Authored descriptions compare writer, peer, export and durable rows after caller mutation. Native receiving includes the immediate update snapshot and held settlement cut. The core detachment owner checks buffer bytes, view range, aliases in both traversal orders, foreign realms and custom-constructor compatibility. Native iframe witnesses receive standard foreign ArrayBuffer/Uint8Array/DataView aliases in each engine. Shared-memory concurrency, detached/resizable buffers and arbitrary class private state are outside these copy laws.
• DP13, dedicated workers: the native host owner uses real worker and page contexts for typed-key insert, peer update, import, managed close, retained error snapshot, late-write rejection and worker recreation/restore. Service workers, SharedWorkers and background delivery are unclaimed.

Atomic cross-Collection read-modify-write remains a separate API proposal. Native durability remains the current receipt. These are accepted design limits, not deferred implementations of the approved follow-up.

Electric recovery demand and scoped persisted restore#

The cache-eviction design records the generation and expiry laws and their unresolved cuts. The PR #2069 review at 51563046 records the Query startup handoff, index reverse-order challenge, all review dispositions, and the repair commit's ORC-012 audit. The review of code head 7f1df5c82 records the ORC-012 outcomes, RED/GREEN witnesses, and evidence gaps. The receiving-gap audit at 87aead1be records the native Electric, shared-QueryClient, and old-leader timeout histories, their mutant outcomes, and remaining cuts. The real-SQLite owner checks generation rotation, legacy-writer isolation, warm-run claims, rejection of moved or expired claims, uncertified key-set evidence after partial writes, and physical collection of a retired row table. A held registration test rejects a read after collection and removes its late DDL and metadata. Two further real-SQLite held-registration histories move one claim while a warm peer retains the physical generation. They require both an initial registry insert and a destructive schema reset to check that claim inside their SQLite transactions; the warm peer keeps its schema, rows, applied transaction, and resume metadata. The persisted owner checks demand-triggered and timer-triggered expiry recovery, queued old source commits, and an optimistic mutation held through the accepted truncate. It also holds hydration, row-scan, and replay results across claim expiry and checks publication or returned rows after recovery. A startup history holds private rotation during index bootstrap and checks that the source cannot enter until new storage is bound. The real-SQLite owner rejects an expired startup resume record and checks that a public index event from an expired Collection cannot remove a warm peer's persisted index. The persisted owner also holds cleanup across cache rotation and requires the late private claim to release. It holds a peer full-reload read across claim expiry, checking both returned old rows and SQLite-style rejection at its second claim check; a live-claim I/O failure remains terminal. The real-SQLite owner accepts a valid eager Collection ID with the internal cache prefix and rejects late managed registration that tries to recreate collected storage after the first claim check. Its explicit-storage-target history rejects bare IDs of both ordinary and cache-generated form. It checks all eleven adapter data operations after a managed generation is collected, compares every per-ID catalog and physical table after each rejection, reopens the adapter, and retries the old managed target after explicit eager reuse of the same ID. The contract is claim authority, not a reserved naming prefix: an application that explicitly declares an eager Collection with those bytes may create eager storage. The bare-ID fallback mutant fails at the first post-collection read. The explicit-storage-target review records the checked paths, mutants, and remaining native-host limits. The persisted owner also keeps a subset demand through rotation from an old row version 10 to a new version 1 and requires the new peer notice to request source reacquisition. Four held-rotation histories cross old row versions 1 and 10 with an old physical cache's commit or reset before rotation binds. The new notice has row version 3 or 1, so the old notice can have a lower or higher version. A fixed and random bounded grammar also varies absent, commit, and reset old notices, both row versions, and absent or present new notices. The queued old callback cannot add a source request; the new notice must request source reacquisition. These use a controlled in-process coordinator whose recording adapter shares row storage across physical IDs. Exact durable row isolation, arbitrary interleavings, and native multi-tab delivery remain separate checks. The persisted owner varies whether a custom on-demand source has an active subset before claim loss. It requires one source cleanup and a new source entry after rotation, checks that a retained demand reaches the replacement, and invokes a late callback from the retired session. The callback cannot publish or persist its row. A real SQLite receiving history expires the first claim, then checks reentry, public rows, and the replacement physical cache through a claimed adapter read. Native-host delivery remains separate. The controlled owner also holds custom rotation until Collection cleanup; it requires one old-source cleanup and no replacement source entry after disposal. The same owner crosses cleanup before and after a held scoped refresh settles. Its raw coordinator release log requires exactly one release in both orders; the cleanup-first case rejected the prior double-release path at the late settlement checkpoint. A real multi-tab transport receiving cut remains open. The persisted owner also rejects a startup resume read after its claim expires, including two successive claim losses, then enters the source only after a live read under the replacement claim. A live-claim read error stays terminal. The real-SQLite owner now holds a resume transaction before its second claim check. Its fixed and generated histories cross clock cuts before, at, and after expiry; row inclusion; zero-to-three rows; and a later peer-claim time. An expired read makes no generation-specific durable access beyond claim validation; the live peer retains exact rows and metadata. Removing the transaction-local check and moving it after payload access fail at separate comparisons. The wrapper's response to that rejection remains a controlled adapter history, not a composed SQLite startup receiving history. The persisted owner holds resume certification across claim expiry: an old answer or a second claim-check rejection starts private recovery, while a live-claim I/O failure remains terminal. It also holds initial scoped rotation while aborting one demand and checks prompt rejection with a sibling still pending. The CLI owner writes a claimed physical ID through sqlite3, and its subset-failure cases seed the claimed storage while preserving their public and durable assertions. The Browser owner checks two concurrent runs: the recovering demand reaches its own source owner while the warm run keeps its source-backed row. Another controlled receiving test delivers a peer notification to an expired claimant before its renewal timer runs and checks subset reload. Both coordinator owners offer unload before a held source load settles. The persisted owner now holds claim renewal after wrapper admission and varies whether the demand retires before the claim check returns. At load settlement it requires zero coordinator acquisitions for retired demand and one for retained demand; the retired case rejected the former late-acquisition path. It also revokes a claim after a cache subset read, then holds the replacement acquisition. The active demand must request it once and remain pending until it settles. The old path made two coordinator requests at that cut. A separate pre-read expiry history and peer-notice histories cover their narrower cuts; these controlled paths do not prove every real-host scheduling interleaving. The Browser coordinator owner holds an acquisition across a failed release and varies whether the acquisition settles before or after release starts. A pending release retry survives both orders. Its unacquired-release case observes no outbound RPC. The overlapping case failed before the acquisition-success path stopped clearing release retry debt. These are controlled transport schedules; a real tab crash and an indefinitely unreachable leader remain outside them. The Browser coordinator owner also checks that a managed local mutation carries its exact claim into the coordinator-created transaction. Its recording-adapter law failed before the repair at the target-kind comparison. A follower-RPC claim-loss mutant fails at its success checkpoint. A real SQLite receiving history accepts that write and rejects a late local mutation after rotation without recreating the retired table or registry. Direct coordinator callers that omit a claim remain outside this adapter law; the coordinator interface still accepts eager Collection IDs. The Electron IPC receiving owner forwards claim, renewal, rotation, release, cache-claim read contexts, exact-ID reconciliation, and durable term reservation through protocol v6. Its in-process main adapter witness keeps the logical Collection ID for adapter selection while reads address the claimed physical storage ID. A direct shared-renderer-adapter claim/read/release history selects the authored logical ID, and a raw managed envelope without it fails before main-process selection. The shared SQLite adapter contract runs its claimed-cache cases over that bridge. A custom main-process adapter can explicitly disable managed cache generations and retain the full-shape fallback. The local Electron binary is unavailable, so an actual main/renderer process receiving cut remains with the Electron runtime-bridge owner.

The Electric descriptor owner now holds an old SDK snapshot across claim expiry. The replacement provider session settles both demands from fresh snapshots, rejects a pending old txid wait, and excludes a late old row from public and durable state. A second delivery lands during rotation, before the replacement stream starts; it rejects old callback admission into the new cache. Initial scoped recovery also forgets imported old txid evidence, and retiring an incomplete old stream transaction releases its commit turn so a new demand can start. These histories killed the one-phase restart, retained acknowledgement, and open-transaction designs at their named checkpoints. The Electric descriptor owner also holds rotation while aborting one old demand: that demand rejects promptly and a sibling later applies fresh source rows. Its overlapping-rotation history rejects a callback from the retired middle provider session, then requires the final provider session to apply a fresh subset demand after the second gate opens. The unabortable restart wait failed at this settlement checkpoint before the repair. The SQLite owner rejects coordinator stream-position, replay, and index work from a specific expired claim even while a peer claim is live. An expired run recovers privately while the healthy current cache remains claimable. The older Electric resume-race owner explicitly exercises adapters without managed generations; its unknown and missing on-demand evidence cases now require full-log replacement. The scoped reset settlement owner uses an abstract managed claim for that one applied-receipt law; the SQLite owner checks physical generation separation. The bounded cache-authority design grammar also checks incompatible resume evidence followed by claim expiry. SQLite's transaction-time claim test makes that rotation private. The SQLite receiving owner now holds the real adapter's rotation after a controlled source starts scoped recovery, expires that run's claim while a peer remains live, then checks the peer's public and durable rows and unchanged resume metadata, an empty then fresh subset in the private generation, its reset marker, the recovering claim's storage ID, and a later claim of the unchanged head. A mutant that uses the expired claim's remembered storage ID advances the head and fails at that comparison. The controlled source supplies the recovery decision. The Electric resume-race owner now supplies an incompatible stored shape identity, reaches Electric's own scoped-recovery decision, expires its claim before SQLite's rotation transaction, and checks that a warm peer keeps its rows and resume metadata while the recovering run gets private storage. This witness failed before Electric stopped writing a reset marker into the shared generation. A second real-SQLite witness holds rotation after the storage transaction but before public truncate. It delivers a retired Electric callback and starts a distinct demand in that interval. The replacement session refetches the active empty subset and applies fresh rows for both explicit demands. Only those rows reach public and durable state. A deliberate wrong row in the rotated storage fails the held private-cache assertion. The grammar combines those actions; these fixed receiving cuts supply the missing implementation evidence. It does not model physical garbage collection or arbitrary callback schedules. The separate receipt-settlement grammar checks the accepted-versus-visible distinction during scoped recovery with a persisting optimistic transaction. It is bounded model evidence; the optimistic-history and Electric owners remain the production checks for those receipt laws. The installed-SDK delivery owner now holds an old HTTP subset response across managed rotation and observes fresh demand settlement, public rows, and the new cache's durable rows after that old response arrives. Its adapter is a controlled Map; real SQLite and native multi-tab delivery are separate cuts. The same owner uses real SQLite and the installed SDK for a cold restart after expiry rotation left a partial row and no reset marker. It observes the row absent before and after an empty source subset snapshot, including with an explicit Electric offset or handle. The explicit-cursor cases were RED at the pre-response public-row checkpoint before the cache-trust predicate changed. This rules out both early cache hydration and relying on source completion to delete that row. The descriptor owner also checks that cleanup during a held rotation fulfills after rotation settles. It does not establish a prompt cleanup bound while the adapter rotation remains held. The Query ownership owner now pairs a real QueryClient with managed Node SQLite. It advances a cache claim beyond expiry, uses a disjoint demand to trigger rotation, and requires an already active subset to reacquire its distinct row without another caller request. A later demand with stale QueryClient data waits for a new fetch; an old fetch and a public utility refetch cannot publish or return their retired result. A held real SQLite retention scan cannot delete a same-key row reacquired in the replacement generation. A released acquisition cannot launch another fetch after its held old result settles. These are fixed histories at public-row, request-count, and caller-settlement cuts. A paired-Collection real-SQLite history now gives two on-demand Query Collections one QueryClient and prefix-overlapping but distinct Query keys. Only the earlier claim expires; its rotation and fresh fetch must leave the warm peer's public row, Query cache entry, durable row, current storage ID, and fetch count intact. A broad prefix-eviction mutant failed at the peer cache-entry comparison. Shared exact-key cleanup follows the documented Query cache contract; arbitrary retention schedules and custom provider restart implementations remain outside these histories. The expiry and late-fetch histories also read the tested run's claimed physical SQLite generation after fresh settlement and after the retired fetch resolves; both cuts require the fresh rows and exclude old rows. A separate active-head claim would inspect a different generation when an expired run rotates privately. The same owner distinguishes a private startup rotation from a warm startup: only the rotated run must refetch a cached QueryClient success. It also holds a peer Query fetch that began before source entry through that rotation. Both its late success and late error require a new fetch before demand fulfillment. Two queued rotations have a separate held-second-rotation cut: the first recovery cannot reacquire an active Query subset or start a provider fetch. After the second rotation, that demand must fetch and apply a fresh row. The Query owner also checks new keys with and without a stale QueryClient value after claim rotation: one provider fetch satisfies the generation boundary in either case, with no extra cancelled fetch. A rejected SQLite rotation instead puts the Collection in public terminal error and rejects later demands with that same error; this is fail-stop, not a silent observer freeze. These are real SQLite/QueryClient cuts, not arbitrary provider failure schedules. The persisted owner also holds active rotation across index bootstrap and checks that an index added during the hold targets new storage. Its adapter call log does not prove native SQLite DDL completion. A virtual-clock history holds the provider restart after rotation and requires claim renewal once it resumes; index creation and renewal failures stay best-effort without changing public readiness. A held bootstrap lets index removal settle before the earlier creation completes; the wrapper reconciles the final durable index with the Collection's declaration. Re-adding that index during reconciliation has a separate fixed witness. The SQLite resume-snapshot owner now runs both reverse-order histories through the persisted wrapper and real node:sqlite DDL. It holds the first new-generation ensure until removal settles, then checks the Collection declaration, index registry, and sqlite_master after rotation. Its re-add history makes the replacement ensure finish before the held reconciliation removal, so a missed final re-ensure leaves the real index absent. Host-specific native DDL scheduling remains outside these Node cuts. The persisted Electric interleaving owner holds an uncancelable local cache read after demand abort. It requires the returned load to remain pending until the cached row is public, then reject with AbortError; both fixed and random campaigns were RED at the early-settlement checkpoint before the wrapper separated pre-hydration abort from in-flight baseline settlement. A separate composed Electric probe confirms prompt abort while a later source snapshot is held after local hydration. These cuts do not establish cancellation of an SDK request that has already delivered its rows through the shared stream.

The persisted owner refuses a managed custom adapter that lacks rotation, renewal, or release, and refuses recovery from a managed source without a provider-session restart capability. The Browser owner holds the old leader's release message while the new generation starts its own source demand. Its host factory owner checks that configured claim lifetime and clock reach the SQLite adapter. A composed receiving history advances that clock past expiry and rejects a peer update before reloading the demanded subset. Cross-package Browser runs require freshly built core package artifacts because package exports otherwise resolve stale dist files.

Reachable limits remain. A source that declares a restart capability must itself retire callbacks synchronously when recovery calls it. Claim expiry after core publication but before SQLite accepts the write rejects the receipt and leaves the Collection in terminal error; a real-SQLite hostile probe confirmed the row can remain public without becoming durable. The ordinary durability-failure law permits that fail-stop, while automatic expiry reload covers admission before publication. The first new-format claim isolates but does not reclaim legacy storage. The Browser coordinator owner now drops an old leader's release reply after its adapter unload, transfers leadership, lets the real RPC timer expire, and checks that retry retires the outbound acquisition without replaying demand or unloading twice. A release-without-retirement mutant failed at the new owner's unexpected load. Claimless direct-adapter access to a physical ID after its catalog row is collected remains unproved and has a reproduced orphan-write probe; rejecting it while retaining arbitrary eager Collection IDs requires a durable distinction for former physical IDs. The Browser owner now has a combined receiving history over real wa-sqlite and the controlled Browser coordinator wire. Two runs hold distinct claims on one generation; only the earlier claim expires before its renewal timer. A real durable peer write precedes a matching, manually delivered notice. The expired run reloads into private storage while the warm peer retains its exact public and durable row, live claim, and source ownership for another demand. The current head remains unchanged. An always-rotate-head mutant failed at the head-ID comparison. Native coordinator emission, multi-tab or OPFS scheduling, and a composed SQLite-to-wrapper startup rejection were open at that review head. The SQLite owner now composes a real claim rejection during startup with the persisted wrapper: the expired run gets a private cache and a fresh demanded row, while a later live peer keeps its public row, durable row, and resume metadata under the unchanged head. Its separate three-generation reachability model varies release, expiry, renewal, zero or two rows, and collection checkpoints immediately before and at both renewed expiries. It compares retained row, tombstone, resume, and key contents; both physical tables; native indexes; every generation-scoped catalog; and claim identities. Wall-clock passage alone is not a sweep checkpoint. The persisted notice grammar now holds the fresh source receipt behind an optimistic transaction and checks a pending constrained demand, stale-row quarantine, the public publication trace, and release of the exact (storage ID, options) refresh acquisition. Its controlled coordinator supplies the receipt wait. The fixed Browser receiving cut below supplies that premise with a real coordinator on one schedule. The Browser OPFS owner now has a fixed two-context receiving history in which a real source commit makes the coordinator emit a physical-ID notice over native BroadcastChannel. One receiver callback is held until its claim expires; its private reload leaves the warm peer's public and durable rows and current head intact. An explicit demand stays pending until the fresh source receipt applies. The renewal timer lies beyond the fixed test window, and the receiver checks no refetch before releasing the delivered callback. The same fixed two-context history now also runs the installed Electric SDK in the expired tab against controlled HTTP source snapshots. It holds an old subset request and the new source response across the native notice, then checks pending demand, public and durable rows, and the warm peer. Dropping the held native callback fails at the refetch-entry checkpoint. Arbitrary native scheduling and a live Electric service rather than controlled HTTP remain separate unproved cuts; these fixed receivers do not close every cache-eviction interleaving.

The cache-generation oracle audit records the generated grammar controls, killed mutants, direct replays, and the remaining handoff limits for code commit 53ded62d8ef70ccd63b75d0e6dbc0a964f14b17c. The cache-claim gap audit records the added receiving witnesses, hostile checks, direct replay, and remaining limits for code commit 575fb9473dd7d8eccbe469d0831dc9f71cffddd4. The native SQLite index receiving audit records the two reverse-order DDL witnesses, hostile checks, and remaining host-specific limit for code commit b4d57ced63d513dd0dcb794b8e8bb2a840577758. The follow-up review audit records the exact recovery-settlement and target-table assertion repairs for code commit b42b94b73ddba79a6a87fa93e71787dd126ea1bd.

Issue #2056 evaluation records the original RED and candidate comparisons on head f43a16522c990134ae993235a312d2d5e433dc8a. The later scoped design revises the Electric guide's on-demand cold-recovery contract. The earlier “Complete” literacy status is not a claim that every recovery law or provider assumption is enforced.

Primary owner: packages/electric-db-collection/tests/electric-descriptor-isolation-oracle.test.ts. Its tag-history fixture has no managed cache claim, so an incompatible on-demand resume waits for a full source replacement while cached rows remain visible until the source transaction begins. The controlled ShapeStream rejects snapshot requests in full mode. Tagged cold, legacy, explicit reset, warm resume, interruption, partial replacement, and late demand have named cuts. Managed scoped recovery has separate descriptor and installed-SDK histories. The fixed/random tag campaigns share budget and grammar; a direct seed/path replay runs only the selected property. An unconstrained subset demand can fetch all rows because the caller requested all rows; it does not prove bounded network work.

Receiver: packages/electric-db-collection/tests/electric-sdk-delivery-oracle.property.test.ts. A real installed SDK receives two launches through the Electric adapter and persistence wrapper with controlled HTTP and durable storage. Direct demand and public live-query preload settle through changes-only scoped snapshots in a managed fixture with separate durable stores for retired and current cache generations. The receiver verifies id = 1 and its bound parameter on both launches. It permits one snapshot to satisfy the live query's active demand and checks its public and durable row after settlement. It does not require a second physical request for the same subset. Lost tags, changed shape, and malformed resume state keep stale B in the retired store without exposing it after an A snapshot or an empty B snapshot. The changed-shape case makes B's empty snapshot first. A third launch with no demand starts no full-shape transport or unrestricted local subset read. The fixture models generation routing, while real SQLite independently checks claim enforcement and physical tables. Another receiving witness rejects concurrent SDK snapshot invocation on the shared cursor. Compatible untagged resumes and the unmanaged full-log fallback remain separate controls. An installed-SDK abort witness holds subset HTTP across external stream retirement, then returns a valid row. The demand rejects, the row stays absent, and an identical demand is not certified as loaded. The two-launch receiver also delivers a coordinator invalidation after a paginated scoped snapshot. The persistence owner crosses targeted, paginated, full-reload, and reset notifications after an active source row. Its post-invalidation public-row checks distinguish source authority from durable cache; the non-scoped paginated reload remains a neighboring control. The persistence owner also checks that a scoped cache clear preserves initial Collection loading until the source marks ready. A held optimistic handler checks that the same clear settles before the handler releases: core applies a truncate immediately, so the proposed accepted-versus-applied deadlock does not arise on this path. Its subset settlement law remains separate. The persistence owner now calls baseline hydration after starting scoped recovery with a stale durable row. It requires that no row enter the public Collection and that no full-row resume snapshot be read. This is a direct capability-ordering witness; ordinary Electric startup does not call baseline hydration after choosing scoped recovery. The buffered partial-update recovery read has a gated failed-local-load history: a partial source update may appear, but it cannot inherit stale durable fields. Removing the scoped read guard fails at that public-field checkpoint. electric-resume-snapshot-races.test.ts also holds a real SQLite metadata read across row loss or a committed replacement. Unknown and missing key-set evidence start changes-only without publishing the cached rows; a row-1 demand then applies only its source snapshot. This is a fixed Node SQLite receiving witness, not a generated-history claim or a native Expo result. Its two cache-generation receiving histories use Electric's real resume classifier and wrapper with real SQLite. An incompatible stored shape reaches private rotation after claim expiry without overwriting a warm peer's resume metadata. A later active-session claim expiry holds the boundary after SQLite rotation and before public truncate; a retired callback cannot write there, and a demand started in that interval settles after its replacement subset applies. The ShapeStream callback schedule is controlled. An installed-SDK HTTP delivery at this exact intermediate cut and native-host execution are not established.

Applied-settlement owner: packages/electric-db-collection/tests/electric-oracle.property.test.ts. Held optimistic application distinguishes readiness from subset completion for demand both before and after readiness. A later same-run reset distinguishes a current replacement obligation from a permanently fulfilled startup gate. Concurrent initial-error and cleanup cuts observe settlement and lifecycle authority; cleanup quietly settles in-flight adapter loads. A sibling-demand abort cut requires one canceled demand to reject promptly while its sibling and a replacement of the canceled demand wait for the full source snapshot and succeed after its row applies. A separate external stream abort rejects its current full-log demand and never certifies an identical later demand as loaded. These full-log wait obligations still apply when scoped recovery is unavailable; the scoped path uses SDK snapshots and applied receipts. The changes-only path has the same refusal both when a subset transport returns after stream retirement and when an applied receipt is held across that retirement. The full-mode retry histories now reject their pre-error demand, then require a new demand to succeed after a same-run recovered snapshot, both with and without a held applied receipt. An installed-SDK controlled-HTTP receiver exhausts 503 backoff, invokes the user's retry handler, and acquires a new demand while the retry HTTP request is open. It requires that demand to wait, then succeed after the new full-log up-to-date. A missing-header response checks that the SDK's refusal to retry rejects later demands rather than leaving a renewed gate pending. The scoped reset history acquires a snapshot before must-refetch, then requires subset-end to apply its row before demand success without waiting for a full up-to-date. The neighboring full-mode reset retains that stronger wait. The Electric durable fixture has an adversarial insert check that rejects retained old columns or tag metadata; it is driver validation, not a new model owner. The Electric adapter owner now holds an asynchronous user retry decision and checks that a new full-recovery demand remains pending until source replacement, while the pre-error demand rejects. It also checks caller abort before subset transport settlement, while a request is queued behind the SDK cursor, and while an applied receipt is held. Each original behavior failed at the caller settlement cut; the fixed driver requires prompt AbortError without certifying that demand. The explicit-resume neighbor keeps malformed durable metadata untouched until source evidence arrives. The persistence owner now invokes a retired scoped-recovery capability after cleanup and restart; the original cleared the replacement Collection, and the lifecycle guard preserves its row. These fixed schedules do not prove arbitrary overlapping retry decisions or all failure paths through startScopedRecovery. A valid scoped-clear commit failure with an exact public sync-error observation still needs a witness; an attempted subscriber-throw fixture did not reach that callback during the local clear and supplies no evidence for the review's error-report claim.

Remaining witnesses before broader closure:

• Electric tag/history owners: unknown or missing key-set evidence combined with tagged scoped demand, multiple resets overlapping held application, and partial updates arriving before a scoped baseline. Repeated provider errors, SDK retry-loop exhaustion, and a scoped reset overlapping a held applied receipt also need witnesses. The untagged SQLite metadata-read race is covered above.
• Persistence/coordinator owners: native SQLite reads, browser/electron cross-tab transport delivering an invalidation during cache quarantine, and source versus local-only truncate durability. Controlled coordinator delivery and installed-SDK receipt cover the wrapper response, not the multiprocess transport premise. Scoped recovery also needs an explicit durable-cache eviction or certification policy: the current reset marker makes later uncertified starts repeat quarantine, and deleted durable rows can remain on disk. Neither a safe offline subset certificate nor bounded storage growth is proved here.
• Installed-SDK delivery and Electric service E2E owners: actual subquery/tag emission, overlapping provider responses, and the scoped restart schedule against a live service.
• Expo expo-persisted-collection.e2e.test.ts and emulator owners: the offered node:sqlite fixture, native storage, and actual process relaunch.
• Descriptor/tag and SDK DNF owners, if durable tags are selected: complete selected membership and silent active-condition changes persisted atomically with rows and the resume certificate, including migration/reset admission.

No individual maintainer assignment or approved deferral is implied by these executable ownership destinations. The bounded controlled-HTTP and Map-backed persistence witnesses do not establish class closure across those hosts.

Paced persistence serialization#

Issue #2058's primary owner is packages/db/tests/paced-mutations-oracle.test.ts. Its held-write model crosses debounce/throttle, explicit leading/non-leading and omitted leading with trailing enabled, and successful release one tick before, at, one tick after, or ten ticks after the successor's timer edge. It observes handler concurrency, start times, transaction states, receipt settlement and identity, and optimistic rows at admission, timer edges, release, and drain. The original implementation fails 18 of 24 histories at the held edge; the six release-before-edge controls pass. The model's immediate handoff after both prerequisites hold is the chosen pacing policy. The original overlap violates the independent serialization promise regardless of that policy.

Adjacent histories check renewed debounce quiet, throttle spacing from actual starts, leading-only admission isolation, same/distinct-key success or failure, pending cancellation, manual rollback of a persisting transaction, and synchronous nested admission. Manual-rollback witnesses cross all three serial strategies, including queue, and observe handler overlap after the public receipt has rejected. The wrong implementation fails at that intermediate cut; the repaired implementation waits for the handler itself to return.

The owner also drives a leading debounce successor canceled while the first handler is held. A third admission after either direct rollback or same-key cascade must start after its own quiet edge and the held handler's release; the old callback cannot consume the third call's persistence obligation. The reviewed implementation fails at that handler-start cut, while the ownership repair passes both histories. A failed optimistic callback must not retain a newly created empty pending transaction: admitted debounce, dropped debounce, and queue paths now have scope-retention witnesses that fail on the reviewed implementation and pass after cleanup. The owner checks the chosen group-rejection law for a nested admitted call both with and without an earlier pending call. All receipts sharing the failed pending transaction reject with the callback error, no member reaches the backend, and a later independent call persists. The earlier-pending regime failed at the transaction-state cut before the group rollback repair; both factories now pass at the throw and scheduled edges. A separate held-handler matrix crosses debounce, throttle, and queue: manual commit() throws before changing a pending receipt, and the strategy still starts that write only after its timer edge and the prior handler's release.

The owner also checks one strategy shared by two managers. Reentrant leading/trailing and ordinary trailing histories retain both separate transactions at one timing boundary. A renewed-quiet history moves another manager's eligible callback to the new quiet edge while the first handler is held. A held-handler rollback keeps the second manager's write behind the first handler. The reviewed code fails the second backend-start assertion for both debounce and throttle; the keyed pending-run repair passes. The owner does not yet cover provider echo, cleanup during a held handler, longer arbitrary bursts, held default/omitted-trailing combinations, or more than two managers. It owns those future source-level witnesses. Leading-only throttle admission-window timing while a write is held remains a separate policy question; the existing serialization and minimum actual-start spacing do not depend on its resolution. Real server ordering, framework unmount scheduling, and published npm behavior require receiving integration witnesses; the present evidence is controlled DB source execution. The revision-bound review record is docs/contributing/oracle-reviews/issue-2058-paced-serialization.md.