@lossless.org/nosqldb 10.11.0 → 11.0.0

package/readme.md

@@ -1,6 +1,6 @@
 # @lossless.org/nosqldb
 
-A MongoDB-wire-compatible embedded database server powered by a native Rust MVCC engine. It supports the documented command surface through the official `mongodb` driver without an external MongoDB server. Memory and file storage use the same paged engine, including the operation log, point-in-time revert and debug dashboard. Matching executables are bundled with the package.
+A MongoDB-wire-compatible database server powered by its own native Rust MVCC engine, engineered from scratch in a clean room with a public API surface derived from the Apache-2.0-licensed official MongoDB Node.js driver, and built for every scale: from a test fixture or a database embedded in a single application to large enterprise deployments. Its goal is to beat MongoDB on performance and on features. It supports the documented command surface through the official `mongodb` driver without an external MongoDB server. Memory and file storage use the same format-3 store, including the operation log, point-in-time revert and debug dashboard. Matching executables are bundled with the package.
 
 ## Issue Reporting and Security
 
@@ -12,32 +12,29 @@ For reporting bugs, issues, or security vulnerabilities, please visit [community
 pnpm add @lossless.org/nosqldb
 ```
 
-## Moving from @push.rocks/smartdb
+---
 
-The module has moved to `@lossless.org/nosqldb`. Install the new package and update imports and product-specific names together:
+## What It Does
 
-| Previous name | New name |
-| --- | --- |
-| `@push.rocks/smartdb` | `@lossless.org/nosqldb` |
-| `SmartdbServer` | `NoSqlDbServer` |
-| `LocalSmartDb` | `LocalNoSqlDb` |
-| `SmartdbStorageRehearsal` | `NoSqlDbStorageRehearsal` |
-| `SmartdbDebugServer` / `SmartdbDebugUi` | `NoSqlDbDebugServer` / `NoSqlDbDebugUi` |
-| `ISmartdb*`, `ISmartDb*`, `TSmartdb*`, `TSmartDb*` | `INoSqlDb*`, `TNoSqlDb*` |
-| `createSmartDb*`, `normalizeSmartDb*`, `smartDb*` | `createNoSqlDb*`, `normalizeNoSqlDb*`, `noSqlDb*` |
-| `SMARTDB_*` environment variables | `NOSQLDB_*` environment variables |
-| `<smartdb-debugui>` / `/api/smartdb/*` | `<nosqldb-debugui>` / `/api/nosqldb/*` |
-| Benchmark `--engine smartdb` | Benchmark `--engine nosqldb` |
+`@lossless.org/nosqldb` is a **real database server** that speaks the wire protocol used by MongoDB drivers. The core engine is written in Rust for high performance, with a thin TypeScript orchestration layer. Connect with the standard `mongodb` Node.js driver — no mocks, no stubs, no external binaries required.
 
-The `./debugui` and `./debugserver` package subpaths stay the same. The new module exports the new API names; it does not export aliases for the previous names. Update explicit binary overrides to `NOSQLDB_RUST_BINARY`, and rename the release-builder environment variables shown below.
+### From one process to enterprise scale
 
-This is a package and API rename, not a storage-format conversion. Existing current-format v7 databases, authentication records, allocation identities, export formats, and operation receipts retain their original byte formats. Versioned `smartdb.*` format identifiers, the `smartdb` allocation provider, hash domains, and private locking/workspace names deliberately remain unchanged. Do not edit those values in stored data or rewrite existing receipts. The native `rustdb` executable, `rustdb_*` packaged artifact names, and `.__rustdb_*` storage directories also keep their existing identities. Earlier incompatible storage formats remain subject to the admission restrictions documented below.
+NoSQLDB brings its own clean-room engineered, MongoDB-compatible engine to every stage of an application's life:
 
----
+- **Development and tests:** start a server from code, in memory or on disk, with nothing else to install.
+- **Embedded:** ship the database inside your application and reach it over TCP or a Unix socket.
+- **Enterprise scale:** large datasets, many collections and indexes, and many concurrent clients on its own durable MVCC engine.
 
-## What It Does
+The target is to beat MongoDB on performance and on features: more throughput, lower latency, and less memory and disk per operation, with MongoDB-compatible behaviour wherever applications rely on it, and capabilities beyond it where they help, such as the built-in operation log, point-in-time revert and debug dashboard.
 
-`@lossless.org/nosqldb` is a **real database server** that speaks the wire protocol used by MongoDB drivers. The core engine is written in Rust for high performance, with a thin TypeScript orchestration layer. Connect with the standard `mongodb` Node.js driver — no mocks, no stubs, no external binaries required.
+### MongoDB compatibility
+
+NoSQLDB is an independent implementation, written from scratch to be MongoDB compatible. Its public API surface is derived from the client side: the official MongoDB Node.js driver (`mongodb`, Apache-2.0 licensed) and the commands and replies it exchanges. Compatibility is established by runtime testing against MongoDB through its wire protocol and the official drivers. NoSQLDB contains no MongoDB server code. It is built with the clean-room setup of [AGL](https://code.foss.global/modelprofile.com/agl): the sessions that write its code work in confined containers that hold nothing but this repository. Where this readme says a behaviour, code or message is MongoDB compatible, it was implemented to match what such testing observes.
+
+Contributions follow the same clean-room rules: describe behaviour as implemented to be MongoDB compatible, never as the same as a MongoDB version; record provenance as observed by runtime testing against MongoDB; and never read, quote, cite or link MongoDB server source code or its test suites.
+
+MongoDB is a trademark of MongoDB, Inc. NoSQLDB is not affiliated with or endorsed by MongoDB, Inc.
 
 ### Why NoSQLDB?
 
@@ -49,7 +46,7 @@ This is a package and API rename, not a storage-format conversion. Existing curr
 | **Persistence** | Memory or file-based | Full disk engine |
 | **Debug UI** | Built in | External tooling |
 | **Point-in-time revert** | Built in | Depends on the database |
-| **Perfect for** | Unit tests, CI/CD, prototyping, local dev, embedded | Production at scale |
+| **Built for** | Unit tests, CI/CD, local dev, embedded applications and large-scale production | Production |
 
 ### Three Ways to Use It
 
@@ -252,7 +249,7 @@ Each entry contains:
 
 ## 🔢 Document Field Order
 
-Like MongoDB, every stored document leads with `_id`. Inserts, upserts, replacements, `findAndModify`, `$out` and `$merge` move a client-supplied `_id` to the front (the Node.js driver appends its generated `_id` after the caller's fields) and generate a missing one there. Every other field keeps its written order: update operators change existing fields in place and append the fields they create, and a replacement keeps its own field order after `_id`. Documents stored with a trailing `_id` by 10.7.3 and earlier keep it until an update, replacement or `$merge` changes them.
+Every stored document leads with `_id`, implemented to be MongoDB compatible. Inserts, upserts, replacements, `findAndModify`, `$out` and `$merge` move a client-supplied `_id` to the front (the Node.js driver appends its generated `_id` after the caller's fields) and generate a missing one there. Every other field keeps its written order: update operators change existing fields in place and append the fields they create, and a replacement keeps its own field order after `_id`. Documents stored with a trailing `_id` by 10.7.3 and earlier keep it until an update, replacement or `$merge` changes them.
 
 ---
 
@@ -260,7 +257,7 @@ Like MongoDB, every stored document leads with `_id`. Inserts, upserts, replacem
 
 The engine detects document rewrites that change nothing and skips them entirely — no storage write, no WAL append, no index update, and no oplog entry. A skipped rewrite still counts as matched (`matchedCount: 1`) but reports `modifiedCount: 0`.
 
-As in MongoDB, a rewrite is skipped only when the document stays identical: the same fields in the same order with the same values and BSON types, at every depth. Only the position of `_id` is ignored, so a document stored with a trailing `_id` by 10.7.3 and earlier is not rewritten by a write that changes nothing. A replacement or `$set` that only reorders fields is written. Explicit changes to `_updatedAt` are persisted and returned just like changes to any other field. Applications decide when to advance their timestamps.
+To be MongoDB compatible, a rewrite is skipped only when the document stays identical: the same fields in the same order with the same values and BSON types, at every depth. Only the position of `_id` is ignored, so a document stored with a trailing `_id` by 10.7.3 and earlier is not rewritten by a write that changes nothing. A replacement or `$set` that only reorders fields is written. Explicit changes to `_updatedAt` are persisted and returned just like changes to any other field. Applications decide when to advance their timestamps.
 
 Counters are exposed through `serverStatus`:
 
@@ -338,6 +335,59 @@ try {
 
 The socket parent directory must already exist with the caller's desired access
 permissions. `RustDbBridge` also accepts `{ binaryPath }` for direct lifecycle use.
+When its `spawn()` returns false, `spawnFailureMessage` says what that means as
+far as the bridge knows: with a `binaryPath`, that the engine there did not
+report ready within the bridge's limit, with the path as given and the time
+waited; without one, that no engine binary was found or that the engine found
+did not report ready, as nothing tells which. If ending that engine fails,
+`spawn()` throws instead of returning false, and `spawnFailureMessage` keeps the
+message. After any other `spawn()`, including one that throws on its own
+`timeoutMs` or `signal`, it is undefined. A `binaryPath` that does not exist
+is refused before `spawn()` returns, with `RustBinaryLocatorError`.
+
+#### Engine output
+
+The engine writes its log to its standard error. None of it reaches the host
+process's standard error: by default the server keeps only the engine's last
+lines, for errors. To receive the log, pass `engineLog`, which is called once
+for every line, in order, without the line break. `onEngineExit` receives a
+`NoSqlDbEngineExitError` for each unexpected exit of the engine: an exit with a
+non-zero status or by a signal while the server runs and no stop is in
+progress. An exit with status 0, which the engine makes after a graceful
+shutdown it was signalled to make, is not reported; the server counts as
+stopped either way.
+
+```typescript
+import { NoSqlDbServer } from '@lossless.org/nosqldb';
+
+const server = new NoSqlDbServer({
+  storage: 'file',
+  storagePath: '/var/lib/app/nosqldb',
+  engineLog: (line) => logger.info(`nosqldb: ${line}`),
+  onEngineExit: (error) => logger.error(error.message, error.engineStderrTail),
+});
+```
+
+Whatever is set, these carry the engine's last 64 standard-error lines in their
+field `engineStderrTail`, a frozen array of strings, without any change to
+their message:
+
+- every rejection of `start()` of `NoSqlDbServer` and `LocalNoSqlDb`, with an
+  empty array when the start failed before it spawned an engine;
+- the `NoSqlDbEngineExitError`, whose message is
+  `nosqldb Rust process exited unexpectedly (code=<code>, signal=<signal>)` and
+  which has `exitCode` and `signal`;
+- the rejection of a management call that fails because the engine no longer
+  runs.
+
+A line longer than 1,024 characters keeps its first 1,024, followed by
+` [<n> more characters]`; `engineLog` receives it whole.
+`noSqlDbEngineStderrTailLimits` exports both bounds. `LocalNoSqlDb` accepts
+both options and passes them to its server. `RustDbBridge` accepts `engineLog`
+as well, and its `engineStderrTail` getter returns the last lines of the
+running or most recently spawned engine. Each function runs in its own
+microtask, after the server has recorded the line or the exit; an exception it
+throws is not caught and reaches the process as an uncaught exception.
 
 #### Native memory and file storage
 
@@ -380,54 +430,68 @@ above is an example, not a universal default. Reopen with the stored SCRAM work
 factor; bootstrap users may be omitted after initialization. `LocalNoSqlDb`
 accepts `folderPath`, `socketPath`, `binaryPath` and the same `auth` options.
 
+The engine allocates its memory with jemalloc, under settings built into the
+engine: two arenas, freed memory returned to the operating system over 5
+seconds (dirty decay 5,000 ms, muzzy decay 0), and on Linux the allocator's
+background threads. At start the engine checks that its allocator runs these
+settings and raises its soft open-files limit to its hard limit (on macOS to at
+most `kern.maxfilesperproc`). When either fails, as the check does when
+`_RJEM_MALLOC_CONF` in its environment changes a setting, the engine does not
+start: it exits with status 71, and `start()` rejects with the reason in
+`engineStderrTail`. The `MIMALLOC_ARENA_EAGER_COMMIT` and
+`MIMALLOC_ALLOW_LARGE_OS_PAGES` variables that earlier releases set for the
+engine are no longer set or read.
+
+The performance figures this release states are measured with file storage on
+XFS. ext4 was measured only on a loop-backed substitute, so this release makes
+no latency claim for ext4. Recovery after a crash relies on a filesystem that
+never exposes stale blocks after a crash: XFS, or ext4 with ordered data
+(`data=ordered`, its default mode). ext4 mounted with `data=writeback` is not
+supported. On macOS, file storage runs on APFS; the durability gates and the
+timed gates of this release run on Linux only.
+
 #### Native query and maintenance efficiency
 
 Bounded synchronous reads, including principal resolution, publication authority
-and query setup, share a retained generation lease. No lease or resolved
-authorization is reused across requests or asynchronous suspensions.
+and query setup, share one retained snapshot of the root. No such snapshot or
+resolved authorization is reused across requests or asynchronous suspensions.
 
 Filesystem ownership and root bindings are validated once per command for
 reads: the reads of each wire command or background maintenance turn reuse one
-full validation of the root and its bindings that began after the command
-started, run by its own first storage read or by a concurrent command, and
-every retained generation file's binding is checked once per command. Reads go
-through retained descriptors, so a path swap cannot change what they return. A
-failed validation revokes every earlier one, so commands still running stop at
-their next read. A validation covers reads for at most one second after it
-began, measured on a monotonic clock, so a long-running command such as a large
-aggregation or sort validates again at its first read after that and fails at
-that read once its root or a binding has been replaced. Every mutation,
-including commit conflict checks, appends, flushes, compaction, relocation and
-directory changes, still validates ownership and bindings before and after
-itself, and startup, recovery and native management calls, which run outside
-wire commands, validate every access. A root, container or generation file
+full validation of the enclosing owner, the root and its bindings that began
+after the command started, run by its own first storage read or by a
+concurrent command. Reads go through retained descriptors, so a path swap
+cannot change what they return. A failed validation revokes every earlier
+one, so commands still running stop at their next read. A validation covers
+reads for at most one second after it began, measured on a monotonic clock,
+so a long-running command such as a large aggregation or sort validates again
+at its first read after that and fails at that read once its root or a
+binding has been replaced. Every write, whether a commit's, a group's, a
+maintenance operation's or an index build's, validates the enclosing owner
+and every binding before it writes, and a commit's conflict checks validate
+in full before and after themselves, before the commit takes its place in
+the log. After a write, when its outcome can be unknown, the root's bindings
+and each file the write wrote, by its binding and its length, are checked
+through the retained descriptors alone, without opening the owner's path; a
+failure there fences the root, and the next command's first access validates
+the enclosing owner again. Startup, recovery and native management calls,
+which run outside wire commands, validate every access. A root or container
 renamed or replaced between commands fails the next command's first storage
-access. Durability, cancellation and close checks remain enforced.
-
-Compound indexes combine leading equality fields, if any, with a range on the
-next field. For example, `{ serverId: 1, timestamp: 1 }` seeks directly into the
-requested server's time interval. Inclusive/exclusive endpoints, descending
-components, trailing fields and reverse pagination retain their normal
-semantics. A range is built from `$gt`, `$gte`, `$lt` and `$lte`, and from
-`$ne: null` or a `$nin` list holding null, which read only the non-null keys as
-MongoDB's `[MinKey, undefined) ∪ (null, MaxKey]` bounds do: documents without
-the field or with an explicit null are not examined. Ranges are built only on
-complete indexes whose values all have a scalar order, and on a list field from
-one side of the range only (see **List fields** below); other indexes are not
-narrowed. The full predicate is still checked for every selected candidate.
+access, and a data or log file replaced underneath the root fails the next
+write that writes it. Durability, cancellation and close checks remain
+enforced.
 
 For a query whose filter references only `_id` and whose projection is exactly
 `{ _id: 1 }`, the native primary index can supply the original BSON identity
 without loading the document payload. Range endpoints, order, skip, limit and
 cursor pagination retain their normal semantics. The engine verifies the index
-and unique-owner values, the document frame's existence, and either matching
-commit versions or a storage-owned SHA-256 certificate of the exact BSON `_id`.
-Updates that keep the same identity leave the primary owner and its certificate
+and unique-owner values, the document record's existence, and the storage-owned
+SHA-256 certificate of the exact BSON `_id` that every document record holds.
+Updates that keep the same identity leave the primary owner and the certificate
 unchanged, avoiding an extra index rewrite. Numeric BSON width changes update
 the certificate and primary identity atomically with the body. A covered read
-does not checksum an unrequested document payload. Older records without a
-usable identity proof use the normal bounded body read; the next actual write
-adds the certificate.
+does not checksum an unrequested document payload. An entry whose owner names
+another identity than the certificate uses the normal bounded body read.
 Secondary-index projections and predicates requiring other fields retain normal
 document reads. No application cache or configuration flag is required.
 
@@ -449,27 +513,20 @@ discard their uncommitted changes. An admitted command that reaches the closing
 session owner fails with `ShutdownInProgress` (code 91), and one still waiting
 for a database or collection gate fails with `InterruptedAtShutdown` (code
 11600); a transaction statement carries `TransientTransactionError` with
-either, as in MongoDB 8. Successful shutdown releases storage-root
+either, implemented to be MongoDB compatible. Successful shutdown releases storage-root
 ownership and exits with code 0 even when the parent's management pipe remains
 open. A second shutdown signal, a drain failure, or the overall 40-second
 deadline forces exit with code 70; forced exit does not promise drain completion.
 `NoSqlDbServer.stop()` also succeeds after a confirmed engine exit without
 sending another management request to the dead child.
 
-**Storage compatibility:** version 10 adds a 40-byte certified document-ordinal
-record alongside the legacy 8-byte ordinal. It reads existing stores directly;
-startup and reads perform no format rewrite. After version 10 writes certified
-records, use version 10 or later to reopen that store. Older binaries reject the
-new record representation. Keep a pre-upgrade backup if a binary downgrade is
-required. The K2 pages, commit markers and recovery protocol are unchanged.
-
 Maintenance batches catalog work and parks completed reclamation and no-TTL
 sweeps until the committed position changes. Session cleanup skips its metadata
-scan until a session can expire. Compaction uses the persisted generation anchor
-as its baseline, so reopening an already-compacted root does not rewrite it.
-Compaction runs separately from TTL maintenance, observes shutdown cancellation,
-and does not restart a large copy because a short maintenance deadline elapsed.
-These maintenance optimizations preserve the existing generation and commit formats.
+scan until a session can expire. The store maintains itself on its own thread:
+it merges its write buffer into the tree, writes checkpoints, prunes the
+tombstones no snapshot needs and moves the live data out of data segments
+that hold much garbage. No pass copies the whole root, and there is no
+compaction to run, resume or restart.
 
 #### File startup admission
 
@@ -480,20 +537,26 @@ The exported type is `TNoSqlDbFileStorageStartup`. Invalid values, including
 `'migrate'`, reject at construction. Selecting the policy with memory storage
 also rejects.
 
-Default startup accepts a fresh root or a current native root. Use
-`fileStorageStartup: 'existing-only'` when the database must already exist:
-missing paths, empty directories and identity-only roots without committed
-initialization fail instead of creating an empty database. The native owner
-enforces this policy; no TypeScript existence check or fallback can create a
-new root. Older binaries reject the new option rather than silently ignoring it.
+Default startup accepts a fresh root or a current native root, and converts a
+root that a 10.x release wrote before it serves it (see **Storage format
+migration** below). Use `fileStorageStartup: 'existing-only'` when the database
+must already exist: missing paths, empty directories and identity-only roots
+without committed initialization fail instead of creating an empty database,
+and a 10.x root that holds a committed database counts as existing and is
+converted as under the default. The native owner enforces this policy; no
+TypeScript existence check or fallback can create a new root. Older binaries
+reject the new option rather than silently ignoring it.
 Rehearsal startup retains its separate current-format-only configuration.
 
-Foreign, old, mixed and
-orphaned migration staging layouts are rejected without conversion. TypeScript
+Foreign and mixed layouts, a 10.x name beside entries of this release without
+the record of a conversion in progress, and a 10.x root that the conversion
+cannot take are rejected before anything is written. TypeScript
 performs no storage writes before starting the engine. Native format admission
 uses the owning detector; the exclusive native file-root lease is acquired before
 initialization, recovery, authentication or index preparation.
 
+A root that carries a format or a feature that this release does not know, such as a root that a later release wrote, is refused before anything is written, and no root is created in its place or beside it. The start's rejection then carries `responseErrorCode: 'UNKNOWN_ROOT'`, which no other start failure carries, and its message names the cause. A missing storage path is created together with every directory missing above it, each accessible to its owner alone; `'existing-only'` creates none of them.
+
 Only after `await server.start()` succeeds should consumers prepare SmartData
 models or run application migrations. Start cancellation and deadlines cover the
 native operation; failed-start cleanup confirms child exit, and `stop()` remains
@@ -501,10 +564,9 @@ retryable if termination cannot yet be confirmed. A second owner of the same
 root is rejected without disturbing the winner. Callers must also exclude
 manual edits and lifecycle changes outside NoSQLDB's ownership protocol.
 
-No automatic format or auth-permission migration runs during startup.
-Persisted-format conversions belong exclusively in the top-level
-`ts_migration/` folder and require their own explicit qualification. This
-release contains no old-engine or authentication-schema conversion.
+**Storage format migration.** Every root this release creates is a format-3 root under `.nosqldb-control` and `.nosqldb-store`. A start, under either `fileStorageStartup` policy, converts a root that a 10.x release wrote, which it recognizes by `.__rustdb_internal` and `.__rustdb_mvcc`, and then serves the result. The conversion reads the 10.x root without writing into it, builds the format-3 root beside it under this release's names, verifies it record for record against the 10.x content, and only then removes the 10.x entries. It records its progress in `.nosqldb-conversion`, so a start that is stopped or interrupted during the conversion resumes it at the next start. Before it writes anything it declares the space it needs beside the 10.x root, and the start is refused when the file system does not hold it. It carries the database as of the root's last completed commit, with no history of writes committed before the conversion and no part of an import that had not finished. No earlier release reads a root that this release has created, converted or aligned: keep a stopped copy of the 10.x root if you may need to go back. That copy is a copied root: restored into another directory or onto another machine, it keeps the binding of its old place, and 10.8.1, like this release, refuses to start on it until it is aligned. Alignment refuses a root that holds auth users, so for such a root a copy restored that way is no way back. A start refuses, and leaves the path as it found it, a 10.x root that holds no committed database or only part of one, a 10.x name beside entries of this release without the conversion's record, a 10.x root that a running 10.x process holds or that a rehearsal created, a collection whose recorded count its documents do not hold, and a unique index that would hold two documents under one key once each array member is indexed on its own. A 10.x root that was copied, moved or restored converts too but keeps the binding of its old place; like every copied root, it must be aligned (`alignStoppedStorageRoot`) before a start serves it. No authentication or permission migration runs during startup, and this release contains no authentication-schema conversion.
+
+A stopped root that a 10.x release wrote can be read before a start converts it. The stopped operations that only read open it read-only, under its own names and its own lock as a 10.x release's stopped operations did, and change nothing in it: the root audit (`inspectStoppedStorageRoot`), the string and namespace inspections (`inspectOfflineStringValue`, `inspectOfflinePhysicalNamespaces`) and data validation (`--validate-data`), which runs the namespace inspection. Alignment, relocation and rehearsal refuse a 10.x root with `UNSUPPORTED`: start a server on it to convert it, then copy and align the converted root. Every stopped operation refuses a path on which a conversion is in progress, one that holds `.nosqldb-conversion`; the root audit answers it as `unavailable` with `UNSUPPORTED`, and the string and namespace inspections and data validation reject it with `UNSUPPORTED`. A start on that path resumes the conversion and finishes it.
 
 ```typescript
 import { NoSqlDbServer } from '@lossless.org/nosqldb';
@@ -546,6 +608,15 @@ const lean = new NoSqlDbServer({
   oplog: { enabled: false },
 });
 
+// The store's memory budget, which its node cache and write buffer share:
+// 4 MiB to 1 TiB, refused outside that range and never clamped
+// (default: computed from the memory the process may use)
+const budgeted = new NoSqlDbServer({
+  storage: 'file',
+  storagePath: './data',
+  storageBudgetBytes: 256 * 1024 * 1024,
+});
+
 // TLS transport for TCP mode
 const tlsServer = new NoSqlDbServer({
   port: 27017,
@@ -608,7 +679,7 @@ the transaction's first statement. Supported reads and writes see the
 transaction snapshot plus its staged changes. Commit publishes atomically;
 abort discards staged changes.
 
-Write conflicts follow MongoDB: the first statement to write a document or a
+Write conflicts are implemented to be MongoDB compatible: the first statement to write a document or a
 unique index key wins, and the later writer is told at its own statement.
 
 - A transaction statement that inserts, updates, replaces, deletes or upserts a
@@ -620,8 +691,16 @@ unique index key wins, and the later writer is told at its own statement.
   `commitTransaction` report `NoSuchTransaction` (251), also labelled
   `TransientTransactionError`. The transaction that wrote first keeps its
   documents and commits. The driver's `withTransaction` retries the loser on a
-  fresh snapshot, so a transaction that writes a hot document and then does more
-  work makes progress against clients looping short transactions on it.
+  fresh snapshot, and each attempt can lose again: no priority, ageing or wait
+  rule favours a retrying transaction. So a transaction that writes a hot
+  document and then does more work makes progress against clients looping
+  short transactions on it only by its odds of winning each attempt, with no
+  bound on its attempts or its time. Those per-attempt odds are lower than
+  MongoDB's, as observed by runtime testing against MongoDB (`mongo:7.0`,
+  7.0.39): MongoDB releases a committing transaction's documents before it
+  acknowledges the commit, while NoSQLDB acknowledges a commit as it releases
+  them, after the commit is durable. On a host whose durable sync is slower,
+  the odds fall further.
 - Reads never conflict: they see the snapshot, not another transaction's
   uncommitted writes. A statement that writes nothing (a filter that matches
   nothing in the snapshot, an update that leaves the document unchanged) does
@@ -635,96 +714,18 @@ unique index key wins, and the later writer is told at its own statement.
   finish. Writes to other documents are not delayed. A multi-document write
   outside a transaction stays all-or-nothing: it publishes nothing until it can
   publish every document.
-- A transaction open for longer than 60 seconds is aborted, as by MongoDB's
-  transaction reaper: its staged writes are discarded and its cursors, write
-  claims, transaction capacity and database and collection gates are
-  released. The server
-  checks idle sessions once a second; a statement still executing when the
-  limit passes is not interrupted, and the transaction aborts when that
-  statement has finished (MongoDB instead interrupts that statement with
-  `TransactionExceededLifetimeLimitSeconds` (290)). Its later statements, `commitTransaction` and
-  `abortTransaction` report `NoSuchTransaction` (251); statements and
-  `commitTransaction` carry `TransientTransactionError`, so `withTransaction`
-  retries from the start. Before that abort, the next writer that needs one of
-  its documents aborts it too rather than wait. The limit is fixed at
-  MongoDB's default `transactionLifetimeLimitSeconds` and is not configurable.
-  Ending or expiring the session, and stopping the server, release a
-  transaction's writes as well.
 - TTL expiry is not a contending writer. It leaves out the documents an open
   transaction has written, deletes the other expired documents of the index
   and moves past the held ones. A later pass over the index expires those
   still expired once the transaction has ended. It never waits for a transaction and never aborts
-  one, whatever its age. MongoDB's TTL monitor instead retries a conflicting delete until
-  the transaction ends and leaves aborting it to its transaction reaper.
+  one, whatever its age. MongoDB's TTL expiry, as observed by runtime testing, instead retries a conflicting delete until
+  the transaction ends and leaves aborting it to the transaction lifetime limit.
 - A key already visible in the transaction's snapshot is not a conflict:
   inserting it fails the statement with `DuplicateKey` (11000), as outside a
   transaction. A collection created inside a transaction has no stored identity
   until commit, so two transactions creating the same collection both succeed
-  their statements and the second commit reports `WriteConflict` (112), as on
-  MongoDB 7.
-
-#### Read fences
-
-`readFence` is a NoSQLDB command, not a MongoDB one, available from 10.11.0. It
-lets a transaction depend on documents it read without writing them: its commit
-fails if any of them changed after the transaction's snapshot. Two transactions
-that only read and fence one document therefore both commit, where fencing by
-writing the document would make one of them conflict.
-
-```typescript
-await session.withTransaction(async () => {
-  const lane = await lanes.findOne({ _id: 'dns' }, { session });
-  await db.command({ readFence: 'lanes', ids: ['dns'] }, { session });
-  await jobs.insertOne({ _id: 'next', basedOn: lane?.revision }, { session });
-});
-```
-
-- `{ readFence: <collection>, ids: [...] }` answers `{ ok: 1 }`, only as a
-  statement of a multi-document transaction; outside one it is refused with
-  `InvalidOptions` (72). `ids` holds 1 to 1,000 `_id` values, otherwise the
-  statement fails with `BadValue` (2). Duplicates count once, compared as
-  `_id` values are, so `1`, `NumberLong(1)` and `1.0` are one id. It needs the
-  read privilege of the database, as `find` does, and refuses a view with
-  `CommandNotSupportedOnView` (166). A refused statement ends its transaction,
-  as every failed transaction statement does.
-- `commitTransaction` is refused with `WriteConflict` (112), labelled
-  `TransientTransactionError` and never `UnknownTransactionCommitResult`, when
-  a fenced `_id` has a committed change newer than the transaction's snapshot:
-  an insert, replace, update, delete or TTL expiry, by any writer, inside or
-  outside a transaction. Fencing an absent `_id` holds its absence. A drop,
-  rename or re-create of the collection, a drop of its database, and the
-  creation of a fenced collection or database that was absent also refuse the
-  commit. The check is atomic with the commit, and nothing of a refused
-  transaction becomes visible; `withTransaction` retries it on a fresh
-  snapshot.
-- A fence can also name documents by the value of a unique key, which holds
-  a value whether a document holds it or not:
-  `{ readFence: <collection>, key: <field>, values: [...] }`. On an existing
-  collection the field needs a unique, non-partial, single-field index with
-  the simple collation, otherwise the statement fails with `IndexNotFound`
-  (27). A null value, empty `values`, more than 1,000 values, or `ids` and
-  `key` together fail with `BadValue` (2); equal values count once.
-  `commitTransaction` is refused when, after the snapshot, a committed write
-  changed the document that held a fenced value, or made any document hold
-  one: an insert of an absent value, an update or replace of the holder, its
-  delete, a move of its key to another value, a delete and re-insert, another
-  document taking the value, or TTL expiry. Dropping the index also refuses
-  the commit. `key: "_id"` is the fence by `ids`.
-- The statement itself never fails because of a concurrent change: only the
-  commit decides.
-- A fence takes no write claim. Fences never conflict with each other, never
-  wait for a writer and never make one wait or fail. A writer that commits
-  after the fencer has committed succeeds: the order is fencer, then writer.
-  Changes to other documents of the collection, new indexes and new
-  collections do not refuse the fencer.
-- Fencing and writing the same document makes the transaction a plain writer
-  of it. A transaction that only reads and fences still gets the commit check.
-  Transactions without fences behave exactly as before.
-- The statement takes the database gate every transaction statement takes, so
-  `drop`, `renameCollection` and `dropDatabase` in that database wait for the
-  transaction to end, as they wait for any transaction with a statement there.
-  It retains no collection gate: creating the fenced collection or its indexes
-  does not wait for the transaction.
+  their statements and the second commit reports `WriteConflict` (112),
+  implemented to be MongoDB compatible.
 
 Write intents live in memory only; no transaction survives a restart, so
 there is nothing to recover.
@@ -744,15 +745,6 @@ options. A new collection or a changed index catalog waits only for the
 transactions that named that collection, and revalidates under its exclusive
 collection gate before any publication (see "Database waits" below).
 
-Logical sessions survive socket disconnects. Expiry, `endSessions` and
-`killSessions` drain active work and release cursors and namespace gates.
-A `commitTransaction` or `abortTransaction` retried while its session is being
-ended still replays the transaction's stored outcome, so a committed
-transaction is never reported as aborted; a transaction that was still open
-when its session ended publishes nothing and reports `NoSuchTransaction` (251).
-Rejected new transaction envelopes do not consume session capacity or reset
-existing sessions. See the native resource budgets below.
-
 ### Durable Committed Writes
 
 `NoSqlDbServer.getCommittedWrites()` and the database-scoped wire command
@@ -789,13 +781,16 @@ an application write; subsequent serving publications start retained coverage
 after that boundary. A move preserving the provider identity preserves the
 cursor epoch, but any uncovered native publication still reports a gap.
 
-Opening a 10.8.1 root does not initialize a journal or rewrite any stored record.
-The first new serving publication atomically adds optional journal and coverage
-records, beginning at the old committed head; earlier history explicitly gaps.
-This is additive lazy journal initialization, not a historical rewrite. Engines
-before 10.9 do not recognize the added record families, so do not downgrade a
-root after 10.9 writes. A deployment pinned to 10.8.1 remains unaffected unless
-its storage root is deliberately opened for writes with the new engine.
+A start converts a root that a 10.x release wrote, a 10.8.1 root included, into
+this release's format (see **Storage format migration** under File startup
+admission). The converted root keeps the 10.x root's committed position as its
+head and carries no history of writes committed before the conversion: a cursor
+before that head gets `gap: true`, and publications after the conversion are
+retained from that head on. No earlier release reads the converted root. A
+deployment pinned to 10.8.1 is unaffected until a start of this release opens
+its root; keep a stopped copy of the root before that if you may need to go
+back. For a root that holds auth users, a copy restored into another directory
+is no way back (see **Storage format migration** under File startup admission).
 
 Pages are exclusive of `after` and follow commit order. Their `cursor` advances
 over examined publications even when none belongs to the requested database;
@@ -882,7 +877,7 @@ const released = await server.commitDatabasePublication({
 });
 ```
 
-The held barrier survives restart and blocks wire commands, transactions and index restoration for that database while unrelated databases remain available. A blocked wire command fails with `ConflictingOperationInProgress` (code 117, no error label) naming `EFENCE_PUBLICATION_HELD`. `exportHeldDatabase()` is a bounded management-only read of one pinned committed catalog, auth and fence root. It requires the exact still-held receipt and capability, returns the same canonical Extended JSON shape as `exportDatabase()`, and does not release the barrier. Ordinary export and wire access remain closed; native TTL maintenance cannot expire held documents. A wrong, stale or already released receipt fails closed. Native physical compaction preserves the held records. Commit is exact and idempotent. A successful commit removes the raw capability from durable state and retains only protected verification material. Provider/root identity and bounded validation of native fencing records make copied, incomplete or corrupt allocation state fail closed. A higher fencing token compacts resolved older receipts, so long-lived coordinators do not exhaust receipt capacity.
+The held barrier survives restart and blocks wire commands, transactions and index restoration for that database while unrelated databases remain available. A blocked wire command fails with `ConflictingOperationInProgress` (code 117, no error label) naming `EFENCE_PUBLICATION_HELD`. `exportHeldDatabase()` is a bounded management-only read of one pinned committed catalog, auth and fence root. It requires the exact still-held receipt and capability, returns the same canonical Extended JSON shape as `exportDatabase()`, and does not release the barrier. Ordinary export and wire access remain closed; native TTL maintenance cannot expire held documents. A wrong, stale or already released receipt fails closed. Commit is exact and idempotent. A successful commit removes the raw capability from durable state and retains only protected verification material. Provider/root identity and bounded validation of native fencing records make copied, incomplete or corrupt allocation state fail closed. A higher fencing token compacts resolved older receipts, so long-lived coordinators do not exhaust receipt capacity.
 
 Durable database publication holds and allocation fencing use native file storage on the supported Linux and macOS filesystems.
 
@@ -892,7 +887,7 @@ Coordinators that do not yet have their own durable record can call `getDatabase
 
 `allocateDatabaseTenant()` is the create-only control-plane API for permanently allocation-managed database names. It is available only when `allocationFencingVersion === 1`, `allocationFencingSupported === true`, and `allocationFencingRequiresDrain === true`. The request requires literal `expectedAbsent: true`, an `INoSqlDbResourceFence`, and the tenant database, username, and password. `roles` is optional and defaults to `['readWrite', 'dbAdmin']`. Under native ownership and database/control admission, NoSQLDB proves catalog and principal absence, then commits the catalog, principal, complete auth allocation binding and fencing receipt at one position. It returns an `INoSqlDbAllocateDatabaseTenantResult`; its `.allocation` field is the durable `INoSqlDbDatabaseAllocationIdentity`. Exact fence replay returns the same allocation ID, generation, principal ID, and receipt digests.
 
-Pass the returned `allocation` identity to every later `ensureDatabaseTenant()`, `importDatabase()`, and `deleteDatabaseTenant()` request for that name. Managed import and delete requests also require the exact allocation `username`; the identity alone is insufficient. Each distinct managed mutation requires a strictly newer fence token; the current token is accepted only for exact receipt replay or continuation, and older receipts become explicitly stale after advancement. Held publication receipts carry the allocation into `commitDatabasePublication()`. Managed requests without it and unmanaged requests with it fail closed. Deprovision drains affected runtime authority, then atomically retires the catalog, exact principal, grants and auth binding with a permanent `deprovisioned` fencing tombstone. A later allocation requires a newer fence token, increments generation, and receives a fresh allocation and principal identity. Wire data access is available only while active and only to the current allocation principal; any other principal is refused with `Unauthorized` (code 13), and while the allocation is not active every wire command on the database is refused with `Unauthorized` naming `EALLOCATION_DEPROVISIONED`. The database/user ownership-changing wire commands `dropDatabase`, `createUser`, `updateUser`, `dropUser`, `grantRolesToUser` and `revokeRolesFromUser` are refused with `Unauthorized` (code 13), as MongoDB 8 refuses a user without the privilege.
+Pass the returned `allocation` identity to every later `ensureDatabaseTenant()`, `importDatabase()`, and `deleteDatabaseTenant()` request for that name. Managed import and delete requests also require the exact allocation `username`; the identity alone is insufficient. Each distinct managed mutation requires a strictly newer fence token; the current token is accepted only for exact receipt replay or continuation, and older receipts become explicitly stale after advancement. Held publication receipts carry the allocation into `commitDatabasePublication()`. Managed requests without it and unmanaged requests with it fail closed. Deprovision drains affected runtime authority, then atomically retires the catalog, exact principal, grants and auth binding with a permanent `deprovisioned` fencing tombstone. A later allocation requires a newer fence token, increments generation, and receives a fresh allocation and principal identity. Wire data access is available only while active and only to the current allocation principal; any other principal is refused with `Unauthorized` (code 13), and while the allocation is not active every wire command on the database is refused with `Unauthorized` naming `EALLOCATION_DEPROVISIONED`. The database/user ownership-changing wire commands `dropDatabase`, `createUser`, `updateUser`, `dropUser`, `grantRolesToUser` and `revokeRolesFromUser` are refused with `Unauthorized` (code 13), the MongoDB-compatible refusal of a user without the privilege.
 
 Allocation bindings are native records, excluded from logical database exports and never accepted from import payloads. Startup and stopped-storage inspection require the complete matching fence and auth binding even when no read grant was ever issued. Missing bindings are rejected without reconstruction. This includes allocated roots produced by experimental native versions that did not create the complete binding. This release provides no automatic conversion or downgrade path; never remove or edit private metadata to force admission.
 
@@ -996,7 +991,7 @@ await client.db('admin').command({ usersInfo: 'reader' });
 | Method / Property | Type | Description |
 |---|---|---|
 | `start(options?)` | `Promise<void>` | Start under one optional cancellation/deadline budget; join partial sidecars before rejection or retain ownership for `stop()` retry if termination fails |
-| `stop()` | `Promise<void>` | Wait for active startup work, then stop the server and confirm Rust bridge cleanup, including partial startup cleanup |
+| `stop()` | `Promise<INoSqlDbServerStopResult>` | Wait for active startup work, then stop the server and confirm Rust bridge cleanup, including partial startup cleanup; resolves with how the engine ended |
 | `getConnectionUri()` | `string` | Get the active `mongodb://` URI; before start and after stop, port `0` remains unresolved |
 | `running` | `boolean` | Whether the server is currently running |
 | `port` | `number` | Actual bound port while running; otherwise the configured port (TCP mode) |
@@ -1024,6 +1019,30 @@ await client.db('admin').command({ usersInfo: 'reader' });
 | `deleteDatabaseTenant(params, options?)` | `Promise<INoSqlDbDeleteDatabaseTenantResult>` | Durably delete an exact tenant database/user, optionally leaving publication held; supports fail-stop cancellation and deadlines |
 | `commitDatabasePublication(params, options?)` | `Promise<TNoSqlDbCommitDatabasePublicationResult>` | Idempotently release an exact held publication receipt; supports fail-stop cancellation and deadlines |
 
+`stop()` resolves with an `INoSqlDbServerStopResult` that says how the engine
+ended: `stopRequestSent`, whether a stop request was sent to a running
+engine; `stopAcknowledged`, whether the engine acknowledged it;
+`forcedByServer`, whether the server had to signal or kill the engine to end
+it; and `exitCode` and `exitSignal`, as the engine process's exit reported
+them, each `null` where there was none. `clean` is true exactly when the
+request was sent and acknowledged, the server neither signalled nor killed the
+engine, and the engine exited with code 0 and no signal. After an acknowledged
+request, `stop()` closes the engine's management input and gives the engine
+`noSqlDbServerStopGraceMs` (10,000 ms) to exit by itself; only an engine that
+has not exited by then, or one that did not acknowledge, is ended by the
+server. A stop when no engine runs resolves with a result that says no request
+was sent, and concurrent callers share one result. `stop()` rejects only when
+the bridge's termination fails, as before. `LocalNoSqlDb.stop()` resolves
+with its server's result.
+
+A start that meets a storage root, or a feature of one, from a later NoSQLDB
+release than the one starting refuses it before it writes anything there and
+creates no root in its place. `start()` of `NoSqlDbServer` and of
+`LocalNoSqlDb` then rejects with a `NoSqlDbUnknownRootError`, whose `code`
+is `UNKNOWN_ROOT` and whose message names that cause; its `cause` is the
+management error that carried the code. A caller tells this refusal apart
+from every other start failure by the code, never by the message.
+
 ### NoSqlDbStorageRehearsal
 
 `NoSqlDbStorageRehearsal.createDestination(input, options?)` creates an isolated,
@@ -1113,11 +1132,14 @@ publication and validated on retry. Every other record's bytes and version are
 preserved, with unchanged complete non-profile record count and fingerprint.
 Its authority admits no internal relocation or alignment workspace. An
 unrelated staged workspace rejects before native opening, append or recovery.
-Existing v2 rehearsal journals without a plan remain readable: an unfinished
-binding intent explicitly migrates to the v3 journal and acquires a plan before
-its first append, while an already-bound
-stage is verified without rebinding or adding a second commit. Existing native
-manifests, fencing-profile schemas and committed records need no rewrite.
+This release neither rehearses a root that a 10.x release wrote nor finishes
+a rehearsal that a 10.x release began, or returns the receipt of one that it
+finished. A request whose source, destination or unfinished copy is such a
+root, in whole or in part, fails with `UNSUPPORTED`, and the retry of one
+whose 10.x roots starts have converted since fails with `UNSUPPORTED` or
+`SOURCE_CHANGED`; no such request changes either path or the operation
+workspace. Finish a 10.x rehearsal with that release before a start converts
+its source, or rehearse the converted root into another destination.
 
 Active source owners, rehearsal-as-source, old or mixed layouts, unknown entries,
 unfinished import or fencing operations, active read grants, unfinished or
@@ -1220,7 +1242,7 @@ underlying server and bridge are constructed by `LocalNoSqlDb.start()`.
 | Method / Property | Type | Description |
 |---|---|---|
 | `start()` | `Promise<ILocalNoSqlDbConnectionInfo>` | Start and return connection info |
-| `stop()` | `Promise<void>` | Stop the server |
+| `stop()` | `Promise<INoSqlDbServerStopResult>` | Stop the server; resolves with its server's stop result |
 | `getConnectionInfo()` | `ILocalNoSqlDbConnectionInfo` | Get current connection info |
 | `getConnectionUri()` | `string` | Get the connection URI |
 | `getServer()` | `NoSqlDbServer` | Access the underlying server |
@@ -1288,9 +1310,10 @@ source, inspect it for pins, copy it while it remains stopped, and align the cop
 before its first start. Pins cannot prove that an unverified backup is complete;
 a file truncated exactly at a commit boundary can still be internally consistent.
 
-Version 1 requires current production file storage, a clean committed tail, no
-generation newer than the manifest, no auth users, and no fencing, allocation,
-publication-hold, grant or import-stage authority. The complete catalog, auth,
+Version 1 requires current production file storage, a clean committed tail that
+no serving open would still repair, no auth users, and no fencing, allocation,
+publication-hold, grant or import-stage authority. A root that a 10.x release
+wrote is refused; a start converts it first. The complete catalog, auth,
 index, transaction-outcome and fencing audits must pass. Rehearsals, memory
 storage, unknown files (including `.DS_Store`/AppleDouble), symlinks, hard links
 and unsafe ownership or modes are refused. The operation never repairs them.
@@ -1323,8 +1346,9 @@ existing file is never overwritten. Use the relocation identifier rules for
 `acknowledgeUnverifiedCopy: true` when no source pins survive, never both.
 `binaryPath`, `timeoutMs` and `signal` select the engine and bound the operation.
 
-The following archive recipe was qualified from macOS arm64 APFS to Linux
-x86_64 ext4 and XFS. Run as the service user, with the source stopped throughout,
+The following archive recipe was qualified on this release's format-3 roots,
+from macOS arm64 APFS to Linux x86_64 ext4 and XFS (alignment.md records the
+run). Run as the service user, with the source stopped throughout,
 and retain its inspection pins separately. Start with a new private destination
 parent; preserve the private file/directory modes and do not include filesystem
 metadata sidecars. On macOS use the exact canonical case and Unicode spelling;
@@ -1365,16 +1389,16 @@ include `INVALID_REQUEST`, `NOT_FOUND`, `DESTINATION_CONFLICT`, `STATE_CORRUPT`,
 `abortStoppedStorageRootAlignment(request, options?)` accepts the identical
 request and only rolls back an exact **incomplete** planned append. A complete
 append must finish alignment. If permissions changed after interruption, restore
-the required ownership and modes first. Abort permits changed timestamps while
-still checking original inodes, the full inventory, original bytes and append
-prefix. It durably records abort, truncates/fsyncs, removes its exact reserved
-receipt and cleans up. Retry abort after an interrupted abort; alignment cannot
-override that decision. An absent workspace returns `not-pending`.
-
-Older 8.0.2 engines reject pending workspaces with “startup rejects existing
-file-provider bookkeeping”. Finish or abort with the newer engine; deleting the
-workspace is not a fix. A v8-produced fixture remains readable by v8 after this
-one-profile append. This does **not** allow downgrading v10-created catalogs.
+the required ownership and modes first. Abort permits a changed change time,
+which restoring ownership or modes leaves, while still checking every file's
+identity, length and modification time, the original bytes, and that the planned
+append's place holds only its own bytes or zeros. It durably records abort,
+writes zeros where the interrupted append wrote and syncs, removes its exact
+reserved receipt and cleans up. Retry abort after an interrupted abort; alignment
+cannot override that decision. An absent workspace returns `not-pending`.
+
+Finish or abort a pending alignment with this release; deleting the workspace is
+not a fix. No earlier release reads a root that this release has aligned.
 Qualification results and study corrections are recorded in the repository's
 [alignment design note](https://code.foss.global/lossless.org/nosqldb/src/branch/main/alignment.md).
 
@@ -1387,7 +1411,14 @@ through the complete record-owner audit. A running engine returns `BUSY`.
 
 An `audited` result includes the recorded provider identity, live binding state,
 lineage (`groupId`/`timelineId`), decimal-string LSN and counts, full-record and
-profile-excluded SHA-256 digests, generation inventory and alignment eligibility.
+profile-excluded SHA-256 digests, `storageFormat: 'format-3'` for a root of this
+release or the generation inventory of a root that a 10.x release wrote, and
+alignment eligibility. A format-3 root that a serving open would still repair,
+such as one whose log ends inside an unfinished write, is ineligible with
+`RECOVERY_PENDING`. A root that a 10.x release wrote is audited read-only as that
+release audited it, with the same identity, counts, digests and generation
+inventory, and is ineligible with `CONVERSION_PENDING` first among its reasons:
+this release does not align it, and a start converts it first.
 It counts allocation replays as well as fences, receipts, holds and allocations.
 The audit accepts no active grants or import stages. Auth users or authority
 history make a fully audited root ineligible for independent-fork alignment.
@@ -1407,10 +1438,15 @@ the TypeScript interfaces for older engine binaries.
 #### Offline String-Value Inspection
 
 `LocalNoSqlDb.inspectOfflineStringValue(input, options?)` reads one string from a
-stopped current native file root on supported Linux filesystems or macOS APFS.
+stopped native file root of this release, or read-only from one that a 10.x
+release wrote, on supported Linux filesystems or macOS APFS.
 It starts only a disposable management sidecar, acquires the existing native
 leases read-only, and pins the committed root. It never starts a listener,
-initializes storage, repairs tails, replays writes or compacts the source.
+initializes storage or writes to the source: a root of this release is
+recovered in memory only, as a start would recover it, and a cut log tail or a
+leftover anchor replacement stays on disk as found. A root that a 10.x release
+wrote is read up to its committed state, and one that a 10.x process left
+without a clean stop is refused with `RECOVERY_REQUIRED`.
 
 ```typescript
 import { LocalNoSqlDb } from '@lossless.org/nosqldb';
@@ -1501,7 +1537,7 @@ await debugServer.start();
 await debugServer.stop();
 ```
 
-The UI is bundled as base64-encoded content (via `@git.zone/tsbundle`) and served from memory — no static file directory needed.
+The UI is bundled as base64-encoded content (via `tsrepo bundle` from `@git.zone/tsrepo`) and served from memory — no static file directory needed.
 
 ### NoSqlDbDebugUi (Web Component)
 
@@ -1553,72 +1589,20 @@ await collection.findOneAndReplace({ _id: id }, { name: 'Replaced' }, { returnDo
 
 ### Query Operators
 
-```typescript
-// Comparison
-{ age: { $eq: 25 } }     { age: { $ne: 25 } }
-{ age: { $gt: 18 } }     { age: { $lt: 65 } }
-{ age: { $gte: 18 } }    { age: { $lte: 65 } }
-{ status: { $in: ['active', 'pending'] } }
-{ status: { $nin: ['deleted'] } }
-
-// Logical
-{ $and: [{ age: { $gte: 18 } }, { active: true }] }
-{ $or: [{ status: 'active' }, { admin: true }] }
-{ $not: { status: 'deleted' } }
-
-// Element
-{ email: { $exists: true } }
-{ type: { $type: 'string' } }       { value: { $type: ['int', 'long'] } }
-
-// Array
-{ tags: { $all: ['mongodb', 'database'] } }
-{ scores: { $elemMatch: { $gte: 80, $lt: 90 } } }
-{ labels: { $not: { $elemMatch: { $nin: ['linux', 'gpu'] } } } }
-{ items: { $elemMatch: { sku: 'a', qty: { $gt: 2 } } } }
-{ items: { $all: [{ $elemMatch: { sku: 'a' } }, { $elemMatch: { qty: 0 } }] } }
-{ tags: { $size: 3 } }
-
-// Regex
-{ name: /^Al/i }                    { name: { $regex: '^al', $options: 'i' } }
-{ tags: { $in: [/^db/, 'mongodb'] } }
-
-// Aggregation expressions
-{ owner: 'o', $expr: { $lte: [{ $add: ['$retainedBytes', '$reservedBytes', size] }, max] } }
-{ $expr: { $gt: ['$leaseExpiresAt', '$$NOW'] } }
-```
-
-`$type` takes a type alias (`'string'`, `'number'`, …), a numeric BSON type
-code or an array of them, and matches an array field through its elements as
-well as `'array'` itself.
-
-`$comment` annotates a filter without constraining it, at the top level and
-in an `$and`, `$or`, `$nor` or `$elemMatch` document; under a field it is
-refused as an unknown operator, as on MongoDB.
-
-A filter is checked as MongoDB 8 checks it, before any document is read and
-with its messages: `$and`, `$or` and `$nor` need a non-empty array of
-documents, `$in`, `$nin` and `$all` an array, and a `$in` or `$nin` member
-whose first field starts with `$`, such as `{ $gt: 1 }`, is refused
-(`cannot nest $ under $in`), each with `BadValue` (2). A DBRef member such as
-`{ $ref: 'users', $id: id }` is a value. Partial index filters and `$pull`
-conditions refuse the query features MongoDB 8 bans there: `$expr` and
-`$jsonSchema` with `QueryFeatureNotAllowed` (224), `$where` and `$text` with
-`BadValue`, and `$near`, `$nearSphere` and `$geoNear` with `Location5626500`.
-
-`$elemMatch` has MongoDB's two forms. An operand whose first key is a query
+`$elemMatch` has two forms, implemented to be MongoDB compatible. An operand whose first key is a query
 operator applies its operators (`$eq`, `$ne`, `$gt`, `$gte`, `$lt`, `$lte`,
 `$in`, `$nin`, `$exists`, `$type`, `$regex`, `$size`, `$mod`, `$all`, `$not`,
 `$elemMatch`) to each element as a whole; any other operand is a query over
 each embedded document, and a nested array is matched as a document keyed by
 index. A dotted path tests every array it reaches on its own. `$expr` inside
-`$elemMatch` is refused with `BadValue` (2), as on MongoDB.
+`$elemMatch` is refused with `BadValue` (2), implemented to be MongoDB compatible.
 
 A regular expression matches the same way wherever a filter holds one — as a
 field's value, through `$regex` and `$options`, in a `$in`, `$nin` or `$all`
 list, under `$not`, and as a `$pull` condition: a string or symbol matches when
 the pattern finds a match in it, an array matches through its elements, a
 stored regular expression matches only when its pattern and options are equal,
-and a missing field never matches. `$options` takes MongoDB's flags `i`, `m`,
+and a missing field never matches. `$options` takes the MongoDB-compatible flags `i`, `m`,
 `s`, `x` and `u`. Patterns run on Rust's `regex` crate rather than PCRE, so
 matching takes time linear in the input, constructs only PCRE has
 (look-around, backreferences, `\Q…\E`, `\Z`, `(?#…)` comments, a `{` that
@@ -1627,28 +1611,16 @@ starts no repetition) are refused as invalid, and a few match differently:
 does not match before a final newline, a possessive quantifier such as `a++`
 is greedy, and `x` ignores whitespace inside a character class too. A
 pattern is checked when the filter is validated, before any document is read
-and even when the collection does not exist, with MongoDB's errors in
-MongoDB's order: options given in both `$regex` and `$options` are
+and even when the collection does not exist, with MongoDB-compatible errors in
+a MongoDB-compatible order: options given in both `$regex` and `$options` are
 `Location51074` or `Location51075`, an unknown flag `Location51108`, a null
 byte `BadValue` (2), a pattern longer than 32,764 bytes or one that does not
 compile `Location51091` `Regular expression is invalid: <reason>` (the reason
-is the crate's, such as `unclosed group` where MongoDB says `missing closing
+is the crate's, such as `unclosed group` where MongoDB, as observed by runtime testing, answers `missing closing
 parenthesis`), and a regular expression as the operand of `$ne`, `$gt`,
 `$gte`, `$lt` or `$lte` `BadValue` (2). A match charges the work budget the
 size of the field's value times the length of the pattern.
 
-`$expr` evaluates an aggregation expression per document in `find`, `count`,
-`distinct`, `update`, `delete`, `findAndModify` and a `$match` stage, and
-matches when the result is truthy. It accepts the operators listed under
-[Aggregation Pipeline](#aggregation-pipeline). Evaluation is charged against
-the same work budget as every other predicate, and an operator the engine does
-not implement is refused by name with `TypeMismatch` (code 14) before any
-document is read. `$$NOW` is one instant per command, as in MongoDB: the
-engine reads the clock once when the command starts, and the command's filter,
-every document of a pipeline update, every aggregation stage, `$lookup` and
-`$unionWith` sub-pipeline, and every `getMore` of its cursor see that instant.
-Filters outside a command, such as a partial index filter, have no `$$NOW`.
-
 ### Update Operators
 
 ```typescript
@@ -1671,8 +1643,8 @@ may be an array of `$addFields`, `$set`, `$project`, `$unset`, `$replaceRoot`
 or `$replaceWith` stages, and any other stage is refused by name. The pipeline
 must produce exactly one document and cannot change `_id`.
 
-An upsert that matches nothing inserts the filter's equality conditions, as
-MongoDB does: top-level fields and `$and` clauses, `$eq`, a single-element
+An upsert that matches nothing inserts the filter's equality conditions, to be
+MongoDB compatible: top-level fields and `$and` clauses, `$eq`, a single-element
 `$in`, `$all` members and a single-clause `$or`. A dotted path such as
 `'owner.id'` becomes a nested document, and a regular expression is copied only
 as an `$eq` operand. A replacement takes only `_id` from the filter and fails
@@ -1695,64 +1667,6 @@ const results = await collection.aggregate([
 
 **Supported stages:** `$match`, `$project`, `$group`, `$sort`, `$limit`, `$skip`, `$unwind`, `$lookup`, `$addFields`, `$count`, `$facet`, `$replaceRoot`, `$set`, `$unionWith`, `$out`, `$merge`
 
-**Supported expression operators:**
-
-| Group | Operators |
-| --- | --- |
-| Comparison | `$eq`, `$ne`, `$gt`, `$gte`, `$lt`, `$lte`, `$cmp` |
-| Arithmetic | `$add`, `$subtract`, `$multiply`, `$divide` |
-| Logical | `$and`, `$or`, `$not` |
-| Conditional and variables | `$cond` (array or `if`/`then`/`else` form), `$ifNull` (two or more operands), `$let` |
-| Type and arrays | `$isNumber`, `$type`, `$in`, `$size`, `$arrayElemAt` |
-| Dates | `$dateAdd` |
-| Collections | `$map`, `$objectToArray`, `$setEquals` |
-| Literals | `$literal` |
-
-plus `$field` paths, `$$variable` references including `$$ROOT` and `$$NOW`,
-and documents or arrays of those. Every other operator is refused by name with
-`TypeMismatch` (code 14) before any document is read; the engine never treats
-an operator it cannot execute as a literal value.
-
-Expressions follow MongoDB's value semantics. A field that is absent is
-*missing*, which is not `null`: `$type` answers `'missing'`, `$ifNull`
-replaces both, and comparisons order values as MongoDB does (MinKey, missing,
-`null`, numbers, strings, objects, arrays, binary data, ObjectIds, booleans,
-dates, timestamps, regular expressions, MaxKey), so `{ $eq: ['$absent', null] }`
-is false. Numbers compare by value across their wire types. A path through an
-array maps over its elements and always answers an array: `'$mailbox.path'`
-over one looked-up document is `['INBOX']`, so `$arrayElemAt` and `$size`
-apply to it. Arithmetic answers `null` when an operand is `null` or missing;
-an int result that overflows widens to a long and a long to a double, a double
-operand makes the result a double, and `$divide` always answers a double.
-`$add` accepts one date and answers a date; date minus date is milliseconds.
-Runtime errors keep MongoDB 7's codes: a non-numeric operand is
-`TypeMismatch` (14), `can't $divide by zero` is `BadValue` (2), a date that
-leaves the 64-bit range is `Overflow` (15), and the array and date operators
-answer MongoDB's location codes (a second date in `$add` 16612, `$in` without
-an array 40081, `$size` without an array 17124, `$arrayElemAt` 28689–28691,
-`$dateAdd` 5166403, 5166405, 5166406 and 5439013, a non-string time zone
-40517, an unknown unit `FailedToParse` (9)). Decimal128 operands in arithmetic
-are refused with `TypeMismatch` (14) — decimal arithmetic is not
-implemented. `$and`, `$or`, `$cond` and `$ifNull`
-evaluate, and charge, only the operands MongoDB evaluates, so a guard keeps an
-invalid branch from failing the statement. `$dateAdd` computes in UTC with the
-units `millisecond` to `year`, clamping `month`, `quarter` and `year` to the
-end of the target month; a `timezone` other than UTC is refused by name.
-Within a document expression a member that is missing is still written as
-`null`, where MongoDB omits the member.
-
-`$lookup` supports the equality form and a bounded correlated pipeline form with
-`let`, an optional `$match` (any filter, `$expr` included), and an optional
-following `$limit`. A `let` variable that reads an absent local field is bound
-to the missing value, as in MongoDB. Correlated string equality predicates
-(`$expr` with `$eq`, optionally under `$and`) can use a full-key or subset
-foreign equality index to reduce candidates when available. Candidates are
-paged, the complete expression remains authoritative, and `$limit` counts only
-exact expression matches. Other BSON value shapes use the bounded scan path.
-Mixed `localField`/`foreignField` plus `pipeline` lookups and other inner stages
-are rejected explicitly. Complete filter trees are validated before data is
-read, and query nesting plus aggregation work are bounded.
-
 A leading `$match` narrows the pipeline's source load instead of filtering
 after it: only matching documents are materialized, using an equality index when
 one serves the filter and a bounded scan otherwise. Filter shapes the query
@@ -1772,19 +1686,6 @@ describes, as it does on its own.
 
 **Group accumulators:** `$sum`, `$avg`, `$min`, `$max`, `$first`, `$last`, `$push`, `$addToSet`, `$count`
 
-`$group._id` accepts a literal (`null`, a number, a string), a `$field`
-reference, or a document of expressions: `{ _id: { owner: '$owner', repo:
-'$repo' } }` groups by the evaluated pair, one group per distinct composite
-key. Inside a composite `_id`, a member whose field is absent evaluates to
-`null` and stays part of the key, where MongoDB omits the member instead.
-Accumulator operands accept the same expression forms. A field reference
-resolves per document, and a missing field is not a value: `$sum`, `$avg`,
-`$min`, `$max`, `$push` and `$addToSet` skip it, while `$first` and `$last`
-record `null` for it. Every field beside `_id` must hold an accumulator
-document naming exactly one accumulator, such as `{ $sum: 1 }`, and an operator
-outside the two lists above is refused with `TypeMismatch` (code 14) when the
-stage is parsed.
-
 ### Indexes
 
 ```typescript
@@ -1798,77 +1699,8 @@ await collection.dropIndexes();  // drop all except _id
 
 > 🛡️ **Unique indexes are enforced at the engine level.** Duplicate values are rejected with a `DuplicateKey` error (code 11000) *before* the document is written to disk — on `insertOne`, `updateOne`, `findAndModify`, and upserts. Index definitions and entries are committed with native storage and survive restart.
 
-NoSQLDB supports ascending and descending index keys with `name`, `unique`,
-`sparse`, `partialFilterExpression` and `expireAfterSeconds` options. It
-accepts `background` as a validated no-op and index version `v: 2`.
-Unsupported options, including `collation` and `hidden`, are rejected before
-any index in the request is created. A legacy `ns` field is accepted only when
-it names the target namespace. With `ignoreUnknownIndexOptions: true`,
-`createIndexes` removes the fields MongoDB 7 does not know as index options
-(and plugin-specific fields such as `weights` or `bits` on an ascending or
-descending key) before validation, as MongoDB does; options MongoDB knows but
-NoSQLDB does not implement are still rejected. Native maintenance expires eligible BSON
-dates and date arrays in bounded batches, preserving publication holds and
-active snapshots.
-
-**Partial indexes.** An index with a `partialFilterExpression` holds only the
-documents that match the filter, and a unique partial index enforces
-uniqueness among those documents only:
-
-```typescript
-await jobs.createIndex(
-  { activeClaimKey: 1 },
-  { unique: true, partialFilterExpression: { activeClaimKey: { $exists: true } } },
-);
-await pulls.createIndex(
-  { org: 1, repo: 1, sourceRef: 1, targetRef: 1 },
-  { unique: true, partialFilterExpression: { state: 'open' } },
-);
-```
-
-The filter accepts MongoDB 8's subset: equality (`field: value` or `$eq`),
-`$exists: true`, `$gt`, `$gte`, `$lt`, `$lte`, `$type`, `$in`, whose list may
-hold regular expressions that match as they do in a query, `$all` of values,
-which is the conjunction of their equalities and counts as one level, `$and`
-and `$or`, nested at most four expression levels deep; `$comment` is accepted
-and ignored. Any other expression — `$exists: false`, `$ne`, `$nin`, `$not`,
-`$nor`, a regular expression outside `$in`, an empty `$all` or one holding a
-regular expression or `$elemMatch`, `$elemMatch` and `$size` — and a filter
-combined with `sparse` are refused with `CannotCreateIndex` (code 67);
-`$expr`, `$jsonSchema`, `$where`, `$text` and the `$near` operators are
-refused with the codes listed under [Query Operators](#query-operators), a
-malformed filter, such as an empty `$and`, is `BadValue` (2) and a
-non-document is `TypeMismatch` (14). As in MongoDB, the whole filter is first
-validated as a query, so a malformed operand or an invalid regular expression
-anywhere in it (`Location51091`, `Location51108`) is answered before an
-expression outside the subset.
-An update that moves a document into the filter claims its key, one that moves
-it out releases it, and transactions claim keys the same way, so a racing
-claim is a `WriteConflict` (112) with `TransientTransactionError`.
-`listIndexes`, canonical export and import report the filter exactly as it was
-created. The filter identifies the index: the same name with a different
-filter is `IndexKeySpecsConflict` (86); the same key with an equivalent filter
-under another name is `IndexOptionsConflict` (85); a different filter over the
-same key under another name is a separate index. Two filters are equivalent
-when MongoDB 8 normalises them to the same expression: implicit equality and
-`$eq`, numeric wire types, `$in: [1]` and `1`, an `$or` of equalities on one
-path and their `$in`, `$in` order and duplicates, `$all` and the `$and` of
-its values, nested and flat `$and` or `$or`, `$type` aliases and their codes,
-`$exists: true` and `1`, and a `$comment` or none compare equal, and so do
-conjuncts and `$or` branches on different paths or of different kinds in any
-order. Predicates of one kind on one path keep their written order, so
-`{ $and: [{ a: 1 }, { a: 2 }] }` and its reverse are separate indexes, as are a
-repeated conjunct and the conjunct alone, a document operand with its fields
-in another order, and `$type: 'number'` and the list of the four numeric
-types. The query
-planner never selects a partial index on its own; a `hint` naming one reads
-only its members, as MongoDB's hinted scan does. A partial TTL index expires
-only its members. Engines older than this release refuse a storage root that
-holds a partial index instead of enforcing its uniqueness over every
-document.
-
 **List fields.** An index on a field that holds lists has an entry per element,
-as a MongoDB multikey index, and a compound index an entry per combination of
+to be compatible with MongoDB multikey indexes, and a compound index an entry per combination of
 its list fields' elements. Equality, `$in` and one-sided ranges on the elements
 read their bounds, and a document with several entries within them is returned
 once. A list matches a range bounded on both sides when one element meets the
@@ -1879,10 +1711,12 @@ through the index. An index with element entries returns no order, so a sorted
 read sorts its matches, and a `hint` naming it is refused. A unique index on a
 list field is unique per element: a document that shares an element with
 another is a `DuplicateKey` (11000), while one document may repeat an element.
-An index whose field already held a list under 10.7.3 or earlier keeps its
-whole-list entries and uniqueness and is maintained but never selected until it
-is dropped and created again. Engines up to 10.7.3 refuse an index with element
-entries instead of maintaining it with whole lists.
+An index whose field already held a list under 10.7.3 or earlier, which those
+releases kept with whole-list entries, gets element entries when 11.0.0
+converts its root at start, and is then selected like any other index; a unique
+one whose documents share an element refuses the start before anything is
+written. Engines up to 10.7.3 refuse an index with element entries instead of
+maintaining it with whole lists.
 
 `find()` and collection `aggregate()` accept `hint` as an index name (including
 `_id_`) or an exact ascending/descending key pattern. Key-pattern order matters;
@@ -1929,7 +1763,7 @@ Nontransaction aggregation pipelines composed of `$match`, `$project`, `$unset`,
 `$set`, `$addFields`, `$replaceRoot`, `$replaceWith`, `$skip`, `$limit`, `$sort`,
 `$group`, `$count`, `$unwind`, `$lookup`, `$unionWith`, and `$facet` also operate
 beyond 10,000 input or output documents.
-Counts use exact collection metadata where applicable, otherwise stream matching
+Counts use each collection's exact count from its statistics record where applicable, otherwise stream matching
 records. A limit bounds the work needed to find the requested number of matches.
 Without a limit, exact counts continue to EOF. Hints, deadlines and empty-result
 shapes remain supported; signed BSON count overflow and resource exhaustion
@@ -1995,8 +1829,9 @@ transaction and native commit byte admission. `$out` and `$merge` have no
 10,000-document output ceiling; their atomic output is subject to the same write
 budgets and rejects before publication if those budgets are exceeded. Native
 database import uses private staging for larger supported exports, then publishes
-the catalog and receipt atomically. Existing old-engine storage is rejected
-without conversion.
+the catalog and receipt atomically. A start converts a root that a 10.x release
+wrote (see **Storage format migration** under File startup admission); any other
+old storage is rejected without conversion.
 
 ### Comparing performance with MongoDB
 
@@ -2051,40 +1886,23 @@ time-series collections, clustered indexes, encrypted fields, and all general
 view pipelines remain unsupported and are rejected before the database or
 namespace is created.
 
-`create` accepts an `idIndex` only when it describes the primary index every
-collection gets: key `{ _id: 1 }`, name `_id_`, optionally `v: 2` and an `ns`
-naming the new collection. Any other `idIndex` is `InvalidOptions` (72).
-
 **Collection names.** A name with a NUL, an empty name and a name starting
 with `.` that storage cannot hold, such as `.` or `..`, are `InvalidNamespace`
-(73) on every command naming them, with MongoDB 8's messages, before the
-command runs. A name MongoDB 8 accepts that one storage path component cannot
+(73) on every command naming them, with MongoDB-compatible messages, before the
+command runs. A name MongoDB accepts that one storage path component cannot
 hold, one with `/`, `\` or a control character or longer than 255 bytes, names
 a collection that cannot exist: reads, `drop`, `viewOn` and a rename source see
 it missing, and commands that create or write it are refused with
 `InvalidNamespace`, or `IllegalOperation` (20) for `$out` or a rename into a
-name longer than 255 bytes. Such a refused write ends its transaction, as
-MongoDB 8's refusal of a namespace longer than 255 bytes does. NoSQLDB limits
-the collection name to 255 bytes where MongoDB 8 limits the whole
+name longer than 255 bytes. Such a refused write ends its transaction, to be compatible with MongoDB's
+refusal of a namespace longer than 255 bytes. NoSQLDB limits
+the collection name to 255 bytes where MongoDB, as observed by runtime testing, limits the whole
 `database.collection`, and it accepts a name such as `.a` that starts with `.`
-but that its storage holds, which MongoDB 8 refuses.
-
-**Importing from MongoDB.** `mongorestore` (MongoDB Database Tools 100.x)
-restores a `mongodump` of ordinary collections with its default flags: the
-documents, validators and supported indexes (unique, compound, sparse,
-partial and TTL). It sends this `idIndex` with every `create` and
-`createIndexes` with each index's `ns` and `ignoreUnknownIndexOptions: true`,
-and it builds several collections' indexes in parallel, which wait for one
-another instead of failing (see "Database waits" below). Exclude the `admin`
-and `config` namespaces (`--nsExclude 'admin.*' --nsExclude 'config.*'`) and create users
-through NoSQLDB's authentication options. Collections or indexes that use
-unsupported features (collation, text, geospatial, hashed or wildcard
-indexes, capped or time-series collections) fail the restore with the
-refusing command's error instead of being restored differently.
+but that its storage holds, which MongoDB refuses.
 
 ### Collection Validators
 
-`create` and `collMod` accept MongoDB's `validator`, `validationLevel`
+`create` and `collMod` accept the MongoDB-compatible `validator`, `validationLevel`
 (`strict`, `moderate`, `off`) and `validationAction` (`error`, `warn`), and
 `listCollections` reports them under `options` exactly as set:
 
@@ -2111,7 +1929,7 @@ is `bsonType` (every BSON alias and `number`), `type` (`object`, `array`,
 `additionalProperties` (boolean), `minProperties`, `maxProperties`, `enum`,
 `minimum`, `maximum`, `exclusiveMinimum`, `exclusiveMaximum`, `minLength`,
 `maxLength`, `pattern`, `items` (one schema), `minItems`, `maxItems`, `title`
-and `description`, with MongoDB's semantics: a keyword applies only to values
+and `description`, with MongoDB-compatible semantics: a keyword applies only to values
 of its kind and not at all when `bsonType`/`type` excludes that kind, `enum`
 compares numbers by value and embedded documents regardless of field order,
 NaN fails `minimum` and `maximum`, and lengths count code points. Everything
@@ -2119,9 +1937,9 @@ else is refused when the validator is set, never ignored: `patternProperties`,
 `additionalItems`, `uniqueItems`, `dependencies`, `allOf`, `anyOf`, `oneOf`,
 `not`, `multipleOf`, `encrypt`, `encryptMetadata`, `items` as an array and
 `additionalProperties` as a schema answer `FailedToParse` (9) `$jsonSchema
-keyword '…' is not currently supported`, as MongoDB answers for `$ref`,
+keyword '…' is not currently supported`, the MongoDB-compatible answer for `$ref`,
 `format`, `default`, `definitions`, `id` and `$schema`; `$jsonSchema` below the
-top level answers `BadValue` (2). Malformed validators answer MongoDB's codes
+top level answers `BadValue` (2). Malformed validators answer MongoDB-compatible codes
 (2, 9, 14, `Location51091` for an invalid `pattern`). `pattern` uses the same
 regular-expression dialect as `$regex`; constructs only PCRE supports are
 refused as invalid.
@@ -2133,10 +1951,10 @@ written document; `moderate` skips updates to documents that did not satisfy
 the validator before the update; `off` validates nothing; a no-op update and a
 delete are never validated. A refused document answers
 `DocumentValidationFailure` (121), `errmsg: "Document failed validation"`, and
-MongoDB's `errInfo: { failingDocumentId, details }` — as a write error of
+the MongoDB-compatible `errInfo: { failingDocumentId, details }` — as a write error of
 `insert`/`update`, keeping ordered and unordered batch semantics, and as the
 command error of `findAndModify` and `aggregate`. A refused statement aborts
-its transaction. `details` has MongoDB's shape for every `$jsonSchema` keyword
+its transaction. `details` has a MongoDB-compatible shape for every `$jsonSchema` keyword
 above and for `$and`, `$or`, `$nor`, `$not`, `$eq`, `$ne`, `$gt`, `$gte`,
 `$lt`, `$lte`, `$exists`, `$type`, `$in`, `$nin`, `$regex`, `$size`, `$all`,
 `$elemMatch`, `$mod` and `$expr`; other operators report only `operatorName`
@@ -2145,12 +1963,12 @@ and `specifiedAs`. `validationAction: 'warn'` writes the document and logs a
 `bypassDocumentValidation` (a boolean or number) on `insert`, `update`,
 `findAndModify` and writing `aggregate` skips validation; with authentication
 it requires `dbAdmin` on the written database, as `collMod` does — `readWrite`
-alone is refused with `Unauthorized` (13), as in MongoDB's built-in roles.
+alone is refused with `Unauthorized` (13), implemented to be compatible with MongoDB's built-in roles.
 
 `collMod` changes only the options it names; `validator: {}` removes the
 validator; a `null` option is absent; `collMod` without options answers
 `{ ok: 1 }`. A missing collection answers `NamespaceNotFound` (26), a view or
-`system.*` collection `InvalidOptions` (72), MongoDB's other `collMod` options
+`system.*` collection `InvalidOptions` (72), the other MongoDB `collMod` options
 (`index`, `viewOn`, `pipeline`, `expireAfterSeconds`, `timeseries`,
 `changeStreamPreAndPostImages`, `dryRun`, `cappedSize`, `cappedMax`, …)
 `InvalidOptions` (72) by name, and unknown fields `IDLUnknownField` (40415).
@@ -2163,13 +1981,13 @@ content digest includes them only then, so digests of collections without
 options are unchanged. Engines up to 10.6.1 refuse a storage root or an export
 holding collection options instead of silently not enforcing them.
 
-Differences from MongoDB 7: `create` on an existing collection answers
+Differences from MongoDB, as observed by runtime testing: `create` on an existing collection answers
 `NamespaceExists` (48) even when the options are identical (MongoDB answers
 `ok`); a validator together with `viewOn` is refused (MongoDB ignores it); an
-invalid `pattern` at the schema root is refused (MongoDB never compiles it
+invalid `pattern` at the schema root is refused (MongoDB accepts it
 there);
-command errors say `Document failed validation` without MongoDB's
-`Plan executor error during …` prefix; the `warn` log carries `errInfo`, not
+command errors say `Document failed validation` without the
+`Plan executor error during …` prefix MongoDB adds; the `warn` log carries `errInfo`, not
 the whole document.
 
 ### Restricted Deny-All Views
@@ -2205,7 +2023,7 @@ replaced by a view keeps that original snapshot for `find`, `count`, and
 with `CommandNotSupportedOnView` (code 166). `dropCollection` is the supported
 DDL exception for removing a logical restricted view.
 
-Definitions are persisted in the physical `system.views` catalog. As in MongoDB,
+Definitions are persisted in the physical `system.views` catalog. To be MongoDB compatible,
 `listCollections` lists `system.views` as a physical storage collection and the
 logical namespace as type `view` with `{ viewOn, pipeline }`, read-only metadata,
 and no `idIndex`. `system.views` is reserved from direct wire reads,
@@ -2242,9 +2060,6 @@ const estimated = await collection.estimatedDocumentCount();
 const names = await collection.distinct('name');
 ```
 
-The `count` command answers `n` as a 32-bit integer when the count fits and as
-a 64-bit integer above that, as MongoDB does.
-
 ---
 
 ## Wire Protocol Commands
@@ -2256,87 +2071,9 @@ a 64-bit integer above that, as MongoDB does.
 | **Aggregation** | `aggregate`, `count`, `distinct` |
 | **Indexes** | `createIndexes`, `dropIndexes`, `listIndexes` |
 | **Sessions** | `startSession`, `endSessions`, `killSessions` |
-| **Transactions** | `startTransaction`, `commitTransaction`, `abortTransaction` through driver sessions; `readFence` (NoSQLDB-specific, see Read fences) |
+| **Transactions** | `startTransaction`, `commitTransaction`, `abortTransaction` through driver sessions |
 | **Admin** | `ping`, `buildInfo`/`buildinfo`, `listDatabases`, `listCollections`, `drop`, `dropDatabase`, `create`, `collMod` (validation options), `serverStatus`, `dbStats`, `collStats`, `connectionStatus`, `renameCollection` |
 
-Advertises MongoDB wire protocol versions 0–21 and reports MongoDB 7.0.0
-compatibility for its command surface. The documented command surface is tested
-with the official `mongodb` Node.js driver version 7.5.x. Wire limits and error
-replies follow MongoDB 8.0, whose document size tiers are larger than 7.0's;
-where NoSQLDB still differs from MongoDB 8.0, the list at the end of this
-section says so.
-
-OP_MSG parsing rejects unknown required flags, invalid CRC-32C checksums,
-duplicate BSON keys, noncanonical array indexes, malformed section boundaries,
-multiple body sections, duplicate or colliding document-sequence identifiers,
-and missing or non-string `$db` fields. Early command-envelope validation then
-accepts document sequences only as `insert.documents`, `update.updates`, or
-`delete.deletes`, before authentication or command resources are acquired. A
-write command refuses any other sequence as an unknown field of its own,
-`IDLUnknownField` (40415) naming `insert.x`, or `insert` for an empty
-identifier, as MongoDB 8 does; any other command refuses document sequences with
-`InvalidOptions` (72). All three accepted forms are consumed as the
-corresponding bulk command argument. Unknown optional flags are ignored.
-
-As in MongoDB 8, a complete frame that is malformed or over a document limit is
-answered with an error reply to its request id, and the connection stays usable
-for the requests behind it: for example `InvalidBSON` (22) for a bad document
-length or a body cut short, `Overflow` (15) for nesting beyond 100 levels, the
-`Location404xx` codes for malformed sections, `Location51252` for a checksum
-that leaves no room for a section, and `BSONObjectTooLarge` (10334) for an
-oversized document. The 10334 message shows the document's first element as
-MongoDB's does, cut after 160 bytes. In MongoDB 8's order, a document's
-structure (lengths, terminators, element types and booleans) and nesting are
-checked before its size, and a message's sections and BSON before its checksum.
-A defect in a legacy OP_QUERY document, its nesting included, is `InvalidBSON`
-(22), as MongoDB 8 answers it, and bytes after an OP_QUERY's field selector are
-ignored, as MongoDB 8 ignores them. A refused `moreToCome` request gets no
-reply. A frame that cannot be delimited or trusted closes the connection, again
-as in MongoDB: an invalid length prefix, an OP_MSG too short to hold its flags,
-a request whose `responseTo` is not 0, an unknown required flag, more than 128
-sections, or a checksum mismatch.
-
-A message is limited to 48,000,000 bytes. A command body may be up to 16,809,984
-bytes and a document-sequence or legacy OP_QUERY document up to 16,793,600 bytes,
-MongoDB 8's 16 MiB plus 32 KiB and 16 KiB of command overhead; a stored document
-is limited to 16,777,216 bytes, and an insert row over it is that row's
-`BSONObjectTooLarge` write error. An `insert`, `update` or `delete` batch must
-hold 1 to 10,000 operations, the advertised `maxWriteBatchSize`; other batches
-are refused with `InvalidLength` (16), and drivers split larger input batches.
-
-Before any of a request is decoded, its BSON is checked and the heap its decoded
-form takes is computed from the bytes alone, each allocation rounded up as the
-allocator rounds it. A request holds that charge against the server's
-decoded-memory budget, 1 GiB by default, until its command has finished with
-it. A request whose decoded form takes 16 KiB or less, as handshakes, pings
-and ordinary commands do, holds it against a separate 16 MiB share kept beside
-the budget instead, which holds one such request for each of the 1,024
-connections a server accepts, so it never waits behind larger requests. A
-request whose frame is small but whose decoded form is larger, such as a find
-with a long `$in` list, waits in the budget with the large ones. A request
-that needs more than the
-whole budget is refused whole with `BSONObjectTooLarge` (10334) and the message
-"send smaller batches", after its sections and BSON are checked and before its
-checksum. The number of elements, nested documents and arrays a request holds
-is not limited, so a full batch of 10,000 wide documents is accepted as in
-MongoDB. A request that does not fit what the budget has left waits for it
-behind every request of its share that arrived before it, for at most its
-`maxTimeMS` or five seconds from when it arrived. A request still waiting then
-is answered without being decoded or run: with `MaxTimeMSExpired` (50) when its
-`maxTimeMS` is five seconds or less, and otherwise with `LockTimeout` (24),
-which a transaction statement gets with the `TransientTransactionError` label.
-A statement of a running transaction answered so aborts its transaction; a
-`commitTransaction` or `abortTransaction` answered so, or a statement that would
-start its transaction, leaves the transaction as it was. A `moreToCome` request
-still waiting closes its connection. A command's `maxTimeMS` counts from when
-the server had the whole request, so the wait is part of it; a request sent
-while the connection's previous command ran counts from when that command
-finished, as MongoDB reads it only then. `maxTimeMS: 0` means no limit, as in
-MongoDB, so such a request waits the five seconds and gets `LockTimeout`. A
-legacy OP_QUERY command wrapped in `$query` is answered from an envelope that
-misses its `maxTimeMS` and `lsid`, so it waits five seconds and gets
-`LockTimeout` without a transaction label.
-
 The `moreToCome` request flag is accepted only for the exact `endSessions` or
 `killSessions` cleanup envelope: an `admin` command body containing only the
 session array, `writeConcern: { w: 0 }`, and `$db: "admin"`, with no document
@@ -2402,40 +2139,10 @@ The decoded budget also bounds the largest request the server accepts, so a
 smaller one refuses smaller requests with `BSONObjectTooLarge`. Each server has
 its own budgets, so servers in one process do not share them.
 
-NoSQLDB still differs from MongoDB 8.0 on the wire in these points:
-
-- An opcode other than OP_MSG and OP_QUERY closes the connection. MongoDB 8
-  ignores most unknown opcodes and answers the legacy `OP_GET_MORE` with error
-  5739101.
-- A legacy OP_QUERY to a collection other than `$cmd` is routed as a `find`,
-  where MongoDB 8 answers 5739101.
-- Nesting is limited to 100 levels; MongoDB 8 allows 200.
-- A write batch over 10,000 operations is refused with `InvalidLength` (16);
-  MongoDB 8 accepts up to 100,000.
-- A request whose decoded form needs more than the decoded-memory budget, 1 GiB
-  by default, is refused with `BSONObjectTooLarge` (10334); MongoDB 8 has no
-  such limit.
-- A request that waits for decode memory longer than its `maxTimeMS` or five
-  seconds is answered with `MaxTimeMSExpired` (50) or `LockTimeout` (24)
-  without being run; MongoDB 8 has no decode budget.
 - A frame over 8 KiB whose bytes average less than 1 MiB per second after a
   10-second grace closes its connection while another connection waits for
-  the encoded budget or more than seven eighths of it are charged; MongoDB 8
+  the encoded budget or more than seven eighths of it are charged; MongoDB
   has no such limit.
-- The identifier a `Location40431` or `Location40433` message names is cut
-  after 256 bytes; MongoDB 8 names it whole.
-- A duplicate key anywhere in a request is refused with `InvalidBSON` (22);
-  MongoDB 8 does not refuse duplicate keys on the wire.
-- A field name or string that is not valid UTF-8 is refused with `InvalidBSON`
-  (22); MongoDB 8 does not check UTF-8 on the wire and stores such data.
-- Most `InvalidBSON` (22) messages describe the defect in NoSQLDB's own words.
-- A message with three document sequences gets an error reply, where MongoDB 8
-  closes the connection.
-- A command other than `insert`, `update` and `delete` refuses document
-  sequences with `InvalidOptions` (72); MongoDB 8 runs it.
-- `moreToCome` is accepted only for the session cleanup envelope above, where
-  MongoDB 8 runs any command sent with it.
-- A request that carries a checksum is answered without one.
 
 ### Identifying the Engine
 
@@ -2458,9 +2165,9 @@ is. Every `hello`, `ismaster` and `isMaster` reply carries a self-contained
 `version` is the released `@lossless.org/nosqldb` version the running binary was
 built from: the Rust build compiles it in from the package manifest, so the
 answer belongs to the shipped artifact and cannot drift from it.
-`mongodbCompatibility` is the MongoDB release whose wire protocol and command
-semantics this engine implements — a compatibility statement, never a claim to
-be that build.
+`mongodbCompatibility` is the compatibility version NoSQLDB reports to drivers
+and tools for the command surface it implements to be MongoDB compatible — a
+compatibility value, never a claim to be a MongoDB build.
 
 The handshake carries the identity unconditionally, before authentication, so a
 client can derive its backend from the connection it already has. `buildInfo` is
@@ -2468,7 +2175,7 @@ available to **every authenticated connection**, including a `readWrite`-only
 tenant user and an allocation read grant; it requires no `clusterMonitor` role
 and creates no session state. `buildInfo` answers from build metadata alone and
 therefore still answers on a fenced or closed runtime, while `hello` fails
-closed. It answers in MongoDB's shape so existing tooling keeps working:
+closed. It answers in a MongoDB-compatible shape so existing tooling keeps working:
 
 ```json
 {
@@ -2494,16 +2201,65 @@ reported, including `version` and `process: "rustdb"`, and now reports the same
 `nosqldb` identity beside them — but it remains a `clusterMonitor` command, so
 least-privilege connections use `hello` or `buildInfo`.
 
+`serverStatus.engineFigures` reports the storage engine's own figures, each
+read from a counter or from the allocator's own statistics, so forming them
+takes no time that grows with the data. Every count is an int64 that is 0 when
+the server opens its storage and never decreases while it runs. `commitMode` is
+`buffered`: commits go through the write buffer, the only commit path.
+`bufferedBytes` is the bytes of committed writes that the buffer holds and no
+merge has yet written into the tree, the sum of `activeGenerationBytes` and
+`frozenGenerationBytes`; `commits` counts the publications made durable and
+visible, and `mergesStarted` and `mergesCompleted` the buffer's merges.
+`freezes` counts the buffer's generations frozen for a merge, by cause: `size`
+when the generation reached its size, `idle` when no commit arrived for the
+quiet period, `age` when its oldest commit reached the age limit, and `prune`
+when records that history pruning wrote waited for a merge. `backstopStall`
+counts the commits that waited at the buffer's backstop (`stalls`) and the
+nanoseconds they waited (`stalledNanoseconds`), and gives the commits waiting
+there now (`stalledWriters`). A commit waits there when it would take the
+active generation past its size while a generation is pending, from its
+freeze until the checkpoint after its merge is durable, or while commits that
+passed the backstop before it and are not linked yet fill the active
+generation; and a background commit waits there at its claim on the buffer
+while another background commit holds one. `refusals` counts the
+requests for space that the engine refused for lack of free
+space, a commit's or the engine's own work's (`space`), and the
+commits refused after waiting at the backstop as long as their limit
+allows (`backstop`). While a merge cannot get room,
+`serverStatus.engineFigures.mergeWedge` reports what it lacks (`bytesShort` or
+`segmentsShort`), and is null again once a later attempt of the merge is
+admitted; `mergeRefusals` counts the merge attempts refused since the root
+opened. `restarts` counts the write preparations started again by cause,
+`catalogChange`, `pruningWindow` and `merge`; one for a conflict on a document
+or unique key counts under none. `bytesWritten` counts the bytes handed to the
+file system for the storage files by duty: `redo`, `merge`, `cleaner`,
+`indexes`, `checkpoint`, `directory` and `fill`. `liveBytes` is the bytes the
+current state reaches and `fixedBytes` the bytes the engine's files hold apart
+from data: the anchor, segment headers and pre-sized log space.
+`directoryBytes` and `cacheResidentBytes` are the memory that the directory of
+stored frames and the node cache hold, and `cacheBudgetBytes` is the cache
+budget that `storageEngine.cacheBytes` reports.
+`serverStatus.engineFigures.pinnedBytes` is the bytes in the storage's data
+segments that the engine keeps, where it would otherwise free them, only
+because a live snapshot, such as an open cursor's, can still read superseded
+data in them: the value its latest maintenance round found, and 0 when no
+snapshot keeps any. `allocator` states whether a
+check at run time found the shipped allocator (`verified`), and only then its
+arena count, its decay times in milliseconds, whether it runs background
+threads, and the bytes allocated through it and resident; while `verified` is
+false, those fields are null.
+
 ### Read and Write Concerns and Wire Deadlines
 
 NoSQLDB serves every database from exactly one voting node and states its
 concern profile in those terms instead of ignoring or blanket-rejecting the
 fields:
 
-- **Write concern.** Every acknowledged write is fsynced to the write-ahead log
-  and the data file before the response is sent, so `w: 1`, `w: "majority"`
+- **Write concern.** Every acknowledged write is in the write-ahead log before
+  the response is sent: fsynced there with file storage, while memory storage
+  keeps its log in the process's memory. So `w: 1`, `w: "majority"`
   (the majority of one voter is that voter), and `j: true` are all satisfied by
-  the same durable commit. `w: 0` is acknowledged the same way whenever a
+  the same commit. `w: 0` is acknowledged the same way whenever a
   response is expected; the exact `writeConcern: { w: 0 }` `endSessions` and
   `killSessions` envelopes still run without a transport response. `wtimeout`
   bounds a replication wait that does not exist on one node and has no
@@ -2523,65 +2279,6 @@ fields:
   and `aggregate` only, and `afterClusterTime`, `atClusterTime`, and
   `afterOpTime` are rejected with `InvalidOptions` because a single node issues
   no cluster time.
-- **Deadlines.** `maxTimeMS` attaches a cooperative deadline to the command,
-  counted from when the server had the whole request, or from when the
-  connection's previous command finished for a request sent while it ran. It
-  is checked while the request waits for decode memory, at admission, during
-  namespace-lock and maintenance-gate waits, before `find`, `count`, and
-  `distinct` materialize documents, between
-  documents in `insert` and `delete` batches, and immediately before a
-  transaction commit is handed to storage; expiry fails with `MaxTimeMSExpired`
-  (code 50). A single storage step or an in-progress `update` batch runs to completion
-  before the next check, so a write that expires after its first documents
-  were published reports the expiry while those documents remain durable,
-  exactly like an interrupted MongoDB batch. The official driver transmits a
-  transaction's `maxCommitTimeMS` as `maxTimeMS` on `commitTransaction`; a
-  commit that expires before its batch is handed to storage publishes nothing,
-  records the transaction as aborted, and carries the
-  `UnknownTransactionCommitResult` label; the driver's commit retry then sees
-  `NoSuchTransaction` with `TransientTransactionError` and restarts the whole
-  transaction. `getMore` rejects `maxTimeMS` with `BadValue` because NoSQLDB
-  has no awaitData cursors, and a literal `maxCommitTimeMS` field is rejected
-  with `InvalidOptions`.
-- **Database waits.** DDL that drops or reshapes collections (`drop`,
-  `dropIndexes`, `collMod`, `dropDatabase`, `renameCollection`,
-  `$out`/`$merge`) holds its database exclusively; other commands on that
-  database wait for it, as they wait for a MongoDB database lock. Creating a
-  collection or its indexes (`create`, `createIndexes`) holds only that
-  collection exclusively, as MongoDB locks the collection: it waits for the
-  open transactions whose statements targeted that collection (a collection
-  a transaction reads only through `$lookup` or `$unionWith` is not held; the
-  transaction reads its snapshot of it), transaction statements on that
-  collection that arrive after it queue behind it, and everything else
-  proceeds. Commands outside a transaction take no collection
-  gate; writes still queue for the storage writer, which an index build holds
-  until its index is ready. A command outside a
-  transaction waits first in, first out for as long as it may run: until
-  `maxTimeMS` (`MaxTimeMSExpired`, code 50), until its client disconnects or
-  shuts down its sending side (the wait ends with `ClientDisconnect`, code
-  279, which a client that still reads receives before the connection closes)
-  or until the server shuts down (`InterruptedAtShutdown`, code 11600). A
-  database DDL command likewise waits for the open transactions on its
-  database to commit or abort, and every command on that database that
-  arrives after it queues behind it, including reads of other collections. An
-  open transaction therefore delays DDL and the commands behind it at most
-  until the transaction lifetime limit (60 seconds, MongoDB's
-  `transactionLifetimeLimitSeconds`) aborts it.
-  A transaction statement that needs a further database or collection keeps a
-  fixed five-second limit and then fails with `LockTimeout` (code 24, labelled
-  `TransientTransactionError`), so a transaction never waits without bound while it
-  holds its databases and collections; like any failed statement, it aborts
-  the transaction and releases them. One transaction targets at most 4,096
-  distinct collections across all its databases; statements that revisit a
-  collection retain no extra gate. This matches the process-wide collection-lock
-  registry's 4,096-live-identity bound; concurrent transactions and collection
-  DDL share that registry. A command that finds the shared registry full fails
-  with `LockTimeout` (code 24; labelled `TransientTransactionError` in a
-  transaction) and can be retried once in-flight operations complete. It bounds process-local locks, not document staging,
-  WAL record size or atomic publication. A statement targeting one more fails
-  with code 16500 (`Location16500`, MongoDB 8's code name for it) and aborts it. The service operations (export,
-  import, tenant and publication fencing) keep the five-second gate-wait limit and report
-  `EFENCE_BUSY`.
 
 Callers may therefore rely on a successful NoSQLDB response as a durable,
 single-node acknowledgement. They must not read it as a replica-backed
@@ -2615,7 +2312,7 @@ The Rust engine is organized as a Cargo workspace with 12 focused crates:
 | `rustdb-wire` | Wire protocol parser/encoder (OP_MSG, OP_QUERY, OP_REPLY) |
 | `rustdb-query` | Query matcher, update engine, aggregation, sort, projection |
 | `rustdb-state` | Internal deterministic storage commands, stable retry identities, and durable receipts |
-| `rustdb-kernel` | Native paged committed-log kernel with stable timelines, contiguous LSNs, strict recovery and exact receipt replay |
+| `rustdb-kernel` | Native storage format 3: a log of commits, a write buffer merged into a tree, checkpoints and a cleaner, with stable timelines, contiguous LSNs and strict recovery; and the format-2 reader of 10.x roots |
 | `rustdb-replication` | Internal non-serving OpenRaft 0.9.25 one-voter fresh-root foundation; not linked into the released `rustdb` server |
 | `rustdb-storage` | Native catalogs, documents, exact counts, staged imports, reclamation and bounded OpLog |
 | `rustdb-index` | Native index records, query plans, uniqueness, bounded builds and TTL |
@@ -2626,57 +2323,35 @@ The Rust engine is organized as a Cargo workspace with 12 focused crates:
 
 The native MVCC engine serves both memory and file storage.
 Its Rust APIs use `mvcc` modules and `Mvcc` type names independently of npm
-versions and persisted format versions. The K2 kernel stores immutable paged
-roots, typed BSON records and checksummed commit markers in one append stream.
-Snapshots pin roots; normal writes append changed pages. Descriptor-relative
+versions and persisted format versions. The format-3 store writes each
+publication as one checksummed `COMMIT` frame of typed BSON records to its
+log, keeps recent writes in an in-memory buffer, merges them into a
+copy-on-write tree in data segments and writes checkpoints from which
+recovery replays the log. Snapshots pin a published view, and maintenance
+frees nothing a pinned snapshot can reach. Descriptor-relative
 access and the enclosing native file-root lease protect the entire lifecycle.
 Ambiguous publication fences the owner until recovery. Confirmed close drains
 requests, sessions, cursors and retained workers before releasing ownership.
 
-The bounded page cache retains validated key prefixes for point lookups when
-large separators cannot fit as complete nodes. Prefix coverage grows with the
-probe length and preserves exact ordering; scans and writes use complete keys.
-This keeps unrelated small-key operations from repeatedly loading wide index
-separators without increasing the cache budget or changing the stored format.
-A collection scan looks up the backpointers and documents of each page's rows
-in one ordered pass over the tree and reads their values in file order. Scans
-and range pages read adjacent values together, up to 64 KiB per system call,
-and still verify each value on its own.
-
-Verified record values have their own bounded cache, 4 MiB by default, so value
-churn never evicts tree pages. A point read admits a value of up to 64 KiB, or
-an eighth of the cache if that is smaller. A range read admits like a point
-read only when it returns a single record and exhausts its range, such as an
-exact unique-index probe; other range reads admit nothing. A query or
-transaction read whose whole index selection is one entry caches its document
-like a point find. The other per-record reads of a selection or pass use
-cached values but admit none: the documents of collection and index scans, the
-identities of covered `_id` scans, the index entries a multi-value `$in`
-probes, and the reads of validation, stopped
-inspection, TTL and authentication passes, including their single-record
-probes. A user listing and a write's own probes of unique owners, index
-entries and natural-order records admit nothing either. A scan, maintenance
-pass or listing therefore cannot flush hot catalog records and documents.
-A commit forgets the cached value of every record it replaces or deletes, so
-a write, however many documents it changes, leaves behind at most what its
-query would have cached as a find. Frames are immutable and append-only, and a
-snapshot reaches only the frames its own tree references: an older snapshot
-that still needs a forgotten value reads it from storage again, and a new
-version is cached once a read looks it up. As with tree pages, a value is
-verified once when it is cached;
-storage corruption of a cached frame is detected after eviction or generation
-retirement.
-
-Both caches evict by CLOCK. Each cached node and value carries a referenced
-bit. Every read sets it on the inner tree nodes it passes through, since each
-lookup beneath such a node passes through it again. On leaves and values, point
-lookups, the range reads of point queries and value admission set it; scans,
-maintenance passes, generation copies and a commit's own reads leave it as they
-find it, and the leaves and values they cache start without it. To make room, a
-hand sweeps the entries in turn, clears each set bit it passes and evicts the
-first entry whose bit is clear. A leaf or value that point reads use therefore
-outlasts the scan entries cached after it by one turn of the hand, and a cache
-hit costs no reordering.
+The store keeps verified tree nodes in one node cache, half of its memory
+budget, evicted by CLOCK. The budget is `storageBudgetBytes` where that option
+of `NoSqlDbServer` is set, from 4 MiB to 1 TiB, and otherwise a sixteenth of
+the memory the process may use, measured as for the inbound budgets above, from
+16 MiB to 4 GiB; `serverStatus.storageEngine.cacheBytes` reports the cache's
+half. A root the server serves takes it when it is created or opened and keeps it
+until it closes; the stopped operations' reads of a stopped root, a start's
+checks of a root before it serves it and a 10.x conversion open the store
+with 64 MiB. Each cached node carries a referenced bit:
+inner nodes enter with it set and leaves without it, and a point read sets it
+on the nodes it uses. To make room, a hand sweeps the entries in turn, clears
+each set bit it passes and evicts the first entry whose bit is clear. A read
+that is one row of a pass over many records, such as a scan, a merge or a page
+of the commit journal, clears no bit and is cached only in place of an
+unreferenced entry at the hand, so such reads cannot displace the nodes point
+reads keep. A publication removes the nodes it supersedes from the cache.
+There is no value cache: a value stored outside its leaf is read from storage
+each time. A collection scan reads each page of documents as one range read of
+their bodies in natural order, with no lookup per document.
 
 Database and collection lookups, absent names included, are remembered for the
 newest committed root a read has used, up to 256 names and 1 MiB, so the
@@ -2690,7 +2365,7 @@ one root list its indexes once. The first listing on a root reads the catalog
 whole; a catalog of more than 64 indexes, aliases included, and a listing that
 fails are not kept.
 
-Document, catalog, exact-count, natural-order, index-entry, unique-owner,
+Document, catalog, statistics, natural-order, index-entry, unique-owner,
 authentication, fencing and retry-receipt records share atomic publications.
 Transactions retain changed documents and immutable read views with byte and
 concurrency admission; they do not copy a complete database snapshot or impose a
@@ -2701,15 +2376,25 @@ generated IDs and zero-match outcomes, across restart. Failed statements do not
 receive success receipts. Session termination drains active work and retires its
 cursors.
 
-Custom indexes build in bounded batches under a writer reservation and become
-Ready together. Startup resumes interrupted builds under native ownership before
-serving. If a resumed build confirms duplicate keys or exceeds its work budget,
-its Building state remains intact and a secret-free warning identifies the need
-for explicit index repair. Reads avoid that index; indexed writes fail closed.
-Use the supported index drop/recreate operation to resolve it. Cancellation,
-corruption and uncertain publication fail startup. Held databases remain closed
-and are skipped during recovery; releasing a hold does not run extra mutations.
-Their interrupted indexes can recover on a later restart.
+Custom indexes build in the background: `createIndexes` publishes them as
+building in one short commit and answers once they are ready, while other writes
+go on. A build sorts its entries off the writer, after reserving the space its
+sort runs and its output need, with its runs in a private scratch directory
+inside a file root and in memory on a memory root, and attaches the entries in
+one commit; it then applies the writes made meanwhile until the writers keep
+its indexes up to date in their own commits, and makes its indexes ready
+together in a commit that carries no entry. No read uses its indexes
+before then. A request for the same indexes joins a running build, and
+`serverStatus` reports builds under `indexBuilds`. A build that its collection's
+writes outpace, or that meets a resource limit, fails with an explicit refusal
+and leaves no index; a duplicate key fails a unique build with `DuplicateKey`
+(11000). Interrupted builds restart from the beginning under native ownership
+before serving, and run in the background, so serving does not wait for them.
+A restarted build that fails removes its indexes, restores a quarantined index
+it was rebuilding, logs a warning that names neither the index nor a key, and
+shows as failed in `indexBuilds` until the next build of that index; it is not
+retried by itself. Held databases remain closed and are skipped during
+recovery; releasing the hold restarts their interrupted builds.
 
 Index names and aliases, sparse and unique constraints, empty collections,
 restricted-view catalogs and exact BSON survive supported database export/import.
@@ -2728,7 +2413,7 @@ The serving profile is:
 | Auth/sessions | SCRAM-SHA-256, logical sessions, snapshot transactions, commit/abort and durable retryable writes |
 | Management | Health, tenants, grants, attestation, fencing, publication holds, export/import and content digest |
 | Debug | Bounded current-session OpLog, atomic data revert, document/collection pages and dashboard |
-| Maintenance | Bounded TTL expiry, retired record reclamation, orphan import retirement and generation compaction |
+| Maintenance | Bounded TTL expiry, retired record reclamation, orphan import retirement, and the store's merges, checkpoints, tombstone pruning and cleaning |
 | Stopped storage | Native inspection and relocation; isolated authenticated rehearsal on its qualified platform profile |
 | Import/control admission | 100 MiB encoded import; bounded private staging and a small final catalog/receipt commit. Other control requests: 1 MiB |
 | External cluster | Replication and HA remain unsupported; the one-voter OpenRaft foundation is not linked into serving |
@@ -2737,16 +2422,20 @@ These are operation and resource budgets, not total database/document limits.
 Unsupported options and commands reject explicitly. Imports that cannot fit one
 derived document or index entry within the native commit budget reject before
 publishing the replacement. Reclamation preserves pinned roots and retires parent
-identities only after their children have been handled. Automatic compaction
-requires at least 64 MiB of growth and 50% growth over its prior baseline.
+identities only after their children have been handled. The store's cleaner
+moves the live data out of a data segment of which at least a third of the
+written bytes is garbage, and a segment is removed once no checkpoint or
+pinned snapshot needs it.
 
-There is one serving engine and no Bitcask fallback. No historical storage or
-authentication conversion runs during startup or rehearsal. Conversion code,
-when explicitly commissioned, belongs exclusively in top-level `ts_migration/`.
+There is one serving engine and no Bitcask fallback. A start converts a root that
+a 10.x release wrote into format 3 (see **Storage format migration** under File
+startup admission); no other storage conversion and no authentication conversion
+runs during startup or rehearsal. Any other conversion code, when explicitly
+commissioned, belongs exclusively in top-level `ts_migration/`.
 
 NoSQLDB makes no general MongoDB performance or feature-parity claim.
 Versioned packages contain Linux amd64/arm64 and macOS amd64/arm64 native
-executables through [@git.zone/tsrust](https://www.npmjs.com/package/@git.zone/tsrust).
+executables through [@git.zone/rsrepo](https://www.npmjs.com/package/@git.zone/rsrepo).
 
 ### Multi-host release artifacts
 
@@ -2768,7 +2457,7 @@ The native distribution terms and qualified library requirements are recorded in
 extract and install these files independently of its compiled JavaScript bundle;
 NoSQLDB does not download engines at startup.
 
-A plain `tsrust` build, as run by `pnpm build` and before `pnpm test`, compiles only the configured targets of the host's own architecture (its GNU and musl engines on Linux); `tsrust --configured-targets` builds the host's complete partition from `targetsByHost`. The development suite checks the packaged engines of the host architecture. Releases use `tsrust matrix` to coordinate both partitions after the version commit exists, then publish only after native verification passes and every exact-commit binary has executed and passed strict provenance assembly.
+A plain `rsrepo` build, as run by `pnpm build` and before `pnpm test`, compiles only the configured targets of the host's own architecture (its GNU and musl engines on Linux); `rsrepo --configured-targets` builds the host's complete partition from `targetsByHost`. The development suite checks the packaged engines of the host architecture. Releases use `rsrepo matrix` to coordinate both partitions after the version commit exists, then publish only after native verification passes and every exact-commit binary has executed and passed strict provenance assembly.
 
 The release coordinator needs Git, Node.js, pnpm and SSH access to the configured macOS builder. The local Linux amd64 builder needs `aarch64-linux-gnu-gcc`, `x86_64-linux-musl-gcc` and `aarch64-linux-musl-gcc` and a registered Linux arm64 `binfmt` interpreter. Linux file storage requires kernel 5.6 or newer with `openat2` enabled. Cross-architecture file qualification requires a full-system Linux guest or a native host. A linux-user executable probe does not qualify secure filesystem syscalls such as `openat2`. The built-package acceptance script `test/verify-alpine.mjs` exercises authenticated nested document persistence and restart through Node and Deno on Alpine; run it on both Linux architectures before publication. The Apple Silicon builder needs Rosetta. The matrix qualifies macOS first and then Linux; both partitions must pass before artifact assembly. Set these environment variables to authorized builders and their dedicated temporary roots:
 
@@ -2777,11 +2466,11 @@ export NOSQLDB_RELEASE_MACOS_SSH="release-user@mac-builder.example"
 export NOSQLDB_RELEASE_MACOS_TEMP_ROOT="/absolute/dedicated/nosqldb-release"
 ```
 
-`gitzone release` first runs `pnpm run release:check-builders`, before creating a version commit or tag. It verifies the project-local tsrust version, compiles and executes the required architecture probes, and rejects missing cross-toolchains or emulation, an unsuitable macOS host, missing tools, or an unsafe remote temporary root. The release build then:
+`gitzone release` first runs `pnpm run release:check-builders`, before creating a version commit or tag. It verifies the project-local rsrepo version and rejects missing cross-toolchains or emulation, an unsuitable macOS host, missing tools, or an unsafe remote temporary root. The release build then:
 
 1. Builds the TypeScript package and debug UI bundle from the version commit.
 2. Transfers an exact Git bundle into isolated local Linux and SSH macOS worker workspaces and installs each frozen lockfile.
-3. Runs the configured `release:verify-native` command on each worker: the full Rust workspace, TypeScript test checks, a `tsrust --configured-targets` build of the worker's partition, the public API suite with the packaged-engine checks for both architectures, and explicit-engine authentication/ownership/rehearsal tests through the worker's other packaged architecture. Tests use short, private disposable filesystem roots under `/var/tmp` on Linux and canonical `/tmp` on macOS. Linux builders must provide `/var/tmp` on a native-supported durable filesystem; tmpfs is rejected. Failures retain diagnostics and prevent assembly.
+3. Runs the configured `release:verify-native` command on each worker: the full Rust workspace, TypeScript test checks, a `rsrepo --configured-targets` build of the worker's partition, the public API suite with the packaged-engine checks for both architectures, and explicit-engine authentication/ownership/rehearsal tests through the worker's other packaged architecture. Tests use short, private disposable filesystem roots under `/var/tmp` on Linux and canonical `/tmp` on macOS. Linux builders must provide `/var/tmp` on a native-supported durable filesystem; tmpfs is rejected. Failures retain diagnostics and prevent assembly.
 4. Builds and executes GNU and musl Linux amd64/arm64 plus macOS arm64/amd64 binaries on their assigned workers.
 5. Retrieves bounded artifact sets and transactionally publishes the complete provenance-checked matrix into `dist_rust/`.
 
@@ -2793,13 +2482,38 @@ No host address or path is stored in the repository. A failed run retains its un
 
 - Atomic native publications include data, indexes, authentication, fences and
   durable outcomes. File writes are acknowledged after durable commit.
-- Immutable roots keep reads stable through concurrent writes and compaction.
+- Snapshots keep reads stable through concurrent writes and maintenance:
+  merges, checkpoints and the cleaner free nothing a snapshot can reach.
 - Checksums, frame identities and contiguous positions validate committed
   history. Only a valid incomplete final append is repairable during owned
   startup; complete or interior corruption is rejected.
+- A device that loses acknowledged bytes at the end of the log and reads
+  them back as zeros cannot be detected: recovery takes the zeros for the end
+  of the log. The loss reaches back at most to the newest durable
+  checkpoint's redo start. The commits it can lose hold at most half the
+  buffer budget plus two holds, counted as their keys and values plus 64
+  bytes per record: one hold of commits, which is one commit or one group
+  or batch of commits, and one background commit's claim on the buffer.
+  The server sets the budget when it opens a root, to
+  `storageBudgetBytes` where that option is set (4 MiB to 1 TiB), and
+  otherwise to a sixteenth of the memory the process may use, from 16 MiB to
+  4 GiB: 64 MiB plus the two holds can be lost in a 2 GiB container, and at
+  most 2 GiB plus the two holds unless the option sets a larger budget.
+  Each hold is at most the batch limit, 64 MiB by default.
 - Uncertain publication fences the engine until confirmed recovery.
-- Bounded maintenance reclaims unreachable records and obsolete generations
-  after their readers release them.
+- Bounded maintenance reclaims unreachable records, and segments that hold
+  only superseded data, after their readers release them.
+- Disk use under live snapshots is unbounded: the store does not limit how
+  long a snapshot stays open. A segment whose data has all been superseded
+  stays on disk while a snapshot that can still read it is open, and
+  `serverStatus` reports those bytes at
+  `serverStatus.engineFigures.pinnedBytes`.
+- Writes are admitted at full speed until the free space falls to the
+  store's floor: 64 MiB or two segments, whichever is more, beyond what the
+  write buffer holds. There, every write but a delete or a drop is refused
+  with the capacity code 16500 and writes nothing. Deletes and drops are
+  still admitted, down to two segments, while no snapshot older than the
+  newest write is open.
 - A durable session whose records this version cannot read does not stop
   maintenance. The obsolete-outcome sweep passes over it and leaves its records
   in place. It logs an error at most once a minute and counts the session in
@@ -2823,22 +2537,48 @@ deadline, 100,000 filesystem-entry and 1 TiB byte limits, and bounded native
 record/result admission. This is storage integrity evidence; it does not replace
 the full authenticated rehearsal or production ownership protocol.
 
+A failure names a stable code (`NoSQLDB stopped inspection failed with code …`).
+Two codes describe states the tool deliberately does not validate:
+
+- `RECOVERY_REQUIRED` while a stopped relocation or alignment has left its
+  workspace in the root: finish that relocation or alignment, or abort the
+  alignment, with its exact request, then validate again. A root of this
+  release that a crash left needs no start first: the tool reads it as a start
+  would recover it, writing nothing. A root that a 10.x process left without a
+  clean stop also reports `RECOVERY_REQUIRED`; a start of this release converts
+  it as of its last completed commit.
+- `UNSUPPORTED` while an index build is unfinished: an index that is building,
+  quarantined, or importing into a collection that is not dropped. A start
+  restarts interrupted builds from the beginning in the background, without
+  waiting for them before it serves, so a root stopped before they publish
+  still reports `UNSUPPORTED`, as does one whose database's publication hold
+  keeps them back. A restarted build that fails, for example on duplicate
+  keys, removes its indexes or restores the quarantined index it was
+  rebuilding, which validation reports until that index is dropped or rebuilt.
+
 ---
 
 ## Testing Example
 
-The offline regression `test/test.commit-journal-compatibility.node.ts` creates
-disposable roots with the exact published 10.8.1 executable, then qualifies the
-current engine against them. A normal `pnpm install --frozen-lockfile` provides
-the exact `@lossless.org/nosqldb@10.8.1` package through the pinned development
-alias `@lossless.org/nosqldb-baseline-1081`, with registry integrity in the lockfile.
-The test reads its platform executable directly from `node_modules`, with no
-manual artifact cache or environment variable. It also pins each supported
-executable's published SHA-256
-and fails on missing or substituted artifacts; it never fetches, skips, builds
-the baseline, or changes dependency manifests at runtime. Build the current
-engine normally before running the test. This qualifies opening existing data
-without rewriting its native format, followed by durable journal publications.
+The offline regression `test/test.commit-journal-compatibility.node.ts` reads
+`test/format-2/compatibility.tar`, a root that the published 10.8.1 release
+wrote once from the definition in `test/format-2/roots.ts`
+(`test/format-2/archives.md` records how). It checks every archive in
+`test/format-2/` against `SHA256SUMS`, and each of its tests that reads the root extracts that
+archive into a new directory that only its owner can access, so the root it
+reads is a copy. It qualifies that
+the stopped audit and the namespace and string inspections read the 10.x copy
+without changing a byte: the audit finds it foreign and ineligible, with
+`CONVERSION_PENDING`, `AUTH_USERS_PRESENT` and the definition's two users, and
+the inspections give the definition's databases, collections and values. An
+`existing-only` start converts the copy, leaving only this release's names, and
+is refused because a copied root is served only after alignment; a second start
+is refused the same way and changes nothing. The converted root keeps the 10.x
+root's provider, group, timeline and LSN, its two users and its databases,
+collections and values, and alignment refuses it with `UNSUPPORTED`, as a dry
+run and for real, because it holds auth users; it writes no receipt and
+changes nothing. The test starts only this release's engine; build it normally
+before running the test.
 
 The commit-journal lifetime regression uses the existing test-support executable
 and its three-second `NOSQLDB_TEST_TRANSACTION_LIFETIME_MS` setting. It compares
@@ -2848,7 +2588,7 @@ qualification executable through `test:before`; production keeps its unchanged
 60-second transaction lifetime and the suite keeps its 60-second file timeout.
 
 ```typescript
-import { expect, tap } from '@git.zone/tstest/tapbundle';
+import { expect, tap } from '@git.zone/tsrepo/tapbundle';
 import { NoSqlDbServer } from '@lossless.org/nosqldb';
 import { MongoClient } from 'mongodb';