feat: one-click side-by-side sessions — surface the Chat Deck as the canonical split

[aarontrowbridge]

Important

Problem — Side-by-side session viewing already exists twice: the Chat Deck (many panes in one editor tab, drag-to-edge split, persisted layout, on the extension's mainline) and SplitFrame v2 (drag a titlebar tab onto an edge rail, in the fork app). But neither has a discoverable entry point — the deck is a command-palette secret, and the in-app split is drag-gesture-only, caps at one right pane, and never persists. Users ask for "split panel with sessions side by side" because they can't find what's already there.
Approach — Make the Chat Deck the canonical split surface and give it one-click entries. (1) A "Split session side by side" command plus editor-title action that reveals the deck seeded with two panes: active session left, most-recent other session right. (2) An "open alongside" action on the app's sessions rail and titlebar tab strip, carried over the existing workbench bridge to the same two-pane deck reveal. (3) A visible split control on the deck's sash strip, so splitting is discoverable once the deck is open — no drag gesture required.
Scope — in: deck reveal seeded with a two-pane layout; the split command + editor-title button; one new bridge verb; app-side rail and tab-strip actions. out: unifying SplitFrame v2 onto the deck state machine (separate design pass); N-pane persistence for the in-app split; touch-layout work.
Assumptions — The deck's state machine can be seeded with a two-group layout at reveal; the bridge's message allowlist can grow one verb without a compat break; the app-side actions ship with the fork app's release train, so the feature lands in two repo slices that can merge independently.

Acceptance Criteria

• A palette command "Amicode: Split session side by side" reveals the Chat Deck with two pane groups: the active session left, the most recent other session right
• The sessions rail and the titlebar tab strip offer an "open alongside" action, and invoking it produces the same two-pane reveal
• The deck shows a visible split affordance on its sash strip (not drag-only entry)
• The revealed two-pane layout persists across VS Code reload through the deck's existing persistence path
• Drag-to-edge split and tab drag still work (no regression in deck interaction tests)
• Bridge replies still route per-pane by tab tag with the new verb in play — no cross-pane bleed

Testing Decisions

Extend the deck model's existing unit suite (the split/move/resize state machine) with seeded-reveal coverage; extend the bridge allowlist tests for the new verb. No new suites — this rides the existing deck and bridge test surfaces.

Key Decisions

• The deck (N-group, persisted, extension-side) is the canonical split surface. SplitFrame v2 stays the lightweight in-app drag idiom, not the substrate to grow.
• Seeded reveal fills the right pane with the most recent other session rather than an empty draft — a dead right pane teaches nothing.

Constraints & Invariants

• Panes are never reparented — group ordering stays CSS-based; a dragged pane pays exactly one iframe reload.
• Inspector and run-status broadcast semantics stay untouched: broadcast-to-all-panes with per-pane buffering.
• The in-app recursion guard (pane-in-pane) must survive the new entry points.

Prior Art

Deck modules: deck_panel, the deck shell webview bundle, and the deck state machine deck/model. Extension bridge: chat_bridge (kind allowlist + per-pane tab tagging). App side: the sessions rail (workbench-panel), titlebar-tab-strip, the tab model (context/tabs), and the workbench bridge verbs (utils/pane-bridge). SplitFrame v2 (split-frame, context/split) as the drag-idiom reference.

Source

User request, live session 2026-10-01 — "split panel with sessions side by side in amicode". Precedent: no open issue covers this (searched split/deck/pane, 2026-10-01).

Notes

Exploration on 2026-10-01 found both split implementations already present — the deck on the extension mainline, SplitFrame v2 on a fork app branch. The app-side rail/tab actions live in the fork app repo; decompose into a fork-side slice at pickup if release-train coupling matters. Unifying the two split models is deliberately out of scope — it wants its own design pass.