Proposal: vertical (stacked) split for the right Sidebar

[DevRishii]

Summary

The right Sidebar's two-pane split is horizontal only today: two panes side by side, divided by a vertical divider. This proposes allowing the same two panes to be stacked vertically (top/bottom) as well, for content that reads better at full column width.

Default behavior stays unchanged — the strip's split control still splits to the right. Vertical split would be opt-in per action and persisted like any other layout.

Motivation

Many right-Sidebar tabs are wide by nature (documents, code, file trees, browser pages). With the two-pane limit and a ~400px column, a side-by-side split leaves each pane too narrow for them, while a stacked split keeps full width and uses vertical space that is usually abundant. Editors commonly offer both orientations for the same reason.

Proposed behavior

• Right-click a docked tab → Split pane vertically: wraps the clicked pane in a column split and seeds the new bottom pane with the same default page the horizontal split would seed.
• The two-pane budget, pane resizing, focus, empty-pane merging, default-page seeding, and reload persistence keep working.
• The room rule becomes per axis: a side-by-side split checks width; a stacked split checks height.
• Public API grows one optional parameter: ctx.sidebarRight.split(paneId?, axis?) with axis: 'row' | 'column' (default 'row'), and planSplitPane(..., axis?) / DockController.splitPane(paneId?, axis?) mirror it.
• Saved-layout validation accepts a two-pane root split on either axis; all other invariants (two panes, two children, sizes sum to one, docked root) are unchanged.

Implementation status

I have a working implementation on a fork; it is not submitted as a PR (upstream pull requests are disabled).

• Branch: https://github.com/DevRishii/deepseek-harness/tree/feat/sidebar-vertical-split
• Diff: master...DevRishii:feat/sidebar-vertical-split
• Commit: a1054ff

Touched packages, all client-side:

• packages/client/ui-dockkit — DockLayout renders a root split on either axis (Grid rows/columns, rotated divider, per-axis empty-pane and float placement); planner/controller take an optional axis.
• packages/client/ui-sidebar-right — per-axis split intent and room rule, the tab-menu action, saved-layout validation, fullscreen chrome/inset selectors for stacked panes, all 8 locale dictionaries, and the bilingual READMEs.

Testing done

Focused suites against the sources (Vitest + jsdom): 7 files / 193 tests passing, including new tests for column-axis planning, controller behavior, rendered stacked DOM, store action, stacked-layout restore, and the per-axis room rule. Translation-pairing records for both README pairs were re-recorded and verified.

Caveat: the repository's full lane (pnpm install && pnpm run test:gui, typecheck, test:web, build) was not run in my environment; I would run it before an actual PR.

Open questions for maintainers

1. Is “two horizontal panes” an intentional product rule (e.g. for presentation/resize reasons), or just the current first cut? If intentional, is a vertical orientation still acceptable as an opt-in action?
2. Would design prefer the orientation exposed in the tab menu (current implementation), as a second chrome control beside the split button, or as a choice on the split control itself?
3. Should vertical drag-and-drop zones be enabled too, or is menu-only enough for a first version?
4. If external contributions become possible (PRs or a patch exchange), I am happy to adjust to the preferred shape and run the full checks.

Thanks — feedback on the product rule is especially welcome before I invest further.