Specify the workspace catalog and CRDT shard boundary

[brylie]

Problem

#13 contains the architectural decision, persistence model, routing rules, migration concerns, and implementation work needed for multi-space. That is too large to execute or review as one issue. Compendium needs an approved shard model before the implementation and migration slices can begin.

Scope

• Record the measured baseline produced by CRDT capacity benchmark and resource observability #31 and identify the constraints it places on the design.
• Define the smallest durable workspace catalog: Spaces, hierarchy/title metadata, permissions/scopes, and view metadata.
• Decide the ownership and partitioning of Document content, Collection data, catalog data, Awareness, agent holds, and audit/provenance data.
• Specify trusted routing from UI, WebSocket, and MCP boundaries to a workspace and shard; client-provided selectors are never authority.
• Define lazy load, flush, idle unload, recovery, compaction, and horizontal-scaling responsibilities.
• Define lossless migration from the current single-space workspace into one default Space, preserving stable IDs, links, attribution, and access grants.
• Update the relevant architecture, data-model, persistence, collaboration, and MCP specifications with the approved decision.

Non-goals

• Shipping the shard implementation itself.
• User-facing Space switching or multi-tenant authentication.
• Choosing an arbitrary record-count limit without CRDT capacity benchmark and resource observability #31 evidence.

Dependencies

Blocked by #31. This is a child decomposition of #13 and supplies the approved design consumed by the implementation and migration slices.

Done when

The repository contains an approved, testable workspace/catalog/shard design with explicit routing, persistence, migration, isolation, and operational rules; implementation issues can proceed without reopening those decisions.

[brylie]

Priority unset → P0: #13 cannot choose the workspace/catalog/shard boundary from intuition; #31 supplies the measured baseline, so #112 is blocked by #31. Once approved, this design directly unblocks #113. Sequencing: #31 → #112 → #113 → #114 → #6.

[brylie]

Design draft added locally in docs/specifications/workspace-sharding.md (linked from the specifications index). Proposed direction: SQLite workspace catalog for Spaces/title/hierarchy/scope metadata; one Y.Doc per Document and Collection; shard-local Awareness; a workspace hold coordinator; and committed-catalog-write outbox events delivered through scoped, revision-aware SSE invalidations.\n\nThis is intentionally marked Proposed: #31 must supply the measured baseline before #112 approves the Document/Collection shard granularity, Collection partition threshold, event-retention window, and snapshot/recovery cadence. #113 should not start its implementation decision work until that approval is recorded.