Working by project can sound like grouping tabs and files. But one project waiting for a reservation while another runs Jupyter needs more than different folder names. I reorganized Northstar so a project is a boundary for actual execution and retained state.
One visible window can contain different jobs
A single browser window should allow different projects to continue working in their own tabs. If every run consults one globally selected project, changing the visible screen can retarget a reservation. A harmless view change for a person becomes an environment change for another job.
I therefore retain the project, profile and tab bound when execution begins. That is why the execution cursor differs from the visible selection. Reading reference material or moving to another project should not redirect background work. If the bound target disappears, the system should report that state rather than substitute another tab.
projectHost does not create another physical host
projectHost wraps one BrowserHost and supplies execution-side workspace, profile and active-tab values from a cursor. Visible-tab queries are narrowed to that project, and target-sensitive operations such as creation, selection and stopping enforce the same scope. Separating projects does not require cloning every browser session.
The current code also distinguishes interactive selection from background selection. An interactive run can update the visible selection only under the condition involving the project already visible to the person. That detail is why I reread the current file instead of treating an old description as the current behavior. The cursor principle and the display conditions need to be checked together.
Bind code and environment as well as tabs
Separating tabs is insufficient if Python runs share a writable environment. One project's package replacement or live variables could then affect another workflow. A project has its own virtual environment, local packages, Jupyter kernel and notebook assets. Reading shared installed packages is different from sharing writable state and a live process.
Plugins and skills are discoverable through a common catalog while settings and local definitions remain project-specific. ProjectProgramLibrary copies a needed definition on first use and skips an existing manifest rather than overwriting that project's version after a shared change. Reusing a program is different from forcing every project to remain in the same edited state.
Separate within-project order from cross-project concurrency
Scheduling uses a project lane so preparation and execution do not overlap inside that project, while different projects can run separately. A lock serializing one reservation's metadata must also be distinguished from the lifetime of its actual program execution. One giant lock would defeat the purpose of project separation.
ProjectLanes retains a symbol owner and releases only its own claim. Its callers arrange release in finally even when execution or persistence fails. This is not a feature established merely by creating separate folders. Targets, state, resources and ownership mechanisms have to be connected in the implementation.
Verification should exercise the execution boundary
The historical project-isolation verification ran two owned test projects at the same time and checked each tab's input and outcome. It compared same-named variables and different Python prefixes and checked that stopping one kernel did not stop the other workflow. That is different from newly completing two public reservations on external services.
For this article I reread that report and the current implementation. I did not interrupt operational accounts or existing kernels. Historical test counts are not presented as tests rerun today. Explaining an execution boundary requires both the reason for the check and the environment in which it was actually established.
Design a workbench around actual shared resources
For automation across locations, brands or responsibilities, I would first list what should be shared and what must remain separate. Common functions need not be copied repeatedly, while inputs, results, edited definitions and execution schedules should not become mixed. The resource relationships matter more than the project label.
Sharing an account session means logout and external-service limits can still affect other projects. Execution separation is not whole-computer isolation or an authentication system. The next article narrows that shared boundary. The workbench is intended to let different jobs continue while keeping ownership of each one understandable.