docs: retarget deferred work to v2.x — no v3 planned

v2.x is the project's terminal arc. Docs that referenced v3.0 as a
future milestone get retargeted to concrete v2.x.x slots:

- v2.3 — Stage 5 sub-db migrations (history, files, views)
- v2.4 — write-handler migration + MemoryStore decommission (the
  architectural endpoint), B7 recovery enum collapse paired with it
- v2.5 — extract in-binary v1.x → v2.x migration to a separate
  `smartbotic-database-migrate-v1` deb once every prod host has booted
  v2.4 ≥ once

The "Out of scope" items from the v2.0 roadmap (secondary indexes,
online schema evolution, distributed clustering, writer-pool sharding,
adaptive buffer pool, vector index variants) are simply not planned —
not "deferred to v3" — and need their own roadmap doc + operator
decision if they ever come back into scope.

CLAUDE.md F1 answer updated. v2.1 backlog doc updated end-to-end.
Memory updated to reflect "no v3 planned" status.

No code change — docs only.

docs/superpowers/plans/2026-05-16-v2.1-backlog.md

@@ -1,8 +1,12 @@
-# v2.1+ backlog — shadowman audit follow-up + Stage 5-10 remainder
+# v2.x backlog — shadowman audit follow-up + Stage 5-10 remainder
 
 Origin: shadowman team alignment audit `/tmp/sbdbv2.md` (2026-05-15) +
 the unfinished items from `2026-05-15-v2.0-storage-engine-phase-c-execution.md`.
 
+**v2.x is the project's terminal arc — no v3 is planned.** Every item
+below targets a v2.x.x slot. Items that don't fit the v2.x roadmap are
+simply not planned (no v3 backlog to escalate them to).
+
 This document supersedes the loose "Out of scope (deferred to v2.1+)"
 section in `2026-05-15-v2.0-roadmap.md` (lines 351-359). Each entry has
 an explicit drop trigger so the calendar of removals is observable.
@@ -13,7 +17,7 @@ an explicit drop trigger so the calendar of removals is observable.
 
 | F# | Question | Answer (committed v2.1.1) |
 |----|----------|---------------------------|
-| F1 | When does the v1.x auto-migration path drop? | Stays in-binary through v2.x. Extracts to separate `smartbotic-database-migrate-v1` deb in v3.0. Trigger: every production host has booted v2.0 at least once + a major version bump. |
+| F1 | When does the v1.x auto-migration path drop? | Stays in-binary through v2.4. Extracts to separate `smartbotic-database-migrate-v1` deb in v2.5 once every production host has booted v2.4 ≥ once. v2.x is the terminal arc — no v3 escalation. |
 | F2 | Is `setReadOnly` operator-only or client-callable? | Both. Operator via `smartbotic-db-cli unlock`; client via `Client::lock()` for self-defensive migrations. |
 | F3 | WAL-fallback fields — zero on healthy v2.0? | Yes, guaranteed zero on the LMDB-served path (Find handler explicitly leaves them at their default-constructed zero). Non-zero = real signal, treat as alert. |
 | F4 | `migrateCollectionTimestamps` cost on hot `messages`? | Deferred bench until shadowman runs D.1. Back-of-envelope: ~1ms / 1k docs, online-safe up to ~1M docs; >1M docs schedule a maintenance window. Will be re-measured against real traffic post-D.1. |
@@ -22,13 +26,13 @@ an explicit drop trigger so the calendar of removals is observable.
 
 | B# | Surface | Drop trigger | Target |
 |----|---------|--------------|--------|
-| B1 | In-binary v1.x → v2.0 migration (commit `15893b1`) | Every production host has booted v2.0 ≥ 1× | v3.0 (extract to separate deb) |
+| B1 | In-binary v1.x → v2.0 migration (commit `15893b1`) | Every production host has booted v2.4 ≥ 1× | v2.5 (extract to separate deb) |
 | B2 | Defensive MemoryStore fallback on LMDB-throw | Shipped — closed v2.1.1 | ✅ done |
 | B3 | Stripped `QueryOptions` in document.hpp | Shipped — closed v2.1.0 | ✅ done |
 | B4 | Plain `find(collection)` overload | Shipped — closed v2.1.0 | ✅ done |
 | B5 | Default `"ms"` timestamp precision | Every rapid-write collection migrated via shadowman D.1 | v2.2 (flip default to `"ns"`) |
 | B6 | `update()` as RMW verb | Every RMW callsite converted to `patch()` via shadowman D.2 | v2.x.next (mark `update()` as "replace whole doc only" in docs) |
