sqlrite 0.9.1__tar.gz → 0.10.1__tar.gz

{sqlrite-0.9.1 → sqlrite-0.10.1}/.github/workflows/ci.yml

@@ -299,6 +299,15 @@ jobs:
   wasm-build:
     name: wasm-build
     runs-on: ubuntu-latest
+    # Pinned binaryen version — see docs/release-plan.md
+    # ("Pinned binaryen / wasm-opt") for the bump procedure. Older
+    # binaryen rejects rustc's multi-table WASM output with
+    # "Only 1 table definition allowed in MVP", which the runner
+    # image's cache state used to surface non-deterministically
+    # (SQLR-58). Pinning keeps wasm-opt out of "whatever's cached"
+    # territory.
+    env:
+      BINARYEN_VERSION: version_122
     steps:
       - uses: actions/checkout@v4
 
@@ -313,12 +322,29 @@ jobs:
           workspaces: sdk/wasm
           shared-key: wasm-build
 
+      - name: Install pinned binaryen (wasm-opt)
+        # MUST run before wasm-pack: wasm-pack picks up wasm-opt from
+        # PATH if present, otherwise downloads whatever binaryen its
+        # own internal cache happens to have. Pinning + prepending
+        # to PATH forces a deterministic version across runner images.
+        run: |
+          set -euo pipefail
+          curl -fsSL "https://github.com/WebAssembly/binaryen/releases/download/${BINARYEN_VERSION}/binaryen-${BINARYEN_VERSION}-x86_64-linux.tar.gz" \
+            -o "$RUNNER_TEMP/binaryen.tar.gz"
+          tar -xzf "$RUNNER_TEMP/binaryen.tar.gz" -C "$RUNNER_TEMP"
+          echo "$RUNNER_TEMP/binaryen-${BINARYEN_VERSION}/bin" >> "$GITHUB_PATH"
+          "$RUNNER_TEMP/binaryen-${BINARYEN_VERSION}/bin/wasm-opt" --version
+
       - name: Install wasm-pack
         uses: jetli/wasm-pack-action@v0.4.0
 
       - name: wasm-pack build --target web --release
         working-directory: sdk/wasm
-        run: wasm-pack build --target web --release
+        run: |
+          # Sanity-check that the pinned wasm-opt is what wasm-pack sees.
+          which wasm-opt
+          wasm-opt --version
+          wasm-pack build --target web --release
 
       - name: Report .wasm size
         # Surfaces size regressions in PR logs. Not a hard limit yet;

{sqlrite-0.9.1 → sqlrite-0.10.1}/.github/workflows/release.yml

@@ -1189,6 +1189,14 @@ jobs:
     if: needs.detect.outputs.should_release == 'true'
     runs-on: ubuntu-latest
     environment: release
+    # Pinned binaryen version — see docs/release-plan.md
+    # ("Pinned binaryen / wasm-opt") for the bump procedure. Older
+    # binaryen rejects rustc's multi-table WASM output with
+    # "Only 1 table definition allowed in MVP" (SQLR-58). The
+    # release pipeline can't tolerate that flake — a failed
+    # publish-wasm leaves the rest of the release wave inconsistent.
+    env:
+      BINARYEN_VERSION: version_122
     permissions:
       # OIDC: required for npm trusted-publisher token exchange.
       # Same flow proven in publish-nodejs after the v0.1.5–0.1.7
@@ -1207,6 +1215,20 @@ jobs:
           shared-key: publish-wasm
           workspaces: 'sdk/wasm -> target'
 
+      - name: Install pinned binaryen (wasm-opt)
+        # MUST run before wasm-pack: wasm-pack picks up wasm-opt
+        # from PATH if present, otherwise downloads whatever
+        # binaryen its own internal cache happens to have. Pinning
+        # + prepending to PATH forces a deterministic version
+        # across runner images.
+        run: |
+          set -euo pipefail
+          curl -fsSL "https://github.com/WebAssembly/binaryen/releases/download/${BINARYEN_VERSION}/binaryen-${BINARYEN_VERSION}-x86_64-linux.tar.gz" \
+            -o "$RUNNER_TEMP/binaryen.tar.gz"
+          tar -xzf "$RUNNER_TEMP/binaryen.tar.gz" -C "$RUNNER_TEMP"
+          echo "$RUNNER_TEMP/binaryen-${BINARYEN_VERSION}/bin" >> "$GITHUB_PATH"
+          "$RUNNER_TEMP/binaryen-${BINARYEN_VERSION}/bin/wasm-opt" --version
+
       # Install wasm-pack — the canonical tool for building +
       # packaging Rust crates as npm-publishable WASM modules.
       # `cargo binstall` would be faster than `cargo install`
