delete old docs

5 files changed, 0 insertions, 1263 deletions

diff --git a/docs/join-strategies.md b/docs/join-strategies.md
deleted file mode 100644
index 049aad7..0000000
--- a/docs/join-strategies.md
+++ /dev/null
@@ -1,305 +0,0 @@
-# Join Strategies in the Tarski FOL Runtime
-
-This document covers the join operators available or planned for the Tarski
-Volcano engine, their memory and I/O characteristics, and the role that backend
-indexes play in making large-relation joins practical.
-
----
-
-## Current implementation: nested-loop join
-
-The current `JOIN` node is a classic nested-loop join.
-
-```
-for each outer (left) tuple L:
-    reset inner (right) cursor to offset 0
-    for each inner tuple R:
-        if join condition holds: emit merge(L, R)
-```
-
-**Memory**: O(1). The left cursor holds one page (one tuple at `PAGE_SIZE = 1`).
-The right cursor also holds one page at a time; `ResetInner` clears the page and
-resets `fetch_offset` to 0 so the backend re-reads from the start for each outer
-tuple. Neither side is ever materialized in full.
-
-**I/O**: O(n × m) backend reads. The right relation is scanned once per outer
-tuple, so a billion-row right side costs a billion backend reads per outer tuple.
-
-**Best case**: ephemeral relations (builtins like `eq`, `lt`, etc.) on the right
-side. These run the generator function in O(1) with no backend I/O. The join
-degenerates into a streamed filter.
-
-**Worst case**: two large stored relations with no index. Acceptable only when
-one side is small, or when the right side fits in the OS page cache.
-
----
-
-## Index nested-loop join
-
-The most practical improvement. If Sakura exposes a B+ tree index on the join
-attribute of the right relation, the inner loop becomes a point lookup instead
-of a full scan.
-
-```
-for each outer tuple L:
-    key = L[join_attr]
-    R = backend.Lookup(right_relation, join_attr, key)   // O(log m)
-    if R exists: emit merge(L, R)
-```
-
-**Memory**: O(1). Same as nested-loop — no buffering on either side.
-
-**I/O**: O(n log m). Each outer tuple triggers one B+ tree traversal on the right.
-
-**Backend requirement**: `IStorageBackend` would need a new method:
-
-```cpp
-virtual std::vector<std::string> TupleHashesByKey(
-    const std::vector<std::string>& relation_path,
-    const std::string& attribute,
-    const std::string& value,
-    std::size_t offset,
-    std::size_t limit) = 0;
-```
-
-Sakura already maintains a per-relation B+ tree of tuple hashes. An additional
-B+ tree keyed by attribute value is the natural extension and mirrors how most
-production storage engines implement secondary indexes.
-
-This is the correct long-term default join strategy for stored × stored joins.
-
----
-
-## Sort-merge join
-
-Both inputs are scanned once in sorted order, advancing a cursor on each side
-in lock-step.
-
-```
-L = Next(left)
-R = Next(right)
-while L and R:
-    if L[key] == R[key]: emit merge(L, R); advance both
-    if L[key] <  R[key]: L = Next(left)
-    if L[key] >  R[key]: R = Next(right)
-```
-
-**Memory**: O(1) if both inputs arrive pre-sorted. The Volcano model handles
-page boundaries transparently — each `Next()` call fetches the next page from
-the backend when the current page is exhausted, independent of the other cursor.
-There is no synchronization problem at the page level; the operator logic only
-ever holds two tuples at a time.
-
-**I/O**: O(n + m). Each relation is scanned exactly once.
-
-**Requirement**: both inputs must be sorted on the join attribute before the
-merge step. This means either:
-- The backend returns tuples in sorted attribute order (sorted scan support), or
-- A `SORT` operator precedes each input in the plan tree.
-
-Sorting an unsorted relation requires O(n log n) time and — unless done via an
-external merge sort that stays within a fixed memory budget — O(n) memory.
-Sakura's B+ tree already imposes an ordering on stored tuple hashes; whether
-that ordering corresponds to an attribute value ordering depends on the index
-structure.
-
----
-
-## Hash join
-
-Build a hash table from the smaller relation, probe with the larger.
-
-```
-phase 1 — build:  for each R: insert R into hash_table[R[key]]
-phase 2 — probe:  for each L: for each match in hash_table[L[key]]: emit merge(L, R)
-```
-
-**Memory**: O(min(n, m)). The build side must fit entirely in memory. Fails
-under memory pressure for large relations.
-
-**I/O**: O(n + m) — each relation scanned once.
-
-This is the right choice when the build side is small and fits in RAM. Not
-suitable as a general-purpose operator in a constant-memory runtime.
-
----
-
-## Grace hash join (partitioned hash join)
-
-An extension of hash join that handles larger-than-memory relations by
-partitioning both sides into buckets that individually fit in memory.
-
-```
-phase 1 — partition: hash each side into k buckets written to temporary storage
-phase 2 — join:      for each bucket pair (left_i, right_i): in-memory hash join
-```
-
-**Memory**: O(√(n + m)) with optimal bucket count. Bounded but not O(1).
-
-**I/O**: O(3(n + m)) — three full passes over the data.
-
-Requires a writable temporary storage area (spill buffer). Relevant only if
-memory pressure prevents a standard hash join and sort-merge is not available.
-Not planned for the near term.
-
----
-
-## Symmetric hash join
-
-Builds hash tables for both sides simultaneously as tuples arrive from either
-input. Suitable for streaming or pipelined inputs where one side may block
-before producing all its tuples.
-
-**Memory**: O(n + m) in the worst case — both hash tables may grow to full size.
-
-Not planned. Mentioned because Sakura streams tuples lazily; if the OCaml side
-ever introduces back-pressure on one relation while the other produces freely,
-symmetric hashing becomes relevant.
-
----
-
-## LeapFrog TrieJoin
-
-LeapFrog TrieJoin (Veldhuizen, 2012) is the state of the art for multi-way
-joins in logic programming and Datalog engines. It is **worst-case optimal**:
-it runs in time proportional to the AGM bound — the tight theoretical upper
-bound on the output size of a conjunctive query given the sizes of its input
-relations. Traditional pairwise binary joins applied sequentially can produce
-intermediate results that exceed this bound, making them suboptimal for cyclic
-or highly connected queries.
-
-### How it works
-
-Rather than joining two relations at a time, LeapFrog TrieJoin joins all
-relations in a query **simultaneously**. Each relation is represented as a
-trie — a sorted, prefix-keyed index over its attribute values. One cursor per
-relation is maintained, all pointing into their respective tries at the same
-attribute depth.
-
-The algorithm iterates over one shared variable at a time. At each step:
-
-1. Find the relation whose cursor currently points to the **maximum** value
-   among all cursors.
-2. **Seek** all other cursors forward to that maximum (or the next value ≥ it).
-3. If all cursors agree on the same value: emit the binding and descend to the
-   next variable.
-4. If a cursor cannot find a value ≥ the maximum: backtrack and advance the
-   previous variable.
-
-The seek operation is what makes this efficient. Instead of scanning linearly
-through values that cannot match, a cursor jumps directly to the next candidate
-using the sorted order of the trie. No intermediate results are materialized.
-
-**Memory**: O(k) where k is the number of relations — one cursor per relation,
-plus one tuple per active binding level. Constant with respect to relation size.
-
-**I/O**: O(n^τ\*) where τ\* is the fractional edge cover of the query
-hypergraph. For acyclic joins this matches the Yannakakis bound; for cyclic
-joins it beats any binary join plan.
-
-### Why this fits the Tarski/Karuta model
-
-Karuta is WAM-based. The WAM already operates on term tries during unification,
-advancing through sorted clause indexes when resolving goals. LeapFrog TrieJoin
-is the relational analogue: the trie structure and the seek-based iteration
-pattern are the same. When Sakura emits a plan to Tarski, the multi-way join
-over several relations maps directly onto a LeapFrog node whose cursors are
-driven by the same pull model as every other Volcano operator.
-
-### Current state of Sakura
-
-Reading `lib/algebra.ml`, the current join implementation materializes the
-entire right-hand relation into memory before beginning the left-hand scan:
-
-```ocaml
-let right_tuples = drain right_gen in   (* ← full materialization *)
-List.filter_map (fun rt -> ...) right_tuples   (* ← linear scan per left tuple *)
-```
-
-This is a documented TODO in the codebase. Beyond the memory cost, it is a
-strictly binary join — three or more relations require multiple sequential
-passes with growing intermediate materialization.
-
-The generator type (`int option -> result`) is forward-only and position-counted.
-It has no seek primitive: you cannot ask a generator to jump to the next value
-≥ a target without scanning every value in between.
-
-Sakura does have a B+ tree binding (`lib/bplustree.ml`, FFI to a C library) but
-it is currently wired only to the KV storage layer for tuple hash persistence,
-not to any per-attribute ordered index.
-
-### What would need to change in Sakura
-
-**1. Per-attribute sorted indexes**
-
-Each stored relation needs a secondary index mapping attribute values to tuple
-hashes, maintained in sorted order. The existing B+ tree binding is the natural
-substrate for this — it already supports ordered key storage and would expose
-range traversal and seek as cursor operations.
-
-The index structure per relation would be:
-
-```
-relation_path / attribute_name → B+ tree of (value, tuple_hash_set)
-```
-
-**2. A seek-capable cursor type**
-
-The generator type needs to be extended (or complemented) with a cursor
-abstraction that supports:
-
-- `current()` — the value at the current position
-- `seek(target)` — advance to the first value ≥ target; return whether one exists
-- `next()` — advance by one step
-
-A generator that only supports `next()` cannot implement LeapFrog without
-scanning every skipped value. The seek operation is the essential primitive.
-
-**3. A multi-way join operator in `algebra.ml`**
-
-The current `equijoin` function is binary. LeapFrog TrieJoin takes an arbitrary
-list of relations and a variable ordering. A new `leapfrog_join` function would
-replace the sequential application of `equijoin` for multi-relation conjunctive
-queries.
-
-### What would need to change in Tarski (this codebase)
-
-On the C++ side, the `CursorManager` would need a `Seek` operation alongside
-`Next`:
-
-```cpp
-/** Advances the cursor to the first tuple whose join-attribute value is ≥ target.
- *  Returns nullptr if no such tuple exists (relation exhausted). */
-Tuple* Seek(cursor* c, const std::string& attribute, const std::string& target);
-```
-
-The plan tree would gain a `LEAPFROG` node holding N child SCAN cursors and a
-variable ordering list. `VM::Next` on a `LEAPFROG` node drives the seek loop
-across all cursors rather than delegating to nested-loop iteration.
-
----
-
-## Summary
-
-| Strategy | Memory | I/O | Requires |
-|---|---|---|---|
-| Nested-loop (current) | O(1) | O(n × m) | Nothing |
-| Index nested-loop | O(1) | O(n log m) | Per-attribute B+ tree index |
-| Sort-merge | O(1)* | O(n + m) | Pre-sorted inputs |
-| Hash join | O(min(n,m)) | O(n + m) | Build side fits in RAM |
-| Grace hash join | O(√(n+m)) | O(3(n+m)) | Spill storage |
-| LeapFrog TrieJoin | O(k) | O(n^τ\*) | Seek-capable trie cursors |
-
-\* O(1) only if both inputs arrive sorted. Sorting in-place requires O(n) memory.
-
-The practical roadmap for this runtime:
-
-1. **Now**: nested-loop covers all ephemeral-relation joins in O(1) memory.
-2. **Next**: index nested-loop once Sakura exposes per-attribute B+ tree reads —
-   covers the large stored × stored binary join case without buffering.
-3. **Target**: LeapFrog TrieJoin once Sakura adds seek-capable cursors and
-   per-attribute sorted indexes. This replaces both index nested-loop and
-   sort-merge for multi-relation conjunctive queries and is the correct
-   long-term join primitive for a Datalog/WAM-oriented engine.
-4. **Only if needed**: hash join with an explicit memory budget, for ad-hoc
-   joins where no usable index exists.
diff --git a/docs/mainpage.dox b/docs/mainpage.dox
deleted file mode 100644
index 8cef183..0000000
--- a/docs/mainpage.dox
+++ /dev/null
@@ -1,90 +0,0 @@
-/**
- * @mainpage RNT
- *
- * @image html logo.png
- * <p><a href="https://www.gnu.org/licenses/agpl-3.0.html"><img src="https://www.gnu.org/graphics/agplv3-with-text-162x68.png" alt="GNU AGPLv3" /></a></p>
- *
- * RNT is an experimental database kernel inspired by the
- * object-management model of the Windows NT kernel. The project applies
- * explicit object management to database state: relations, tuples,
- * transactions, namespaces, permissions, cursors, and handles are
- * runtime-managed objects rather than isolated subsystems.
- *
- * @section motivation Motivation
- *
- * The NT kernel is a good model for a dedicated database kernel for three
- * reasons.
- *
- * **The object manager.** NT's OB gives every kernel resource a named path,
- * a security descriptor, and a uniform open/close lifecycle enforced through
- * handles. A database kernel has the same requirements. Rather than building
- * those mechanisms independently for each database concept, this project
- * borrows the NT object manager's shape directly.
- *
- * **Physical backends as drivers.** NT device drivers expose a narrow
- * dispatch table. The kernel routes I/O through it without knowing whether
- * the device is a local disk or a network adapter. Storage backends here
- * follow the same pattern. A remote backend like etcd is just another
- * driver, but brings its own concerns: network latency, connection
- * management, and the possibility of partial failure. The driver boundary
- * keeps those concerns inside the backend module.
- *
- * **Clients as environment subsystems.** NT supports Win32, POSIX, and OS/2
- * as environment subsystems layered above a common native API. A database
- * client works the same way: a PostgreSQL wire adapter, a MySQL wire
- * adapter, or an HTTP/JSON interface each translates its protocol into
- * kernel-level operations. The kernel never sees SQL syntax or protocol
- * framing.
- *
- * @section architecture Architecture
- *
- * - ObjectManager registers, locates, and references database objects by
- *   logical path.
- * - PermissionsManager keeps capability checks separate from object lookup.
- * - IdentityManager decides whether an object supports a requested lifecycle
- *   operation.
- * - LifecycleManager models monitoring, pinning, cleanup, and contention.
- * - HandlerManager orchestrates the full open/close workflow and owns handle
- *   allocation.
- * - CursorManager provides a pull-based iterator over storage, abstracting
- *   pagination, snapshot pinning, and scan boundaries.
- * - VM separates terminating first-order relational retrieval (Tarski) from
- *   higher-order logic execution (Karuta).
- * - NamespaceReferenceManager handles logical path mapping and namespace
- *   isolation, including private branch shadowing and atomic multi-reference
- *   updates.
- *
- * @section building Building
- *
- * Requires the Nix development shell on GNU/Linux. The flake provides GCC,
- * CMake, Ninja, SQLite, PicoSHA2 headers, Catch2, Doxygen, and Graphviz.
- *
- * @code{.sh}
- * nix develop
- * cmake --preset gnu-debug
- * cmake --build out/build/gnu-debug
- * @endcode
- *
- * A release build uses @c --preset @c gnu-release.
- *
- * @section docs Generating Documentation
- *
- * @code{.sh}
- * doxygen Doxyfile
- * @endcode
- *
- * Generated HTML is written to @c docs/generated/html.
- *
- * @section license License
- *
- * RNT is free software licensed under the GNU Affero General Public License
- * v3.0. See the repository @c LICENSE file for the full terms.
- *
- * Copyright (C) 2026 Marcos Magueta, RNT contributors, and Don't Rely on
- * Nulls. Maintainer: Marcos Magueta.
- */
-
-/**
- * @namespace nt
- * @brief Contains the Relational NT runtime managers and API facade.
- */
diff --git a/docs/nt-architecture-mapping.md b/docs/nt-architecture-mapping.md
deleted file mode 100644
index 3510f82..0000000
--- a/docs/nt-architecture-mapping.md
+++ /dev/null
@@ -1,489 +0,0 @@
-# NT Kernel Architecture — Holistic Mapping to a Database Kernel
-
-A full-system view of the ReactOS NT kernel (`ntoskrnl/`) mapped onto the
-architecture of a database kernel. The object manager comparison is covered
-separately in `reactos-ob-comparison.md`; this document covers the rest of the
-kernel and treats the project as a whole.
-
-The central thesis: **NT is already a database kernel in disguise**. It manages
-named, typed, reference-counted objects; enforces capability-based access control;
-schedules work across a pool of threads; routes requests through a layered
-dispatch stack; and maintains a write-buffered, lazily-flushed cache in front of
-physical storage. Every one of those responsibilities has a direct counterpart in
-a relational database engine.
-
----
-
-## Subsystem Map
-
-| NT subsystem | DB kernel counterpart |
-|---|---|
-| **KE** — kernel scheduler, IRQL, APC/DPC, synchronization primitives | Query scheduler, latch manager, deferred execution |
-| **PS** — process/thread lifecycle, job objects, quotas | Session manager, worker thread pool, resource groups |
-| **IO** — driver model, IRP dispatch stack, completion ports | Storage engine interface, query operator pipeline, async execution |
-| **MM** — virtual memory, page faults, working set, section objects | Buffer pool, page frame allocator, eviction policy |
-| **CC** — cache manager, lazy writer, VACB, prefetcher | WAL buffer / dirty page flusher, sequential prefetch |
-| **SE** — tokens, ACLs, DACL/SACL, privilege evaluation | User principal, role/privilege set, access control, audit |
-| **EX** — events, work queues, lookaside lists, rundown refs | Synchronization utilities, worker dispatch, buffer allocation |
-| **LPC** — port objects, request/reply messaging | Wire protocol layer, client connection, inter-session RPC |
-| **FSRTL** — fast I/O bypass, MCB extent map, file byte-range locks | Index hot-path, extent/page mapping, record-level locks |
-| **OB** — object manager | Object manager (covered in reactos-ob-comparison.md) |
-| **HAL** — CPU, interrupt, DMA, timer abstraction | Storage media abstraction, CPU/NUMA topology |
-| **KD** — kernel debugger transport | EXPLAIN / trace / diagnostic interface |
-| **CONFIG** — registry hive manager | System catalog, configuration store |
-
----
-
-## 1. Subsystems as Client Protocols
-
-NT supports multiple *environment subsystems*: Win32 and POSIX both run on top of
-the same kernel. Each subsystem is a user-mode personality layered above a common
-native API (`ntdll.dll`). The kernel itself has no awareness of Win32 or POSIX;
-it exposes only native NT objects (files, processes, events). The subsystem DLLs
-translate environment-specific calls into native system calls.
-
-```
-Win32 application            POSIX application
-      ↓                            ↓
-  kernel32.dll                  libc (POSIX layer)
-      ↓                            ↓
-         ntdll.dll (native NT API)
-                    ↓
-           ntoskrnl (kernel)
-```
-
-**Database analogue: wire protocols as subsystems.**
-
-The database kernel (RelationalNT) is the `ntoskrnl`. Each supported wire
-protocol — PostgreSQL, MySQL, HTTP/JSON — is an environment subsystem. A thin
-native client library is the `ntdll` equivalent: it translates wire-protocol
-messages into kernel-level handle opens, cursor operations, and VM plan
-evaluations. The kernel itself never sees SQL syntax or protocol framing.
-
-```
-psql client         MySQL client        HTTP client
-      ↓                  ↓                   ↓
-  PG wire adapter   MySQL wire adapter   REST adapter
-      ↓                  ↓                   ↓
-         native client library (ntdll equivalent)
-                         ↓
-              RelationalNT kernel
-```
-
-The subsystem boundary is where SQL parsing, result serialization, and
-protocol-specific error codes live. The kernel boundary is where object paths,
-handle allocation, cursor iteration, and capability checks live. Keeping these
-boundaries clean means a new wire protocol never touches the kernel; it only
-implements the native-to-protocol translation layer.
-
-`CSRSS` (the client-server runtime) is the service process that hosts
-session-specific subsystem state on the NT side. The DB equivalent is a per-
-protocol server daemon that owns wire connections and dispatches them to the
-native API.
-
----
-
-## 2. IO Manager → Query Operator Pipeline
-
-The NT I/O manager's driver stack model is the most directly applicable pattern
-for query execution.
-
-### NT Driver Stack
-
-```
-NtReadFile
-  ↓
-I/O Manager: allocates IRP, fills stack location [0]
-  ↓  IoCallDriver()
-Filesystem driver (NTFS):  interprets path, maps to block range
-  ↓  IoCallDriver()
-Disk class driver: translates logical → physical sectors
-  ↓  IoCallDriver()
-Disk port driver: issues SCSI/ATA commands
-  ↓  IoCallDriver()
-Miniport: hardware-specific DMA
-```
-
-Each driver layer processes its stack location and either completes the IRP
-inline (sync fast path) or pends it and calls the next driver. Completion fires
-back up through registered completion routines — bottom to top — until the
-original caller wakes.
-
-### Database Analogue: PlanNode as IRP
-
-The VM's `PlanNode` is an IRP. Each operator in the query plan is a driver layer
-with a dispatch routine (`Next()`). The Volcano pull model is completion-routine
-dispatch in reverse: instead of pushing results down-to-up on completion, the
-caller pulls up-to-down via `Next()`.
-
-```
-VM::Next(root_plan_node)
-  ↓  Next() dispatch
-JOIN operator:    requests rows from left and right children
-  ↓  Next()
-FILTER operator:  requests rows, discards those failing predicate
-  ↓  Next()
-PROJECT operator: strips unwanted attributes
-  ↓  Next()
-SCAN operator:    pulls raw tuples from CursorManager
-  ↓
-CursorManager::Next() → physical storage
-```
-
-NT's `IRP_STACK_LOCATION` (one per driver layer) maps to each `PlanNode` holding
-its own operator-local state (join buffer, filter expression, projection map).
-NT's `IRP_MJ_READ` / `IRP_MJ_WRITE` major function codes map to `Op::SCAN`,
-`Op::JOIN`, `Op::FILTER`, `Op::PROJECT`.
-
-**Filter drivers.** NT allows filter drivers to insert between any two layers
-without modifying either. The DB equivalent is transparent middleware: a
-compression or encryption operator inserted between SCAN and PROJECT without
-touching either. An audit operator inserted at the top of every plan without
-touching the plan itself.
-
-**Async IRP / completion ports.** NT issues an IRP and gets a completion
-notification later. For the DB, a query issued by a session does not block the
-session thread if the operator tree must wait on I/O. A completion-port analogue
-(a result queue per session) allows the session thread to yield and be notified
-when the cursor has rows ready. This is relevant when the physical storage backend
-is remote (etcd, S3) and latency is non-trivial.
-
----
-
-## 3. Drivers → Storage Backends
-
-A NT device driver is a self-contained module that satisfies read/write/control
-requests for a physical or logical device. The kernel does not know whether the
-device is a disk, a network socket, or a USB key; it only knows the driver
-dispatch table.
-
-`CursorManager` is the equivalent of the I/O manager's dispatch layer. The mock
-store (`unordered_map`) is the miniport. Replacing it with LMDB, RocksDB, etcd,
-or an in-memory append log is equivalent to swapping a miniport driver without
-changing the I/O manager or the filesystems above it.
-
-```
-CursorManager::Open / Next / Close
-         ↓
-Storage backend interface (the "driver dispatch table")
-         ↓
-   ┌─────────────┬──────────────┬─────────────┐
-   │ LMDB backend│ etcd backend │ memory backend│
-   └─────────────┴──────────────┴─────────────┘
-```
-
-The driver model implies that the storage backend interface should be stable and
-narrow: `Open(path, snapshot_id)`, `Next()`, `Close()`. All backend-specific
-concerns (transaction semantics, key encoding, compression) stay inside the
-backend module. `CursorManager` holds snapshot pinning and buffering logic that
-applies regardless of backend, exactly as the disk class driver holds caching
-logic regardless of whether the miniport is SATA or NVMe.
-
-**Filter driver analogue.** A replication backend can be a filter: it intercepts
-`Next()` calls after the underlying backend returns a row and ships a copy to a
-replica. A row-level encryption backend decrypts inline before returning to the
-caller. These compose without the operator pipeline or the caller knowing.
-
----
-
-## 4. MM → Buffer Pool
-
-NT's Memory Manager manages physical page frames and virtual address mappings. The
-three-tier hierarchy is:
-
-```
-Process working set (recently used pages, trimmed under pressure)
-         ↓
-Cache Manager VACBs (256 KB mapped views of files in kernel VA space)
-         ↓
-Physical storage (disk, via filesystem IRP)
-```
-
-Page faults are demand-load: a page is only brought from disk when first accessed.
-The working set trimmer evicts least-used pages under memory pressure. Section
-objects allow multiple processes to map the same physical pages (shared memory).
-
-**Database buffer pool.** The same three tiers apply:
-
-```
-Query working set (pages referenced by active cursors, pinned)
-         ↓
-Buffer pool frames (fixed-size pages cached in memory)
-         ↓
-Physical storage backend
-```
-
-The NT page fault handler (`MmNotPresentFault`) maps to a buffer pool miss:
-when a cursor requests a page not in the buffer pool, load it from the backend.
-The NT working set trimmer maps to LRU eviction: under memory pressure, unpin
-pages not referenced by any active cursor. NT section objects (shared physical
-pages across processes) map to shared buffer pool pages accessible from multiple
-sessions.
-
-Because this project uses immutable snapshot storage, the eviction policy is
-simplified: a page belonging to a snapshot pinned by at least one cursor
-(`reference_count > 0` on the snapshot registry entry) cannot be evicted. Pages
-belonging to snapshots with no remaining cursors are candidates for eviction
-regardless of recency. This is cleaner than NT's working-set model because there
-is no dirty-page complexity — writes always produce new pages, never mutate
-existing ones.
-
----
-
-## 5. CC → WAL and Dirty Page Flush
-
-NT's Cache Manager sits between the filesystem and MM. Its `VACB` (Virtual Address
-Control Block) is a 256 KB view of a file in kernel virtual address space. The
-lazy writer (`CcWorkerThread`) periodically scans `DirtyVacbListHead` and writes
-modified pages back to disk. The prefetcher traces access patterns and pre-loads
-pages before they are requested.
-
-**Database analogue: write-ahead log buffer and sequential prefetch.**
-
-Because storage is immutable here, the cache manager's dirty-write concern does
-not apply directly. New snapshot pages are always appended; they are never
-modifications of existing cached pages. However, the structural lessons hold:
-
-- **Append buffer.** New snapshot pages accumulate in an in-memory append buffer
-  before being flushed to the physical backend. The lazy writer pattern (flush
-  when the buffer exceeds a threshold, or periodically) applies directly.
-- **Read-ahead prefetch.** Sequential scans access pages in order. A prefetch
-  mechanism that issues backend reads ahead of the cursor's current position
-  reduces latency. NT's prefetcher learns per-scenario patterns; a database
-  prefetcher can use the query plan to predict access order exactly.
-- **VACBs as buffer frames.** Each VACB is a fixed-size view; the database
-  equivalent is a fixed-size buffer frame. Fixed-size frames simplify allocation
-  and eviction arithmetic.
-
----
-
-## 6. PS → Sessions and Worker Threads
-
-NT process = database session. NT thread = query worker thread.
-
-```
-PEPROCESS                    Session
-  ├─ Handle table              ├─ Handle table (open cursors, relations)
-  ├─ Token (identity)          ├─ Connection context (AUTH_CLAIM set)
-  ├─ Working set               ├─ Buffer pool pinned pages
-  ├─ Quota (memory, CPU, I/O)  ├─ Resource quota (memory, CPU, I/O)
-  └─ ThreadListHead            └─ Worker thread set
-
-PETHREAD                     Query worker
-  ├─ APC queue                 ├─ Deferred plan evaluation queue
-  ├─ IRP queue                 ├─ Pending cursor operations
-  └─ Impersonation context     └─ SECURITY DEFINER / SET ROLE context
-```
-
-NT job objects group processes with shared limits: NT's `NtAssignProcessToJobObject`
-enforces memory, CPU time, and I/O quotas across a group. The DB equivalent is a
-*resource group* or *tenant*: a set of sessions sharing a memory limit and a CPU
-share. Multi-tenant databases need this to prevent one tenant's runaway query from
-starving others. Job objects are the right model: assign sessions to resource
-groups at connection time and enforce limits at the job-object level rather than
-per-session.
-
-**Impersonation.** NT allows a thread to temporarily assume a different security
-context (`SeImpersonateClient`). The DB equivalent is `SET ROLE` or `SECURITY
-DEFINER` in stored procedures: the query worker temporarily adopts a different
-access context without requiring the connection to re-authenticate.
-
----
-
-## 7. SE → Authorization Beyond the Object Manager
-
-NT's security subsystem extends what the object manager does. Where OB attaches a
-security descriptor to an object and checks access at handle-open time, SE
-provides the richer infrastructure underneath:
-
-- **Token structure.** A token carries the caller's SID (identity), group
-  memberships, privilege set, and mandatory integrity level. The DB equivalent
-  is the connection context: user identity, granted AUTH_CLAIMs, session-level
-  role, and a trust level (e.g., a connection from localhost vs. from the public
-  internet might carry different trust).
-- **DACL / SACL split.** The DACL controls access; the SACL controls audit logging
-  (which accesses are recorded, on success or failure). For a database these are
-  different concerns: the permission check decides whether to allow the operation;
-  the audit policy decides whether to log it. Conflating them in a single
-  security descriptor is correct design; it keeps both concerns co-located with
-  the object rather than scattered.
-- **Privilege evaluation.** NT privileges (SE_BACKUP_PRIVILEGE bypasses ACLs;
-  SE_DEBUG_PRIVILEGE allows opening any process) have a DB analogue in superuser
-  privileges: a DBA role that bypasses row-level security, or a replication user
-  that bypasses normal write contention checks. These are orthogonal to the
-  capability tree and should be modelled as privileges on the connection token,
-  not as explicit capabilities on every object.
-- **Mandatory access control (integrity levels).** NT's integrity levels
-  (UNTRUSTED < LOW < MEDIUM < HIGH < SYSTEM) prevent low-integrity processes
-  from writing to high-integrity objects even if the DACL permits it. The DB
-  equivalent is a trust tier on connections: an externally-facing API connection
-  at LOW tier cannot write to audit or system catalog tables regardless of the
-  DACL, because those tables require HIGH tier.
-
----
-
-## 8. LPC → Wire Protocol and Inter-Session Messaging
-
-NT's Local Procedure Call provides synchronous request-reply messaging between
-processes via named port objects. A server process creates a named connection port;
-clients connect and receive private communication ports. This is the mechanism
-through which Win32 applications communicate with CSRSS (console, shutdown) and
-through which subsystem DLLs synchronize session state with the subsystem server.
-
-**Database analogue: wire protocol connection.**
-
-Each client connection to the database is an LPC communication port. The session
-server daemon listens on a named port (the TCP socket); accepted connections
-become private communication ports (per-client sessions). The session daemon is
-CSRSS.
-
-LPC's fixed message size limit (`LPCP_MAX_MESSAGE_SIZE`) prevents a misbehaving
-client from forcing unbounded allocation. The DB wire protocol layer should apply
-the same discipline: a maximum query length, a maximum result frame size, and a
-maximum number of concurrent open cursors per session.
-
-LPC ports are objects in the NT namespace. Database connection endpoints (the
-listening socket, or a named pipe for local connections) should similarly be
-registered as objects in the RelationalNT namespace, making them subject to the
-same capability checks: a client must have explicit permission to connect to a
-particular endpoint.
-
----
-
-## 9. FSRTL → Index Extent Management and Record Locks
-
-The File System Runtime Library is a set of utilities that filesystems use. The
-most relevant pieces for a database are:
-
-- **MCB (Map Control Block).** Tracks the logical-to-physical block mapping for a
-  file that may be stored in non-contiguous extents on disk. The DB equivalent is
-  an index page map: a B-tree or extent map translating a logical page number in
-  an index to a physical storage location. The MCB API (`FsRtlAddLargeMcbEntry`,
-  `FsRtlLookupLargeMcbEntry`) is a model for an extent manager that handles
-  fragmentation without surfacing it to callers.
-- **Fast I/O bypass.** `FAST_IO_DISPATCH` provides function pointers for
-  synchronous I/O that skip IRP allocation entirely when the requested data is
-  already in the cache. The DB equivalent is a buffer pool hot-path: if the
-  requested snapshot page is already pinned in the buffer pool, return it without
-  going through the full CursorManager dispatch chain.
-- **Byte-range file locking.** `FILE_LOCK` tracks exclusive/shared locks on
-  sub-file ranges. The DB equivalent is record-level locking within a relation.
-  Since storage here is immutable, this concern is narrowed to locking mutable
-  references (branch HEADs) rather than individual records — but the MCB-style
-  range-tracking structure is still the right data structure for knowing which
-  parts of a namespace are currently locked by which writers.
-
----
-
-## 10. HAL → Storage Media Abstraction
-
-The Hardware Abstraction Layer isolates the kernel from CPU, interrupt controller,
-and timer differences between x86 and ARM machines. It provides a stable set of
-primitives (`HalAllocateAdapterChannel`, `HalReadDmaCounter`, `KeAcquireSpinLock`)
-that the rest of the kernel calls without knowing the underlying hardware.
-
-**Database analogue: storage media and topology abstraction.**
-
-The equivalent boundary sits between `CursorManager` (the "kernel") and the
-physical storage backend (the "hardware"). The HAL lessons:
-
-- **Platform-neutral primitives.** `CursorManager::Next()` and `Close()` should
-  never contain NVMe-specific or LMDB-specific code. Those specifics live in the
-  backend module, exactly as NVMe DMA specifics live in the miniport, not the HAL.
-- **CPU/NUMA topology.** HAL exposes processor and memory node topology so the
-  scheduler can make NUMA-aware placement decisions. A database on a NUMA machine
-  benefits from binding buffer pool regions and worker threads to the same NUMA
-  node. This is a future concern but the right interface is at the HAL boundary:
-  a `platform_topology` structure that the scheduler queries without knowing
-  whether it is running on x86, ARM, or a cloud VM.
-- **Timer abstraction.** HAL provides a system tick and a high-resolution
-  performance counter. The DB needs both: a coarse timer for transaction
-  timestamps and TTL-based expiry, and a high-resolution counter for query
-  latency measurement.
-
----
-
-## 11. KD → Diagnostic Interface
-
-NT's kernel debugger (`kd/`) provides a serial transport over which WinDBG can
-inspect kernel state, set breakpoints, and walk data structures live. The
-`!object`, `!handle`, and `!poolused` debugger extensions expose the object
-manager, handle tables, and pool allocator without stopping the machine.
-
-**Database analogue: EXPLAIN and live diagnostic.**
-
-The equivalent is a diagnostic interface that can walk live runtime state: the
-object registry, open handle table, active cursors, and lifecycle counters.
-Implemented as a reserved namespace path (`/system/diagnostics/`), it exposes
-read-only virtual objects whose `Next()` returns runtime state rather than stored
-data. Queries against `/system/diagnostics/cursors` return a row per open cursor;
-queries against `/system/diagnostics/objects` return a row per registry entry with
-its handle and reference counts. This is `EXPLAIN ANALYZE` and
-`pg_stat_activity` unified under the same object model, for free.
-
----
-
-## 12. Config Manager → System Catalog
-
-NT's configuration manager (`config/`) manages registry hives — persistent
-key-value stores loaded at boot and kept consistent via transaction logs. The
-registry is itself stored as a structured binary file that the kernel reads before
-any filesystem driver is loaded.
-
-**Database analogue: system catalog.**
-
-The system catalog is a set of relations stored in a reserved multigroup
-(`/system/catalog/`) that describes all other objects: their types, paths,
-security descriptors, and capabilities. It is the registry of the database. It
-must be readable before any user-defined relations are accessible, exactly as the
-registry is readable before any device driver is loaded.
-
-Because storage is immutable here, the catalog is itself versioned: each schema
-change produces a new catalog snapshot, and the kernel always reads the latest
-committed catalog version on startup. Old catalog versions remain accessible for
-historical schema reconstruction (e.g., reading data written under a previous
-schema). This is more powerful than the NT registry, which has no built-in
-history.
-
----
-
-## Architectural Summary
-
-The full NT kernel, mapped to a database, produces this layer diagram:
-
-```
-┌─────────────────────────────────────────────────────────────────┐
-│              Wire Protocol Subsystems (LPC / Env. Subsystems)   │
-│    PostgreSQL wire   MySQL wire   HTTP/JSON   native client lib  │
-├─────────────────────────────────────────────────────────────────┤
-│                   Session Manager  (PS)                         │
-│    Sessions · Worker threads · Resource groups · Impersonation  │
-├─────────────────────────────────────────────────────────────────┤
-│              Authorization Engine  (SE + OB)                    │
-│    Tokens · Capabilities · DACL/SACL · Privilege evaluation     │
-├─────────────────────────────────────────────────────────────────┤
-│                Query Operator Pipeline  (IO / VM)               │
-│    SCAN · FILTER · PROJECT · JOIN · SORT · AGGREGATE            │
-│    Async execution · Filter-driver middleware · Plan nodes       │
-├─────────────────────────────────────────────────────────────────┤
-│     Object Manager  (OB)          Namespace  (NamespaceRefMgr)  │
-│     Registry · Handles · Types    Branch refs · View reparse    │
-├─────────────────────────────────────────────────────────────────┤
-│            Buffer Pool  (MM + CC)                               │
-│    Page frames · Working set · Prefetch · Append flusher        │
-├─────────────────────────────────────────────────────────────────┤
-│              Storage Backend Interface  (IO driver model)       │
-│    CursorManager · Backend dispatch table · Filter backends     │
-├─────────────────────────────────────────────────────────────────┤
-│         Physical Backends  (HAL / miniport drivers)             │
-│         LMDB · RocksDB · etcd · in-memory · S3                 │
-└─────────────────────────────────────────────────────────────────┘
-```
-
-The current RelationalNT codebase covers the Object Manager, parts of the
-Operator Pipeline (SCAN only), and the authorization skeleton. The layers above
-(session manager, wire protocols) and below (real buffer pool, real storage
-backends) are the next frontier. The NT architecture shows that each layer has a
-well-understood responsibility and a narrow interface to its neighbours — that
-discipline is the reason the NT kernel scales from embedded devices to 1024-core
-servers without architectural changes.
diff --git a/docs/reactos-ob-comparison.md b/docs/reactos-ob-comparison.md
deleted file mode 100644
index 2f0a391..0000000
--- a/docs/reactos-ob-comparison.md
+++ /dev/null
@@ -1,281 +0,0 @@
-# ReactOS Object Manager — Insights for RelationalNT
-
-A comparative study of the ReactOS kernel object manager (`ntoskrnl/ob`) against
-the RelationalNT runtime, identifying structural patterns from the OS kernel that
-translate directly into improvements for a database kernel.
-
-The ReactOS OB is roughly 8,000 lines across `oblife.c`, `obhandle.c`, `obref.c`,
-`obdir.c`, `obname.c`, and `obsecure.c`. The notes below focus on the subset of
-patterns that have a clear database analogue, with adjustments for the
-immutable-storage model this project uses.
-
----
-
-## 1. Two-Level Reference Counting
-
-**ReactOS pattern.** Every object header carries two independent counters:
-`PointerCount` (kernel-internal references, e.g. a driver holding a pointer) and
-`HandleCount` (external user-visible handles). Object deletion only proceeds when
-*both* reach zero.
-
-**Database analogue.** RelationalNT already has `reference_count` and
-`handle_count` in `registry_head`, but `reference_count` is unimplemented (see
-`ObjectManager.h` TODO). The two counters serve different purposes and must be
-decremented by different paths:
-
-- `handle_count` — open sessions holding a cursor or handle on this object.
-  Managed by `LifecycleManager::Monitor` / `Unmonitor`.
-- `reference_count` — structural dependencies: a view referencing its base
-  relations, an index depending on a relation's schema. Managed by a separate
-  `Pin` / `Unpin` pair.
-
-An object may only be garbage-collected when both counters reach zero.
-`Unmonitor` should trigger GC only after checking `reference_count == 0`.
-Without this, there is no safe way to remove a RELATION that still backs a view.
-
-**Important note on snapshots.** Snapshots in this system are *always immutable*.
-Every insertion or deletion produces a new snapshot version of the multigroup
-rather than mutating the existing one. A snapshot is therefore not a special
-lifecycle category — it is just another registered object. Its `reference_count`
-is non-zero while any cursor is pinned to it, and the snapshot is eligible for
-removal only when that count drops to zero. The object flag classification
-(permanent vs. non-permanent) applies to *schema objects*, not to snapshot
-versions.
-
-**TODOs:** `LifecycleManager` — add `Pin(registry*)` / `Unpin(registry*)`.
-`LifecycleManager::Unmonitor` — check both counters before triggering GC.
-
----
-
-## 2. Type Callbacks Instead of a Method Set
-
-**ReactOS pattern.** Object types register actual function pointers:
-`OpenProcedure`, `CloseProcedure`, `DeleteProcedure`, `ParseProcedure`,
-`SecurityProcedure`. The kernel calls into the type-specific callback rather than
-branching on a type enum.
-
-**Database analogue.** `object_type::methods` is currently a `std::set<METHOD>`
-that `IdentityManager::CanOpen` checks against but never acts on. Replacing the
-set with typed callbacks eliminates the identity manager as a separate component
-and makes object behaviour self-contained:
-
-| Callback | Database use |
-|---|---|
-| `OpenProcedure` | RELATION — acquire snapshot pin, register with LifecycleManager |
-| `CloseProcedure` | TRANSACTION — auto-rollback if no explicit commit was issued |
-| `DeleteProcedure` | MULTIGROUP — cascade to relations |
-| `ParseProcedure` | View/alias entry — reparse to the physical relation's path (see §8) |
-
-**Debuggability concern.** Function pointers are harder to trace than a named
-path through the identity manager. Mitigation: store the callback alongside a
-`const char* name` label in `object_type` so that logs and assertions can
-identify which callback fired. A `std::function` with a wrapper that records the
-type label before dispatching also works.
-
-**Security constraint on ParseProcedure.** When a view (an ephemeral RELATION
-whose `ParseProcedure` reparses to base relations) is resolved, the capability
-check must be evaluated against the *view's* security descriptor, not the base
-relations'. A caller who holds READ on the view must *not* gain the ability to
-open handles directly on the underlying relations — those require explicit
-permissions of their own. The ParseProcedure reparse mechanism navigates
-internally through the namespace on behalf of the runtime; it does not grant the
-caller a transitive handle on the base object. The resolved handle is bound to the
-view, and the base relations are accessed only via the view's own type callbacks.
-
-**TODOs:** `ObjectManager::object_type` — replace `std::set<METHOD> methods` with
-typed callback fields. `IdentityManager` — migrate to invoke `OpenProcedure` /
-`CloseProcedure`; the manager becomes a thin dispatcher or is absorbed into
-`HandlerManager`.
-
----
-
-## 3. Hash Directory / Trie for Object Lookup
-
-**ReactOS pattern.** Each `OBJECT_DIRECTORY` holds a 37-bucket hash table (37 is
-prime, chosen to reduce clustering). Name resolution walks path components
-one-by-one, locking each directory, hashing the component, and following
-collision chains. A found entry is moved to the head of its bucket (MRU
-optimisation).
-
-**Current state.** `ObjectManager::Find` is an O(n) linear scan of a linked list.
-The code comment already says "treat as a list for now, but ideally it is a tree."
-
-**Recommended approach.** Replace the flat list with a trie whose nodes are
-directories keyed by path segment. Each directory node holds a hash map from
-segment string to child `registry*`. This matches the ReactOS structure naturally
-because `object_path` is already a `std::vector<std::string>`.
-
-Rather than implementing the trie from scratch, consider pulling a suitable
-container via the Nix flake (e.g. a radix tree or a well-tested associative structure).
-The only hard requirement is that each directory level supports O(1) average
-lookup by segment name and ordered iteration for namespace enumeration.
-
-**TODO:** `ObjectManager` — replace `std::unique_ptr<registry> entries` (linked
-list) with a trie or per-level hash map. `ObjectManager::Find` and `Register`
-both need to be updated.
-
----
-
-## 4. Per-Handle Access Mask
-
-**ReactOS pattern.** The handle table entry stores `GrantedAccess` per handle, not
-per object. A single object can be opened read-only by one session and read-write
-by another simultaneously; each handle's access mask is checked independently.
-
-**Database analogue.** `HandlerManager::handle` currently holds only `object*`
-and `void* connection_context`. Adding `std::set<AUTH_CLAIM> granted_access`
-enables the access mask to be evaluated once at `Open` time and cached in the
-handle for the duration of the session. This resolves the open performance
-question in `PermissionsManager` ("undecided whether to check on every access or
-cache").
-
-**Immutable storage note.** In this system, storage is append-only. A WRITE claim
-does not mean mutating an existing tuple in-place; it means the session is
-authorised to produce a new snapshot version of the relation. The access mask
-semantics should be read accordingly: READ grants access to query an existing
-snapshot; WRITE grants access to commit a new one. Two sessions holding WRITE
-handles on the same relation produce independent snapshots — there is no conflict
-at the storage level.
-
-**TODO:** `HandlerManager::handle` — add `std::set<AUTH_CLAIM> granted_access`.
-`HandlerManager::Open` — populate it from `PermissionsManager::Firewall` /
-`Access` and store in the handle. Subsequent checks read from the handle rather
-than re-evaluating the security descriptor.
-
----
-
-## 5. Capability-Based Security, No Inheritance
-
-**ReactOS pattern.** ReactOS supports SD inheritance through directory traversal:
-an object can inherit its parent directory's security descriptor if none is
-explicitly set.
-
-**This project does not use SD inheritance.** Permissions here are strictly
-capability-based and must be explicitly granted. There is no implicit flow of
-access rights from a multigroup down to its constituent relations. A caller who
-holds READ on `/multigroups/coffee_shop` does not thereby hold READ on
-`/multigroups/coffee_shop/relations/user` — that is a separate, explicit
-capability.
-
-This is a deliberate departure from the ReactOS model, and it is the correct
-design for a database where row-level and column-level access policies are
-common. The capability tree in `PermissionsManager` is the authoritative
-source of truth; the namespace hierarchy is purely organisational.
-
-**Implication for the SD cache.** When a shared security descriptor cache is
-added (see §7 of the original notes), descriptors must be deduplicated by
-content, not by ancestry. Two unrelated relations that happen to have identical
-ACLs may share a cached SD; that sharing is a performance optimisation, not a
-statement about inheritance.
-
----
-
-## 6. Mutable Reference Contention (Branch HEAD)
-
-**ReactOS pattern.** `OB_FLAG_EXCLUSIVE` on an object header prevents more than
-one handle from being open simultaneously. The flag is checked during
-`ObpCreateHandle`; a second opener fails immediately.
-
-**Database analogue.** `LifecycleManager::Contention` is a stub that always
-returns `true`. It needs to distinguish:
-
-- **Immutable objects (RELATION snapshots, MULTIGROUP snapshots, TRANSACTION)** —
-  contention is never raised. These are content-addressed and append-only; two
-  sessions opening the same snapshot independently is fine.
-- **Mutable reference states (branch HEAD, namespace entries)** — contention must
-  be enforced. A branch HEAD is the only mutable pointer in the system; it needs
-  single-writer semantics. When a session holds a write handle on a HEAD, a second
-  writer must block or fail.
-
-The contention check belongs on the *reference object* (the HEAD pointer), not on
-the snapshot object it points to. This maps cleanly to ReactOS's exclusive flag:
-add an `exclusive` flag to `object_type` (or a dedicated flag on `registry_head`)
-that Contention() checks.
-
-**Note on session parallelism.** Because storage is immutable, two sessions
-writing to the same relation in parallel always produce separate, independent
-snapshots. There is no write-write conflict at the data level. The only genuine
-contention point is advancing a branch HEAD — the moment where one of the
-competing snapshots must be chosen as the new tip. This is the correct and narrow
-scope for Contention().
-
-**TODOs:** `ObjectManager::registry_head` or `object_type` — add `bool exclusive`
-flag. `LifecycleManager::Contention` — implement: return false immediately for
-non-exclusive objects; for exclusive objects, return false if `handle_count > 0`
-for a write-mode opener.
-
----
-
-## 7. Deferred Deletion / Asynchronous GC
-
-**ReactOS pattern.** When an object's pointer count reaches zero, ReactOS does not
-delete it inline. It appends to a lock-free `NextToFree` linked list and posts a
-work item to a reaper thread (`ObpReapObject`). This keeps deletion latency off
-the hot path and prevents stack overflow in nested deletes.
-
-**Database relevance.** Snapshot compaction and history pruning are expensive
-operations that should not run inline inside a client-facing `Close()`. The reaper
-pattern maps to a background GC worker: `Unmonitor` enqueues the object when both
-counters reach zero; the GC thread drains the queue and calls the type's
-`DeleteProcedure`.
-
-This is noted for completeness. **Compaction is out of scope for the current
-implementation phase.** Record it here so the architecture accommodates it:
-`LifecycleManager::Unmonitor` should eventually enqueue rather than immediately
-free.
-
----
-
-## 8. NamespaceReferenceManager as the Reparse Layer
-
-**ReactOS pattern.** `ParseProcedure` on a type can return `STATUS_REPARSE` with
-a new path, causing the name resolver to restart from the new path. Symbolic links
-use this. The resolver caps reparse at 30 iterations to detect cycles.
-
-**This is the right architecture for `NamespaceReferenceManager`.** The manager
-currently has no implementation. It should be built around the same concept:
-
-- **Branch references** — a path like `/refs/branch/main` is a namespace entry
-  whose `ParseProcedure` returns a reparse pointing to the actual snapshot path
-  (e.g. `/snapshots/abc123`). The caller's handle lands on the snapshot, not on
-  the reference object itself, unless the caller explicitly opens the reference
-  object for writing (to advance the HEAD).
-
-- **View resolution** — a view's `ParseProcedure` reparses to its base relations
-  internally, subject to the capability security constraint in §2: the reparse
-  happens inside the runtime; the caller's handle and access mask stay bound to
-  the view.
-
-- **Atomic multi-reference updates** — pushing to both `main` and `audit_log`
-  must be all-or-nothing. The implementation should acquire exclusive locks on all
-  involved namespace entries before updating any of them. If a Contention() check
-  fails on any entry, release all locks and abort the batch. This preserves audit
-  consistency.
-
-- **Cycle guard** — view definitions may reference other views. Name resolution
-  must track reparse depth and fail with an error after a bounded number of
-  iterations (30 is the ReactOS figure; a similar constant is appropriate here).
-
-- **Audit branch** — audit is a write concern that spans all branches. It should
-  be modelled as an independent branch whose HEAD is the only contention point for
-  audit-affecting operations, dissociated from the data branch scope.
-
-**TODOs:** `NamespaceReferenceManager` — implement `Resolve(path)` with reparse
-loop and cycle guard. Define the reference object type with an `exclusive` flag
-and a `ParseProcedure` that rewrites the path. Define the batch-update API with
-all-or-nothing semantics.
-
----
-
-## Priority Order
-
-| Priority | Item | Header(s) affected |
-|---|---|---|
-| 1 | Dual ref counting — implement `Pin` / `Unpin` | `LifecycleManager.h` |
-| 2 | Type callbacks — replace `methods` set with function pointers | `ObjectManager.h`, `IdentityManager.h` |
-| 3 | Per-handle access mask | `HandlerManager.h` |
-| 4 | Exclusive flag → real `Contention()` for branch HEADs | `ObjectManager.h`, `LifecycleManager.h` |
-| 5 | Trie / hash directory for `ObjectManager::Find` | `ObjectManager.h` |
-| 6 | `NamespaceReferenceManager` reparse layer | `NamespaceReferenceManager.h` |
-| 7 | Shared SD cache (no inheritance, content-addressed) | `PermissionsManager.h` |
-| 8 | Deferred GC queue in `Unmonitor` | `LifecycleManager.h` |
diff --git a/docs/tarski-sakura-separation.md b/docs/tarski-sakura-separation.md
deleted file mode 100644
index a33e2e3..0000000
--- a/docs/tarski-sakura-separation.md
+++ /dev/null
@@ -1,98 +0,0 @@
-# Tarski / Sakura Separation of Concerns
-
-This document describes how query analysis responsibilities are divided between
-the **Sakura** OCaml frontend and the **Tarski** FOL runtime inside the C++ VM.
-
-## The Two Runtimes
-
-The VM hosts two distinct execution cores:
-
-| Core | Language | Responsibility |
-|---|---|---|
-| **Tarski** | C++ (this repo) | Mechanical FOL plan execution via Volcano pull model |
-| **Sakura** | OCaml | Query parsing, cardinality analysis, plan emission, physical storage |
-
-Sakura is the authoritative source of data and of query semantics. The SQLite
-backend in this repository exists only for isolated testing; in production,
-CursorManager streams data from Sakura over a well-defined interface.
-
-## What Sakura Is Responsible For
-
-### Cardinality analysis and constraint propagation
-
-Every relation in Sakura carries a cardinality tag: `Finite`, `ConstrainedFinite`,
-`AlephZero`, or `Continuum`. When a query joins multiple relations, Sakura
-propagates these tags through the plan to determine the cardinality of the result.
-
-This analysis is non-trivial. Consider:
-
-```karuta
-natural[A], natural[B], natural[C], plus[A,B,C], eq[C, 10].
-```
-
-Each of `natural`, `plus`, and `eq` is individually `AlephZero`. But Sakura can
-determine that binding `C = 10` via `eq` constrains `plus[A,B,10]` to a finite
-set of natural-number pairs, making the overall result finite. Replacing
-`natural` with `integer` changes the result to infinite, because negative pairs
-also satisfy `plus[A,B,10]`.
-
-Tarski does not repeat this analysis. It receives a plan that is already
-annotated with cardinality metadata and executes it mechanically.
-
-### Termination guarantees
-
-If a query produces an infinite result set, Sakura adds a `TAKE` node to the
-plan before emission. Tarski enforces the `TAKE` limit but makes no independent
-judgement about whether a plan terminates.
-
-### Join ordering
-
-Sakura orders the children of each JOIN so that variables are bound from the
-outer (left) side before the inner (right) side is probed. This ensures that
-builtin relations — which may have `AlephZero` cardinality when arguments are
-unbound — are always probed with fully or partially bound arguments, enabling
-O(1) membership validation rather than unbounded enumeration.
-
-### Physical storage
-
-Sakura owns the physical storage layer. CursorManager pulls paginated tuple
-streams from Sakura; the cursor abstraction hides whether the underlying data
-comes from a stored relation or an ephemeral builtin generator.
-
-## What Tarski Is Responsible For
-
-### Mechanical plan execution
-
-Tarski receives a complete, annotated plan tree from Sakura and executes it via
-the Volcano pull model: `VM::Next(PlanNode*)` propagates demand from the root
-to the leaves, returning one tuple at a time.
-
-### Cardinality-aware execution strategy
-
-Each `PlanNode` carries the cardinality tag Sakura attached at plan time. Tarski
-uses this tag only to choose an execution strategy — never to reason about
-termination:
-
-- **Finite / ConstrainedFinite inner side** → safe to materialize for
-  nested-loop join.
-- **AlephZero inner side, all args bound** → probe via `membership_criteria`
-  in O(1); the generator is never called.
-- **AlephZero inner side, unbound args** → should not occur; Sakura must have
-  added a `TAKE` node or reordered the join. Tarski may assert in debug builds.
-
-### TAKE enforcement
-
-`TAKE` is a first-class node in the plan tree. When `VM::Next` passes through a
-`TAKE` node it decrements a counter and returns `nullptr` once the limit is
-reached, regardless of what the subtree would produce.
-
-## Why This Division Is Correct
-
-The cardinality analysis described above requires understanding the **semantics**
-of each relation — what `plus` means over naturals versus integers, how `eq`
-interacts with a functional relation, and so on. That knowledge lives in Sakura.
-Duplicating it in Tarski would couple two layers that must remain independent and
-would place type-level reasoning inside a mechanical executor.
-
-Tarski's contract is simple: given a safe plan, produce correct tuples. Sakura's
-contract is: emit only safe plans.