docs(caching): a declared primary_key is a row constraint, not the cache key The caching refresh-mode page said a declared `acceleration.primary_key` replaces request metadata as the cache key, and its worked example passed a YAML list. Neither is true. A cache lookup is built from the request alone, so a key over response fields could not serve one even in principle; `primary_key` is a uniqueness constraint on the rows the accelerator stores. And `primary_key` deserializes as a string in every release, so the list form never parsed — the whole Spicepod is rejected at load. The example now projects the response fields it keys on with a `columns:` block and passes the key as a parenthesized string. That projection is only available from v2.0.0, so the 1.10.x and 1.11.x copies drop the example instead and state what a key can name there.

Add versioned docs for v2.1 (#1903) Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

docs(retention): retention_sql alone satisfies an enabled policy, and an incomplete one is now reported (#2174) Sources: spiceai/spiceai#13857 Co-authored-by: claudespice <claudespice@users.noreply.github.com>

docs(arrow): the hash index activates from `indexes` too, and `partition_by` is supported (#2168) * docs(arrow): the hash index activates from indexes too, and partition_by is supported The Arrow accelerator deployment guide's Known Limitations contradicted both the code and the Arrow feature pages on two counts. Hash-index activation: the guide said the index 'requires a primary_key constraint; unique constraints alone do not enable the index'. The runtime enables it on 'has_primary_key || has_indexes', so a secondary indexes entry alone (unique included) builds the index with no primary key at all. The same page's Capacity & Sizing section already said '(or secondary indexes entry)', so the page contradicted itself. The real edge the guide missed is the reverse: under refresh_mode: caching the primary-key constraint is stripped before the table is created, so a primary_key alone builds nothing there. partition_by: the guide said 'Not applicable'. Setting partition_by on engine: arrow remaps the engine to PartitionedArrow, which holds one MemTable per partition value. The DuckDB accelerator page and the Partitioning feature page both already tell readers to use engine: arrow for partitioned acceleration. * docs(hash-index): caching drops the primary key, not the whole index — indexes still activates

Add versioned docs for v2.1 (#1903) Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

docs(turso): indexes are supported under MVCC since v2.0.0

Add versioned docs for v2.1 (#1903) Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

docs(snapshots): snapshot files carry the engine extension, not .db Since v1.11.1 (spiceai/spiceai#9318) the snapshot filename ends in the acceleration engine's extension — .duckdb, .sqlite, .cayenne or .turso — via AccelerationEngine::snapshot_extension(). The examples still showed the pre-v1.11.1 ".db" suffix. Scoped to v1.11.x and later; 1.8.x-1.10.x correctly document ".db", which is what snapshot_filename() hardcoded in those releases.