@@ -1239,6 +1261,9 @@ jobs:
       - name: Build WASM package
         working-directory: sdk/wasm
         run: |
+          # Sanity-check that the pinned wasm-opt is on PATH (SQLR-58).
+          which wasm-opt
+          wasm-opt --version
           wasm-pack build --release --target bundler --scope joaoh82
           echo "--- generated pkg/ contents ---"
           ls -la pkg/

{sqlrite-0.9.1 → sqlrite-0.10.1}/.gitignore

@@ -44,3 +44,12 @@ examples/wasm/pkg
 
 # macOS
 .DS_Store
+
+# Local agent / Claude Code worktrees. These shouldn't ever get
+# committed — but `git add -A` from main while a worktree is live
+# under .claude/worktrees/<name>/ will capture it as a gitlink
+# (mode 160000) because the worktree dir looks like a submodule to
+# the parent index. Ignoring the whole tree prevents that whole
+# class of accident. (The release commit 937f8b4 hit exactly this
+# bug; the next commit untracks the leftover gitlinks.)
+.claude/worktrees/

{sqlrite-0.9.1 → sqlrite-0.10.1}/CLAUDE.md

@@ -16,6 +16,7 @@ SQLRite is a from-scratch SQLite-style embedded database written in Rust. It's p
 - `sqlrite-ffi/` — C ABI cdylib + generated `sqlrite.h` header. Backs the Go SDK and any C consumer.
 - `desktop/` — Tauri 2 + Svelte 5 GUI. Embeds the engine directly (no FFI hop).
 - `benchmarks/` — SQLR-4 / SQLR-16 bench harness. `Driver` trait + SQLRite + SQLite (rusqlite-bundled) drivers + criterion-driven workloads. Excluded from the default CI build/test/clippy/doc commands; run locally with `make bench` (or `make bench-duckdb`). See [docs/benchmarks-plan.md](docs/benchmarks-plan.md).
+- `web/` — marketing + docs site (Next.js 15 + Tailwind v4). Independent of the Cargo workspace; lives in-repo for now but is structured to lift into its own repository later. See [web/README.md](web/README.md).
 
 Architecture deep-dive: [docs/architecture.md](docs/architecture.md). The full doc index is [docs/_index.md](docs/_index.md).
 

{sqlrite-0.9.1 → sqlrite-0.10.1}/Cargo.lock

