feat: track explicit new-pane visual-stability follow-up work

## Problem Issue #100 is the user-visible bug report, but the follow-up work splits into multiple layout families, topology classes, and policy decisions. Tracking it as one flat issue would hide the real dependency graph. ## Proposed solution Use this issue as the tracker for the explicit managed `new-pane` visual-stability follow-up work. The order below is the intended topological order, not just a loose checklist. ### Groundwork - [ ] #101 add creation-time `new-pane` visual-stability acceptance tests - [ ] #102 add shared primitives for layout-aware managed `new-pane` targeting ### First-wave local wins - [ ] #103 make `even-horizontal` birth directly into the row tail - [ ] #104 make `even-vertical` birth directly into the column tail - [ ] #105 reduce wrong-branch `master-stack` births when a stack already exists - [ ] #106 make `centered-master` birth the first side-stack pane on the correct side - [ ] #107 make `three-column` birth the first side-column pane on the correct side - [ ] #108 make `dwindle` split the recursive tail directly - [ ] #109 make `spiral` leaf-node phases use direct recursive-tail births ### Harder parity and recursive churn - [ ] #110 reduce `centered-master` parity-transition churn - [ ] #111 reduce `three-column` parity-transition churn - [ ] #112 reduce `master-stack` all-masters-to-stack transition churn when `nmaster > 1` - [ ] #113 reduce `spiral` node-leaf subtree churn ### Policy and hard-boundary cases - [ ] #114 define mirrored `master-stack` `1 -> 2` policy under append-order constraints - [ ] #115 define and mitigate unavoidable global retiles in `grid` - [ ] #116 define `monocle` `new-pane` zoom and focus behavior - [ ] #117 handle min-size failures in layout-aware `new-pane` paths ### Documentation closeout - [ ] #118 document residual `new-pane` flashing limitations in the README ## Context All of these issues are follow-ups to #100. Their shapes were split out because different layouts have different residual topology classes: - exact local split - local equalization - local role shift - global reshape - mirrored order conflict - zoom/focus snap - min-size failure ## Alternatives considered - Keep everything under #100. That makes it hard for agents to tackle scoped pieces safely. - Track one issue per layout only. That mixes easy local wins with hard policy edges and global-reshape cases.

barrettruth commented

2026-04-28 01:58:05 +00:00

Problem

Issue #100 is the user-visible bug report, but the follow-up work splits into multiple layout families, topology classes, and policy decisions. Tracking it as one flat issue would hide the real dependency graph.

Proposed solution

Use this issue as the tracker for the explicit managed new-pane visual-stability follow-up work. The order below is the intended topological order, not just a loose checklist.

Groundwork

#101 add creation-time new-pane visual-stability acceptance tests
#102 add shared primitives for layout-aware managed new-pane targeting

First-wave local wins

#103 make even-horizontal birth directly into the row tail
#104 make even-vertical birth directly into the column tail
#105 reduce wrong-branch master-stack births when a stack already exists
#106 make centered-master birth the first side-stack pane on the correct side
#107 make three-column birth the first side-column pane on the correct side
#108 make dwindle split the recursive tail directly
#109 make spiral leaf-node phases use direct recursive-tail births

Harder parity and recursive churn

#110 reduce centered-master parity-transition churn
#111 reduce three-column parity-transition churn
#112 reduce master-stack all-masters-to-stack transition churn when nmaster > 1
#113 reduce spiral node-leaf subtree churn

Policy and hard-boundary cases

#114 define mirrored master-stack 1 -> 2 policy under append-order constraints
#115 define and mitigate unavoidable global retiles in grid
#116 define monocle new-pane zoom and focus behavior
#117 handle min-size failures in layout-aware new-pane paths

Documentation closeout

#118 document residual new-pane flashing limitations in the README

Context

All of these issues are follow-ups to #100. Their shapes were split out because different layouts have different residual topology classes:

exact local split
local equalization
local role shift
global reshape
mirrored order conflict
zoom/focus snap
min-size failure

Alternatives considered

Keep everything under #100. That makes it hard for agents to tackle scoped pieces safely.
Track one issue per layout only. That mixes easy local wins with hard policy edges and global-reshape cases.

Rows
Columns

feat: track explicit new-pane visual-stability follow-up work #119