A user may start work and then look at another project. If execution repeatedly reads the window's current tab, that movement silently changes the task's destination. I separated visible selection from the project execution cursor so those meanings could remain distinct.

Current has two different meanings

The window's current tab is where the person is looking. The execution's current tab is where its next read or input belongs. Assuming they always agree lets background work and human navigation redirect one another. One shared variable cannot adequately describe both states.

ProjectCursor binds workspace, profile and tab. A project-host proxy supplies those values to that execution rather than creating a second real browser host. Actual sessions and tab storage remain with the existing host. Separating context does not require duplicating the whole screen or session.

Selection first updates the execution cursor

Project-host selection checks project membership, updates cursor tab and profile, wakes the tab and persists corresponding project memory. That does not inherently switch the person's visible project.

Actual screen selection is conditional on an interactive route and the same visible project. Background work must not automatically steal focus as a convenience. Management actions requiring visible feedback and executions continuing quietly have different interface responsibilities.

Method receivers matter as much as property values

Overriding a few properties while binding every method to the original host could make internal this read the visible project again. The current proxy binds its scoped method set to the proxy. Context concerns actual method execution as well as returned properties.

This is not operating-system process isolation or a security sandbox. It separates execution context inside one host. New methods still require scope and caller review; the proxy cannot make every future feature correct automatically. Even this small abstraction has a maintenance contract.

Do not report one cursor as a different requested tab

External context handling rejects an explicit target tab differing from the current execution cursor. An execution on A cannot return A's information as though it answered a request for B.

The integration test checks refusal of B, retention of A and correct responses for A and an unspecified read. It reports the conflict instead of silently switching state to make the request appear valid. Identity of a read reply matters as much as identity of an input target.

Do not infer account or outcome from visible selection

One project can contain tabs for different accounts. Retaining execution context does not establish live authentication. Stored account labels, actual page identity and the original work target still need comparison.

I read the current project proxy, context handler and associated test rather than running background work or switching a user's window for review. Screen navigation, saved-program execution and explicit external context can enter through different routes. This is a record of checked contracts, not a new exhaustive test of every route.

The distinction applies to business tools too

Opening an owner's dashboard should not change the record an employee process is handling. What someone views and what work executes are different states. I made that distinction explicit in browser execution too. Outcome inspection should compare the project and tab retained with the execution record instead of inferring ownership from whichever project happens to be visible now.

A stable execution destination lets a person inspect other material conveniently. Running-work status, cancellation scope and outcome inspection still need matching boundaries. Describing the cursor is less useful than explaining which actual calls it controls and where its responsibility ends.