docs/schema-evolution.md:32-38 tells users to increment a projection version, build a shadow physical table, rebuild from canonical snapshots, and atomically publish while readers keep the old table. The public runtime provides none of this:
- The ProjectionStore layer (ProjectionStore.ts:117-130) fails with ProjectionBlocked when the registered projection_version != binding.projection.version. The registry stores one table per projection_name; there is no concurrent old+shadow table and no atomic swap/publish API.
- A projection version bump also changes definition.hash, so ReplicaBootstrap rejects it with ProtocolMismatch (ReplicaBootstrap.ts:105-112) before any rebuild could start - the documented upgrade is rejected at two independent gates.
- The public surface is clear/replace/replaceDocument (ProjectionStore.ts:20-32), used per-commit; nothing orchestrates an online version upgrade.
Action: either implement the documented shadow-rebuild/publish workflow, or rewrite the guide to describe the actual upgrade path the runtime supports.
docs/schema-evolution.md:32-38 tells users to increment a projection version, build a shadow physical table, rebuild from canonical snapshots, and atomically publish while readers keep the old table. The public runtime provides none of this:
Action: either implement the documented shadow-rebuild/publish workflow, or rewrite the guide to describe the actual upgrade path the runtime supports.