v0.2.2

docs/IMPLEMENTATION_STATUS.md

@@ -1,8 +1,8 @@
-# RustBox 0.2.1 - implementation status
+# RustBox 0.2.2 - implementation status
 
-This file tracks the `0.2.1` source snapshot. Storage/search scope and outstanding acceptance work are tracked in `TODO.md`. A feature is only listed as implemented when working code exists in this source tree; partial items are called out explicitly.
+This file tracks the `0.2.2` source snapshot. Storage/search scope and outstanding acceptance work are tracked in `TODO.md`. A feature is only listed as implemented when working code exists in this source tree; partial items are called out explicitly.
 
-## 0.2.1 storage/search architecture
+## 0.2.2 storage/search architecture
 
 - SQL backend selection (`sqlite`/`mysql`/`pgsql`) is independent from blob storage and search backend selection.
 - Cluster mode clears an implicit/default `data_dir`; PostgreSQL/MySQL single-node deployments may still intentionally use `data_dir`-backed filesystem storage and local Tantivy.
@@ -11,6 +11,7 @@ This file tracks the `0.2.1` source snapshot. Storage/search scope and outstandi
 - OpenSearch is available as the cluster-capable indexer. Local Tantivy remains single-node only; search may also be disabled.
 - Search mutations use a durable SQL outbox with claim/lease, retry/backoff and dead-letter state; the index remains rebuildable derived state.
 - V047 adds attachment checksum metadata and the search outbox across SQLite, MySQL and PostgreSQL.
+- SQL global-schema initialization is centralized in `db::pool::configure()`; database-backed sessions do not repeat startup DDL for SQLite, MySQL or PostgreSQL.
 - Docker Compose examples cover standalone SQLite, PostgreSQL + SILO (S3-compatible) + OpenSearch, and MySQL + NFS + OpenSearch.
 - Live SILO/MinIO/AWS S3/Ceph RGW, live NFS multi-host, live OpenSearch and full multi-node failover acceptance remain release-environment validation items and are not represented as completed here.
 

docs/RELEASING.md

@@ -3,15 +3,14 @@
 1. Update the version in `Cargo.toml` and the RustBox package entry in `Cargo.lock`.
 2. Confirm `UPSTREAM_BASE` is the Oxi revision actually consumed by the release.
 3. Ensure no TypeScript sources or separate frontend build dependencies are present.
-4. Run:
+4. Run the release gate and package only after it passes:
 
 ```bash
-cargo fmt --all -- --check
-cargo test --locked
-cargo clippy --locked --all-targets -- -D warnings
-./scripts/build-release.sh
+./scripts/package-release.sh
 ```
 
+`package-release.sh` runs `scripts/build-release.sh` first. That gate regenerates the lockfile, runs the static validator, `cargo fmt --check`, the full `cargo test --locked` suite, Clippy with `-D warnings`, and the locked release build. The ZIP and SHA256 are created only after all of those steps succeed.
+
 5. Verify:
 
 ```bash
@@ -27,7 +26,7 @@ RUSTBOX_CONFIG=./config.dev.toml ./target/release/rustbox --check-config
 
 Browser JavaScript source lives in functional modules under `src/web/js/`, ordered by `src/web/js/manifest.txt`. `build.rs` concatenates those modules into the embedded `rustbox-ui.js` asset during every Cargo build. The repository has no duplicate `ui/` snapshot; `src/web/` is the only browser UI source.
 
-## Updating an existing checkout to 0.2.1
+## Updating an existing checkout to 0.2.2
 
 Do not overlay the release with `cp *` or another command that skips dotfiles. That can retain stale `.github`, `.env.example`, or `Cargo.lock` files.
 

docs/STORAGE_SEARCH_OPERATIONS.md

@@ -1,6 +1,6 @@
-# RustBox 0.2.1 storage/search operations
+# RustBox 0.2.2 storage/search operations
 
-RustBox 0.2.1 treats SQL, blob storage and search as independent capabilities. The database engine does not decide whether `data_dir` is allowed.
+RustBox 0.2.2 treats SQL, blob storage and search as independent capabilities. The database engine does not decide whether `data_dir` is allowed.
 
 ## Deployment matrix