@@ -4799,7 +4799,7 @@ dependencies = [
 
 [[package]]
 name = "sqlrite-ask"
-version = "0.9.1"
+version = "0.10.1"
 dependencies = [
  "serde",
  "serde_json",
@@ -4827,7 +4827,7 @@ dependencies = [
 
 [[package]]
 name = "sqlrite-desktop"
-version = "0.9.1"
+version = "0.10.1"
 dependencies = [
  "serde",
  "serde_json",
@@ -4839,7 +4839,7 @@ dependencies = [
 
 [[package]]
 name = "sqlrite-engine"
-version = "0.9.1"
+version = "0.10.1"
 dependencies = [
  "clap",
  "env_logger",
@@ -4856,7 +4856,7 @@ dependencies = [
 
 [[package]]
 name = "sqlrite-ffi"
-version = "0.9.1"
+version = "0.10.1"
 dependencies = [
  "cbindgen",
  "serde",
@@ -4866,7 +4866,7 @@ dependencies = [
 
 [[package]]
 name = "sqlrite-mcp"
-version = "0.9.1"
+version = "0.10.1"
 dependencies = [
  "clap",
  "libc",
@@ -4877,7 +4877,7 @@ dependencies = [
 
 [[package]]
 name = "sqlrite-nodejs"
-version = "0.9.1"
+version = "0.10.1"
 dependencies = [
  "napi",
  "napi-build",
@@ -4887,7 +4887,7 @@ dependencies = [
 
 [[package]]
 name = "sqlrite-python"
-version = "0.9.1"
+version = "0.10.1"
 dependencies = [
  "pyo3",
  "sqlrite-engine",

{sqlrite-0.9.1 → sqlrite-0.10.1}/Cargo.toml

@@ -27,7 +27,7 @@ resolver = "3"
 # `package =` key so the import name stays `sqlrite` internally:
 #     sqlrite = { package = "sqlrite-engine", path = "…" }
 name = "sqlrite-engine"
-version = "0.9.1"
+version = "0.10.1"
 authors = ["Joao Henrique Machado Silva <joaoh82@gmail.com>"]
 edition = "2024"
 rust-version = "1.85"
@@ -73,6 +73,15 @@ path = "examples/rust/quickstart.rs"
 name = "hybrid-retrieval"
 path = "examples/hybrid-retrieval/hybrid_retrieval.rs"
 
+# Phase 11.12 — BEGIN CONCURRENT retry-loop demo. Mints a sibling
+# Connection via `Connection::connect`, runs two concurrent
+# transactions (first disjoint, then same-row), and surfaces the
+# Busy / retry path. Run with `cargo run --example concurrent_writers`.
+# See `docs/concurrent-writes.md` for the conceptual walkthrough.
+[[example]]
+name = "concurrent_writers"
+path = "examples/rust/concurrent_writers.rs"
+
 [features]
 # Default build includes everything: the REPL binary (cli) and
 # POSIX/Windows advisory file locks on the Pager (file-locks).
@@ -141,4 +150,4 @@ fs2 = { version = "0.4", optional = true }
 # crate publishes to crates.io, and a path-only dep without a
 # version field fails the manifest verification step. See PR #58
 # retrospective in docs/roadmap.md.
-sqlrite-ask = { version = "0.9.1", path = "sqlrite-ask", optional = true }
+sqlrite-ask = { version = "0.10.1", path = "sqlrite-ask", optional = true }

{sqlrite-0.9.1 → sqlrite-0.10.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: sqlrite
-Version: 0.9.1
+Version: 0.10.1
 Classifier: Development Status :: 3 - Alpha
 Classifier: Intended Audience :: Developers
 Classifier: License :: OSI Approved :: MIT License

{sqlrite-0.9.1 → sqlrite-0.10.1}/README.md

@@ -11,6 +11,8 @@ Rust-SQLite (SQLRite)
 > What I cannot create, I do not understand. 
 > — Richard Feynman
 
+📖 **Project website + docs:** the marketing + getting-started site is in [`web/`](web/) (Next.js 15 + Tailwind v4). Run `cd web && npm install && npm run dev` to preview locally; deploys to Vercel out of the box.
+
 
 <table style="width:100%">
 <tr>
@@ -106,6 +108,15 @@ Wire it into Claude Code (`~/.claude.json`):
 
 `--read-only` opens the DB with a shared lock and hides the `execute` tool. Full docs + the other six tools' references in [`docs/mcp.md`](docs/mcp.md).
 
+### End-to-end example apps
+
+Beyond the per-language quickstarts in [`examples/`](examples/), the SQLR-38 umbrella tracks longer, opinionated example apps that exercise SQLRite in real-world shapes:
+
+| App | SDK | What it shows |
+|---|---|---|
+| [Python LLM agent with persistent memory](examples/python-agent/) | Python | Vector + lexical recall, fact extraction, summaries — all in one `.sqlrite` file |
+| [Chat-with-your-notes via Claude Desktop MCP](examples/nodejs-notes/) | Node.js | Markdown → hybrid HNSW + BM25 index → `sqlrite-mcp --read-only` → Claude Desktop |
+
 ### Developer guide
 
 In-depth documentation lives under [`docs/`](docs/). Start at [`docs/_index.md`](docs/_index.md) — it navigates to:

{sqlrite-0.9.1 → sqlrite-0.10.1}/desktop/package.json

@@ -1,7 +1,7 @@
 {
   "name": "sqlrite-desktop-frontend",
   "private": true,
-  "version": "0.9.1",
+  "version": "0.10.1",
   "type": "module",
   "scripts": {
     "dev": "vite",

{sqlrite-0.9.1 → sqlrite-0.10.1}/docs/_index.md

@@ -16,7 +16,8 @@ A small, hand-written guide to the SQLRite codebase — how it's structured, how
 ## Using SQLRite as a library
 
 - [Embedding](embedding.md) — the public `Connection` / `Statement` / `Rows` API (Phase 5a) and where the non-Rust SDKs plug in (Phase 5b – 5g)
-- [`examples/`](../examples/) — runnable Rust quickstart (`cargo run --example quickstart`); language-specific subdirectories fill in as each 5x sub-phase lands
+- [Concurrent writes — MVCC + `BEGIN CONCURRENT`](concurrent-writes.md) — Phase 11 canonical reference: SQL surface, embedding API, SDK error mapping, REPL meta-commands, durability story, limitations. Design rationale lives in the [historical plan-doc](concurrent-writes-plan.md).
+- [`examples/`](../examples/) — runnable Rust quickstart (`cargo run --example quickstart`) + concurrent-writers retry-loop demo (`cargo run --example concurrent_writers`); language-specific subdirectories fill in as each 5x sub-phase lands
 
 ## Phase 7 — AI-era extensions
 
@@ -52,6 +53,9 @@ As of May 2026, SQLRite has:
 - A Tauri 2.0 + Svelte desktop app (Phase 2.5 complete)
 - AI-era extensions across the product surface (Phase 7 complete): VECTOR columns + HNSW indexes (7a-7d), JSON columns (7e), the `ask()` natural-language → SQL family across the REPL / desktop / Rust / Python / Node / Go / WASM (7g.1-7g.7), and the [`sqlrite-mcp`](mcp.md) Model Context Protocol server (7h + 7g.8)
 - Full-text search + hybrid retrieval (Phase 8 complete): FTS5-style inverted index with BM25 ranking + `fts_match` / `bm25_score` scalar functions + `try_fts_probe` optimizer hook + on-disk persistence with on-demand v4 → v5 file-format bump (8a-8c), a worked hybrid-retrieval example combining BM25 with vector cosine via raw arithmetic (8d), and a `bm25_search` MCP tool symmetric with `vector_search` (8e). See [`docs/fts.md`](fts.md).
+- SQL surface + DX follow-ups (Phase 9 complete, v0.2.0 → v0.9.1): DDL completeness — `DEFAULT`, `DROP TABLE` / `DROP INDEX`, `ALTER TABLE` (9a); free-list + manual `VACUUM` (9b) + auto-VACUUM (9c); `IS NULL` / `IS NOT NULL` (9d); `GROUP BY` + aggregates + `DISTINCT` + `LIKE` + `IN` (9e); four flavors of `JOIN` — INNER, LEFT, RIGHT, FULL OUTER (9f); prepared statements + `?` parameter binding with a per-connection LRU plan cache (9g); HNSW probe widened to cosine + dot via `WITH (metric = …)` (9h); `PRAGMA` dispatcher with the `auto_vacuum` knob (9i)
+- Benchmarks against SQLite + DuckDB (Phase 10 complete, SQLR-4 / SQLR-16): twelve-workload bench harness with a pluggable `Driver` trait, criterion-driven, pinned-host runs published. See [`docs/benchmarks.md`](benchmarks.md).
+- Phase 11 (concurrent writes via MVCC + `BEGIN CONCURRENT`, SQLR-22) is **shipped end-to-end** — `Connection` is `Send + Sync`; `Connection::connect()` mints sibling handles. `sqlrite::mvcc` exposes `MvccClock`, `ActiveTxRegistry`, `MvStore`, `ConcurrentTx`, and the `MvccCommitBatch` / `MvccLogRecord` WAL codec. WAL header v1 → v2 persisted the clock high-water mark; v2 → v3 added typed MVCC log-record frames. `PRAGMA journal_mode = mvcc;` opts a database into MVCC. `BEGIN CONCURRENT` writes commit-validate against `MvStore`, abort with `SQLRiteError::Busy`, and append a typed MVCC log-record frame to the WAL — covered by the same fsync as the legacy page commit. Reopen replays those frames into `MvStore` and seeds `MvccClock` past the highest committed `commit_ts`. Reads via `Statement::query` see the BEGIN-time snapshot. Per-commit GC + `vacuum_mvcc()` bound version-chain growth. C FFI / Python / Node / Go all propagate `Busy` / `BusySnapshot` as typed retryable errors *and* mint sibling handles that share backing state — Go's process-level path registry (Phase 11.11c) handles cross-`*sql.DB` sharing too. The `sqlrite` REPL ships `.spawn` / `.use` / `.conns` for interactive demos; the SQLR-16 benchmark suite adds `W13` (concurrent writers, mostly disjoint rows) as the Phase-11 differentiator workload. The only remaining items are deferred-by-design or foundation work: indexes under MVCC (11.10) and the checkpoint-drain follow-up (parked half of 11.9). **User-facing reference:** [`docs/concurrent-writes.md`](concurrent-writes.md); runnable example at [`examples/rust/concurrent_writers.rs`](../examples/rust/concurrent_writers.rs). Original design proposal: [`docs/concurrent-writes-plan.md`](concurrent-writes-plan.md).
 - A fully-automated release pipeline that ships every product to its registry on every release with one human action — Rust engine + `sqlrite-ask` + `sqlrite-mcp` to crates.io, Python wheels to PyPI (`sqlrite`), Node.js + WASM to npm (`@joaoh82/sqlrite` + `@joaoh82/sqlrite-wasm`), Go module via `sdk/go/v*` git tag, plus C FFI tarballs, MCP binary tarballs, and unsigned desktop installers as GitHub Release assets (Phase 6 complete)
 
 See the [Roadmap](roadmap.md) for the full phase plan.

{sqlrite-0.9.1 → sqlrite-0.10.1}/docs/benchmarks-plan.md

@@ -111,6 +111,16 @@ For W10/W11, the goal isn't to beat the comparators — they're battle-hardened
 
 For W12, no off-the-shelf comparator exists in a single embedded engine; the number stands on its own.
 
+### Group D — Concurrent writes (Phase 11.11b, the Phase-11 MVCC differentiator)
+
+| ID | Name | Shape | Comparator |
+|----|------|-------|------------|
+| W13 | Concurrent writers | 4 worker threads × 50 BEGIN/UPDATE/COMMIT cycles each, random rowid in `1..=1000` (≈ 0.4% collision per op), `UPDATE counters SET n = n + 1 WHERE id = ?` | SQLite (`BEGIN IMMEDIATE` + `busy_timeout = 5s` per-connection) |
+
+The headline workload Phase 11's MVCC machinery was designed for. SQLRite drives `BEGIN CONCURRENT` across sibling [`Connection::connect`](../docs/concurrent-writes.md) handles minted from the same process; SQLite drives `BEGIN IMMEDIATE` across separate `rusqlite::Connection` handles serializing through the WAL write lock. Both engines run the same retry-on-busy outer loop ([`is_retryable_busy`](../benchmarks/src/lib.rs) is engine-dispatched); only SQLRite actually exercises the retry path under this workload's shape — the contrast *is* the measurement.
+
+Workload parameters live in [`benchmarks/src/workloads/concurrent_writers.rs`](../benchmarks/src/workloads/concurrent_writers.rs) as named constants (`W13_PRELOAD_ROWS`, `W13_N_WORKERS`, `W13_TXS_PER_WORKER`). Bumping any of them is a workload-version bump under Q8.
+
 ---
 
 ## Metrics
@@ -127,9 +137,10 @@ Keep tight. The task brief lists many candidates; the suite measures these:
 Explicitly **not** measured in v1:
 
 - **CPU%.** Noisy on a shared machine, redundant with wall-clock for single-threaded workloads.
-- **Concurrency curves.** Engine is single-writer by design (Phase 4e). No concurrent-writer workload is meaningful until that changes.
 - **Network I/O.** All targets are in-process.
 
+**Updated post-Phase 11.11b:** Group D's `W13` (concurrent writers) lifts the single-writer caveat — SQLRite now has a real multi-writer story via `BEGIN CONCURRENT`, and W13 measures it directly against SQLite's single-writer baseline. Full concurrency-curve sweeps (varying `N` workers and collision rate) are a clean follow-up; v1 reports a single representative point.
+
 ---
 
 ## Methodology
@@ -190,7 +201,8 @@ benchmarks/
 │       ├── join.rs        — W9
 │       ├── vector.rs      — W10
 │       ├── fts.rs         — W11
-│       └── hybrid.rs      — W12
+│       ├── hybrid.rs      — W12
+│       └── concurrent_writers.rs — W13 (Phase 11.11b)
 ├── benches/
 │   └── suite.rs           — single criterion entry point that fans out
 ├── scripts/
@@ -264,11 +276,18 @@ Add the `duckdb-rs` driver under a `--features duckdb` flag. Wire only into Grou
 
 **Exit criterion:** `docs/benchmarks.md` exists, the README has a "Benchmarks" section pointing at it, the first dated results JSON is committed.
 
-### Post-9.6 ideas (parked)
+### 9.7 — Group D concurrent writers (Phase 11.11b, shipped)
+
+Adds `W13` (concurrent writers, mostly-disjoint rows) under a new Group D. The `Driver` trait grows three optional methods (`connect_sibling`, `concurrent_begin_sql`, `is_retryable_busy`) with defaults that make sense for engines without an MVCC story; SQLRite overrides all three. SQLite gains a `busy_timeout = 5s` pragma at open so its `BEGIN IMMEDIATE` blocks rather than fails on contention. The workload lives in [`benchmarks/src/workloads/concurrent_writers.rs`](../benchmarks/src/workloads/concurrent_writers.rs).
+
+**Exit criterion:** W13 runs under both drivers, correctness gate passes (`SUM(n) == n_workers * txs_per_worker` after a sample), and the JSON envelope picks up `W13.v1` rows for both drivers.
+
+### Post-9.7 ideas (parked)
 
 - **libSQL driver** if/when we want a non-extension vector competitor for W10.
 - **Per-PR regression detector.** A GitHub Action that runs the bench on a self-hosted runner and posts a comment if any workload regresses >20% from the last `main` baseline.
-- **Concurrency workloads** if/when SQLRite gains true multi-writer support.
+- **Concurrency curves for W13.** Sweep `N` workers (1, 2, 4, 8, 16) and `K` rows (10, 100, 1k, 10k) to chart SQLRite-MVCC's scaling envelope vs SQLite's serial baseline. v1 reports a single representative point; the sweep is a clean follow-up.
+- **W13b hot-row contention.** Same workload, `K = 10` rows instead of 1000 — collision probability climbs to ~40% per op, exercising the retry loop hard. Useful for stressing the GC + retry path under adversarial contention.
 - **Larger datasets (10M, 100M).** v1 is sized for fast iteration on a laptop. A "release-blocker run" config could 100× the row counts.
 
 ### Total scope estimate

{sqlrite-0.9.1 → sqlrite-0.10.1}/docs/concurrent-writes-plan.md

@@ -1,8 +1,16 @@
 # Concurrent writes plan — MVCC + `BEGIN CONCURRENT`
 
-**Status:** proposal, not yet scheduled. Drafted 2026-05-07.
+> 📘 **Looking for the user-facing reference?** This is the original
+> design proposal, kept as the historical record of the decisions
+> that shaped Phase 11. For the shipped surface — SQL, embedding API,
+> SDK error mapping, REPL meta-commands, durability story,
+> limitations — read [**`concurrent-writes.md`**](concurrent-writes.md)
+> first; come back here when you want the *why* and the
+> sequencing discussion.
+
+**Status:** shipped end-to-end through Phase 11.11a (May 2026); a small set of follow-ups remain explicitly parked — see the [roadmap](roadmap.md#phase-11--concurrent-writes-via-mvcc--begin-concurrent-sqlr-22-in-flight--see-concurrent-writes-planmd). Drafted 2026-05-07.
 **Inspiration:** [Turso](https://turso.tech) — a SQLite-compatible engine, written in Rust, that implements multi-version concurrency control to lift SQLite's single-writer ceiling. See [`turso/core/mvcc/`](https://github.com/tursodatabase/turso/tree/main/core/mvcc) and the [Turso concurrent-writes docs](https://docs.turso.tech/tursodb/concurrent-writes).
-**Tracks:** SQLR-?? (Marvin) — to be filed alongside this doc.
+**Tracks:** [SQLR-22](https://app.marvinapp.io/) (Marvin).
 
 This document proposes adding **multi-version concurrency control (MVCC)** and a **`BEGIN CONCURRENT`** transaction mode to SQLRite, enabling multiple writers in the same process to make progress in parallel under snapshot isolation, with row-level write-write conflict detection at commit. It is intentionally a *plan* — there is no code yet.
 
@@ -270,9 +278,11 @@ Goal: more than one `Connection` can target the same `Database` within a process
 
 ### Phase 10.5 — Checkpoint + crash recovery
 
-- Extend the checkpointer to drain MVCC log records into pager-level updates before folding the WAL into the main file.
-- Crash recovery: on open, replay WAL log records into `MvStore`, then replay pager-level commit frames as today.
-- Tests: kill the process mid-MVCC-commit (between log-record append and version-chain push), reopen, verify the committed transaction is visible and the half-written one is not.
+> **Status (roadmap 11.9 — May 2026):** The crash-recovery half landed in roadmap Phase 11.9. WAL format is bumped to v3; commits append a typed `MvccCommitBatch` frame before the legacy save's fsync; reopen replays those frames into `MvStore` and seeds `MvccClock` past the highest `commit_ts`. The checkpoint-drain half — folding MVCC log records into pager-level updates and re-enabling the `Mvcc → Wal` journal-mode downgrade — is the remaining slice and stays parked for a follow-up.
+
+- ~~Extend the checkpointer to drain MVCC log records into pager-level updates before folding the WAL into the main file.~~ *Deferred — see status note above.*
+- Crash recovery: on open, replay WAL log records into `MvStore`, then replay pager-level commit frames as today. **(Shipped — 11.9.)**
+- Tests: kill the process mid-MVCC-commit (between log-record append and version-chain push), reopen, verify the committed transaction is visible and the half-written one is not. **(Shipped — 11.9 covers the clean-drop case which exercises the same recovery codepath; a real OS-kill test is parked with the checkpoint-drain follow-up.)**
 
 ### Phase 10.6 — Garbage collection
 
@@ -294,9 +304,11 @@ Index maintenance under MVCC is hard enough that Turso explicitly punted on it.
 
 ### Phase 10.9 — Docs
 
-- Promote this plan to `docs/concurrent-writes.md` (the canonical user-facing reference), keeping `concurrent-writes-plan.md` as the historical design document.
-- Update [roadmap.md](roadmap.md), [`docs/_index.md`](_index.md), [supported-sql.md](supported-sql.md), [embedding.md](embedding.md), [design-decisions.md](design-decisions.md).
-- Add a worked example under `examples/rust/concurrent_writers.rs`.
+> **Status (roadmap 11.12 — May 2026):** Shipped. The canonical user-facing reference at [`docs/concurrent-writes.md`](concurrent-writes.md) covers the SQL surface, embedding API, SDK error mapping, REPL meta-commands, durability story, and limitations as of Phase 11.11a. This plan-doc is now the historical record. Cross-references in `_index.md`, `supported-sql.md`, `embedding.md`, and `design-decisions.md` point at the canonical doc; a runnable example lives at [`examples/rust/concurrent_writers.rs`](../examples/rust/concurrent_writers.rs).
+
+- Promote this plan to `docs/concurrent-writes.md` (the canonical user-facing reference), keeping `concurrent-writes-plan.md` as the historical design document. **(Shipped — 11.12.)**
+- Update [roadmap.md](roadmap.md), [`docs/_index.md`](_index.md), [supported-sql.md](supported-sql.md), [embedding.md](embedding.md), [design-decisions.md](design-decisions.md). **(Shipped — 11.12.)**
+- Add a worked example under `examples/rust/concurrent_writers.rs`. **(Shipped — 11.12.)**
 
 ---