Deferred: Concurrency & Editing Safety¶
Explicitly not alpha scope. Real-time collaborative editing (live cursors, simultaneous edits) is out of scope for this round and not designed for; the only alpha requirement is that the schema and Change model don't preclude adding locking later. Deferred means not built now and not required for the alpha to ship — not thin or unexamined; this page is the planning reference for when the work is picked up.
Not alpha scope, and why¶
The only requirement for alpha is that the schema and Change model (The Change Model) don't preclude adding this later. Full real-time collaborative editing is out of scope entirely, not merely deferred: the added complexity — a live WebSocket feed of state, undo/redo semantics across concurrent editors — isn't worth taking on now, though it's a plausible future direction, not ruled out forever.
The eventual model: lock, checkout, heartbeat¶
A lock/checkout model, one editor at a time per locked unit — whether that unit is a Project's base or a specific fork is the open question below. Held via an active heartbeat, not a passive disconnect signal — an abrupt disconnect (a closed laptop, a crashed browser, a dead network) won't reliably fire an unload event, so the lock is held via a live heartbeat (a WebSocket ping is the working example) and released automatically once the heartbeat stops, never on a graceful-close signal alone, which an abrupt disconnect never sends.
A separate, explicit preview mode (read-only, doesn't acquire the lock) distinct from edit mode (acquires it), so someone can look at a Project without blocking whoever's working on it. The shape is decided; none of it is built.
How this relates to forking — a tension worth naming plainly¶
Every fork already gives its author an isolated working copy, and the fork model already has a confidence-scored conflict-resolution and mandatory-approval mechanism for reconciling forks that have diverged (Fork, Rebase & Conflict Resolution). So if forking already prevents anyone's edits from being silently lost, why does a UI-level lock also exist?
The two mechanisms solve different costs. Forking solves data safety between separate forks:
two people working their own drafts of the same Project can't destroy each other's work, because the
second to commit finds currentVersionId already moved and must rebase
(Identity, Versions & Schema Versioning → Commit rule);
whatever happens gets reconciled, worst case with manual review. It says nothing about two people
saving into the same fork, which is a separate open question
(The Change Model) and a second reason the lock is
wanted. It does not solve UX confusion: two people unknowingly working on diverging forks of the
same Project, only discovering the conflict at commit time, after real effort has gone into both. The
lock is a product decision to prevent that confusion from happening at all, for now — not a
technical requirement the data model imposes; the data model could support genuinely concurrent
forking without any lock. Worth keeping these separate explicitly, so a future revisit doesn't confuse
"the data model requires this" (it doesn't) with "the product experience currently wants this" (it
might, deliberately, while BSR is a single point of contact rather than a team working in parallel).
Risks¶
- The lock/checkout model may prove too restrictive for how BSR actually works — two people on their side legitimately wanting to work on different Scenes of the same Project at once. Not knowable until real usage.
Open questions¶
- The exact heartbeat interval and stale-lock timeout — neither chosen.
- Where the lock lives — its own table versus a column on the Project row.
- How lock contention surfaces in the UI when someone else holds it: a wait screen, a request-access flow, an automatic drop into preview mode.
- Whether the lock scopes to a Project's base or to a specific fork. A lock over the wrong altitude either blocks legitimate parallel forking that would be perfectly safe, or does nothing to prevent the confusion it exists to prevent. Decide once the fork model is more concrete, not before.