Unified stage layout: one workspace of lanes, rows and a session pool

ARCHITECTURE.md

@@ -750,7 +750,7 @@ accTitle: Why does streaming output not save the whole workspace?
 accDescr: Layout changes and agent output update different stores. Only workspace metadata goes through workspace persistence.
 %% scope: Renderer data flow · persisted layout versus live session state
 subgraph Layout["Workspace changes"]
-        Action["Move a pane / change a tab"] -->|updates placement| Metadata["Workspace metadata"]
+        Action["Move a lane / switch project"] -->|updates placement| Metadata["Workspace metadata"]
         Metadata -->|persists via preload| Saved[("Saved workspace")]
     end
     subgraph Live["Live agent output"]
@@ -1483,49 +1483,54 @@ Closing a window while the app continues can transfer its sessions to a survivin
 
 <!-- architecture-diagram: workspace-model -->
 
-[![How does the grid refer to its sessions?](docs/architecture/diagrams/workspace-model.svg)](docs/architecture/diagrams/workspace-model.svg)
+[![How does the stage refer to its sessions?](docs/architecture/diagrams/workspace-model.svg)](docs/architecture/diagrams/workspace-model.svg)
 
-A split contains two tiles; a leaf refers to session metadata by ID. Rearranging tiles changes placement without making the layout own a provider process.
+A lane refers to session metadata by ID; a session's PROJECT is a field on its own row. Rearranging lanes changes placement without making the layout own a provider process.
 
 <details>
 <summary>Mermaid source</summary>
 
 ```text
 classDiagram
-accTitle: How does the grid refer to its sessions?
-accDescr: A split contains two tiles; a leaf refers to session metadata by ID. Rearranging tiles changes placement without making the layout own a provider process.
-%% scope: Grid layout · selected type relationships, not runtime class inheritance
+accTitle: How does the stage refer to its sessions?
+accDescr: A lane refers to session metadata by ID; a session's project is a field on its own row. Rearranging lanes changes placement without making the layout own a provider process.
+%% scope: Stage layout · selected type relationships, not runtime class inheritance
 direction LR
-    class Tab
-    class TileNode {
-        <<union>>
+    class WorkspaceState
+    class Stage {
+        lanes
+        rows
+        focusedLane
     }
-    class TileLeaf {
-        sessionId
-    }
-    class TileSplit {
-        direction
-        ratio
+    class DispatchLane {
+        selectedSessionId
     }
     class SessionMeta {
         kind
         providerRuntime
         cwd
+        projectId
+        joinedAt
+    }
+    class Project {
+        id
+        title
     }
-    Tab *-- TileNode : root
-    TileNode <|-- TileLeaf : leaf variant
-    TileNode <|-- TileSplit : split variant
-    TileSplit "1" *-- "2" TileNode : children
-    TileLeaf ..> SessionMeta : references sessionId
+    WorkspaceState *-- Stage
+    WorkspaceState *-- SessionMeta : sessions by ID
+    WorkspaceState *-- Project : projects
+    Stage *-- DispatchLane : row-major
+    DispatchLane ..> SessionMeta : references sessionId
+    SessionMeta ..> Project : projectId names a project
 ```
 
 </details>
 
-`TileNode` is a TypeScript discriminated union: a leaf references a session, while a split contains child tiles. The class notation here summarizes that data structure. Each split has exactly two children, either of which can be a leaf or another split. A split ratio is normalized to the allowed range; a tab's focused session must be an actual leaf.
+A session is OWNED iff its `projectId` names a project that exists; unowned rows are dropped at the read boundary. Lane selections, pins and the active project are pointers, never ownership — a stale pointer must not keep a session alive or bring one back. A project exists while at least one session names it and is removed by the commit that takes its last session.
 
-Grid placement, Dispatch Mode lanes, pinning, detached sessions, and buried sessions describe visibility and organization. They do not by themselves terminate a backend. Dispatch lanes are a flat ordered sequence with explicit row structure; row weights and scope are normalized separately. Empty lanes remain meaningful and are not automatically populated from the session pool.
+Lane placement, pinning and pool parking describe visibility and organization. They do not by themselves terminate a backend. Lanes are a flat row-major sequence with explicit row structure; row weights and per-row project bindings are normalized separately. Empty lanes remain meaningful and are not automatically populated from the session pool, and an occupied lane is never displaced by a spawn (context-places).
 
