Reading automation code and checking its actual page requires moving between both. Mixing status into the same narrow area makes the current question harder to follow. Northstar gives notebook, web view and execution records separate places without requiring all three to remain open.
Define each pane by its reading task
The left pane holds cells and outputs, the middle shows the actual site and the right presents execution records and management context. Historically the right side also contained embedded AI conversation controls; the current product removed embedded CLI/model composition. Old workbench imagery must not advertise every historical feature as active.
Code execution and an expected page result are different observations. Keeping them in one workbench supports comparison without repeatedly opening new tabs. Pane placement does not replace a permission boundary. Project/account ownership belongs to execution contracts; panels make that context easier to read.
Use one bounds calculation for React and the native web view
PanelBounds computes left, right and central widths in one shared function. Collapsed panes receive zero, expanded panes use bounded widths, and insufficient web space can hide the left pane in actual layout. React CSS and WebContentsView placement should not maintain competing calculations.
A native web view is not positioned solely as an ordinary DOM child. If the visible boundary differs from the actual page region, hit coordinates and occlusion can disagree too. A shared calculation gives changes one reference. The displayed code is the core of the reviewed original layout function, not a new independently executed module or whole-screen verification.
Explore the implementation
Core of the reviewed original layout function
let left = p.leftCollapsed ? 0 : Math.min(p.notebookWidth || 420, Math.max(320, width - 300));
const right = p.rightCollapsed ? 0 : Math.min(p.panelWidth, Math.max(320, width - 300));
if (left && width - left - right < 260) left = 0;
return { left, right, browser: Math.max(1, width - left - right) };Hiding a pane should not terminate execution
Notebook and right-panel toggles change layout preferences. NotebookBusy and isRunning indicators remain separate. Visibility and executor lifetime do not share one boolean. Reopening a hidden pane to read progress differs from stopping the work.
That matters especially on a small screen. Closing a pane to enlarge results must not unexpectedly cancel execution. Conversely, continued work behind a hidden pane needs an outside activity indicator. The layout should make it possible to organize space without confusing that action with a change to business effects or execution authority.
Make resizing readable through pointer and keyboard paths
The notebook separator uses pointer capture for dragging and arrow keys for twenty-pixel width changes. The right pane also clamps pointer position against remaining web space. Shared calculation connects preferred stored widths to bounds actually possible in the current window.
Historical workbench documentation retains project/profile preferences and scoped checks for narrow windows, execution-time closing and output restoration. It does not certify every screen size or assistive technology. HTML/JS cell output remains text rather than active execution. A readable pane should not be mistaken for an unrestricted web-output runtime; visibility and execution capability are different choices.
Remembered layout reduces preparation for the next task
Even when a small window cannot honor stored widths exactly, it should leave room to inspect the web result. Remembering a preference and calculating a currently feasible layout belong together. One default should not require every person to keep three panes open at all times.
This account reads code and historical checks without a new panel-drag experiment. Original notebooks, logins and other projects remain untouched. The shared status-copy module is another synthetic example. The intended workbench offers recoverable places and context for comparing code, target and outcome, rather than merely more columns. Collapsing a view should not collapse the meaning of the work.