internal/multiwin/ Multi-window architecture
Process-per-window. Send tab to window. Shared store across windows via SQLite WAL.
Each ShellYard window is its own OS process. The first window starts a localhost peer server; additional windows register and broadcast tab + resource events to siblings.
Why processes, not tabs
A long-running packet capture in window A doesn’t lock up window B. Window crashes are isolated. Memory pressure on one workflow doesn’t bleed into the others.
Concurrency
SQLite uses WAL with a busy_timeout, so concurrent windows can write the same store without lock contention. The peer broadcasts resource.upserted events so a connection saved in window A appears in window B’s list within a few hundred milliseconds.
Send tab to window
Right-click any tab → Send to window → pick a target. Tools and documents move cleanly. Terminals transfer their display, but the underlying SSH session keeps running in the source process — closing the source window kills the session.
Auth handoff
The first sign-in broadcasts the auth state. Sibling windows that open afterward never see the sign-in flow.