-Related-session selection can display a child in a physical grid leaf owned by another session. Linked terminal parentage is a one-level association with cascading close behavior. Orchestration parent/root/run metadata is a separate relationship and should not be reused as the linked-terminal tree.
+Linked terminal parentage is a one-level association with cascading close behavior. Orchestration parent/root/run metadata is a separate relationship and should not be reused as the linked-terminal tree.
 
 #### 6.2.3 Recovery preserves the workspace shell
 
@@ -3074,12 +3079,11 @@ Sources: [Vitest configuration](vitest.config.ts), [live configuration](vitest.l
 | Application session | Stable Agent Code identity associated with workspace metadata and, when active, a managed backend |
 | Session run | One backend execution attempt, distinguished from the stable application session |
 | Native session identity | Provider-owned conversation identity used to locate/resume native history |
-| Pane / tile | A visible workspace placement; it is not itself a provider process |
-| Project tab | A workspace membership boundary that can differ from another tab using the same directory |
-| Dispatch Mode | Workspace presentation using explicitly ordered agent lanes and independent scope/focus |
+| Stage | The one workspace layout: rows of lanes beside the agent index. Each lane shows at most one session |
+| Lane | A visible slot on the stage; selecting a session into it shows that session. It is not itself a provider process |
+| Pool | Every session a project owns. A session not in any lane is still in the pool, alive or hibernated |
+| Project | A workspace membership boundary (`projectId` on each session) that can differ from another project using the same directory |
 | Hibernated session | Retained session metadata whose backend is intentionally absent until wake |
-| Buried session | Hidden retained session placement; a live backend can continue running |
-| Detached session | Session associated with the workspace/project but not placed in the ordinary grid |
 | Provider runtime flavor | The execution mechanism for a provider, such as structured OpenCode versus OpenCode terminal |
 | PTY | Pseudoterminal connecting the application to a native interactive process |
 | tmux attachment | A PTY connection to a separately managed persistent shell session |

README.md

@@ -82,13 +82,13 @@ a running session can move mid-task among Claude Code, Codex, and OpenCode.
 - **Persistent terminals** — tmux-backed shells that survive UI reloads.
 - **Built-in MCP + agent control** — orchestration lets a parent create and
   coordinate real Agent Code children. The independently configurable Agent
-  Management MCP can inventory every grid, Dispatch, and buried agent in the
-  caller's project, expose transcript/activity evidence, read bounded outputs,
-  and send follow-ups. Destructive close is restricted to an explicit current
+  Management MCP can inventory every agent in the caller's project — on a
+  lane or parked in the pool — expose transcript/activity evidence, read
+  bounded outputs, and send follow-ups. Destructive close is restricted to an explicit current
   user request and refuses self-close or multi-session cascades.
 
   <p align="center">
-    <img src="docs/screenshots/orchestration.png" alt="Agent Code Dispatch sidebar with orchestration MCP tool calls (send_prompt, wait_agents, read_agent, close_run) running in a live session" />
+    <img src="docs/screenshots/orchestration.png" alt="Agent Code agent index with orchestration MCP tool calls (send_prompt, wait_agents, read_agent, close_run) running in a live session" />
   </p>
 
 - **TLDR peek** — enable **TLDR MCP** for an agent, then hold **Cmd+L** to

docs/command-style.md

@@ -5,7 +5,7 @@ This repo treats command titles as stable names, not as descriptions of the curr
 ## Rules
 
 1. Use a stable noun phrase for toggles and modes.
-   Examples: `Reader Mode`, `Spotlight`, `Tiled Tabs`, `Dangerous Agents`, `Git Bar`.
+   Examples: `Reader Mode`, `Spotlight`, `Auto-follow All Visible Agents`, `Git Bar`.
 
 2. Do not encode state changes into the title.
    Avoid: `Toggle`, `Enable`, `Disable`, `Enter`, `Exit`, `Turn On`, `Turn Off`.
@@ -14,7 +14,7 @@ This repo treats command titles as stable names, not as descriptions of the curr
    Use short badges like `On`, `Off`, `Claude`, `Codex`, `Active`.
 
 4. Use imperative verbs for one-shot actions.
-   Examples: `Open Settings`, `Copy Last Response`, `Normalize Layout`, `Reload Agent`.
+   Examples: `Open Settings`, `Copy Last Response`, `Close Focused Session`, `Reload Agent`.
 
 5. Use `New X` for creation commands.
    Examples: `New Tab`, `New Agent`, `New Terminal Right`.