One long reservation should not stall every project, but two queues must not run conflicting work in the same project. I separated short record serialization from occupancy of the actual project. The lane stays owned through final persistence, making the point at which another execution may begin explicit.
Reservation serialization and project occupancy have different jobs
ProjectJobs links metadata promises by reservation identity, ordering operations such as cancellation and claim for one record. Project lanes retain ownership by workspace, preventing overlapping executions there. Record ordering and project occupancy are not represented by one global busy value.
Long dispatch runs outside the short record lock. Unrelated record activity therefore need not wait for the entire program. The useful question is what a lock protects and for how long, rather than simply whether locking exists. A broad lock can preserve correctness while creating avoidable waiting elsewhere.
Different queues still need a shared view of one project
General reservations and the Cafe delivery queue each have internal lanes. Those alone cannot detect occupancy in the other queue. The application gives both queues a shared project claim, combining host ownership with each queue's own lane.
Availability examines active programs, notebooks, task state and unresolved results. Selecting a different visible project does not make an execution slot empty. The concern here is how queues share occupancy, beyond the separate question of retaining the correct target context. Destination and resource conflict are different boundaries.
Retain occupancy while final state is still being saved
Returning from dispatch does not immediately release the project. Final state, run identity and errors pass through their persistence path before the owned lane is released in finally. Another operation should not enter the same project while execution and retained records are still settling.
Other projects have independent lanes, so that waiting need not serialize them all. This is not a benchmark showing every workflow is fast. The structural aim is to prevent one project's occupancy from forcing unrelated execution into the same queue, specifying permitted progress without inventing a performance percentage.
Hold persistence while allowing a peer project to progress
The existing fault test holds a general reservation's success write behind a gate. Cafe work for the same project must remain undispatched while another project progresses. Releasing the gate then permits the Cafe item. This directly examines occupancy during persistence rather than merely slowing execution.
A same-queue test also retains the second item for one project while another project finishes. These existing tests use execution stubs and files. This publication task creates no user reservations and reruns no original test. The inspected structure and historical verification retain their identified scopes.
Ownership also protects against late cleanup by an old run
Release clears a lane only when its ownership token still matches. Repeating an old release after a new claim cannot erase the new owner. Several cleanup paths can run after errors, so that boundary needs its own check.
The public lane module independently tests ownership and stop-request metadata. It does not implement persistence or the complete reservation queue. Combining original storage-fault tests with an in-memory module does not establish every operational race as solved. The example explains how the small ownership rule participates in the larger execution route.
Choose serialization by ownership rather than by a global setting
Running everything concurrently can mix inputs; serializing everything creates unnecessary waiting. Project ownership defines execution occupancy, while reservation identity defines a smaller metadata boundary. The relevant question is which execution owns what, not which screen happens to be visible.
Business applications face a similar problem when document editing is confused with a company-wide lock. Necessary waiting should remain without stalling unrelated work. The design begins with explaining who owns the execution place until when, rather than treating parallel execution as a feature name sufficient by itself.