FACTUAL ACTIVITY RECORD · An activity record based on work that took place
Selecting which sessions appear in the 3D space
Managing display-only scope with an owner-scoped allowlist while preserving synchronization of all history
Purpose
Every synchronized root session appeared in the 3D space, with no way to focus on the tasks of interest. A display-selection mechanism was needed without narrowing or deleting stored history.
The goal was to select multiple sessions from an authenticated administration screen and apply the same allowlist to islands, session selection, and conversation retrieval while continuing to store unselected history.
Implementation
An administration screen was added in page implementation and session-administration UI. It supports search, multiple selection, clearing all, limit feedback, and saving, success, and failure states, allowing up to 24 display sessions at once.
- session-visibility policy reads and writes allowed sessions for an owner and project.
- endpoint implementation accepts authenticated requests and separates list retrieval from replacement saves.
- A dedicated database RPC validates owner, project, root sessions, and the limit before atomically replacing the allowlist.
Owner-scoped row controls were applied to the allowlist table, and concurrent saves from multiple tabs to the same project were serialized with a project row lock. The initial migration allowed the latest 24 sessions to avoid abruptly hiding the existing view; newly synchronized sessions remain hidden until explicitly selected.
Allowed sessions are passed into synchronization adapter and 3D-state mapper, limiting 3D islands, the session pull-down, and conversation API to the same set. A hidden roomId falls back to the latest visible session, and zero selections show administration guidance instead of fabricating an island.
- Deselecting a session changes display only and does not delete synchronized tasks, turns, or messages.
- Full collection and database synchronization remain unchanged, separating storage from display responsibility.
- The control is limited to display within one authenticated owner and is not treated as per-viewer public authorization.
Alongside mapper and display-boundary tests, an authenticated database was used to check the 24-item limit, serialization of concurrent saves, exclusion of hidden sessions, and fallback from an invalid selection. Lint, type checking, a production build, and database lint were also run against the change.
Session selection used a shared database and application cap and distinguished configuration, mismatch, limit, and query failures before stopping.
Rendering diagram…
What was confirmed
Verification results
Twenty-one tests passed, along with lint, TypeScript type checking, the production build, and database lint.
The 24-item limit and serialization of multiple saves worked against the authenticated database.
Disallowed sessions were excluded from islands, selectors, and conversation retrieval, and invalid selections fell back to a visible session.
With zero selections, the interface showed administration guidance rather than a fictional session.
At the cutoff, display administration and the allowlist had been applied to the target while full-history synchronization remained intact. Per-viewer public authorization and display beyond 24 sessions were outside this scope.
Basis for completion
The scope was complete when the administration screen, atomic allowlist replacement, owner-scoped row controls, and shared filtering across all three display paths were present, normal, concurrent, hidden, and zero-item cases passed, and the result was applied to the target.