-| B7 | 6-value `recoveryOutcome` enum | Write-handler migration ships → MemoryStore decommission → LMDB-only recovery semantics | v3.0 (collapse to single `lmdb_ready`) |
+| B7 | 6-value `recoveryOutcome` enum | Write-handler migration ships → MemoryStore decommission → LMDB-only recovery semantics | v2.4 (collapse to single `lmdb_ready`, paired with the write-flip) |
 
 ### Shadowman D-section (their migration items)
 
@@ -58,7 +62,7 @@ Estimated effort: 5.2 medium (HistoryStore deletion + test port), 5.3 + 5.4 smal
 
 ### Stage 4-finish + Stage 6+ — write-handler migration & beyond
 
-This is the v3.0 milestone: handlers call `doc_store_->put()` directly with id-gen / timestamp / version orchestration extracted from MemoryStore into a WriteCoordinator. Once landed, MemoryStore deletes; persistence/wal.cpp / persistence/snapshot.cpp delete; eviction config knobs delete; recovery enum collapses (B7).
+This is the **v2.4** milestone — the v2.x arc's architectural endpoint. Handlers call `doc_store_->put()` directly with id-gen / timestamp / version orchestration extracted from MemoryStore into a WriteCoordinator. Once landed, MemoryStore deletes; persistence/wal.cpp / persistence/snapshot.cpp delete; eviction config knobs delete; recovery enum collapses (B7).
 
 Subsequent stages from the original plan, mostly unchanged:
 
@@ -66,9 +70,12 @@ Subsequent stages from the original plan, mostly unchanged:
 * Stage 7 — migrations RPC: port `MigrationRunner` to call `DocumentStore`
 * Stage 8 — eviction + recovery cleanup audit
 * Stage 9 — performance gates + 24h soak (NOT done for v2.0 — `load_test_mixed` 30s was the proxy)
-* Stage 10 — v3.0 release
+* Stage 10 — v2.4 release (the v2.x arc's architectural endpoint)
+
+## Not planned
 
-## Out of session for v2.x — escalated to v3.x backlog
+The v2.0 roadmap's "Out of scope (deferred to v2.1+)" list contained
+items that, with no v3 in the plan, simply aren't scheduled:
 
 * Secondary user-defined indexes
 * Online schema evolution
@@ -77,9 +84,10 @@ Subsequent stages from the original plan, mostly unchanged:
 * Adaptive `buffer_pool_size_mb` auto-tune
 * Vector index variants (IVF, HNSW)
 
-These are mentioned in the v2.0 roadmap's "Out of scope (deferred to
-v2.1+)" — they're now formally v3.0+ since the v2.x arc terminates at
-the write-handler migration.
+If any of these become required, they need their own roadmap document
++ explicit operator decision to extend the v2.x arc. None of them is
+blocking the v2.x terminal milestone (v2.4 write-handler migration +
+MemoryStore decommission).
 
 ## Sequencing
 
@@ -90,10 +98,10 @@ The earliest valuable sub-PR sequence after v2.1.1:
 3. **Shadowman D.1** (their migration, unblocks B5 in v2.2)
 4. **5.2 history** (bigger refactor; touches history_store.cpp + test_snapshot_durability)
 5. **B5 flip default to ns** — v2.2 release
-6. Then write-handler migration / Stage 4-finish — v3.0 milestone
+6. Then write-handler migration / Stage 4-finish — **v2.4** (the v2.x terminal architectural milestone)
 
 ## Open questions
 
 * Is there a consumer beyond shadowman that we need to coordinate with on B5's default flip? (callerai uses ms today.)
-* Does the `smartbotic-database-migrate-v1` deb (per F1) need to support v1.x → any v2.x, or only v1.x → v3.0 (its target)? Affects how much v1.x code we carry inside the migration deb.
-* For Stage 9, do we wait for a real Zoe-shape soak before shipping v3.0, or is the load_test_mixed 30s proxy acceptable?
+* Does the `smartbotic-database-migrate-v1` deb (per F1) need to support v1.x → any v2.x.x, or only v1.x → v2.5 (its target)? Affects how much v1.x code we carry inside the migration deb.
+* For Stage 9, do we wait for a real Zoe-shape soak before shipping v2.4, or is the `load_test_mixed` 30s proxy acceptable as the gate to MemoryStore decommission?